In article <3368a3ac.3086818@news.sydney.apana.org.au>,
<rajt@gco.apana.org.au> wrote:
>
>{ courtesy copy emailed to ouster@tcl.eng.sun.com , johns@cnet.com}
>---------------------------------------------------------------------------------------------------------
>Someone who claimed to be John Shen <johns@cnet.com> wrote:
>>Dear Professor O,
>> Please get back to doing your good work and gently ignore them.
>>I must say that your paper (which undoubtedly can be improved in many
>>ways) truly has had an enormous impact on all the programmers/project
>>leaders as I have not seen that much discussions on any other topic
>>recently in so many programming groups.
>
>I personally was favorably affected by Prof O's paper.
>Sure, it may not be a literary or a CS masterpiece, but it certainly
>provided food for thought.
Tastes vary. Many of us already knew the almost all of the stuff in the
whitepaper, had questions about them, and were left unsatisfied, or
even with a bad taste in their mouths.
Ousterhout's notion of "scripting" vs. "systems" programming is a
very limitied view, and many of us think it's not right---there
can be languages that can be good for both "systems" and "applications"
programs, and there are languages that can be good for both "applications"
and "systems" programming. Unfortunately, the split that Ousterhout
has chosen just happens to be the one that makes Tcl look best.
It's also the one that appeals to C programmers, who are sick to
death of using a systems programming language as an applications
programming language. Mightn't it be better to use a convenient,
interactive language most of the time, and only write the most
time-critical or system-dependent code in C?
It's interesting that many Tcl programmers are using Tcl as one could
Lisp or Smalltalk. They're not hitting themselves in the head with a
big rock (C development style) as often as they used to. Instead
they're hitting themselves with a smaller rock (Tcl's limitations)
most of the time. In some sense, Lisp has won, after being shunned
by macho C programmers for so long. ("We don't need no steenking
command-loop, we've got compilers! And we write FAST code!")
Often the reason that Tcl seems like the right language for the job,
even one it's not designed for, is just that C is the wrong language
for the job.
>>Languages like
>>Perl and Tcl (well, I cannot help putting Perl ahead of Tcl :-) have
>>been looked down upon by some as tools to craft quick-and-dirty
>>solutions, yet their successes in mission-critical projects
>>contradicts such views (actually they can be used for the full
>>spectrum from q&d to enterprise-level applications, which is the
>>beauty of it all).
As I've said before, languages like Tcl should in fact embarrass the
academic programming languages community, which has generally had
tunnel vision with respect to gluing.
>His clear accounts of the gluing vs systems programming paradigms
>were "worth the price of admission ".
I think that the general idea has some truth to it, but Ousterhout
presents it in such a way that it misleads many of his readers.
Mostly by omission, he makes it sound as though the design of Tcl
followed rationally from the problem domain, which many knowledgeable
people doubt. Some of the language features are obviously a good
idea, but the guts of the language seem poorly motivated.
I, for one, had hoped we could get to a point where we'd talk about
design choices in programming languages, and how they'd interact,
rather than just flaming back and forth about whose language was
better.
>Perhaps he didn't mention your or my currently favorite languages, (
>eg: Perl in your case, Python in mine ) but that was not the point of
>the paper.
No, it wasn't, but he also didn't mention programming language design
alternatives, such as lexical scope, conventional dynamic typing,
closures, objects, and garbage collection. People have been doing
scripting of some sort in languages with various combinations
of those features for a very long time. Are they irrelevant?
By neglecting to mention language *ideas* that are relevant, as
well as seminal languages, and by strongly pushing a false dichotomy,
Ousterhout wrote a paper that sounded to some people like more biased
marketing hype rather than interesting discussion of important issues.
If Ousterhout had taken the line that "Tcl is a warty, limited
language, but it has momentum so let's go with it," fewer people
would have objected. But by what he stresses, and omission, he
makes Tcl sound better than it is, and like it has not only
momentum but righteousness. He stakes out the ground of a good
language designer who's invented a New Kind of Language.
>Read, learn and move on....
Exactly. But to learn what's important, you have to understand
basic things, so that you can compare them properly, and know
what lessons to take with you.
I'm a language designer, and I don't know what to make of Tcl.
I think Ousterhout's a very smart guy, and I have immense respect
for much of his work in other areas. When it comes to Tcl,
though, I often can't distinguish between his technical smarts
and his marketing smarts. I don't know what to learn from Tcl
other than that "Tk and glue are real handy."
Arguments from popularity and size of extant programs can have
some merit, but remember that there are programs in COBOL that are
millions of lines long, and that well after UNIX became fairly
popular, MS-DOS was by far the most popular OS in the world.
None of that convinces me that COBOL and MS-DOS are Good Things.
The fact that it's possible to use something for a nontrivial
task doesn't make it a good idea. The fact that many people do so
doesn't make it a good idea, either.
Simple personal testimonials don't quite cut it---unless there is a
description of the advantages of that tool, and *how* the tool works
well when you'd think it'd be lacking a crucial feature. An argument
like "we don't need no steenking records, because I wrote 100,000
lines of Tcl and it worked!" The same goes for millions of lines of
COBOL and FORTRAN, and IBM 360 assembler. Unless we're told how
it was done, and why doing it that way is better than doing it some
seemingly better way, we don't know how to learn from it.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|