I don't see the authors' objection that SICP focuses on domain knowledge
too much a valid objection, at least nowadays.|
As margins on hardware and software fall,
all that computer companies have left is *consulting services*
and *domain knowledge* is what makes consultants and
consulting organizations valuable.
To make students ready for this they should be thrown some rich, realistic,
and challenging *problems from specific domains*, like the classics
in SICP and PAIP...or...
The telecommunications domain which
has several DSL's and even conferences devoted to it,
comes to mind as a good new source of new domain problems
to replace the toy problems, examples, and
games that textbooks traditionally rely on
Furthermore, consulting is a niche through which non-mainstream languages
(Haskell, Scheme, DSL's) and their features can slip into the mainstream.
An expert recommending a language for a specialized purpose
Little Languages, Little Maintenance
), is going to have more chance than
someone advocating the language for everyday use in some major bastion of
conservatism like data processing or systems programming.
Capturing domain knowledge is the best reason I can see to use DSL's.
The norm is for a consulting organization to be valuable
because of its human capital, i.e. the knowledge resides in its employees'
heads not the organization itself.
I've seen consulting organizations (tech support departments also)
try to capture domain knowledge by setting up *knowledge bases*,
but these just grow and grow and grow old, messy, irrelevant, and finally die,
*mere recording is not enough*,
the domain knowledge must reside in *a tool that is continuously being
used to solve problems in the domain*: A Domain Specific Language.
Users will adapt the tool to its changing context of use.
(Whoops. I seemed to have veered from the subject. Sorry. :)
HTDP and SICP seem more like complements than substitutes to me,
I love HTDP's recipe-cookbook detailed descriptions of how to write programs.
I think many older people enjoy SICP because they've already seen these concepts described in all their full blown complexity.
Build Scheme DSL's with modular monadic action semantics.
Build interpreters from standard language modules first,
then use partial evaluation to derive compilers.
Combine and reuse language features from different programming paradigms in these interpreters. This should break students fixation on syntax.
Embed Scheme in Java using Java syntax to disorient the students a little bit and get them to ask some hard meta-questions like: "What is Java?" and "What is Scheme?" Felleissen's book and Wadler's Featherweight Java provide good hints on how to do this.
Make Scheme relevant to current employment market by calling it an "advanced Java feature."
Add language features to Scheme like strong typing, lazy evaluation,
and parametric polymorphism in a modular fashion.
(Sch(eme)+(H)askell = Schaskell
Code smells --> refactoring
Unit testing + refactoring = meaning preserving program transformations
Refactoring as a form of program understanding, simplification,
elimination of redundancy, and readability.
Two student team projects using extreme programming.