Lambda the Ultimate

I also agree that some of the examples are perhaps too much physics-oriented for CS students. I think some other examples could have been more CS-like (of the top of my head, some algorithm classes that can be parameterized, like tree traversal, dfs vs. bfs). But finding the right examples is just so very hard.

I like examples that are difficult enough to make the students feel they are learning important new tools (and domain knowledge!) Most CS text books fail to achieve this goal, while SICP comes fairly close.

I like the distinction between structural and generative recursion in HTDP, too.

I think Evans tried to achieve some of the goals I emphasize. I am not sure how well it went it practice, though.

I too found HtDP glacially slow and loved SICP, but then I came to SICP rather than it being forced upon me, and I already had many years programming experience (including a touch of Scheme).

Drawing a 3-D maze (in the style of the original Wizardy and Bard's Tale) is an excellent example of a fun and easy recursive problem. If I'd know about recursion when I was 13 the characters in my little 3-D wouldn't have suffered from tunnel vision! The 'physics' is trivial when you only allow 90-degree turns but the structure of the drawing algorithm is still reasonably complex. And the results are way cool!

Point is, the first course is lioke boot camp -- it has to make you realize that what you like to play around with at home is not necessarily the same as what CS is about.

I claim that you can do this, and still make the course interesting and exciting. But I am known to be an uncurable optimist...

This is obviously true. But the reverse can also happen: students are sure they understand concepts they really don't, and it becomes an up hill battle to teach them the correct version.

It is easier with theory - since most students don't have prior exposure; but with programming it can be a real pain.

Teach programming languages I see quite a few students that are sure they know what a stack is and how it is different than the heap -- when in fact they don't have a clue. But someone told them something about these, when they learned about procedure calls in CS1.

Another tragic example, was an instructor that told her students not to use recursion ever "I worked 10 years in industry, and not once have I seen recursion used." If this is the result of teaching recursion in CS1, it'd be better to drop it.

(Note: None of the above is directed at HTDP; I am talking about CS1 general. HTDP is among the better options)

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 (see 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.

SICP:

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

HTDP:

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.