kroger@scarecrow.cognet.ucla.edu (James Kroger) (02/06/91)
Someone from Franz stated in a recent post that (I paraphrase) LISP is still profitable, and adapting to real-world needs just fine. I'm in a research lab where AI-type programs are the norm. The actual programming on these usually is done by undergraduates and grad students, as is true of most university labs. The language most often used used to be LISP (we even have an Explorer), but simply because of the preference of the programmers, the language of choice is more often C now. I seldom hear of anyone using LISP anymore, and having worked in both industry AI labs and university AI research, am becoming convinced that LISP is indeed (to my dismay) fading away, albeit slowly. I think it would be quite interesting and appropriate at this juncture for someone who is in a position to know (ie, Franz) to tell us just who IS using LISP these days, and for what. Thanks, --Jim Kroger
kaplan@spruce.cs.uiuc.edu (Simon Kaplan) (02/07/91)
well, for what it is worth, the University of Illinois has several large groups in the "software engineering" area. (or systems, or whatever your favorite term is). Common Lisp (usually with CLOS) is heavily used by my research group, and is used by at least two others. This doesnt include the AI groups here, but I'm pretty sure they use a mix of CL and Prolog. We used to do all our programming in C, and have now switched almost exclusively to Lisp, using C as a portable assembler when the need is dire. We used to use AKCL+PCL, then switched to Allegro CL+PCL, now using that and Allegro CL 4.0, which included CLOS. Of course this is just one datum, but there it is. -- Simon -- Simon Kaplan kaplan@cs.uiuc.edu Department of Computer Science uiucdcs!kaplan@uunet.uu.net University of Illinois at Urbana-Champaign 1304 W. Springfield Ave phone: +1 217 244 0392 Urbana Illinois 61801, USA fax: +1 217 333 3501
espen@math.uio.no (Espen J. Vestre) (02/07/91)
In article <806@mara.cognet.ucla.edu> kroger@scarecrow.cognet.ucla.edu (James Kroger) writes: > I'm in a research lab where AI-type programs > are the norm. The actual programming on these usually is > done by undergraduates and grad students, as is > true of most university labs. The language most often used > used to be LISP (we even have an Explorer), but simply because > of the preference of the programmers, the language of choice > is more often C now. I seldom hear of anyone using LISP anymore, Hm. Why don't you force these students to learn lisp? It isn't good to grow up thinking C is all that there is to programming. Being sort of at the fringe of the AI Society (doing natural language semantics / computational linguistics), I wonder what kinds of "AI programs" it is that someone ever could prefer to write in C. I guess the least you need is a pile of C code to simulate some things that come for free in lisp: For instance _atoms_ (symbols), which is the most basic need for doing symbolic programming. Does these guys reinvent atoms every time they need them (or worse, are they doing it all with strings??), or are there some nice libraries around which gives you some of the functionality of lisp inside C?? ----------------------------------------- Espen J. Vestre Department of Mathematics University of Oslo P.o. Box 1053 Blindern N-0316 OSLO 3 NORWAY espen@math.uio.no -----------------------------------------
ajs@prg.ox.ac.uk (Adolfo Socorro) (02/07/91)
At Oxford and SRI International, we use AKCL for the development of the OBJ family of languages and systems. I was at UMass-Amherst before, and there Common Lisp is used in the implementation of an extension of the Boyer-Moore theorem prover, and for the development of a (prototype of a) database language that is connected to the prover. The AI groups use a combination of Common Lisp and C. Adolfo
weigele@bosun2.informatik.uni-hamburg.de (Martin Weigele) (02/11/91)
ajs@prg.ox.ac.uk (Adolfo Socorro) writes: >At Oxford and SRI International, we use AKCL for the development of the OBJ >family of languages and systems. [Hi Adolfo -] I think the crucial question about programming languages is the way of thinking and the attitude towards programming problems they encourage. Historically, lisp was the language of choice for the AI people because of its at that time exceptional abilities of symbol manipulation and list processing. As a least common denominator, Common Lisp was then created to be as compatible as possible with the existing lisp families. Nowadays, I think that Common Lisp has become a dinosaur because of the incredibly many features built in - also known as "creeping featurism" - as a result of the desire to be as compatible as possible. Languages like scheme seem much "cleaner" and "nicer". But even scheme lacks the kind of type support available in the modula/pascal/oberon language family, or in languages like ML. On the other hand, the widespread use of Common Lisp in the AI community and the fact that with some programming self-discipline, you can write decent and powerful programmes might still justify its use. Also, the more specification languages are really used in programming projects, perhaps the less important the features of the programming languages at least at the stage of system analysis, and the less incentive from throwing away the built-up know-how of an existing programming language. Martin Weigele FB Informatik, Uni Hamburg, Germany
phil@Neon.Stanford.EDU (Phil Stubblefield) (02/12/91)
In article <weigele.666261076@bosun2> weigele@bosun2.informatik.uni-hamburg.de (Martin Weigele) writes: >As a least common denominator, Common Lisp was then created to be as >compatible as possible with the existing lisp families. > >Nowadays, I think that Common Lisp has become a dinosaur because of the >incredibly many features built in - also known as "creeping featurism" - >as a result of the desire to be as compatible as possible. Languages >like scheme seem much "cleaner" and "nicer". Recently I've been rereading Tracy Kidder's _The_Soul_of_a_New_ _Machine_. (For the uninitiated, it's about Data General's attempt to develop their first 32-bit machine, partly in response to the then-new VAX.) At one point, a microcoder for the Eagle project was talking about how wonderful was the VAX's complex and powerful instruction set. Having taken a computer architecture class from one of the Stanford RISC proponents, my thoughts were, "Microcode? CISC? Bleah!" What does this have to do with Lisp, you ask? Well, it occurred to me that there are some parallels between the two stories. The VAX was the logical outgrowth of some of the theories of the day about machine design. A quick glance through my VAX-11 Programming Card reveals 325 separate assembler mnemonics, including thirty "Branch on <condition>" instructions, fifty type conversion instructions, and even four instructions for performing queue operations using hardware locking! The table titled "Assembler Notation for Addressing Modes" contains sixty entries, including "@L^12(R10)[R11]", for "forced longword displacement deferred indexed". Talk about "creeping featurism"! In terms of size, this was (and is) truly a Common-Lisp-sized architecture. In addition, the VAX was designed to be as compatible as possible across the entire family line, and also upwards compatible with the PDP-11, at least for the VAX-11's. I think this is an interesting comparison to Common Lisp's desire "to be as compatible as possible with the existing lisp families." In contrast, it seems that Scheme is to Common Lisp what the new RISC wave is to the VAX. Scheme seems like a cry of "Enough already!" to the complexities of Common Lisp, although I know far too little about Scheme to ascibe motives to its designers. (BTW, I program in Common Lisp almost exclusively, and would hate to have to switch to a non-Lispish language.) -- Phil Stubblefield (415) 325-7165 Rockwell Palo Alto Laboratory phil@rpal.rockwell.com
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/12/91)
In article <weigele.666261076@bosun2> weigele@bosun2.informatik.uni-hamburg.de (Martin Weigele) writes: >Nowadays, I think that Common Lisp has become a dinosaur because of the >incredibly many features built in - also known as "creeping featurism" - >as a result of the desire to be as compatible as possible. Languages >like scheme seem much "cleaner" and "nicer". But even scheme lacks the >kind of type support available in the modula/pascal/oberon language family, >or in languages like ML. I'm glad it doesn't have the kind of "type support" available in Pascal. ML is reasonably flexible as far as types are concerned, but lacks too many things (eg, much in the way of I/O, a good macro mechanism). In short, Lisp still wins. If you want something smaller and cleaner than CL, try Scheme. BTW, the idea that CL has too many features out of a desire to be compatible with older dialects isn't quite right. For example, the scoping rules in CL are a cleanup and generalization of those in (compiled) MacLisp, not (as some have supposed) a mix of things from different dialects. -- jd
alms@cambridge.apple.com (Andrew L. M. Shalit) (02/12/91)
In article <1991Feb11.204514.19880@Neon.Stanford.EDU> phil@Neon.Stanford.EDU (Phil Stubblefield) writes:
In contrast, it seems that Scheme is to Common Lisp what the new RISC
wave is to the VAX. Scheme seems like a cry of "Enough already!" to
the complexities of Common Lisp, although I know far too little about
Scheme to ascibe motives to its designers.
This is an interesting comparison, but I think there's an important
difference to keep in mind. In theory, no one is supposed to have to
write much RISC assembler code. Everyone is supposed to write in a
"higher level language" (read as: "C"). Only the compiler authors
need to know about the arcane simplicity of the instruction set.
In contrast, Lisp (whether Common Lisp or Scheme) is supposed to be a
language that people actually use day to day for programming. The
common complaint about Scheme is that it is too small for real work,
that it needs lots of libraries.
I think the problem with Common Lisp is a combination of size,
redundancy, and inconsistancy. So, maybe there *is* a parallel
after all :-)
(BTW, I program in Common Lisp almost exclusively, and would hate to
have to switch to a non-Lispish language.)
Congratulations!
-andrew
--jeff@aiai.ed.ac.uk (Jeff Dalton) (02/12/91)
In article <1991Feb11.204514.19880@Neon.Stanford.EDU> phil@Neon.Stanford.EDU (Phil Stubblefield) writes: >In addition, the VAX was designed to be as compatible as possible >across the entire family line, and also upwards compatible with the >PDP-11, at least for the VAX-11's. I think this is an interesting >comparison to Common Lisp's desire "to be as compatible as possible >with the existing lisp families." > >In contrast, it seems that Scheme is to Common Lisp what the new RISC >wave is to the VAX. Scheme seems like a cry of "Enough already!" to >the complexities of Common Lisp, although I know far too little about >Scheme to ascibe motives to its designers. I like the CL : CISC :: Scheme : RISC analogy. However, I think it's worth bearing in mind that Common Lisp wasn't meant to include everything from every Lisp or to be a union of (all good features of) all Lisps. Indeed, some people have criticized the CL designers for making a MacLisp sucessor and not paying enough attention to the rest of the Lisp world (eg, InterLisp, PSL, Lisp/VM), although they aren't necessarily arguing for CL to be bigger.
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (02/13/91)
Nowadays, I think that Common Lisp has become a dinosaur because of the
incredibly many features built in - also known as "creeping featurism" -
as a result of the desire to be as compatible as possible. Languages
like scheme seem much "cleaner" and "nicer". But even scheme lacks the
kind of type support available in the modula/pascal/oberon language family,
or in languages like ML.
Your statement seems to imply that there is consensus that such type
systems are desirable. Some of us in the Scheme community, and I bet
many in the Lisp community, view such type systems as a step
backwards, not forwards. I realize that this is a matter of taste,
but there are good arguments for both kinds of type systems. Rather
than choosing one over the other, it's even better to have a choice,
so don't look for the ultimate language, because it would probably be
a dinosaur or boring.jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (02/13/91)
In contrast, it seems that Scheme is to Common Lisp what the new RISC
wave is to the VAX. Scheme seems like a cry of "Enough already!" to
the complexities of Common Lisp, although I know far too little about
Scheme to ascibe motives to its designers.
Although reducing the size of the instruction set and addressing modes
seems to be a performance win in architecture, it is not clear that
reducing the size of a programming language is desireable. The real
question is what the expressive power of the language is and whether
Scheme "gives up" some of Common Lisp's expressive power. I don't
think the answer is clear.
In other words, richer languages don't necessarily mean slower or
worse languages, while it seems that richer instruction sets mean
slower machines.
I am firmly in the Scheme community but often envy Common Lisp
constructs and features.scheng@ccwf.cc.utexas.edu (David Boles) (02/13/91)
In article <JINX.91Feb12132549@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu writes: >In other words, richer languages don't necessarily mean slower or >worse languages, while it seems that richer instruction sets mean >slower machines. Not necessarily, the IBM RIOS processor delivers more performance per Hz than any other processor used in a box and it has more than 180 instructions. RISC indeed :) -- David Boles apas611@hermes.chpc.utexas.edu
davis@barbes.ilog.fr (Harley Davis) (02/13/91)
In article <weigele.666261076@bosun2> weigele@bosun2.informatik.uni-hamburg.de (Martin Weigele) writes:
Nowadays, I think that Common Lisp has become a dinosaur because of the
incredibly many features built in - also known as "creeping featurism" -
as a result of the desire to be as compatible as possible. Languages
like scheme seem much "cleaner" and "nicer". But even scheme lacks the
kind of type support available in the modula/pascal/oberon language family,
or in languages like ML.
I'd like to point out EuLisp, under development here in Europe. It is
a multi-layered, Scheme-like language with an extensible class system,
generic functions, and modules. At its lowest level, level-0, it is
small like Scheme. At higher levels, more interesting and complex
CommonLisp-like functionality is added, including a metaobject
protocol for the object system, and many libraries.
You can get more information about EuLisp, including the latest
version of the specification (subject to change at any time) and a PD
implementation, by sending mail to eudist@maths.bath.ac.uk.
EuLisp is not yet finished, but I think it points the way toward a
plausible future for Lisp, supporting both the complex, high-level
applications with rapid development cycles we are used to in Lisp, and
commercially viable delivery systems.
-- Harley
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: davis@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, Francelkramer@brahms.udel.edu (Laurence Kramer) (02/14/91)
Anybody in a research AI lab type environment that is programing in C rather than Lisp needs their head examined. Lisp is clearly a better prototyping/research environment due to its interactive nature. (Besides other benefits). It is my opinion that the grads and undergrads that you mentioned are prob- ably programming in C because they don't know any better (i.e., have done most of their academic coursework in C, and been only briefly exposed to Lisp). Enough of the diatribe. As to your question: We at Quantum Software (a smallish software house specializing in AI applications) do 90% of our coding in Lisp. The other 10% is in C, primarily for the systems' related aspects of our programs. We also use C to "hand compile" some functions within our Lisp deliverables which are particularly time critical. Larry
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/15/91)
On 12 Feb 91 18:25:49 GMT, jinx@zurich.ai.mit.edu (Guillermo J. Rozas) said: jinx> The real question is what the expressive power of the language is jinx> and whether Scheme "gives up" some of Common Lisp's expressive jinx> power. I don't think the answer is clear. I beg to disagree. To my it is *clear* that the expressive power of Scheme, with all the options, is superior to that of CL, as Scheme can do things that CL cannot do in any way. Note that I am not saying that Scheme can do everything that CL can do *in the same way*; some rewriting may be needed. But there are things that Scheme can do that CL cannot do under any rewriting. jinx> In other words, richer languages don't necessarily mean slower or jinx> worse languages, while it seems that richer instruction sets mean jinx> slower machines. If they are richer, not just bulkier because they include, like the abominable Ansi C, the libraries in the language definition. Just look at this: the Scheme report, for the core language, and it is one that includes (optional) rationals and complexes (arrgggh!), is well under a hundred pages; the CL one is well over a thousand. Nearly two orders of magnitude. Does this make CL almost two orders of magnitude "richer" or "more useful", whatever your metric is, than Scheme? Hardly... jinx> I am firmly in the Scheme community but often envy Common Lisp jinx> constructs and features. Maybe you just envy the CL libraries -- well, many Scheme implementations do have libraries as rich as those of most any CL system; T, and obviously CScheme, that you probably are using, come to mind. What little is missing can be usually implemented quite easily and quickly, with much less verbiage than in CL. CLOS? Well, I have just reread Abelson & Sussman (generics and packages), and there is something similar there. Not as fanatically overspecified as CLOS, but, incredibly, not that distant from it. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/16/91)
In article <PCG.91Feb15143111@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >jinx> The real question is what the expressive power of the language is >jinx> and whether Scheme "gives up" some of Common Lisp's expressive >jinx> power. I don't think the answer is clear. > >I beg to disagree. To my it is *clear* that the expressive power of >Scheme, with all the options, is superior to that of CL, as Scheme can >do things that CL cannot do in any way. What Scheme has that CL lacks is (full) call/cc and the exact/inexact distinction for numbers. Or is there something else I'be forgotten. Here are some things I can do in CL but not scheme. I don't think it matters that much whether they're part of expressive power or not. 1. Macros (soon to be fixed). 2. Definition of a new, distinct data type. 3. Eval. > Note that I am not saying that >Scheme can do everything that CL can do *in the same way*; some >rewriting may be needed. But there are things that Scheme can do that CL >cannot do under any rewriting. Well, you can do a rewriting to get call/cc. It's not a simple rewriting, but it's a rewriting. (I'm thinking of CPS conversion.) >jinx> I am firmly in the Scheme community but often envy Common Lisp >jinx> constructs and features. > >Maybe you just envy the CL libraries -- well, many Scheme >implementations do have libraries as rich as those of most any CL >system; T, and obviously CScheme, that you probably are using, come to >mind. What little is missing can be usually implemented quite easily and >quickly, with much less verbiage than in CL. There's all kinds of stuff in CL that isn't in T. And CLOS, for example, cannot be implemented quite easily and quickly. (To be fair, there are also things in T that are not in CL and that could not be implemented easily and quickly.) >CLOS? Well, I have just reread Abelson & Sussman (generics and >packages), and there is something similar there. Not as fanatically >overspecified as CLOS, but, incredibly, not that distant from it. Maybe you don't like CLOS. Ok. But don't confuse that with other issues. CLOS cannot be implemented easily and quickly in Scheme (nor, for that matter, in a Common Lisp that doesn't already have it). The stuff in Abelson and Sussman can be implemented easily and quickly in Common Lisp. -- jd
grant@hqda-ai.UUCP (Pete Grant) (02/19/91)
In article <18736@brahms.udel.edu>, lkramer@brahms.udel.edu (Laurence Kramer) writes: > Anybody in a research AI lab type environment that is programing in > C rather than Lisp needs their head examined. Lisp is clearly a better > prototyping/research environment due to its interactive nature. (Besides > other benefits). > Right on. Lisp is still the King when it comes to rapid software development, especially in those situations where the goals are not clearly defined. At the Army AI Center, we use Lisp almost exclusively for our work. There's no way we could achieve anywhere near the same productivity using C or any other "conventional" systems. > It is my opinion that the grads and undergrads that you mentioned are prob- > ably programming in C because they don't know any better (i.e., have done > most of their academic coursework in C, and been only briefly exposed to > Lisp). > Yes, to be productive in Lisp, one must be proficient in it. Proficiency in any language takes time and practice -- and Lisp is no exception. I'm going into my 6th year of Lisp programming and am still learning (and getting better), although the learning curve has flattened considerably.
marti@mint.inf.ethz.ch (Robert Marti) (02/19/91)
In article <1991Feb18.082559@disuns2.epfl.ch> baechler@disuns2.epfl.ch (Emmanuel Baechler) writes: > Here, we are still using Common Lisp for all our work, and there is no > consideration to "go back" to a classical language like C++. I'm amazed to learn that C++ is a "classical" language. It certainly isn't a classical language in my book, so what exactly is your definition of a classical language? A strongly-typed language? An imperative language? A language for which (almost) no interpreters exist? (Note that all of this is true for C++, even though C++ is more of an object-oriented than an imperative language -- if used correctly.) > I know that, theoretically, all languages are equivalent, An interesting statement, especially in conjunction with your remark on the expressive power of CommonLisp vs Scheme below. > but I am convinced that without lisp our programs would be unmanageable. What evidence do you have to support the above statement? Have you actually compared at least one nontrivial Lisp application (say >10000 lines of code) with the same application written in another language? (You may want to look at "C++ versus Lisp: A Case Study", by H. Trickey, SIGPLAN Notices Vol.23, No.2, February 1988, pp.9-18. Note that I do not claim that Trickey's findings generalize to _all_ applications, though.) > In addition, the environment of a Lisp Machine help us a lot. I don't doubt this for one minute. However, there are quite a few impressive programming environments for other languages running on "stock" hardware as well. > I don't know whether Scheme has really more expressive power than CL. Didn't you just tell us that "all [sic!] languages are equivalent"?! While I readily agree that Lisp is a very useful language for certain kinds of applications -- after all, I teach Scheme in one of my lectures -- I object to the above sweeping generalizations which appear to be rampant among _some_ people in the AI community. -- Robert Marti | Phone: +41 1 254 72 60 Institut fur Informationssysteme | FAX: +41 1 262 39 73 ETH-Zentrum | E-Mail: marti@inf.ethz.ch CH-8092 Zurich, Switzerland |
sam@esl.com (Samuel S. Hahn) (02/20/91)
Greetings... I don't know who started this (I'm late to this particular discussion) but I must also go on record that there is much in my department that is quite dependent on Lisp. In fact, I'd prefer that more of my staff have Lisp expertise, because of what I know to be true regarding the productivity of Lisp environments and programmers, and what is tractable using the environment that I wouldn't seriously consider using C or other languages. In specific, there are two subsystems to my current project which are implemented in Lisp. One is a document analysis tool, the other a smart database-cognizant "stuffer" tool. Other components to the total system are implemented in C and Objective-C, but I don't think we would have been quite so successful trying these two in anything other than Lisp. What's important to us are the tools in the environment, the incremental nature of Lisp development, and therefore the actual productivity of my Lisp developers. In addition, there are constructs and concepts in Lisp that aren't quite so strongly embodied in most other languages, so that I find Lisp-cognizant staff are quite a bit more literate in language issues than most that don't have a Lisp background. -- Sam Hahn (sam@esl.com)
mpearson@twilight.gatech.edu (Mark Pearson) (02/21/91)
I've enjoyed following this discussion.
Just to assure you that LISP is not "dead", we
are currently implementing a LISP programming
environment on top of Clouds, a distributed operating
system in development here at Georgia Tech.
The implementation is written in (C)C++, a Clouds
derivative of C++. In this implementation, instances of
user programming environments and knowledge bases which
encapsulate distinct behaviors are stored as large-grained
persistent objects, enabling many users on many
machines to share these environments and knowledge
bases via inter-environment evaluations. Further, these
LISP objects plug and play with other large grained objects
implemented in CC++ and Eiffel (a heap-based, object-oriented
language).
The fact that a group of Operating System researchers
are interested in LISP, and the things it can do in a
distributed system, should put to rest all notions
that LISP, and its derivatives are on the way out.
-Mark Pearson
Mark Pearson, Distributed Systems Group/Clouds Project, College of Computing
Georgia Institute of Technology, Atlanta, Georgia, 30332-0280 404-853-9390/1
uucp : ...!{akgua,decvax,ihnp4,ulysses}!gatech!helios!mpearson
Internet: mpearson@cc.gatech.edu
Mark Pearson, Distributed Systems Group/Clouds Project, College of Computing
Georgia Institute of Technology, Atlanta, Georgia, 30332-0280 404-853-9390/1
uucp : ...!{akgua,decvax,ihnp4,ulysses}!gatech!helios!mpearson
Internet: mpearson@cc.gatech.edujeff@aiai.ed.ac.uk (Jeff Dalton) (03/18/91)
In article <25595@neptune.inf.ethz.ch> marti@mint.inf.ethz.ch (Robert Marti) writes: >> but I am convinced that without lisp our programs would be unmanageable. > >What evidence do you have to support the above statement? Have you >actually compared at least one nontrivial Lisp application (say >10000 >lines of code) with the same application written in another language? >(You may want to look at "C++ versus Lisp: A Case Study", by H. Trickey, >SIGPLAN Notices Vol.23, No.2, February 1988, pp.9-18. Note that I do >not claim that Trickey's findings generalize to _all_ applications, >though.) But you think they're true of _his_ application? That is, if someone else performed the same experiment they'd get the same result? Indeed, when someone says "our programs would be unmanageable" you need some evidence that those very programs would be manageable, not that someone once found that they preffered C++ for some other programs. What Trickey says is extremely misleading as a guide to what's true, as opposed to how things appear to someone who prefers C++ to Lisp. As far as Dickey was concerned compile-time type checking was the most important difference, and it appears that he would decide against Lisp no matter what Lisp implementations do so long as that difference remained. A common pattern in his observations is to say Lisp has feature X, but he could code up something in C++ that was nearly as good and after this initial effort the advantage to Lisp was essentially removed. Ok, so in his view print functions are just as good as an inspector, but this is hardly something with which everyone will agree. Moreover, he is strongly influenced by problems with particular implementations of Lisp (eg, the (real) superiority of dbx over the Lisp debugger). He tried to gain a measure of objectivity by trying two implementations, but he was nonetheless comparing implementations rather than languages. I have no objection to people preferring one language over another, and Trickey has good reasons (from his point of view) for preferring C++. What I do object to is the attempt to universalize this judgement. Trickey doesn't do this explicitly, but his article is easily used to that end and goes some way to encourage it.
baechler@disuns2.epfl.ch (Emmanuel Baechler) (03/20/91)
In article <4330@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > In article <25595@neptune.inf.ethz.ch> marti@mint.inf.ethz.ch (Robert > Marti) writes: > >> but I am convinced that without lisp our programs would be > unmanageable. > > > >What evidence do you have to support the above statement? Have you > >actually compared at least one nontrivial Lisp application (say > >10000 > >lines of code) with the same application written in another > language? > >(You may want to look at "C++ versus Lisp: A Case Study", by H. > Trickey, > >SIGPLAN Notices Vol.23, No.2, February 1988, pp.9-18. Note that I > do > >not claim that Trickey's findings generalize to _all_ applications, > >though.) > > But you think they're true of _his_ application? That is, if someone > else performed the same experiment they'd get the same result? > What I am doing is qualitavite reasoning applied to mechanism kinematics. My code is bigger than 1 Meg. It was (and is) difficult to develop. However Lisp proved to be *VERY* helpful to do it. I still claim than doing it with a "classical" (i.e. imperative (and even with an object-oriented extension, C++ remains imperative)) would have been several orders of magnitude more difficult. Common Lisp is not only, functional, object-oriented, and so on, it is EXTENSIBLE, wich allows to describe something in a way corresponding to the problem. As all programming languages have a THEORETICALLY equivalent expressive power, experience showed me that there is a strong difference between theory and prectice, in the sense that some languages allow to express thing more easily than other. This is where Lisp definitely wins. As this difference between theory and prectice has already been discussed a lot, I won't go into it any more. I have read than some people are extemely happy to build AI programs in C or whatever else. In a sense, they could also do it in assembly language, which wouldn't be very different. In my opinion this is like people spending their time writing huge programs in assembly langage, because it can be done ansd because one can win 1 femtosecond on a loop wich might be never executed. This is simply not the thing to do, because things are not described at the proper level. E. Baechler AI Lab Ecole Polytechnique Federale de Lausanne MA - Ecublens 1015 Lausanne Switzerland