Choosing a programming language as a competitive tool

[Douglas Alan]

Courageous <jkraska1 at san.rr.com> writes:

> > I can pick up Lisp programs I wrote 20 years ago and read them
> > like I wrote them yesterday -- and I haven't programmed in Lisp in
> > 16 years.

> But in 20 years, the language has become something else.

Not really -- Common Lisp isn't *all* that different from ZetaLisp on
a Lisp Machine.

I agree that these days perhaps people use the term "Lisp" to mean
"Common Lisp", but I don't, and I think it is a mistake to do so.  I
use it in the traditional sense to mean a *family* of languages that
share a common core.  Common Lisp does suffer from the kitchen sink
approach.  This allows Common Lisp programmers to be more productive,
once they've read all the manuals than they might otherwise be, but it
also means they have a lot of reading to do.  Lisp is not the only
dialect of Lisp still heavily used, however.  Scheme, Emacs Lisp, T,
AutoCad Lisp, Dylan, etc., all come to mind.  Lisp doesn't have to
suffer from the kitchen sink approach.  See T or Dylan, for instance.

The lesson to learn from Common Lisp also says more about how to treat
the standard library than the language proper.  With the exception of
the package system, the language proper of Common Lisp is relatively
simple and straight-forward.  I think all the endless functions and
special forms provided are more properly thought of as part of the
standard library.  The object system (which is part of the library and
not part of the language proper) might also be considered needlessly
complex, but here the complexity comes with very distinct rewards.

When programming in Lisp, you have to learn the core concepts, which
are pretty straight forward (but maybe learning the object system is a
bit of a chore), and then you need to keep the reference manual nearby
so that when somone uses a library facility that you don't know, you
can easily look it up.  The same is true of Python too, however.
Python comes with a big library and the manual set is bigger than the
Common Lisp manual, though a typical Python program is most likely to
make use of less of the library.

> Pick up Guy Steele's seminal text on the subject and get swarmed in
> linguistic forms, many completely duplicative.  This comparison to
> Perl is apropos, because Perl is much the same way: there's always
> more than one way to do it.

Well, I suppose there is some point of similarity, but I still don't
feel the comparison is really justified.  Comparing Common Lisp to
PL/1 or Algol68 or Ada would be more appropriate.  The profusion of
duplicative syntactic forms in Perl is a minor annoyance compared to
its much more serious problem - the fact that the core semantics of
the language are completely wack.  Scalar contexts versus list context
is just stupid.  "Thingies" -- yuck.  All this implicit stuff
involving $_, etc., is awful.  The fact that putting a list inside a
list, for intance, merges the lists rather than using containment.
Ugh!  And to get around the problem (which you just couldn't do for
many years) you have to use "references" which amount to pointers.
Pointers and all their headaches and complexities in a supposedly high
level language?  Perl is just insane and that's its biggest problem.
Common Lisp may be flawed, but it isn't insane.

> > Once you get used to Lisp's syntax, it becomes very natural.

> I like Lisp syntax, although I hate the way that most old time Lisp
> programmers indent.

How do most old-timers indent compared to young upstarts?

|>oug