* John Ousterhout
| The reason for this is the difference in typing, as I explained in the
| white paper. A given language embodies a particular style of typing,
| which can range from very strongly typed to totally untyped.
I get the impression that John Ousterhout does not understand what "dynamic
typing" means. "untyped" is recurring in his articles and his paper.
apparently, the concept that an object has type information, not the
variable that holds it, is hard to grasp for many programmers in the C
tradition. yet, unions with type tags are common. now, of course, a C
programmer would shudder at the very idea of using a union with a type tag,
so let's just say that this is well optimized in Lisp implementations,
often with support from the hardware. (yes, CPU's _do_ have instructions
that C compilers don't use.)
| Let's take Lisp as an example. I think that Lisp falls somewhere between
| scripting and system programming. Many of you have suggested that it is
| an ideal language for both system programming and scripting, but I think
| that it isn't really very good for either. In fact I suspect that this
| may be why Lisp hasn't been used much for practical programming.
there are many reasons why Lisp has not become popular. they have all been
hashed out quite extensively over the years. yours is totally new. it is
safe to say that with the criticism presented to you that your distinction
between scripting and systems programming language is artificial, the fact
that you're the first to find this reason for Lisp's lack of use is
actually an argument _against_ your (artificial) distinction. or proof of
incredibly sloppy thinking on your part. perhaps both.
| Lisp isn't a good system programming language because it's too hard to
| write efficient programs in it and it doesn't provide good low-level
| access to machine facilities.
I have criticized the use of "Lisp per se" in comp.lang.lisp, as it seems
that "Lisp" means some sort of proto-Lisp to many people, including you.
since there is no such language, any discussion of Lisp that fails to be
precise in which Lisp it discusses is literally devoid of meaning. that
you draw wide-ranging conclusions about an unspecific language is perhaps
significant, perhaps not. in either case, it is disconcerting that you
don't bother to be specific.
| For example, it's hard to include C code with Lisp because they have very
| different data types and memory models.
this is getting quite amusing...
| Just to short-circuit the discussion that will ensue...
| I'm sure that many of you will argue against these claims ("my new
| version of Scheme is just as fast as C", "Lisp just needs a new garbage
| collector that embodies the latest techniques", "I know someone who
| combined C with Scheme and had no problems at all", etc.).
this is the most ignorant nonsense I have ever seen anyone who pretends to
be serious has ever written! if this is the best John Ousterhout can do
when he researches something, there's no _wonder_ Tcl is the way it is!
have you even _seen_ a Common Lisp compiler, John Ousterhout?
| However, I've seen a fair amount of evidence on this and the problems far
| outnumber the success stories.
why should anyone trust you on that?
| Many of the best minds in Computer Science have worked on Lisp over the
| last 30 years, and they haven't been able to fix the language so that it
| could be widely used either for system programming or scripting tasks.
| This says to me that there is something fundamentally wrong with the
| language, at least for these tasks.
the saddest, but still quite amusing, part of this ranting is that you rely
on the reader's acceptance of "widely used" to justify your arguments, yet
have made no distinction between, e.g., Bill Gates' beloved BASIC and Tcl.
Tcl is clearly a phenomenal failure compared to BASIC. how can you have
the _gall_ to argue that Tcl is widely used and that Lisp is not if you
don't even consider "widely used" relative to their "markets"?
| By the way, I think that Lisp is a fascinating language with neat
| mathematical properties. It's great for a variety of meta-programming
| tasks where you're experimenting with new programming paradigms, such as
| AI and language theory. It just isn't good for system programming or
| scripting. This reinforces my claim that you should use different tools
| for different tasks. This is also why I didn't mention Lisp in the
| paper. The things I discussed in the white paper aren't the things that
| Lisp was designed for or that it does best, so it isn't really fair to
| compare Lisp along those dimensions.
again, why should anyone trust your judgment on this? you are clearly
unable to recognize the simple fact that you don't know Lisp in practice
well enough to pass judgment on it. yet you make a big stink about
evidence and lots of important words that carry no _precise_ meaning.
ANSI Common Lisp, and even Common Lisp the Language, 2nd edition, specify a
language that is, in practice, _routinely_ compiled to code as fast as C,
often faster because Common Lisp programmers use better algorithms and have
more time to optimize where it is needed than C programmers.
it's _tragic_ to see that John Ousterhout is this affected by myths and
general ignorance, and doesn't even know he's out on a limb.
after what I have read from John Ousterhout, I have reached the sad
conclusion that he is intellectually dishonest and does not know when he no
longer has sufficient information to state a conclusion and when he must be
humble enough to request more information before he can do so. a highly
acclaimed academic should not be _able_ to lose this ability just because
he's working for a company.
Richard Gabriel's "worse is better" may even apply to people in some ways.
I'm no longer young enough to know everything.