Language Centric

Many books on 'programming' today are in fact focused solely on the task of writing code in a specific programming language. In some cases, the authors assume that the reader is already familiar with general programming concepts, and thus concentrate on presenting a reference to the new language. However, many of the texts written for novices - especially of the "Learn x in y Days" sort - take an almost Behaviorist, turn-key approach, demonstrating the mechanical process of writing and compiling a program without explaining it; as a result, the student often finishes the book with barely any more knowledge than they began it with. The very worst such books are little more than propaganda pieces for the language itself, and are often full of misinformation about programming, other languages, and even the target language itself.

OTOH, there is certainly room for books whose job it is to teach language X, and which assume that the reader is an already competent programmer. Teaching one to program, and teaching one to program in a particular language, are two different things with two different needs. -- ScottJohnson

The few books which do attempt to present basic concepts in a 'language neutral' manner, such as TheArtOfComputerProgramming or StructureAndInterpretationOfComputerPrograms, usually end up merely hand-waving away their own language prejudices without eliminating them, and are often too unfamiliar to be readily understood by students who anticipate yet another language reference book. -- JayOsako

It is hard to teach software concepts without some kind of consistent notation. BertrandMeyer tried to use EiffelLanguage as the "notation" of his OO book without mentioning it was Eiffel until the very end. That approach got mixed reviews.-- TopMind

OTOH, this device was a surprise to almost nobody; one of the "selling points" of Eiffel (according to Meyer) is that it can be used as a modelling language as well as a programming language - and unlike UML and similar, one can just feed one's Eiffel design into a compiler, add implementation code, and it will work.

While I have no experience with Eiffel, in my experience there is a lot of work needed to get from a high-level design (in UML, ad-hoc squiggles in a notebook, or whatever form) to even the most rudimentary working code; and most of the effort is not in transferring the CocktailNapkinNotation? to the programming language. A high-level Eiffel design, similarly, might take a lot of work before it is fleshed out enough to be useful code. (This is especially true since Eiffel is a very strongly, and statically, typed language, and one which inherits both Pascal's syntax and it's reluctance to accept dubious or incomplete code).

One interesting book to consider is HowToDesignPrograms. It's similar in style to SiCp (both use SchemeLanguage as the teaching language; HTDP engages in far less language evangelism), and also a bit easier for non-engineering students to grasp (many of the examples in SiCp require a working knowledge of other areas of EE or CS - lots of circuit-simulators, etc.)

Use of a real language (as opposed to PseudoCode) is probably a good thing; as that way the reader can try out the examples (and any programs they write) on a real language implementation. It might be useful to include several languages in a programming text (especially if teaching different paradigms), but that might get in the way and make the primarily material (how to program) less accessible rather than more.

-- ScottJohnson