>If this experience is BS, what is the truth? Why _did_ >the Lisp machines die?
There are many reasons, which have been discussed ad naseum, I could say lots (as others probably will) but in my opinion there were two major factors:
1. Market Share. Sun agressively lowered prices to pursue market share and increase sales volume (and other workstatations vendors too) When SUN came out with $5K workstations, Symbolics only grudgingly came out with $20K entry machines and were convinced their machines were "worth it". They failed to understand the big picture of market share, and was still flush from defense industry buyers of their expensive machines.
2. Low-cost application delivery. Simply non-existent with LispMachines. UNIX had dirt-cheap ASCII terminals, SUN had diskless machines, and low-cost diskful machines. Symbolics eventually had a 386-pc delivery vehicle, which was about 5 years too late, and didn't really work, as I recall. LispM applications tended to use the non-portable graphics heavily, which made them hard to port over to the Lisp-on-Unix vendors systems.
In article <5jgodk$nd...@news.utdallas.edu>, mharr...@utdallas.edu (Mark A
Harrison) wrote: > Why are so many of the popular languages created not by language > theorists but by people trying to accomplish some other task?
> (I think JO raised this last point in his MIT lecture.)
I'll take a shot at this one.
Most 'popular' languages started life as highly specialized (i.e., 'limited scope') languages that had access to some peculiar library -- e.g., graphics, type-setting, wimp, linear algebra (matlab), symbolic algebra (macsyma, etc.). People then found out that any language with sufficient power (i.e., not brain dead) was Turing complete, and the converts to these new languages then discovered that they would do _more_ than 'just' graphics, type-setting, etc., etc. Of course, many of these converts had been exposed to only one language, and this language was so much better than that silly Fortran, Pascal, (insert your favorite dog to kick here) language that had been forced upon them in engineering/math/physics/.... school, that they touted it as the next best thing to sliced bread.
The truth is that there isn't more than an ounce of spit in the differences among most of these languages _with the exception of the specialized libraries that they are hooked up to_, so most of this variation is non-productive.
There are major exceptions to this assessment, to be sure. The appearance of soft/dynamic typing, garbage collection, EVAL, sophisticated data structures, dynamically compiled/linked code, etc., etc., quickly separate the sheep from the goats.
So the language theorists focus on the _library-independent_ issues such as typing, data structuring, control structuring, etc., instead of on building large numbers of specialized libraries. The ability of a language to continue growing out of its original niche depends critically on this more balanced view, but this view is seldom to be found in the initial enthusiasm of creating the first Turing-capable interpreter for one's new graphics/type-setting/... library.
The few languages that do manage to leave the premordial slime and move onto dry land (Lisp, Prolog, Smalltalk, ML, etc.) are laughed at by those still in the slime for sloughing off their specialized libraries, even though by doing so, they can now do all of the specialized things from not only their original area of expertise, but also many other areas, as well.
In article <335BAB74.4...@polaroid.com>, pras...@polaroid.com wrote: > If this experience is BS, what is the truth? Why _did_ > the Lisp machines die? People keep blaming "marketing", but > did LMI/Symbolics founders not have enough smarts or the money > to hire some good marketing people? I would doubt either > of these two was the case.
> Or maybe the machines were just too expensive to produce, > to be able to sell them successfully.
The very short answer is that Symbolics promised a 'Lisp Chip' within a certain time frame that would bring the price down to the point of being available to the masses, and they were many years late with this chip. The chip itself wasn't all that complicated, but the politics surrounding getting it funded certainly were.
In article <335BB755.4...@sonic.net>, Ray Dillinger <b...@sonic.net> wrote: > Lisp machines may have had fabulous email systems, but how much good > does that do if the rest of the company is running on *another* email > system? You want to buy lisp machines for every secretary and marketing > rep, just so they can all use the same email system?
Symbolics email system was compatible with every email system on the arpanet, from unix boxes, to vms boxes, to dec-20 boxes, to pc's. If Apollo couldn't handle internet mail, then that was Apollo's problem, not the Lisp Machines.
There were _some_ forms of mailer gateways, and in the later years, Symbolics may very well have supported those, as well.
Oh by the way, I understand that all of the email sent to the White House is being handled by a Lisp mail system that may very well be still running on a Lisp Machine. This project was being run out of MIT a year or two ago.
In article <slrn5lnl9m.la9.m...@ducky.net>, m...@ducky.net (Mike Haertel) wrote: > * LispM's were not multi-user - they could have only > one logged-in user at a time, although they did > provide a degree of remote access.
LispM's had a full multithreaded environment--something not seen in personal computers until very recently. Apple is still having difficulties with this one.
> * LispM's were not secure - the whole system, including > the operating system kernel, ran in a single giant > address space.
A better way of saying this is that LispM's are much _more_ secure, because every item has its hardware datatype which is religiously checked on every access. LispM's weren't the machines crashing when those internet worm attacks were going on!
> The LispM's also cost too much--especially for single-user machines!
The first two items aren't problems on PC's, so we can only conclude that the third item--the cost--is the real problem here. If Symbolics had achieved their Lisp chip in the initially promised time frame--approximately 1985-- instead of 1988-9, the whole character of the argument would have changed. Apple would have gone after the low end of the wimp market, and the Lisp Machines would have captured the space currently occupied by low-end SGI machines. Even though it ran on a much slower processor, the Symbolics graphics software was miles ahead of anything else in the late 1980's, and so it still managed to compete for a while with its slow hardware.
> In article <335BB755.4...@sonic.net>, Ray Dillinger <b...@sonic.net> wrote: > > Lisp machines may have had fabulous email systems, but how much good > > does that do if the rest of the company is running on *another* email > > system? You want to buy lisp machines for every secretary and marketing > > rep, just so they can all use the same email system?
> Symbolics email system was compatible with every email system on the > arpanet, from unix boxes, to vms boxes, to dec-20 boxes, to pc's. If Apollo > couldn't handle internet mail, then that was Apollo's problem, not the Lisp > Machines.
Oh, how nice, if the rest of your business happens to be using SMTP email (SMTP was the standard on ARPANET, as I recall, even back before it became the internet). But at the time, there WAS NO STANDARD that commanded more than a small fraction of the market. ARPANET was a few thousand machines mostly at military bases and a few universities. Software houses were using PC-pursuit and SEADOG, for godssake! They went for SMTP no doubt because it was the biggest -- but even so, I bet it "fit in" with less than a quarter of their clients' email systems.
> There were _some_ forms of mailer gateways, and in the later years, Symbolics > may very well have supported those, as well.
Mailer gateways? You wanna send interoffice memos through mailer gateways in 1984? All the mailer gateways that existed at the time required you to stand on your head, manually fill in forward-to addresses, click your heels together three times, do a backflip, keep your lines shorter than 40 characters and your posts under 80 lines long, wave a dead chicken over your monitor, and guess how many nulls your host needed at end-of-line. Most of them delayed mail by at least four hours, and most of them reformatted your mail for line length -- and let's not forget dropping characters on the floor due to line noise about every two lines (remember, at that time if it wasn't arpanet it didn't have an error-correcting protocol).
Mailer gateways were a bleeding nightmare in 1984. I know, because I ran one. You don't wanna go there, really.
> Oh by the way, I understand that all of the email sent to the White House > is being handled by a Lisp mail system that may very well be still running > on a Lisp Machine. This project was being run out of MIT a year or two > ago.
> 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.
> Obligatory Ousterhout slam: The argument I hate the most from people is "X > is better than Y because more people use X than Y." This argument is > particularly infuriating when it comes from people like Ousterhout and > Stroustrup and Gates because they are clearly content to perpetuate people's > ignorance of superior alternatives, thus protecting their trump-card argument. > (Not that it's their job to inform people of superior alternatives.)
An Hmmm. I don't know what - if anything - Ousterhout said to deserve that label, and I find it hard to think of something significant to say that applies to "Ousterhout and Stroustrup and Gates."
I do not think that I ever said:
"C++ is better than Y because more people use C++ than Y."
To repeat what I posted last time someone accused me of making that argument in comp.lang.c++:
The furthest I go is to claim that unless C++ had at least some of the virtues I claim for it, it would have died during the early years where there were essentially no C++ marketing and alternatives languages with marketing dollars behind them existed.
Naturally, even that is invariably mistaken for the disreputable "5 million morons cannot be wrong" argument :-(
I recommend "The Design and Evolution of C++" (Addison-Wesley) for people who are interested in what I actually claim for C++.
jam...@netcom.com (James Logajan) writes: > NOTE TO LISP AND FORTH FANS: one important reason your languages > have never caught on may be due to the fact that many natural languages > follow the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS > are less likely
[snip]
So, FORTH should be extremely popular in Japan, because Japanese is very much SOV.
And your theory doesn't account for the popularity of the WIMP interface, which is basically OV (select object, select action).
(A nice theory shot down by dirty facts.)
-- Peter Ludemann +1.415.813.6806 (fax: +1.415.813.7499) Software Architect ludem...@inxight.com InXight Software, Inc. http://www.inxight.com PAHV 105, 3400 Hillview Ave., Palo Alto, CA 94304
>> * LispM's were not multi-user - they could have only >> one logged-in user at a time, although they did >> provide a degree of remote access.
>LispM's had a full multithreaded environment--something not seen in >personal computers until very recently. Apple is still having difficulties >with this one.
Of course, being multithreaded has nothing to do with being multi-user. Take NT, for example.
>> * LispM's were not secure - the whole system, including >> the operating system kernel, ran in a single giant >> address space.
>A better way of saying this is that LispM's are much _more_ secure, because >every item has its hardware datatype which is religiously checked on every >access. LispM's weren't the machines crashing when those internet worm >attacks were going on!
Neither were PC's running Novell. Of course LispM's wouldn't be affected - the worm targetted only Unix machines running Sendmail (I think?). -- |Jason V. Robertson <jvrob...@sedona.intel.com> | |Not speaking for Intel. |
In article <5jgvh0$...@pravda.cc.gatech.edu>, ly...@cc.gatech.edu (Lyman
S. Taylor) wrote:
> To futher supplement that "it was the marketing.... " viewpoint, > BusinessWeek has an article this week about how the Alpha is both the > fastest general purpose microprocessor out. And the one with the smallest > market share.
Yup. I read this in the printed version of {Business Week} during my lunch break today.
One especially interesting detail: _APPLE_ approached DEC about using Alphas for their next generation of Macs, but DEC wasn't interested, so they went the PowerPC route.
Apple's having their share of problems these days, mostly because their long-standing tradition of shooting themselves repeatedly in both feet finally caught up with them, so AlphMacs might not have saved them from themselves, but wouldn't they have been _nifty_ boxes!
For of all sad words of tongue or pen, The saddest are these: "It might have been!" -John Greenleaf Whittier
If, of all the words of tongue and pen, The saddest are, "It might have been,'' More sad are these we daily see: "It is, but hadn't ought to be.'' - Bret Harte --------- As of 19 Apr 1997, 986 days till Y2K.... Matthew.He...@yale.edu http://paella.med.yale.edu/~healy "But I thought it was pointed at the rabbit *between* my feet!" --------- Help a victim of severe email harrassment, see http://www.geocities.com/~hitchcockc/story.html#fund ---------
"M. Prasad" <pras...@polaroid.com> writes: > If this experience is BS, what is the truth? Why _did_ > the Lisp machines die? People keep blaming "marketing", but > did LMI/Symbolics founders not have enough smarts or the money > to hire some good marketing people? I would doubt either > of these two was the case.
Well, I am not too sure about that, I have seen worse examples of misjudgements :)
My 0.02 USD worth of theory on the failure of the lisp-machines is: The machines were pretty expensive. At least initially, they were also targeted at a very limited market (the AI market) which then sort of collapsed (details omitted :). Now, the Lisp machines were truely excellent at interoperability and communication with just about any weird piece of hardware, language, file-format and network protocol, so "not compatible" was probably a very minor issue. But you _did_ need to be very rich to get one in the first place. If you had any sanity at all (not all rich people do :), you probably also needed a very good product idea before you could justify the kind of investment such a machine represented, _and_ you needed to be pretty successfull in the execution of your project to defend the investment afterwards. This last issue was probably particularly true if your project ran over budget, didn't complete properly or ran into any number of other problem not necessarily related to your unconventional choice of plattform
Now, are these kinds of issues marketing issues? Yes probably.
-- (Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: r...@ifi.uio.no Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337
"M. Prasad" <pras...@polaroid.com> writes: > If this experience is BS, what is the truth? Why _did_ > the Lisp machines die? People keep blaming "marketing", but > did LMI/Symbolics founders not have enough smarts or the money > to hire some good marketing people? I would doubt either > of these two was the case.
Well, I am not too sure about that, I have seen worse examples of misjudgement from management :)
My 0.02 USD worth of theory on the failure of the lisp-machines is: The machines were pretty expensive. At least initially, they were also targeted at a very limited market (the AI market) which then sort of collapsed (details omitted :). Now, the Lisp machines were truely excellent at interoperability and communication with just about any weird piece of hardware, language, file-format and network protocol, so "not compatible" was probably a very minor issue. But you _did_ need to be very rich to get one in the first place. If you had any sanity at all (not all rich people do :), you probably also needed a very good product idea before you could justify the kind of investment such a machine represented, _and_ you needed to be pretty successfull in the execution of your project to defend the investment afterwards. This last issue was probably particularly true if your project ran over budget, didn't complete properly or ran into any number of other problem not necessarily related to your unconventional choice of plattform
Now, are these kinds of issues marketing issues? Yes probably.
-- (Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: r...@ifi.uio.no Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337
Bjarne Stroustrup wrote: > [...] and I find it hard to think of something significant to say > that applies to "Ousterhout and Stroustrup and Gates."
All three of you have a sign on your back that says "Kick me!"
[...]
> The furthest I go is to claim that unless C++ had at least some > of the virtues I claim for it, it would have died during the > early years where there were essentially no C++ marketing and > alternatives languages with marketing dollars behind them existed.
I was one of those early adopters. At the time I and many others were looking for a better C, and in our ignorance we thought C++ was really great. Isn't it time to admit it was a mistake?
[...]
> I recommend "The Design and Evolution of C++" (Addison-Wesley) for people > who are interested in what I actually claim for C++.
And I recommend folks learn *any* language that supports higher-order functions, automatic memory management, and incremental compilation to see how truly wretched C++ is, regardless of whatever claims Stroustrup makes for it.
If what I wrote sounds harsh, let me explain what I had just spent the previous two hours doing.
I had this:
struct A { /* ... */ }
template <class T> struct B : A { /* ... */ }
I wanted to do this:
A* a = new B<whatever>;
B<whatever>* b = dynamic_cast<B<whatever>*>(a);
I managed to figure out that in order for this to work, it's not enough that the compiler see the entire definition of B<T>, but it also needs to see B<whatever> explicitly instantiated. According to the ANSI C++ proposal, this is done like so:
template class B<whatever>;
But of course the compiler I'm using doesn't support this yet. (IRIX 6.2 C++ 7.1) so you have to do this instead:
#pragma instantiate B<whatever>
There were no warnings, and no clues about what I was doing wrong. dynamic_cast just consistently returned zero.
C++ is *full* of bullshit like this and I've spent way too much of my life fighting it.
In article <l2lo6d9i98....@safran.kurims.kyoto-u.ac.jp> Jacques GARRIGUE <garri...@safran.kurims.kyoto-u.ac.jp> writes:
] Let's see a small example: ] ] (TCL) ] button .b -text Hello -font {Times 12} -relief sunken ] ] (LablTk) ] let b = Button.create parent:top text:"Hello" font:"Times 12" relief:`Sunken ] ] Again, the syntax is not more difficult. Allegedly a little bit more ] verbose, but not really bothering. The difference is that everything ] that can be checked is checked at compile time (or even before, using ] the interactive editor):
I've been pondering this issue of scripting vs. programming, and the two communities they represent. I think this example captures the conflict pretty well. To someone writing a script, the subtle control and data structures are just extraneous and annoying: Create? Of course, what else? Parent:top? Who cares? The difference between the two examples is small in terms of the amount of text, but to the script writer the additions are just annoying. Its like having to write "and" between each entry in your grocery shopping list.
The scripting community will always be much larger than the programming community, but you can't have one without the other. So there is no point to getting the world to stop using simple languages. No offense, but its a little like trying to teach a pig to sing. Its a waste of time and it annoys the pig. -- David Fox http://www.cat.nyu.edu/fox xoF divaD NYU Media Research Lab f...@cat.nyu.edu baL hcraeseR aideM UYN
: > : Warning to Netscape users!! : : The above poster, Michael Kagalenko, has inserted the following : JavaScript code in his e-mail: [script snipped] : This will open windows in your browser until memory is exhausted and/or : your system hangs.
This is annoying and rude behavior on MK's part -- but I must admit that I also see it as a loud "Get another newsreader!" wake-up call to Netscape users. Any newsreader which allows *message content* to crash your machine is fundamentally and perhaps irreparably broken. You should abandon it with all due speed -- the next fun little trick somebody finds may do far more than simply cost you a reboot.
On Tue, Apr 22, 1997 3:29 AM, Henry Baker <mailto:hba...@netcom.com> wrote: >In article <5jgodk$nd...@news.utdallas.edu>, mharr...@utdallas.edu (Mark A >Harrison) wrote:
>> Why are so many of the popular languages created not by language >> theorists but by people trying to accomplish some other task?
>> (I think JO raised this last point in his MIT lecture.)
>I'll take a shot at this one.
>Most 'popular' languages started life as highly specialized (i.e., 'limited >scope') languages that had access to some peculiar library -- e.g., graphics, >type-setting, wimp, linear algebra (matlab), symbolic algebra (macsyma, etc.). >People then found out that any language with sufficient power (i.e., not >brain dead) was Turing complete, and the converts to these new languages >then discovered that they would do _more_ than 'just' graphics, type-setting, >etc., etc.
[ ... ]
Another binary classification of computer languages is 'academic languages' vs. 'toolkit languages' : Academic languages are typically developed to prove or demonstrate something. Toolkit languages are invented to help someone get some work done.
Of course this is a very fluid boundary.
Academic languages that survive long enough tend to become tools:
Fortran was written both as a tool, and to prove that the whole idea of automatic compilation of an algebraic language was practical ( There were quite a few sceptics at the time. )
Smalltalk was written to demonstrate the advantages of a form of purely object oriented programming, but it's become a tool for business computing.
But I think it's reasonable to say that Scheme, ML and Haskell -- good picks for archetypal academic languages -- were all developed to demonstrate the wide utility of a few powerful concepts. ( Maybe I should include N.Wirth's creations here: Pascal, Modula-2, et.al. - but I've never been quite exactly sure what he was trying to prove. )
Lisp, on the other hand, was one of the original toolkit languages: It was invented so that John McCarthy and others would have an easier tool for their AI research. The HOPL-II article on the evolution of Forth, probably the archetypal toolkit language describes how Chuck Moore traveled around with his card deck, porting Forth to one system after another as the first step in whatever application he was working on at the time. Perl started out as Larry Wall's personal Unix programming toolkit. The first paper that mentioned Python was about how it was being used to test network servers for the Amoeba OS project. And Tcl was certainly designed as a tool.
Another "bi-chotomy" that I've used -- similar but different than the previous one is: designed languages vs. "Jes' Grew" languages. The thing that characterizes "Jes' Grew" languages is piecemeal growth. One of the things I've always praised about Python is that it's somewhere in the golden mean of those two poles. After all, if growth doesn't start from a good initial design, it quickly turns into a collection of hacks. We can admire clever hacks, but sometimes they only postpone the inevitable Complete ReWrite.
Jes' Grew languages tend over time, towards an excess of often non-productive features and redundancy as they gather layers of not quite compatible invention. ( CAR, first, head, elt, aref, ... )
I've never doubted the utility of C++, Perl or Tcl as tools, but they all seem limited by their initial design. To be fair, I've also bumped into limitations in Lisp and Python, but they don't seem quite as deeply rooted or severe to me. Also, indicating that I see a design flaw is not criticism of the designer: In the case of C++, one of the design constraints -- that it be compatible with C -- is the source of most of it's "flaws". Sometimes a tool or language may be very well designed given a certain niche or application, but when it's pushed into other realms, problems appear. ( As Henry Baker noted above: there is a tendency for all special purpose languages to grow towards being more general purpose. )
If John Ousterhout is saying that academic comp. sci. has been biased against the toolkit languages and the Jes' Grew languages, and hasn't payed enough attention to practical issues like "glue languages", then I agree. However, I think most of us, including quite a few of the "academics" agree with that notion now. It is other issues: distortion of the truth, assertion without evidence, failing to give credit to, if not his sources, then at least his predecessors, that are the cause of the controversy. I agree strongly with much of what I took to be the intent of that paper, but I disagree strongly with the specific case he makes. As someone else in this thread said: "It's not even wrong!"
Henry Baker (again):
>The truth is that there isn't more than an ounce of spit in the differences >among most of these languages _with the exception of the specialized >libraries >that they are hooked up to_, so most of this variation is non-productive.
And other source of irritation at that paper is as yet another demonstration of the non-productive reinvention of, rather than learning from, History. And typically, without learning from the past, it's not any better the second time around. J.O. is claiming progress in the fact that we now have something nearly as good as we had ten or fifteen years ago. Non productive variation!
A better guide than Ousterhout is Dick Gabriel.
When I first read his "worse is better" paper, I wasn't sure what, if anything, he was advocating.Was he really recommending "worse" ? I wasn't quite sure -- that paper seemed like a sort of left handed compliment.
His latest book "Patterns of Software" ( mostly collected from articles from JOOP ) expands on that paper with his notions of "habitability" -- how to design and plan for systems that will grow and evolve. I think that's what he was aiming at with that first paper, and it's what I was aiming at when I first started calling Python and Perl "Jes' Grew" languages a couple of years ago.
BTW: The phrase "Jes' Grew" is from Ishmael Reed. I don't remember which book. I do almost remember the line: "Where did Jazz come from?" "No Come From, it Jes Grew!"
P.S. I hate to see people spread lies and rumors of the "failure" of Lisp, when lisp has been one of the greatest, most successful Jes' Grew Toolkit languages ever. Lisp is going to be aound when it turns 40. It's obvious it could use another rewrite. If J.O. had wasted less time knocking Lisp and spent a bit more time learning from it, maybe Tcl would not be showing signs of tired old age already.
Bigloo is a compiler for an extended version of Scheme. May you should have a look.
Bigloo contains: - a foreign interface (not restricted to foreign _function_ interface) - a module language (mostly to allow batch compilation) - several libraries (such as parsing libraries, pattern matching, ...) - a native object system based on generic functions. - a macro system.
On Tue, Apr 22, 1997 3:29 AM, Henry Baker <mailto:hba...@netcom.com> wrote: >In article <5jgodk$nd...@news.utdallas.edu>, mharr...@utdallas.edu (Mark A >Harrison) wrote:
>> Why are so many of the popular languages created not by language >> theorists but by people trying to accomplish some other task?
>> (I think JO raised this last point in his MIT lecture.)
>I'll take a shot at this one.
>Most 'popular' languages started life as highly specialized (i.e., 'limited >scope') languages that had access to some peculiar library -- e.g., graphics, >type-setting, wimp, linear algebra (matlab), symbolic algebra (macsyma, etc.). >People then found out that any language with sufficient power (i.e., not >brain dead) was Turing complete, and the converts to these new languages >then discovered that they would do _more_ than 'just' graphics, type-setting, >etc., etc.
[ ... ]
Another binary classification of computer languages is 'academic languages' vs. 'toolkit languages' : Academic languages are typically developed to prove or demonstrate something. Toolkit languages are invented to help someone get some work done.
Of course this is a very fluid boundary.
Academic languages that survive long enough tend to become tools:
Fortran was written both as a tool, and to prove that the whole idea of automatic compilation of an algebraic language was practical ( There were quite a few sceptics at the time. )
Smalltalk was written to demonstrate the advantages of a form of purely object oriented programming, but it's become a tool for business computing.
But I think it's reasonable to say that Scheme, ML and Haskell -- good picks for archetypal academic languages -- were all developed to demonstrate the wide utility of a few powerful concepts. ( Maybe I should include N.Wirth's creations here: Pascal, Modula-2, et.al. - but I've never been quite exactly sure what he was trying to prove. )
Lisp, on the other hand, was one of the original toolkit languages: It was invented so that John McCarthy and others would have an easier tool for their AI research. The HOPL-II article on the evolution of Forth, probably the archetypal toolkit language describes how Chuck Moore traveled around with his card deck, porting Forth to one system after another as the first step in whatever application he was working on at the time. Perl started out as Larry Wall's personal Unix programming toolkit. The first paper that mentioned Python was about how it was being used to test network servers for the Amoeba OS project. And Tcl was certainly designed as a tool.
Another "bi-chotomy" that I've used -- similar but different than the previous one is: designed languages vs. "Jes' Grew" languages. The thing that characterizes "Jes' Grew" languages is piecemeal growth. One of the things I've always praised about Python is that it's somewhere in the golden mean of those two poles. After all, if growth doesn't start from a good initial design, it quickly turns into a collection of hacks. We can admire clever hacks, but sometimes they only postpone the inevitable Complete ReWrite.
Jes' Grew languages tend over time, towards an excess of often non-productive features and redundancy as they gather layers of not quite compatible invention. ( CAR, first, head, elt, aref, ... )
I've never doubted the utility of C++, Perl or Tcl as tools, but they all seem limited by their initial design. To be fair, I've also bumped into limitations in Lisp and Python, but they don't seem quite as deeply rooted or severe to me. Also, indicating that I see a design flaw is not criticism of the designer: In the case of C++, one of the design constraints -- that it be compatible with C -- is the source of most of it's "flaws". Sometimes a tool or language may be very well designed given a certain niche or application, but when it's pushed into other realms, problems appear. ( As Henry Baker noted above: there is a tendency for all special purpose languages to grow towards being more general purpose. )
If John Ousterhout is saying that academic comp. sci. has been biased against the toolkit languages and the Jes' Grew languages, and hasn't payed enough attention to practical issues like "glue languages", then I agree. However, I think most of us, including quite a few of the "academics" agree with that notion now. It is other issues: distortion of the truth, assertion without evidence, failing to give credit to, if not his sources, then at least his predecessors, that are the cause of the controversy. I agree strongly with much of what I took to be the intent of that paper, but I disagree strongly with the specific case he makes. As someone else in this thread said: "It's not even wrong!"
Henry Baker (again):
>The truth is that there isn't more than an ounce of spit in the differences >among most of these languages _with the exception of the specialized >libraries >that they are hooked up to_, so most of this variation is non-productive.
And other source of irritation at that paper is as yet another demonstration of the non-productive reinvention of, rather than learning from, History. And typically, without learning from the past, it's not any better the second time around. J.O. is claiming progress in the fact that we now have something nearly as good as we had ten or fifteen years ago. Non productive variation!
A better guide than Ousterhout is Dick Gabriel.
When I first read his "worse is better" paper, I wasn't sure what, if anything, he was advocating.Was he really recommending "worse" ? I wasn't quite sure -- that paper seemed like a sort of left handed compliment.
His latest book "Patterns of Software" ( mostly collected from articles from JOOP ) expands on that paper with his notions of "habitability" -- how to design and plan for systems that will grow and evolve. I think that's what he was aiming at with that first paper, and it's what I was aiming at when I first started calling Python and Perl "Jes' Grew" languages a couple of years ago.
BTW: The phrase "Jes' Grew" is from Ishmael Reed. I don't remember which book. I do almost remember the line: "Where did Jazz come from?" "No Come From, it Jes Grew!"
P.S. I hate to see people spread lies and rumors of the "failure" of Lisp, when lisp has been one of the greatest, most successful Jes' Grew Toolkit languages ever. Lisp is going to be aound when it turns 40. It's obvious it could use another rewrite. If J.O. had wasted less time knocking Lisp and spent a bit more time learning from it, maybe Tcl would not be showing signs of tired old age already.
>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.
[ ... ]
>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.). However, >I've seen a fair amount of evidence on this and the problems far >outnumber the success stories. 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.
John -- your explaination is even worse that the original paper!
> In fact I suspect that this may be why Lisp hasn't been used > much for practical programming.
You throw in assertions like this with no mention of evidence or a source for this conclusion.
I'm using lisp for practical programming: statistics, graphics, data-analysis, converting foreign file formats. ( I'm not in comp. sci. -- I'm in the Med school, so I'm not as interested in the elegant mathematics properties of Lisp as the fact that it's an excellent tool. ). I know of lots of other people using it for practical programming, including all of the people doing statistics with XLispStat, all of the people writing applications and utilities in emacs lisp, and all of the people writing AutoCad extensions in lisp.
What is the basis for statements about lisp not being widely used or about the failure of Lisp ?
It may be the case that there are more Tcl users than Lisp users, but I haven't seen even a poor attempt at a bad estimate made. Just the assertion that Tcl is a success and Lisp is a failure.
How would you attempt to make such an estimate ?
Number of downloads of software: Well, there are many download sites for Tcl. There are not only many download sites for lisp, there are many different implementations and there are also several different commercial implementations. And how do you rate embedded products. Many people get lisp in autocad or emacs, but only a minority of users ever program it. How does that count. Same problem with Tcl applications.
Size and number of postings to usenet groups: Not reliable. Since there are more Lisp books and it's been around much longer, maybe there aren't as many people asking questions on usenet. It may not be a valid sample.
Number of books and articles published. Lisp has the edge here. Tcl may be gaining. But it's still an unlikely metric.
Surveys: There are sample and coverage problems with surveys. The few large scale surveys I've seen, neither Lisp nor Tcl register as blips. They are burried in the "Other" catagory. Real use may be better, as the coverage of some of those surveys would seem to be weighted towards larger ( more conservative?) organizations.
If you have some evidence, then give it to us! [ I wish academic Comp. Sci. were more interested in some practical basic questions like that, but it's not an exciting project, and nobody is interested in funding it. The same goes for some cross-language productivity studies larger than making a button. These are things that would take a lot of work, would have a clear scientific benefit, and are totally boring and unsexy research. ]
Even if we do accept it likely that there are more Tcl than Lisp users:
[1] Is this a long term trend ? Computer Languages seem to follow the same sort of trends and psychology that's been documented for other technologies. There are early adopters who are looking for novelty, and there are the belt-and-suspenders crowd who will avoid anything until it's time tested and proven. It's likely that there is a temporal pattern, and that Tcl is riding the crest, while Lisp is at a steady state. When Tcl settles to it steady state, will it still have a large volume of users ? The novelty seekers may be onto something new!
[2] Whatever the comparative volume for Lisp and Tcl, they are both clearly fighting it out with two dozen other languages for the "other" category, left over after Cobol, Fortran, C, C++, Basic, and now probably Smalltalk and Java. If you are arguing success by popularity, you're on pretty shakey and not statistically significant ground.
I do think that Tcl has done several things right, and that Lisp has done several things wrong. But after nearly 40 years, we can say without much doubt that Lisp has been one of the great intellectual successes in computer languages. Like - what was it, Algol 60 that this was said about ? - It's a great improvement over most of it's successors.
It would be unfair for me to ask where will Tcl be in 4o years. I don't think that is the proper standard to apply. We're not interested in posterity, but in practical tools now. But, I likewise feel that judging Lisp by how many millionaries it may or may not have created, compared to Basic or Unix is not the proper standard for success or failure. Lisp has been a success as an idea and it's been a success as a tool, and it's got a more solid track record in that regard than Tcl. I think there *was* a good idea in that paper trying to get out, but this sort of thing does more damage to your argument by undermining your credibility. I believe its more due to carelessness than to maliciousness, but "careless with the truth" does not sound very complimentary.
Bjarne Stroustrup wrote: > The furthest I go is to claim that unless C++ had at least some > of the virtues I claim for it, it would have died during the > early years where there were essentially no C++ marketing and > alternatives languages with marketing dollars behind them existed.
Hear, hear!
Likewise corporate backing of Tcl is a very recent thing. For a long time it was just a few enthusiasts with a mailing list and then later a few thousand enthusiasts with a newsgroup. Getting your company to use Tcl was as hard a fight as getting most companies to try any other new thing.
I think it's interesting that where one LISP guy's list of essentials were "full dynamism, introspection, procedural macros, lexically-scoped closures and generic functions and no static typing", mine, when I was looking for a scripting language back in 1988, were that it be embeddable, interpreted, have a reasonably small footprint, be good with text, and be easy to plug C code into.
LISP had a 25 year headstart and a hell of lot more funding. Tcl's competition, in terms of what languages people use instead of Tcl to do the sorts of things that people do in Tcl, has mainly been PERL, IMHO, with a bit of ksh, awk, Python, etc., as well.
This has not stopped the periodic trolling through comp.lang.tcl by LISP and Scheme weenies trying to pick a fight.
I think Tcl is popular because a lot of programmers found that scripting languages were powerful and useful additions to applications, and that Tcl was free and pretty easy to pick up and plug into an app.
So anyone who wants to say Tcl's marketing is what has made it successful, well, old timers just have to laugh. And these threads seem be an argument between the theorists who love LISP and the pragmatists who have an app and a deadline and want to find something that works and use it and ship the thing and move on to the next project.
I can guess how the scathing rebuttal will go... "It's precisely the crap foisted on everyone by the pragmatists that we LISP weenies are trying to fix. But look at these two dead company's most excellent LISP machines. Etc."
The "battle" is a battle for mindshare. That battle is fought one mind... one program... at a time. So we Tcl weenies just keep on chooglin'. If you're a committed bike rider and you turn into a strong headwind, you don't get mad, you just downshift, put your head down, and pedal. And before too long, you've ridden pretty far. You want LISP's influence to increase, you're not going to get people to do it your way by flaming them. You've gotta remove obstacles to its use, pump out tools and apps, help people who run into problems, and push out the examples and games and clever little hacks that pique peoples' curiosity. You gotta sell it to the people who would use it. And make sure it really is as general purpose as you say... Like rewrite some shell scripts in it. But a lot it seems like the attitude of the LISP camp toward workaday programmers ranges from condecension to derision to outright contempt. You want LISP to do better? Lose the attitude, and make sure you have a good, free implementation that runs real well on Windows 95.
w...@peanut.jpl.nasa.gov (Will Duquette) writes: > 1. I like traditional expressions and control structures. > A C programmer can get the gist of a Fortran, BASIC, Pascal, > Ada, or Java program without too much effort. The syntax isn't > identical, but the basic model is much the same.
Don't know what you mean by traditional control structures, but Smalltalk control structures don't seem too different to C in practice.
> 2. (And this is the kicker) I really dislike having my application > and the Smalltalk library classes live in the same "space". In the > Smalltalk system I've looked at (Smalltalk V), if I wanted to > develop two separate applications they either needed to live in the > same class tree, or I needed to maintain too entirely separate > "images", which included all of the system classes. This gives me > chills, for some reason.
> As someone on this thread has commented, OOP in Java is more like OOP > in Smalltalk than it is OOP in C++, and I think this is true...but in > Java, there's a nice clean separation between my code and anybody > else's code. I like that. Again, this may be a purely psychological > issue, but then, I program better when I'm happy. :-)
I think it's purely psychological. :-) Think of the image as an instant compilation of your code changes. To use the same code in two images you need to export. The equivilent in C++ is building a library, installing the library in a common place and then linking with it. On the whole a lot more painful for C++.
"Graham C. Hughes" <graham.hug...@resnet.ucsb.edu> writes:
> I don't traditionally program in Scheme or Common LISP, > not because I don't have interpreters or compilers for them, but > because they aren't good enough at string processing to interest me.
I must disagree. I find scheme *wonderful* for string processing. Using map and filter functions and for-each, you can do incredible things in a few lines of code. And it's fast too!
|
