I agree; I can't imagine teaching a class with either of those
languages. I can't see how anyone but an expert can guess how his C++
program is going to behave, and Perl is only clear and easy to
understand for those with prior experience with sed, awk, shell, etc.
> Significant features include:
> * It's interpreted
> * It uses a syntax-directed editor -- the student cannot enter a
> syntactically-incorrect program
He cannot enter one at all? Or does it just become very obvious by
bizarre indentation? I can't live without my Emacs modes for any of
the languages I use. Syntax-directed editors are a must.
> * No type declarations are needed -- context determines type
As in Perl? I like the Lisp/Scheme/Dylan/Python approach; variables
aren't typed, but objects are. A context-determines-type situation,
while often useful for semantic density, can confuse someone reading
someone else's code.
> * It uses unlimited precision, so there is no need to discuss the
> problems of word size or machine representation (what other
> language will give the correct answer to "write 2**10001" in
> about 1 second?)
Off the top of my head, Python (one implementation freely available),
Lisp (CLISP, GCL, FEEL, XLISP freely available), and Scheme (scm,
vscm, elk, STk and more freely available). It also takes much less
than one second real time for most of those to give the answer on my
486dx33:
winners:
STk: 0.23 sec
clisp: 0.35 sec
scm: 0.47 sec
elk: 0.57 sec
vscm: 0.65 sec
losers:
python: 2.28 sec (only .24s to calculate; like GCL, bad printer)
GCL: 12.00 sec (it only takes .10s to calculate; GCL's
bignum printer is a big loser)
Please don't think I'm trying to make any claims about this
benchmark; I'm just showing the friendly readers that good bignum
performance is a fairly common thing.
> * Sets are a native data type (there are only five: numbers,
> strings, compounds (records without field names), lists, and
> tables (sort of associative arrays).
All the languages I mentioned have all those, although with all the
schemes except STk you need to use Aubrey Jaffer's excellent SLIB
add-on library to get hash tables. Er, actually, I'm not sure why
you'd want "compounds", but you could definitely simulate them easily
enough if you had to have them.
What's equally important is that, with the possible exception of
Common Lisp, all the languages I mention have an equally restrained
set of types. Just enough to get the job done, but not enough to
confuse.
>Best of all, it's free and available for Unix, Macs, MS-DOS and Atari
>STs. (Look on ftp.uu.net in languages/abc, or on ftp.cwi.nl in
Well, with all the quality freely available products out now, "free"
isn't as exciting as it should be. In addition to being free, each of
the products I mentioned has other attractive features.
Python has a rapidly expanding user base and a fairly high
signal-to-noise newsgroup. It's also a newer (sort of OO) language by
one of the creators of ABC (Guido Van Rossum). I find Python much
more readable than ABC. It also provides many of the facilities that
Perl users have come to love, like fairly low-level interfaces to the
native OS, regular expressions, "persistant" associative arrays in the
form of NDBM files, a socket interface, Tk interface, etc. Lately
I've written some projects in Python that I might previously have
coded in Perl; Python has a "cleaner" and more modular feel that lends
itself to programming larger projects. Of course, I'm still a Perl
zealot and use it almost every day.
Back to our main topic, Common Lisp is very well documented and widely
used. I don't need to list its features (and I don't have room). It
may be too much for a teaching language, but it's definitely easy to
learn and use.
Scheme is also well documented and widely used, with the added
advantage of having several modestly sized implementations available.
Both Lisp and Scheme have their own helpful newsgroups, and both are
standardized (Scheme by IEEE, and the ANSI Common Lisp standard is
close to passing). Also, STk has a very nice Tk interface; it has
two, in fact, one modelled after the standard TCL/Tk model and (a much
nicer) one that uses a CLOS/Dylan-like object oriented model.
Dr. Ousterhout must scream every time he sees Tk ported to a new
language; his goal of a single extension language (TCL) simply won't
work because of language religion. On the other hand, Tk is so
successful because everyone hates programming in X.
MIT, among others, considers Scheme to be a suitable language for
beginners, and I agree. Unfortunately, I don't get to use Scheme as
much as I would like to because the bare-bones language spec. doesn't
cover many facilities that I need in my everyday programming, like
regexs, hash tables (alists just aren't fast enough sometimes),
sockets, etc. That's both a strength and a weakness. Many
implementations supply their own versions of these facilities, so as
long as you find one that you like and stick with it, you can get by.
I thought this particularly relevant in the face of the "Tower of
Babel" thread; languages like Perl and Python are very useful
languages for Unix scripting, text manipulation, and non speed
critical programs , while a language like Scheme fits neatly into the
"learning language" pedagogical realm. Perl is the sysadmin's Common
Lisp: intricate, enjoyable, occasionally inscrutable, and full of
tricks.
-- Robert