What computer language should we teach? (203)

138 Name: w : 2006-10-19 23:34 ID:g286UoF4

Two problems here. At least.

1st. Students shouldn't be buried. It's inefficient & demoralizes 'em. This implies smallish lang, smallish ref doc, good tools, eg an IDE. Rules out trad bare editors for command line save/compile/debug/edit... cycle. The Stockholm syndrome may demand we make 'em suffer, but computing is too important for us to indulge.

2nd The lang chosen should not teach bad habits. EWD has a real point. LISP's littered with parens, APL is a terseness too far, & Forth requires simultaneous concern w/ contents of the stack & much higher level issues like getting correct information to (or from) disk. Java is so careful it's a feather pillow -- you're buried in fluff, teaching newbies bad expectations. Ditto many of the special purpose languages, eg for Web work. C's syntax is ad hoc and confusing (so's PERL), and pointer artihmetic (as in C) is a bug farm. C was built for a group who used it were the intellectual peers of Thompson and Ritchie. Few of us are, and no students can be expected to be.

3rd Don't force teachers to reinvent wheels, eg first class teaching materials. They should already be available. Algorithms are a central issue in coding, and part of teaching a first lang should be an appreciation of algorithm design and evaluation. The lang should'nt be so difficult algorithm structures and mechanisms are obscured.

MUMPS, PILOT, LOGO, are all small, but too special purpose or too unusual. APL, Prolog, Simula are too far from the mainstream to carry over much to actual problems. C++, Ada, PL/1, Smalltalk, and Java are too large for a first lang. Intercal, and other Retro-Computing Museum wierdies are only for the self-masochistic; sort of like COBOL and Fortran. Maybe as comic relief? The functional langs (and partial ones like LISP) are too exotic for a first lang, even if they are theoretically cool. Assemblers (for any CPU) are too detailed to be even partially plausible. Even MIX. One of the BASICs might be adequate (I think not VB in any form), but they tend to have some specialized feature that's been over stressed and so aren't very general purpose.

I'd suggest Modula-2. There's a truly superb text, by KN King, in print and in use for a very long time. A very large point in most teaching situations. It's a small lang (the Modula-2 Report is slim, was specified in BNF (a chance for some teaching about lesing/parsing), and has no obscure syntax like C's operators. Obfuscated code is next to impossible; students won't acquire bad habits in the Dijkstra EWD498 sense. Yet it has both pass-by-value and pass-by-reference (w/o going thru memory mapping/allocation/deallocation; none needed to make a pedagogic point), and has access to bare hardware if needed to show device register operations. Data types offered are fine to illustrate programming interaction with the gritty reality of underlying bits. Both are good things, in some intro courses and for some purposes. And it has a sort of multi-programming (the coroutine and monitor provisions) which can be a useful entry into teaching a bit about concurrency. This will help introduce processes, threads and such, if needed.

If Modula 2 is not on, perhaps as insufficiently OO, try Oberon (or Oberon 2). Full OO, just not the Java, C++, or Smalltalk way. The Oberon Report is much smaller still, for those concerned. Oberon and its relatives are almost as clear in their code (though a newbie can twist anything into a pretzel). Lots of free versions, and even an entire operating system/lang/utilities collection for Intel as well.

My favorite term-long project is to require students to read Mythical Man Month (Brooks) to inject some reality, and to translate most of the code in Software Tools (1st RatFor edition) into the lang they're learning. Groups work on diff chunks to allow the whole thing to be done in a term. With more care and thought, in two terms. When they're done, or as extra help, I have them implement/compare some of the algorithms in Sedgewick.

Name: Link:
Leave these fields empty (spam trap):
More options...
Verification: