Slashdot Mirror

Instead of approaching venture capitalists, wouldn't it have been better to do a survey of existing technology?

For example, Xanalys http://www.xanalys.com/ sells exactly this type of software. I'm familiar with Xanalys because, for some time, they were the second largest common lisp vendor -- before a buyout by their programmers. (Their most interesting software is built with common lisp).

Good grief. That's 40 years of DARPA funding majestically dismissed.

This is something that has fascinated me for quite some time, but I don't have the time to start a project do build something like this. I'm interesting in combining tools such as those from Xanalys with ECRI.
I'd like to see geotagged items tossed into a Watsonish tool that then feeds something like Rigel. I'm not especially interested in crime tracking, but building the tracking systems sounds like fun.
Looking for correlation in apparently unrelated facoids combined with geographic representation and pattern finding. Who could ask for a juicier data mining project?

Again, no further comment, except to note that no one, I mean no one in business computing considers using Lisp.

AMD also uses GNU Common Lisp and ACL2 internally, though they can't reveal any specifics - this is of course the problem with a language that's suited well for the research and development part of the product phase. Who wants to give away what they're doing just to advertise that they're using Lisp?

Of course, if you wanted pretty pictures and "yet another database web interface", try the Stargreen site. But you won't find a lot of people using Lisp on those, for the simple reason that most of that work is cut and paste from a previous project.

(a) I would say that Lisp is easier to master than C++. But "mastering" C++ is mastering endless idiosyncrasies and special cases, while learning workarounds for deficiencies. And when you've expended all that effort doing that, to acknowledge C++'s obvious flaws would be to devalue the effort you expended, so cognitive dissonance sets in and you become a rabid C++ advocate...

(b) Lisp's reputation suffered heavy damage (unjustly) due to its association with AI. The 80s AI hype was the .com hype of its time. Lisp is only now recovering, really.

(c) The division between Scheme and Common Lisp befuddles people. They're both really part of a wider "lisp" platonic ideal, but very different in many ways - in particular, CL offers much better support for large system development, while scheme values purity above all else.

(d) Lots of people repeat obsolete stuff about Lisp that is no longer true. Yes, Lisp was a resource hog once. Compared to Java, it's certainly not. Yes, lisp once only had lists - in the 1960s! Yes, lisp once only had dynamic scoping. That changed with scheme and common lisp. Yes, lisp once only had dynamic typing. That changed with common lisp. Yes, lisp can be used for functional programming. Because it can be, it is often used to teach it - but it can also do OO, data-directed and procedural programming!

(e) Lisp isn't exactly fading. It's got an active user community, new stuff is still being done in it, and the Open Source Lisp community is increasing its visibility a lot these days - e.g. the McCLIM GUI subsystem is shaping up very nicely.

(f) If Lisp used for server-side apps, you won't know unless someone chooses to tell you. xanalys' biggest customers are intelligence agencies. Not reknowned for shouting from the hilltops what technologies they use. Xanalys is doing very well for itself, all the same.

(g) Marketers have found they can "sell" languages. C# and Java are both deeply flawed languages from a technical perspective. But they're both hyped so hard there are whole internet-generations (2 years) of programmers who really think they are all there is - and it doesn't help that corporate programmers are usually told what language to use by their PHB, rather than being allowed choose the best language for the job.

The "lack of commercial CL success" meme has GOT to die. CL is used for very high-value commecial systems. Apps written in CL are used by law firms, intelligence, security and police agencies worldwide as an investigative aid, it's used to get your airline tickets ready, it's used to do all sorts of HARD stuff. The stuff that other people look at and go "not possible with today's technology" or "you'll need a human to do that."

No, it's not hyped like Java, but I confidently predict that in 40 years time Lisp will still be around (as will Fortran...). Lisp is one of the oldest computer languages, but it has continuously evolved, and is still evolving today.

It's pretty pathetic to see the XML and scripting-language-du-jour communities discover problems that Lisp solved years ago, reinvent/steal solutions to those solved problems, then hype the solutions as big new "wins"...

Why not just use Common Lisp? It has a lot of users, and it has garbage collection, and macros (like templates done right). It's object oriented, too.

Only? Them's mighty strong words, bubba!

You might want to check out Common Lisp. See these links before you make a fool of yourself.

You could also qualify the statement to be something like: `` ... only buzzword-compliant language ... ''

p.s. Notice that I've accepted the proposition that c++ is a high-level language. I probably should have pointed out that that's a questionable assertion. Roll-your-own garbage collection is not high-level!

Almost true, but much truer of Scheme than Common Lisp.

Common Lisp is emphatically not a purely functional language, its proponents will tell you it's "multiparadigm", and it's not all that unusual to see explicit loop constructs and other imperative stuff in production code. Sometimes the imperative form really is the more natural way to express something.

CL really gives you the best of most worlds in programming.

Scheme isn't purely functional either, but does tend to steer you toward functional programming more than CL, but largely through dropping stuff than Common Lisp programmers tend to find useful...

Moreover, I don't believe that you're correct. Lisp AFAIK started out as a functional programming language, and Common Lisp added objects much later.

He claimed that Common Lisp specifically (and not Lisp in general) was to provide an OO environment. From the history in the Hyperspec, object-oriented ideas in general were find their way into the Lisp world by the late 70s. While (as far as I can tell; I wasn't really old enough to be around the community at the time) the 1984 definition of Common Lisp didn't include CLOS, clearly people were thinking about it and the problems that had to be solved in getting an object system that would be as compatible as possible with the variety of object systems that had cropped up. (A little more information about this period can be found in Keene's book on CLOS, or in AMOP.) CLOS was officially adopted into Common Lisp in 1988 and appears in the second edition of Steele. It has always been part of the ANSI standard. Since the latter is what people mean when they casually say "Common Lisp" nowadays, I think it's fair to say that having OO facilities was a part of the goal of Common Lisp.

Also, in the history from the Hyperspec we find the following:

In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.

So at very least we have to conclude that by 1986 that this was one of the design goals of Common Lisp

I can't tell whether you're being sarcastic or whether you really don't know about Common Lisp. Dynamic, strong typing, compilers and interpreters, great IDEs and debuggers, easy runtime modification and incremental compilation, flexible and powerful object system (including multiple-inheritance, multiple-dispatch, method combination... and the ability to modify its behavior), macros that have the full power of the language, etc...

Also see CLiki and The Common Lisp Hyper Spec

I've just recently finished researching the available CL implementations, and their relative merits and for my needs Franz Inc's) Allegro CL product was most appropriate, but there are other offerings from Xanalys and the opensource CLISP and CMU-CL to consider as well.

Please do post what your eventual decision is, it'd be useful for some of us to understand your decision making factors.

You can have all those features and many more if you use a commercial Lisp implementation (the free ones have no decent IDE or GUI yet).
If you have a serious budget, take a look at Allegro Common Lisp. The other choice would be LispWorks, which is a little cheaper and without run-time fees.
They both have an excellent IDE and come with Interface Builders using CLIM, meaning your apps run under Windows, Macintosh and Unix (Motif) without a big hassle using native widgets.

The CLR is based on the concepts of classes and single-dispatch, calling methods that "belong" to a class. Lisp's CLOS is built on multiple dispatch, and can cleanly support prototype object systems. It's hard to retrofit these capabilities onto a class and single-dispatch system, but it's easy to go the other way. Emulating multiple dispatch without the ability to re-compile on the fly leads to slow code.

And, socially, many Lispers see Java, .NET, etc. as shallow attempts to mimic what they've had for over a decade: A portable, reflective, dynamic environment. Java and many of the .NET languages leave out key portions of Lisp. Lisp allows programmers to control how the code is read, translated, and then compiled without leaving the language. You can build infix Lisp in Lisp, with all the tools of Lisp at your disposal. Or you can eschew many of the tools in Lisp, all from Lisp.

The CLR is based on the concepts of classes and single-dispatch, calling methods that "belong" to a class. Lisp's CLOS is built on multiple dispatch, and can cleanly support prototype object systems. It's hard to retrofit these capabilities onto a class and single-dispatch system, but it's easy to go the other way. Emulating multiple dispatch without the ability to re-compile on the fly leads to slow code.

And, socially, many Lispers see Java, .NET, etc. as shallow attempts to mimic what they've had for over a decade: A portable, reflective, dynamic environment. Java and many of the .NET languages leave out key portions of Lisp. Lisp allows programmers to control how the code is read, translated, and then compiled without leaving the language. You can build infix Lisp in Lisp, with all the tools of Lisp at your disposal. Or you can eschew many of the tools in Lisp, all from Lisp.

• Successful Lisp
• Common Lisp Hyperspec(ANSI Standard Text on CL)
• Common Lisp The Language
• Common Lisp: A Gentle Introduction to Symbolic Computation
• On Lisp(great book on lisp macros among other things)

Graham's book is the definitive work on Common Lisp's macro facility, itself one of the prime features that make Common Lisp (not Scheme; there's a big difference) the most powerful language on the planet.
If your only exposure to Lisp has been a one-semester course that covered Scheme, you don't know Common Lisp. Try it before you judge it. Open-source versions are CMUCL for most Unix/Linux platforms and OpenMCL for Linux/PPC and Darwin/MacOSX. The full language spec and reference is online.

Now if somebody would just write as good a book for CLOS...

• Structure and Interpretation of Computer Programs
• Common Lisp HyperSpec
• Common Lisp the Language, 2. ed
• Common Lisp - A gentle Introduction to symbolic computation
• The Scheme Programming language, 2. ed
• Reflections on trusting trust
• Lisp: Good News, Bad News. How to Win Big
• John McCarthy's homepage
• Dennis Ritchie's homepage
• Various classic papers it's a shame ACM never bothered to continue adding to
• Another list of classic papers (this time related mostly to programming language design)
• GTK-Gnome Application Development (not a classic, though, as the field is too young)
• KDE 2.0 Development (not a classic though, as the field is too young)
• Eric Weissteins Mathworld
• Compilers and compiler generators - an introduction with C++ (although I'm not too sure if it deserves being called a classic...)
• Parsing techniques - A practical guide
• Art of assembly language programming (never was a dead tree, but good anyway)
• Paul Carters 386 assembly book (same comment as above)
• An Introduction to Scheme and its Implementation (see comment above)
• How to design programs - An introduction to programming and computing (not a classic, yet!)
• The Gutenberg archives contains much non-copyrighted classic fiction in ASCII format
• Sacred texts has copies of or links to many religious text for various major (or minor) religions

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

Multithreading is found in the commercial Common Lisp environments and in the CMUCL/x86 port. CLOCC maintains several libraries for cross-implementation usage of non-standard features such as networking. CLIM solves the GUI problem, the problem is that there was no free CLIM implementation for a long time due to legal issues. Finally, a free CLIM is being developed: McCLIM and I'm sure they can use help. As for iteration, perhaps your mind has been clouded by Paul Graham; who has an irrational fear of the LOOP macro. The LOOP macro, however, provides one of the most powerful iteration constructs I've seen; and it's not parenthesized like the DO macro is. Example:

(loop for x from 1 to 10 summing x do (format t "~&~A" x))

Prints out a list of numbers from 1 to 10 and the sum of them all at the end.
The equivalent DO:

(let ((sum 0))
(do ((x 1 (1+ x)))
((> x 10) sum)
(incf sum x)
(format t "~&~A" x)))

Also the LOOP macro provides yet more keywords for all sorts of handy features which aren't so easy to do with DO; collecting, appending, finally, initially, if/else, etc... Please read the section in the HyperSpec about LOOP, Section 6.1
I even once wrote a finite-state-machine entirely within a single LOOP macro that processed the Unix mbox format. It's quite nearly a language in itself (speaking of which, FORMAT is in a similar category, except for formatted output instead).

I would argue that CL is better at bit-twiddling than C is. Take a look at the CLHS Section 12.1.1.3.2 and the functions BYTE, LDB, and DPB. It's a different perspective than the C view, but more interesting since you can extract and replace any number of bits that you want. Also it's not dependent on 8 bits per byte.

Still, there are many areas where CL just doesn't have the sheer effort put into the libraries, likely due to the lack of manpower. Particularly in the Free-software category; Lisp has a tradition extending long before the current wave of Free-software and while many commercial vendors will provide good support and lots of libraries, the Free implementations often lack this. Many Lisp programmers use the commercial Lisps and have the features they want; if not they ask/pay the vendor to implement them. Another issue is that Common Lisp is not Unix-centric, unlike *ahem* most popular languages today. CL was designed to be workable in any environment, so the designers could not take shortcuts with things like pathnames, executable formats, system libraries, or other system-dependent issues. After all; Common Lisp was conceived in the era of the Lisp Machine. Unix was just another OS in the vast array. Finally, it is unfair to compare the Common Lisp standard against a single-implementation language such as Perl. Standards cost $$$$$ and require a great deal of effort and responsibility. If a Common Lisp implementation does not comply with the standard then it is at fault. But with Perl, whatever Larry Wall does goes. Even if it breaks all your code; too bad.

Some interesting sites with regard to libraries:

• CLiki
• cCLan

(Back to the OP's topic) Franz's Success Stories has plenty of examples of Lisp applications. Franz develops Allegro Common Lisp, a popular commercial CL.

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

Multithreading is found in the commercial Common Lisp environments and in the CMUCL/x86 port. CLOCC maintains several libraries for cross-implementation usage of non-standard features such as networking. CLIM solves the GUI problem, the problem is that there was no free CLIM implementation for a long time due to legal issues. Finally, a free CLIM is being developed: McCLIM and I'm sure they can use help. As for iteration, perhaps your mind has been clouded by Paul Graham; who has an irrational fear of the LOOP macro. The LOOP macro, however, provides one of the most powerful iteration constructs I've seen; and it's not parenthesized like the DO macro is. Example:

(loop for x from 1 to 10 summing x do (format t "~&~A" x))

Prints out a list of numbers from 1 to 10 and the sum of them all at the end.
The equivalent DO:

(let ((sum 0))
(do ((x 1 (1+ x)))
((> x 10) sum)
(incf sum x)
(format t "~&~A" x)))

Also the LOOP macro provides yet more keywords for all sorts of handy features which aren't so easy to do with DO; collecting, appending, finally, initially, if/else, etc... Please read the section in the HyperSpec about LOOP, Section 6.1
I even once wrote a finite-state-machine entirely within a single LOOP macro that processed the Unix mbox format. It's quite nearly a language in itself (speaking of which, FORMAT is in a similar category, except for formatted output instead).

I would argue that CL is better at bit-twiddling than C is. Take a look at the CLHS Section 12.1.1.3.2 and the functions BYTE, LDB, and DPB. It's a different perspective than the C view, but more interesting since you can extract and replace any number of bits that you want. Also it's not dependent on 8 bits per byte.

Still, there are many areas where CL just doesn't have the sheer effort put into the libraries, likely due to the lack of manpower. Particularly in the Free-software category; Lisp has a tradition extending long before the current wave of Free-software and while many commercial vendors will provide good support and lots of libraries, the Free implementations often lack this. Many Lisp programmers use the commercial Lisps and have the features they want; if not they ask/pay the vendor to implement them. Another issue is that Common Lisp is not Unix-centric, unlike *ahem* most popular languages today. CL was designed to be workable in any environment, so the designers could not take shortcuts with things like pathnames, executable formats, system libraries, or other system-dependent issues. After all; Common Lisp was conceived in the era of the Lisp Machine. Unix was just another OS in the vast array. Finally, it is unfair to compare the Common Lisp standard against a single-implementation language such as Perl. Standards cost $$$$$ and require a great deal of effort and responsibility. If a Common Lisp implementation does not comply with the standard then it is at fault. But with Perl, whatever Larry Wall does goes. Even if it breaks all your code; too bad.

Some interesting sites with regard to libraries:

• CLiki
• cCLan

(Back to the OP's topic) Franz's Success Stories has plenty of examples of Lisp applications. Franz develops Allegro Common Lisp, a popular commercial CL.

• Common Lisp does not guarantee tail call optimization, but most decent implementations do it.
• Common Lisp does not guarantee a garbage collector either, but again, most implementations gotta do it ;)
• Tail-recursion is nice, but macros like LOOP with the extended syntax are quite powerful. I would say that Common Lisp is better at iteration than most other languages.
• Your implication that Lisp lacks objects is false. In fact you are wrong: not every type in Java is an object (int, char, etc..). In Common Lisp, every type is an object that has its own identity. You should read Kent Pitman's article on the misappropriation of the term "Object- oriented"
• Also you should read the section of the CLHS that discusses CLOS: The Common Lisp Object System, which is far more powerful object-system than the pathetic Java/C++ one: with multimethod dispatch, method combination, and multiple inheritance. If you feel adventurous, read the Art of the Meta Object Protocol (AMOP) which you can buy for ~ $40, which discusses how to implement CLOS while exposing the internals in a controlled fashion; which allows you to modify the behavior of CLOS easily.
• Yes, Common Lisp is not all there is to Lisp but it is the most widely used one today. Consult the Common Lisp HyperSpec for more information: CLHS

AT&T's Globeview 2000 (an ATM phone switch I think, telecoms is not my speciality) uses Harlequin's (presumably now xanalys) Real Time Lisp (a variant on their ordinary Lisp). It certainly garbage collects in real time meaning their is an upper bound on the length of a pause due to GC and a guarantee of maximum CPU overhead due to GC.

Those resources might be valuable, but so is the ability to add a new voicemail service to your phone switch without dropping existing calls (which rebooting the switch would do).

Here's a press release with some marketing details

Lisp doesn't need to be slow at all. You're thinking of the old 70's Lisp, which was usually interpreted and ran slowly. Today's Lisp implementations can also be compiled in addition interpreted, which results in a big performance boost (lagging only slightly behind C, but faster then Java). Commercial Lisps capable of compiling are for example Allegro CL and LispWorks.
This isn't limited to the commercial ones: CMUCL and SBCL do also compile to native code. The compilers are optimizing (you can choose between variying degrees of Speed, Safety, Debugability and Compile Speed) and you can even enter Assembler code or disassemble single expressions.

That way the sets of "library stuff" already existant could be used, and they're not left re-implementing everything from the compiler on down...

That way the sets of "library stuff" already existant could be used, and they're not left re-implementing everything from the compiler on down...

That way the sets of "library stuff" already existant could be used, and they're not left re-implementing everything from the compiler on down...

This remark on my part might ordinarily seem off-topic, but the credential of my previous remark was challenged so I feel I need to add some defense. This will be my only response on the matter of credential.

I have spoken to him on this matter at length, just not recently. I was at the MIT AI Lab when he was there, and am well familiar with him personally, even if you could not call us friends. He called my house on the phone once to berate me once because I had created a document that was being distributed free of charge but not free-like-he-likes and he was annoyed. I tried to make a case that my document could not have been made available free-like-he-likes, and that the distribution mode I had created was the best that could be done under the circumstances. I said that I thought that it benefited the world just fine as it was, and that it was better than my not doing it. He disagreed and told me flat out that his interest was not in benefiting the world, but in having something that he personally could use. He told me exactly what I said before, that benefiting the world was of no value to him because it was full of people he didn't care to benefit. He would rather it have benefited fewer people and have those be the people who agree with him, and in particular he was irritated that he personally couldn't use it and would have to duplicate my effort to make something to use. It seemed not to matter to him that if I'd not done the project (my only other choice), he still would have had to duplicate my effort, and might not have thought of doing so, and that other people have benefited.

I've had a number of run-ins with him of this kind, and don't really expect him to have changed. I, however, carefully qualified my remarks to say that my data was old, and you are welcome to believe he has changed if you have more modern data. I just doubt that you are right if all you are working form is public talks and not personal interchanges where you have been able to ask probing questions on subtle matters.

I did not, as one moderator seems to suggest, offer my prior remarks as "flamebait". I don't really care what people think of Stallman personally, and have no desire to misrepresent him. The information I offered is, to the best I could, information he offered freely to me. He as much as told me that he's out to help himself and his way of life and that was that. He made no attempt to hide that. So neither did I.

I offered the information (a) because people seem mystified by him, and I just don't think he's that mystical, and (b) because he offers himself as a political figure, and I think the motives of political figures do require some discussion because it relates to whether those they represent will, in fact, be properly represented.

I have always said "There are no political answers, only political questions." If the question of whether he is a good person to guide a political movement is a non-flamebait question, then either possible answer should be a non-flamebait answer. If one can only say yes and not no, you have to question the bias inherent in the forum. I'm quite disappointed in Slashdot on this one. I don't think "flamebait=1, interesting=2, insightful=2" is best summarized as "Flamebait, Score=4".

I don't suppose it matters that Common Lisp has had accessors and SYMBOL-MACROLET since, well, forever, does it? *sigh*

I don't suppose it matters that Common Lisp has had accessors and SYMBOL-MACROLET since, well, forever, does it? *sigh*

Re: I haven't done usability testing with programming languages. But I can guess what you'd find if you did:

• One statement per line aids readability.
• 30 lines of short, simple statements are easier to read than 10 longer, more complex lines.

I'm not into hard-and-fast rules but I don't think these two points are radically inconsistent with most style I see observed in Lisp code. Lisp doesn't have a statement concept, but things very like statements do typically occur on their own line. People don't start blocks and put all the subexpressions on one line, though they could. So, to be honest, I have no idea what you're getting at here. I see nothing Lisp does to really push against this issue one way or another. The comment seems equally applicable to C, even though there, too, people by choice tend not to do the thing the language would let them and that you seem to fear.

• A distinction between statements and expressions aids readability.

Of your various "style rules", this is the only one that I could clearly say there's a parting of opinion on. Now, I know parsing reasons for making this distinction. And perhaps there are teaching reasons. But I've never heard it asserted that this was a readability issue and I'd like some exposition here in order to understand your motivation (both so I can reply and also just because I'd be fascinated simply to understand your reasoning on this in general).

There could be a readability issue here, but a priori I don't see one. In fact, my experiences with things like HyperTalk and this statement/expression issue, since there you have to say for each function which kind you are making, is that you often end up with things that are nominally intended to be expressions but that you want to use as statements. So you do "get foo()" just to make an expression into a statement, even though you plan not to use the "it" variable that "get" sets up.

I find the statement/expression distinction to be tedious and pointless as an enforced mechanism. Though in practice, again, Lisp programmers often have certain expressions they tend to think of as kind of statement-like and so tend not to embed in well-styled code. So again I don't see a problem.

• Deeply nested code and structures are confusing.

The ordinary use of block structure, and the commonplace use of separating blocks into separate functions, both practices introduced decades ago in Algol and long-practiced not only in Lisp but in most major languages seems to make the issue of deeply nested code not an issue. I'd need to see an example to know what this was about. I don't think Lisp gets a lot more nested than most other languages. Certainly nothing about the language forces this. Unless you want a language like Basic or Assembly that doesn't allow any nesting, I don't see how to avoid at least the possibility, and beyond that it's all just personal taste and personal practice, not language design. Do you see otherwise?

• Flatness is good.

You know, at MIT on a mid-term exam in compiler design 20 years ago, I actually saw a question that was "Gotos are (a) good (b) bad". I was immediately alerted to the fact that Computer Science should probably be better named Computer Religion, since it's often more filled with unfounded religious dogmatism than with science. I believe goodness and badness are things that have to be context-relative. One can't just stop a sentence after the word "good" or "bad" without establishing a context and have anything other than a statement of religion. It may be that flatness is good for some unspecified purpose, and that if you specified that purpose we could talk about it more. But I won't give you unqualified Good® on no more than you've offered here.

• Meaningful error messages help.

I have to say I don't know where this comes from. Lisp has an error system capability that is unmatched by any other language I've seen, and has the best guidelines for writing error messages that I've seen anywhere also. If you want an abstract overview of its capabilities, see my paper Exceptional Situations in Lisp . It is not possible to make a programmable facility that leaves the programmer any discretion at all and not risk that someone will do something obscure, but (again) you can't blame the language for that. As a rule, Lisp error messages, in part because they are object-oriented, and in part because of the power of Lisp's powerful FORMAT facility for producing formatted output, seem to me to be much better than I get in other languages. So I'm not sure what you're talking about here.

Re: I haven't done usability testing with programming languages. But I can guess what you'd find if you did:

• One statement per line aids readability.
• 30 lines of short, simple statements are easier to read than 10 longer, more complex lines.

I'm not into hard-and-fast rules but I don't think these two points are radically inconsistent with most style I see observed in Lisp code. Lisp doesn't have a statement concept, but things very like statements do typically occur on their own line. People don't start blocks and put all the subexpressions on one line, though they could. So, to be honest, I have no idea what you're getting at here. I see nothing Lisp does to really push against this issue one way or another. The comment seems equally applicable to C, even though there, too, people by choice tend not to do the thing the language would let them and that you seem to fear.

• A distinction between statements and expressions aids readability.

Of your various "style rules", this is the only one that I could clearly say there's a parting of opinion on. Now, I know parsing reasons for making this distinction. And perhaps there are teaching reasons. But I've never heard it asserted that this was a readability issue and I'd like some exposition here in order to understand your motivation (both so I can reply and also just because I'd be fascinated simply to understand your reasoning on this in general).

There could be a readability issue here, but a priori I don't see one. In fact, my experiences with things like HyperTalk and this statement/expression issue, since there you have to say for each function which kind you are making, is that you often end up with things that are nominally intended to be expressions but that you want to use as statements. So you do "get foo()" just to make an expression into a statement, even though you plan not to use the "it" variable that "get" sets up.

I find the statement/expression distinction to be tedious and pointless as an enforced mechanism. Though in practice, again, Lisp programmers often have certain expressions they tend to think of as kind of statement-like and so tend not to embed in well-styled code. So again I don't see a problem.

• Deeply nested code and structures are confusing.

The ordinary use of block structure, and the commonplace use of separating blocks into separate functions, both practices introduced decades ago in Algol and long-practiced not only in Lisp but in most major languages seems to make the issue of deeply nested code not an issue. I'd need to see an example to know what this was about. I don't think Lisp gets a lot more nested than most other languages. Certainly nothing about the language forces this. Unless you want a language like Basic or Assembly that doesn't allow any nesting, I don't see how to avoid at least the possibility, and beyond that it's all just personal taste and personal practice, not language design. Do you see otherwise?

• Flatness is good.

You know, at MIT on a mid-term exam in compiler design 20 years ago, I actually saw a question that was "Gotos are (a) good (b) bad". I was immediately alerted to the fact that Computer Science should probably be better named Computer Religion, since it's often more filled with unfounded religious dogmatism than with science. I believe goodness and badness are things that have to be context-relative. One can't just stop a sentence after the word "good" or "bad" without establishing a context and have anything other than a statement of religion. It may be that flatness is good for some unspecified purpose, and that if you specified that purpose we could talk about it more. But I won't give you unqualified Good® on no more than you've offered here.

• Meaningful error messages help.

I have to say I don't know where this comes from. Lisp has an error system capability that is unmatched by any other language I've seen, and has the best guidelines for writing error messages that I've seen anywhere also. If you want an abstract overview of its capabilities, see my paper Exceptional Situations in Lisp . It is not possible to make a programmable facility that leaves the programmer any discretion at all and not risk that someone will do something obscure, but (again) you can't blame the language for that. As a rule, Lisp error messages, in part because they are object-oriented, and in part because of the power of Lisp's powerful FORMAT facility for producing formatted output, seem to me to be much better than I get in other languages. So I'm not sure what you're talking about here.

Re: I haven't done usability testing with programming languages. But I can guess what you'd find if you did:

• One statement per line aids readability.
• 30 lines of short, simple statements are easier to read than 10 longer, more complex lines.

I'm not into hard-and-fast rules but I don't think these two points are radically inconsistent with most style I see observed in Lisp code. Lisp doesn't have a statement concept, but things very like statements do typically occur on their own line. People don't start blocks and put all the subexpressions on one line, though they could. So, to be honest, I have no idea what you're getting at here. I see nothing Lisp does to really push against this issue one way or another. The comment seems equally applicable to C, even though there, too, people by choice tend not to do the thing the language would let them and that you seem to fear.

• A distinction between statements and expressions aids readability.

Of your various "style rules", this is the only one that I could clearly say there's a parting of opinion on. Now, I know parsing reasons for making this distinction. And perhaps there are teaching reasons. But I've never heard it asserted that this was a readability issue and I'd like some exposition here in order to understand your motivation (both so I can reply and also just because I'd be fascinated simply to understand your reasoning on this in general).

There could be a readability issue here, but a priori I don't see one. In fact, my experiences with things like HyperTalk and this statement/expression issue, since there you have to say for each function which kind you are making, is that you often end up with things that are nominally intended to be expressions but that you want to use as statements. So you do "get foo()" just to make an expression into a statement, even though you plan not to use the "it" variable that "get" sets up.

I find the statement/expression distinction to be tedious and pointless as an enforced mechanism. Though in practice, again, Lisp programmers often have certain expressions they tend to think of as kind of statement-like and so tend not to embed in well-styled code. So again I don't see a problem.

• Deeply nested code and structures are confusing.

The ordinary use of block structure, and the commonplace use of separating blocks into separate functions, both practices introduced decades ago in Algol and long-practiced not only in Lisp but in most major languages seems to make the issue of deeply nested code not an issue. I'd need to see an example to know what this was about. I don't think Lisp gets a lot more nested than most other languages. Certainly nothing about the language forces this. Unless you want a language like Basic or Assembly that doesn't allow any nesting, I don't see how to avoid at least the possibility, and beyond that it's all just personal taste and personal practice, not language design. Do you see otherwise?

• Flatness is good.

You know, at MIT on a mid-term exam in compiler design 20 years ago, I actually saw a question that was "Gotos are (a) good (b) bad". I was immediately alerted to the fact that Computer Science should probably be better named Computer Religion, since it's often more filled with unfounded religious dogmatism than with science. I believe goodness and badness are things that have to be context-relative. One can't just stop a sentence after the word "good" or "bad" without establishing a context and have anything other than a statement of religion. It may be that flatness is good for some unspecified purpose, and that if you specified that purpose we could talk about it more. But I won't give you unqualified Good® on no more than you've offered here.

• Meaningful error messages help.

I have to say I don't know where this comes from. Lisp has an error system capability that is unmatched by any other language I've seen, and has the best guidelines for writing error messages that I've seen anywhere also. If you want an abstract overview of its capabilities, see my paper Exceptional Situations in Lisp . It is not possible to make a programmable facility that leaves the programmer any discretion at all and not risk that someone will do something obscure, but (again) you can't blame the language for that. As a rule, Lisp error messages, in part because they are object-oriented, and in part because of the power of Lisp's powerful FORMAT facility for producing formatted output, seem to me to be much better than I get in other languages. So I'm not sure what you're talking about here.

Re: Lisp can integrate very well with UNIX if you let it.

You should have stopped here. Most of what follows is, in my opinion, a hodgepodge of misconceptions and very odd reasoning. Ordinarily, I would let this go and just not respond to such, but a lot of people are reading along and might assume that silence indicates agreement.

Re: I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX

Inferring something bad about Lisp from such a source is ridiculous. That book had some legitimate gripes and picked he vehicle of humor to present them. The CL design tried to be enduring by not presupposing any operating system. We didn't know whether certain OS's would win out, and even now we don't know that the dominant OS's will not be overturned by others. CL is OS-neutral, but designed in a way that allows vendors to flexibly cater to their own chosen host operating systems. Some CL implementation are heavily Unix-centric and the language causes them no impediment in that regard.

If you're going to critique Lisp in this way, be specific. Vague and general insults without substance are not appropriate in this venue.

Re: I hope future Lisp implementations will learn from these past mistakes.

First, present implementations already cater to Unix and other modern operating systems.

Second, something funny about the wording here. Languages make design decisions. Implementations just implement them. Implementations do have some discretion, but in that sense, they already do implement that discretion and have for a while.

I used Lisp to implement my Linux-based web server. I actually did all the development on Windows and it deploys seamlessly on Linux with basically no changes. C is often touted for being highly portable, but every C program I've seen has infinite little conditionals that have to be very different between nearly every platform. I commonly write cross-platform tools for Lisp that don't require any conditionals at all. Xanalys even offers a windowing substrate that uses the same operations for windowing under Windows and Linux/Unix, so that one can do GUIs in a natural way on both systems using the same program interface.

There are many good ideas in CMU CL, but it hardly as a corner on the market for Linux-savvy systems.

and yet a few more (Xanalys). The NASA remote agent is particularly interesting.

Macros are a central part of the Common Lisp experience, and if you had a class or book that didn't teach them, it did you (and our community) a disservice by giving you a false sense of what normal programming is like in CL.

As to the size of the language spec, you should probably read my article Don't Judge a Spec by Its Cover which I wrote while the standard was just a draft and lots of people asked questions like these. There are 978 symbols (defined names) in Common Lisp. The ANSI CL spec, whose online incarnation is most easily accessed as the Common Lisp HyperSpec, is about 1195 printed pages. That's an average of about one page per defined name, a lot of which is examples of how to use them. That doesn't seem unreasonable to me on a per-function basis. Perhaps you'd be happier with fewer functions or fewer examples. Or we could have left out the helpful glossary of Lisp terms that provide a normative effect on the community's terminology. That would make the spec smaller.

I personally don't recommend reading the full spec cover to cover. I never have. I recommend reading the opening few chapters on syntax and evaluation, and then thinking of other chapters as libraries that you can read about as you need them. Then again, the spec is not intended to be a tutorial, people just get confused about that because it is (I'm told) more readable than most language specs. If I'd made it more unreadable, most people would never have approached it (as is the case for most other programming languages), and people would judge the language by tutorial texts. Lisp has a great many tutorial textbooks that are much smaller than the spec; the spec's first responsibility was to be a clear and accurate record of the language definition. The prior definition, Steele's Common Lisp: The Language was more brief, but left some things vague that led to portability problems and required more exposition to get right.

Macros are a central part of the Common Lisp experience, and if you had a class or book that didn't teach them, it did you (and our community) a disservice by giving you a false sense of what normal programming is like in CL.

As to the size of the language spec, you should probably read my article Don't Judge a Spec by Its Cover which I wrote while the standard was just a draft and lots of people asked questions like these. There are 978 symbols (defined names) in Common Lisp. The ANSI CL spec, whose online incarnation is most easily accessed as the Common Lisp HyperSpec, is about 1195 printed pages. That's an average of about one page per defined name, a lot of which is examples of how to use them. That doesn't seem unreasonable to me on a per-function basis. Perhaps you'd be happier with fewer functions or fewer examples. Or we could have left out the helpful glossary of Lisp terms that provide a normative effect on the community's terminology. That would make the spec smaller.

I personally don't recommend reading the full spec cover to cover. I never have. I recommend reading the opening few chapters on syntax and evaluation, and then thinking of other chapters as libraries that you can read about as you need them. Then again, the spec is not intended to be a tutorial, people just get confused about that because it is (I'm told) more readable than most language specs. If I'd made it more unreadable, most people would never have approached it (as is the case for most other programming languages), and people would judge the language by tutorial texts. Lisp has a great many tutorial textbooks that are much smaller than the spec; the spec's first responsibility was to be a clear and accurate record of the language definition. The prior definition, Steele's Common Lisp: The Language was more brief, but left some things vague that led to portability problems and required more exposition to get right.

* (describe 'unwind-protect)

UNWIND-PROTECT is an external symbol in the COMMON-LISP package.
Special form documentation:
Unwind-Protect Protected Cleanup*
Evaluate the form Protected, returning its values. The cleanup forms are
evaluated whenever the dynamic scope of the Protected form is exited (either
due to normal completion or a non-local exit such as THROW).

More information can be obtained from the Hyperspec

Actually your knowledge of Lisp seems to be dated back to the 1960's. It has changed quite a bit, as a quick peruse through the Hyperspec will show.

But it's quite easy to answer whether Perl can do what Lisp does. The answer is no; and anyone who has written a macro in Lisp will tell you the same.

Sure, you can find a Java implementation of a word processor, but will it last as long as Emacs? Is it as flexible? Is it as customizable? Is it as powerful? An Emacs based on Common Lisp (instead of its own crippled Lisp) would be even more of an improvement.

Any Java "word processor" is going to have a hard time beating MS Word at its own game. Emacs, however, thrives by playing another game, the "text editor" game. And it wins.

Lisp has toolkits like Common Lisp Interface Manager (CLIM) which are much more than simple layers to create windows with widgets. I can't even come up with a concise description of how different the Lisp idea is. (Some of this is my lack of practical experience with CLIM. I don't program GUI applications.)

Java is fine for relatively simple, solved problems (like GUI word processors). Lisp is for horrendously complex, hard-to-solve problems like managing logistics for airlines. Or bioinformatics

Or managing information in complex investigations and audits.

You'll notice that all of these are created to solve real-world problems, where it might not be obvious how a computer could help you. Word processing and 3D-shooters are all very securely "inside the box" of what computers are known to do, and have been done many times. Lisp is for taking on the world, forging into new territory, and kicking the world's ass. If you want to stay safe and do "yet another" of the same old thing, maybe Java is all you need.

What's the problem? The purpose of the Common Lisp "loop" macro was to develop an easy, almost English-like way to describe iteration. For those who don't know it, it has a lot of "clauses" to describe the various phases of initialization, stepping, testing, and collecting results, which get combined in an almost free-form way.

It includes things like the C for loop, but a lot more as well. [from the Hyperspec]

(loop for x from 1 to 10
for y = nil then x
collect (list x y))

=> ((1 NIL) (2 2) (3 3) (4 4) (5 5) (6 6) (7 7) (8 8) (9 9) (10 10))

;; Collect numbers larger than 3.
(loop for i in '(1 2 3 4 5 6)
when (and (> i 3) i)
collect it) ; IT refers to (and (> i 3) i).
=> (4 5 6)

You don't have to use LOOP if you don't like it. It is a bit of a mess, when different clauses start interacting, but it can be very clear when the other iteration mechanisms might be more confusing.

How would you prefer the syntax to look?

The right link for XAnalys is actually here (no 'i').

Well, if Graham isn't your cup of tea, you should definitely take a look at Norvig's Paradigms of Artificial Intelligence Programming (which is actually of interest to a much wider audience than just AI people, but I digress). As someone else said, Steele's book Common Lisp: the Language is good, thought it predates the ANSI standard, hence you need to be a little careful. The standard itself (or more likely, the Hyperspec, which you can find online at various places; check for example Xanalys; there should be a copy around there somewhere. You can certainly download it, if not independently, as part of their personal edition of Lispworks) is very readable and informative. For a starting CLOS reference, try Sonya Keene's book Object-Oriented Programming in Common Lisp.

Of those, I particularly recommend Norvig, and recommend that you get a copy of the Hyperspec, which you will quickly find much more useful than the back of Graham's book. You might also want to describe exactly what Lisp system you are using, as this may possibly help us give further advice.

While I would personally rather implement almost anything in Common Lisp than Perl (the primary exceptions being when Perl's CPAN advantage comes into play), I certainly sympathize with your plight; it's hard to imagine why they oughtn't let you implement your projects however you like.

1) Is lisp less amenable to use by a team? Can't you implement one object while I implement another? I'm asking because I don't know; all my programming has been for my own research.

Actually, if Lisp has one major flaw it's that it allows too much flexibility. That, combined with the fact that a lot of Lisp hackers (I've worked with a lot) are extremely bright, can make it hard for us mere mortals to grok their code.

5) I really don't know what an IDE is. I gather it is something other than emacs, since emacs supports nearly every language, some wonderfully well (try ESS for R). I really can't comment on this one at all; perhaps someone else could?

Something that hasn't been mentioned yet is CAPI. A decent cross-platform (Linux and Windows) toolking from Xanalys. Available from http://www.xanalys.com/

Before anyone asks, it is not Free. However it does come as part of the personal edition of Xanalys LispWorks.

You seem to have not touched LISP in the last 20 either. Please check out Common Lisp. Scheme is designed to be small (and slib is not what I would consider a language library.. it's more of an add-on).

Common Lisp HyperSpec (ANSI standard)

It has a massively restricted API.

Java's great strength is that it has a huge set of APIs, all in a unified form, making programming a less repetitive and painful experience. Java is for people who understand that recoding the same search tree three hundred times is not going to make them richer, cooler or a better programmer. LISP is for people with time to waste.

Moderators, if you're still here: please mod this up.

> I find talking about LISP as one language compared
> to Java to be a complete joke. Whose LISP? Scheme?
> Whose version of Scheme, GNU's Guile? Is the Elisp
> in Emacs the most widely distributed
> implementation of LISP? Can Emacs be rewritten
> using Guile? What is the GUI framework for all of
> LISP? Anyone come up with a set of LISP APIs that
> are the equivalent of J2EE or Jini?

There are exactly two dialects of Lisp that have relevance to this discussion.

ANSI COMMON LISP is designed for large application development by a large team of programmers. It is the first object oriented langauge to have an ANSI standard. (circa 1990).

Scheme is a minimalist language designed for ease of learning. It is specified by R5RS.

Specifically what features do you feel that a Lisp such as Lispworks (as Mark mentioned) or Allegro do you feel are missing that makes building multi-threaded applications a problem? For your reference, the chapter of the Lispworks Reference manual describing the MP package is here

Try the free personal version of LispWorks at http://www.xanalys.com/software_tools/downloads/lw -personal-edition.html.

It has great multithreading support under Windows and Linux.

-Mark

• http://www.franz.com/products/
• http://www.xanalys.com/software_tools/products/ide .html

More Lisp vendors:

• http://www.digitool.com/ (Mac)
• http://www.corman.net/

'Free' (whatever the current definition of that is nowadays) Lisps:

• http://clisp.sourceforge.net/
• http://www.cons.org/cmucl/

Well, there isn't static typing in Lisp. There is strong typing, but not static. Some implementations (CMUCL, for example) have some ability to make such static checks. But an implementation needn't, and in fact, may not be able to. For example, in your second example, what if we do (bar (read *standard-input*))? There's no way to know at compile time what type of data read is going to return, so reasonable static checking seems somewhat impossible here.

Also, the second example doesn't have to error. If you look here for example, you will see that if we do something like (bar 0) the spec. declares that the consequences are undefined. If you then check the definitions here, you'll see that this doesn't necessarily mean that an error is signaled. It may be, but it needn't be.