Slashdot Mirror

Er... You're just a little behind the Common Lisp community, I'm afraid. :-)

Type-inferencing Common Lisp compilers exist and are widely used, the prime free example being the excellent CMUCL compiler..

Since Common Lisp allows type declarations, you already have "You can write a fully dynamic program like this by specifying no types. You can write a fully static program by specifying all types. Or, you can use a loose mix of the two that lets you do weak compile-time type checking where you want it, and avoid the hassle where you don't"

(Don't be confused that the compiler itself is called "python" - it was called that long before Rossum's python existed.)

This is not a dig directed at you personally: but an AWFUL LOT of people on /. seem to have misapprehensions about the state of the Lisp language - you STILL get people saying "Lisp is slow and interpreted" and "Lisp only does list processing" and "Lisp is not Object Oriented" and other crap like that.

Please, people, just have a look at Common Lisp before committing another "Lisp doesn't..."

In fact, I only know of one implementation that "only" has a bytecode compiler, CLISP. Last I heard, there are about 15 Lisp systems altogether.

So you need a better excuse for not writing a Ruby compiler right now. :-) Go look at the source code of CMU CL, it has one of the fastest Lisp compilers around, and most of it is in the public domain. (The compiler is called "Python" btw., that may be concern for Ruby people ;-))

"Interpreted" is not the same as "dynamic". You can have both speed and a productive environment.

and it's still one of only a few compilable languages (excepting gcj == java) that have a gc.

There is nothing special about a "compilable language" (whatever that means) using GC. Lisp has been doing it for decades (and yes, most Lisp systems are native code compilers, such as CMUCL, Allegro, CormanLisp, SBCL, etc). Oberon-2 compilers use GC, including the open source OOC and Oberon System3 from ETH. Ada was designed such that GC could be implemented, but it rarely is. Many FP languages use GC, such as Haskell. Haskell compilers, such as GHC, NHC, and HBC all use GC.

If you haven't gotten the point yet, there is nothing special about implementing languages using garbage collection, and furthermore, there was nothing innovative when Meyer decided to use it for Eiffel.

The problem is that the big players priced the Compiler based Common lisp development frameworks right out of the reach of most business developers. They also failed to take full advantage in the increasing capability of the PC, turning their noses up at in favour of past glories of the Symbolics machines. A good Lisp compiler could factor out the "cons", producing code sometimes surpassing the performance of C++.

The void was filled mostly by C++ and now Java, lesser beasts dispite their current quality standard libraries, overly verbose and fragmented incomparison to Common Lisp elegance.

Today there are open implementation of the lisp compilers, but they still lack a comparable development enviroment to the commercial varients. Sadly, since I started professionally in 1988, I have not had one job or contract were they would consider the adoption of Common lisp, and I have never programed professionally in it. David Betz's XLisp, and later XScheme was the closest I came to using it at work for scripting, and at home for some early AI-planning system hacking that has yet to see the light of day.

In my opinion, IBM's Eclipse IDE has finally comming close to surpassing the old benchmark of the commercial Lisp IDEs, it even has the ability to plug in refactoring tools. But then I can remember when, thanks to the "cons"-ed Lisp, manupulating the source of the program was as easy as mainpulating the data,

For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).

There most definitely are Lisp implementations (both Common Lisp and Scheme) that compile to machine code. Two examples are CMUCL and Bigloo. It seems clear from some benchmarks that they easily outperform the likes of Perl, Python, and Java. Note that the previous link won't work if you just click on it, but if you copy it, then put it in the location bar of a new window, it will. It seems the author of the page doesn't much like Slashdot.

You're absolutely right about the power of being able to generate source at runtime and evaluate (run) it. That's one of the things I like about Python as well. In fact, I don't think any language can be considered high-level if it doesn't have that. Guess where this concept originated? In the early implementation (around 1960) of Lisp, a function called "eval" was invented to be the definition of the Lisp interpreter. The details are in "The implementation of LISP".

The nice thing about the compiled lisps is that you also have the compiler available at runtime, which means that you can generate source code dynamically, then compile it. You are no longer bound by the traditional code/compile/run cycle.

I don't know of compilers/interpreters that can make such high level decisions about when to bind and evaluate, but I believe that Lisp allows a lot more flexibility in that area than C-like languages. Also, it looks like Self might offer something in that area. Another class of languages I have yet to explore, but may be far superior on these issues is that of pure functional languages, especially the lazily evaluated ones. I plan to learn one of the ML's eventually, like OCaml.

Unfortunately, as you pointed out, the best tools can't always be used because of external requirements like programmer or user familiarity. In fact, that's the main reason I haven't really gotten into using Lisp yet: I'm comfortable with languages I already know. But, I'm determined to try new things, especially when there's evidence that there are better tools available.

The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue.

By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficient native-code compilers. (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)

hey,

If anyone has even used the strokes-mode in (X)Emacs, I have taken that to the X level by writing what is a higher-level application of gesture recognition. Consider this:

Why should each application implement gestures differently? For example WM commands (close, kill, iconify, maximize, resize, etc.) apply to all windows. Then, within each application, you might imagine some application-specific gestures. This can all be done at the X level. I decided to take the elisp code that's been doing gestures in (X)Emacs since '97 and ported it to Common Lisp (using GNU CLISP). This implementation if CL is GPL'd, and has an implementation of Xlib (called CLX) that plugs right in.

Anyway, CLISP is just about as portable as gcc is, so the same goes for the CL version of strokes.

What I havn't done, though, is to build a nice GUI for editing all the different strokes bindings for all the applications.

I've been playing with the idea of releasing this for years so that people could control all their applications using gestures. I figured that someone probably has done this (though probably not in Lisp, which is a shame).

Are people interested in X-level gestures?

dave

Some posts further down recommend interpreted languages like Python and LISP (jeez!) for such applications. They must be joking.

Lisp is not an "interpreted language" (if there even is such a thing as a *language* which needs to be interpreted). In fact, most open-source Lisp systems, as well as all commerical Lisps are compiled into native code.

I find it hard to believe that many people seem to think that after 40+ years of existence, Lisp is still interpreted, as if Lisp users, developers, and researchers were incapable of doing any better.

The CMUCL compiler (named Python, by the way) does this. It also offers efficiency notes. Dynamic languages don't have to be interpreted, even if ones like Python-language and Perl are. And CMUCL even offers interactive compilation and development, as do most CL environments.

Need bounds checking for Linux? May I suggest the CMU Common Lisp interpreter and compiler (to machine code) or perhaps Smalltalk. :)

All of those are much slower than the equivalent C code.

Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout. Though C "wins", I wouldn't exactly call it "much slower".

They all use byte-code or generate C code, then compile the C code.

Wrong. For all languages I mentioned there are native compilers available. For all (AFAIK, not sure about Standard ML), there are also bytecode compilers available, for some also compilers to C.

BTW, nobody would ever be so stupid to first generate bytecode, then C out of this (At least I hope so). Oh, and assembly isn't what you compile to in the end, thats why there are assemblers.

None that I know of generate assembly language directly.

If you talk of generating native binaries directly, you surely should try to get to know more. Here are a few:

• OCaml
• Standard ML of New Jersey
• MLton
• The Glasgow Haskell Compiler
• NHC 98
• CLisp
• CMUCL
• Stalin

All of those are much slower than the equivalent C code.

Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout. Though C "wins", I wouldn't exactly call it "much slower".

They all use byte-code or generate C code, then compile the C code.

Wrong. For all languages I mentioned there are native compilers available. For all (AFAIK, not sure about Standard ML), there are also bytecode compilers available, for some also compilers to C.

BTW, nobody would ever be so stupid to first generate bytecode, then C out of this (At least I hope so). Oh, and assembly isn't what you compile to in the end, thats why there are assemblers.

None that I know of generate assembly language directly.

If you talk of generating native binaries directly, you surely should try to get to know more. Here are a few:

• OCaml
• Standard ML of New Jersey
• MLton
• The Glasgow Haskell Compiler
• NHC 98
• CLisp
• CMUCL
• Stalin

I agree. The GPL is too restrictive, and should give way to the LPGL, or freeBSD-type licenses. I had no idea that Mundie felt the same way! What a surprise!

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.

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.

• 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...

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.

A lot of people have been suggesting Java, and just as many have been debunking it.

I know this is a C/C++/Perl/Java bigot crowd, so I'll keep this short.

What about Common Lisp or Smalltalk? Both are quite portable, and reasonably fast. Common Lisp can even be fully compiled to machine code. They both fill all of the other requirements.

Two notable implementations of CL are CMUCL (Free) and Allegro CL (free trial, commercial- but solid).

As far as Smalltalk, the notable implementations for your project are VisualWorks and IBM's VisualAge for Smalltalk. Couple summers ago I worked at a shop which was heavily into VA/ST, and it was a pretty awesome system. Core of their business, and we're talking about a pretty big insurance company.

(defmethod factorial ((x (eql 0))) 1)
(defmethod factorial ((x integer))
(* x (factorial (1- x))))

I recommend using ILISP with Emacs. It integrates with most of the Lisp environments out there and provides some neat features such as sending the new version of your defun to Lisp, and a slightly buggy buffer-package-matching thingy. Here's the Common Lisp devel stuff in my ~/.emacs:

Well, I would have put it here, except that even with all the text below, the Slashdot lameness filter cens0rizes me. Email me if you're curious and I'll send you a copy.

Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters.

[Sorry about this, but it looks as if I'll have to change the character ratios a bit...] Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation or any nation so conceived and so dedicated can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field as a final resting-place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But in a larger sense, we cannot dedicate, we cannot consecrate, we cannot hallow this ground. The brave men, living and dead who struggled here have consecrated it far above our poor power to add or detract. The world will little note nor long remember what we say here, but it can never forget what they did here. It is for us the living rather to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us--that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion--that we here highly resolve that these dead shall not have died in vain, that this nation under God shall have a new birth of freedom, and that government of the people, by the people, for the people shall not perish from the earth.

CHAPTER 1

It was a bright cold day in April, and the clocks were striking thirteen. Winston Smith, his chin nuzzled into his breast in an effort to escape the vile wind, slipped quickly through the glass doors of Victory Mansions, though not quickly enough to prevent a swirl of gritty dust from entering along with him.

The hallway smelt of boiled cabbage and old rag mats. At one end of it a coloured poster, too large for indoor display, had been tacked to the wall. It depicted simply an enormous face, more than a metre wide: the face of a man of about forty-five, with a heavy black moustache and ruggedly handsome features. Winston made for the stairs. It was no use trying the lift. Even at the best of times it was seldom working, and at present the electric current was cut off during daylight hours. It was part of the economy drive in preparation for Hate Week. The flat was seven flights up, and Winston, who was thirty-nine and had a varicose ulcer above his right ankle, went slowly, resting several times on the way. On each landing, opposite the lift-shaft, the poster with the enormous face gazed from the wall. It was one of those pictures which are so contrived that the eyes follow you about when you move. BIG BROTHER IS WATCHING YOU, the caption beneath it ran.

Inside the flat a fruity voice was reading out a list of figures which had something to do with the production of pig-iron. The voice came from an oblong metal plaque like a dulled mirror which formed part of the surface of the right-hand wall. Winston turned a switch and the voice sank somewhat, though the words were still distinguishable. The instrument (the telescreen, it was called) could be dimmed, but there was no way of shutting it off completely. He moved over to the window: a smallish, frail figure, the meagreness of his body merely emphasized by the blue overalls which were the uniform of the party. His hair was very fair, his face naturally sanguine, his skin roughened by coarse soap and blunt razor blades and the cold of the winter that had just ended.

Outside, even through the shut window-pane, the world looked cold. Down in the street little eddies of wind were whirling dust and torn paper into spirals, and though the sun was shining and the sky a harsh blue, there seemed to be no colour in anything, except the posters that were plastered everywhere. The blackmoustachio'd face gazed down from every commanding corner. There was one on the house-front immediately opposite. BIG BROTHER IS WATCHING YOU, the caption said, while the dark eyes looked deep into Winston's own. Down at streetlevel another poster, torn at one corner, flapped fitfully in the wind, alternately covering and uncovering the single word INGSOC. In the far distance a helicopter skimmed down between the roofs, hovered for an instant like a bluebottle, and darted away again with a curving flight. It was the police patrol, snooping into people's windows. The patrols did not matter, however. Only the Thought Police mattered.

Behind Winston's back the voice from the telescreen was still babbling away about pig-iron and the overfulfilment of the Ninth Three-Year Plan. The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it, moreover, so long as he remained within the field of vision which the metal plaque commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. But at any rate they could plug in your wire whenever they wanted to. You had to live -- did live, from habit that became instinct -- in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized.

Winston kept his back turned to the telescreen. It was safer, though, as he well knew, even a back can be revealing. A kilometre away the Ministry of Truth, his place of work, towered vast and white above the grimy landscape. This, he thought with a sort of vague distaste -- this was London, chief city of Airstrip One, itself the third most populous of the provinces of Oceania. He tried to squeeze out some childhood memory that should tell him whether London had always been quite like this. Were there always these vistas of rotting nineteenth-century houses, their sides shored up with baulks of timber, their windows patched with cardboard and their roofs with corrugated iron, their crazy garden walls sagging in all directions? And the bombed sites where the plaster dust swirled in the air and the willow-herb straggled over the heaps of rubble; and the places where the bombs had cleared a larger patch and there had sprung up sordid colonies of wooden dwellings like chicken-houses? But it was no use, he could not remember: nothing remained of his childhood except a series of bright-lit tableaux occurring against no background and mostly unintelligible.

The Ministry of Truth -- Minitrue, in Newspeak* -- was startlingly different from any other object in sight. It was an enormous pyramidal structure of glittering white concrete, soaring up, terrace after terrace, 300 metres into the air. From where Winston stood it was just possible to read, picked out on its white face in elegant lettering, the three slogans of the Party:

WAR IS PEACE
FREEDOM IS SLAVERY
IGNORANCE IS STRENGTH

Just like C++, Eiffel, Perl 4, and most other languages that predate Java, Common Lisp doesn't specify a threading interface, but several vendors offer proprietary threading interfaces after having made their runtimes thread-safe.

Actually the question should be: Do we really need another C compiler? Besides the fact that C is a poor language to optimize (weak typing, crappy calling conventions, broken arrays, you name it), it's about as close to assembly as a "high level" language gets and assembly is not a very good way to write quick and easily maintained code. Better to work on smarter compilers for languages that allow one to work on a higher level of abstraction. Projects such as CMUCL, SBCL, and OCaML could always use some help.

Two good choices are CMUCL and CLisp. Information for both of these may be found at www.cons.org. (Warning-there have been some problems with the site lately. Be patient or try again if there is a problem. :-) Emacs Lisp is mostly suited for writing Emacs and extensions thereof; it differs from more modern Lisps in some important ways. Of course, one should still know it to facilitate customization of Emacs. :-)

I wonder what would happen if the code were re-run with modern implementations of those languages? Allegro Common Lisp 4.3 is about two major releases old. And the CMU CL x86 compiler totally 0wnz it anyway, especially on numeric code.

I'm sure Java's gotten better too.

• 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/

What I mean is that Smalltalk would be more widely accepted if there were variants that duplicated the look & feel and object model of a common C++ toolkit & framework like MFC or KDE. The idea being that developers could work in Smalltalk but produce applications that seem more native to the end user.

No one can really say if making the GUI aspects of Smalltalks more like a C++ toolkit would make it more popular among (non Smalltalking) programmers. However, it doesn't seem that it would make much sense to do that. The GUI frameworks in Smalltalk are set up to (as you might expect) work logically, consistenty, and robustly with Smalltalk. There's little reason to try to bolt things from a different langauge onto it, and as always, trying to use one language like another instead of using it like itself is not likely to produce good results. As far as producing native-seeming apps for an end user, some Smalltalks take this approach. For example, at work I use Dolphin Smalltalk, whose GUI system is based around native Windows widgets. Build an app and it looks just like it would if you built it with VC++ or VB. It would certainly be possible for a Smalltalk vendor to do this on other platforms (and in fact VW or VA may well work that way; I don't know).

I guess I think Lisp is fun because I spend all day working in procedural OO languages and get bored. However, it doesn't have blazing speed and low level control of C, the GUI friendliness of Smalltalk or Obj-C, or the industrial strength of Ada, C++, or Java.

I doubt too many people would argue that with current machines/OSes something like C is better for getting close to the machine. Of course, there are examples like the Symbolics Lisp Machine where everything was in Lisp, so that wasn't true.(As far as speed goes, that's really an implementation rather than language issue. If one knows how to optimize Lisp code properly and has an implementation with a good compiler, one can do pretty well. See, for example, CMUCL. Or this page for more pointers. I will be honest, however, and admit to sometimes coding small parts of programs in C to improve performance. With the emphasis on small. :-) I do think Smalltalk wins hands down as far as anything I know for GUI, but particular Lisp implementations needn't be all that bad; I use Lispworks, and I don't think I'd say that I think GUI building is any harder in that than in a typical C++ or Java environment. I do think you may underestimate how suitable it is for "industrial strength" applications, though. Hang out in comp.lang.lisp for a while (or better, search the archives) and you will discover those who have built very serious, very large apps in Lisp, in part because of its suitability for such projects.

As for type declarations, they're there both for speed and correctness. The optional type declarations in CMUCL can serve both purposes. There is a tradeoff here: on the one hand, the need to keep track of the type information is a burden on the programmer when it is inessential to the logic of the program; OTOH, compiler needs this information to produce compact code and sometimes, catch errors. I like the CL's approach the best: it provides you with the option ONLY when you need it. Also, when programming in CL, I find type errors are rare; most bugs are logical.

Python is a very nice language, especially for beginners. But I doubt anyone who know CL well will prefer Python over CL. The expressiveness, the flexibility, the speed, the maturity of compiler and runtime system technologies; those are enough reasons for me to stick with CL.

As an aside: I like Python, and I've been watching Python's development for a while; however, I've yet to see a PEP (Python Enhancement Proposal) which cannot be implemented *within* the language in CL with a page or two using Macro, MOP, etc. Therefore I concluded that it is much less effort to bring libraries to CL, than it is to bring Python up to the level of CL in terms of language maturity.

In short, I think it is much easier to find happiness in CL! I believe most people will feel the same, too, if they're persistent enough to master the few beautiful concepts underlying the design of CL.

They really need to take the link to the "BSD comparison" down.

To paraphrase - opensource good - GPL bad

They really need to take the link to the "BSD comparison" down.

To paraphrase - opensource good - GPL bad

I would be inclined to agree with you. I can't talk for OpenBSD because I've not tried it, but I definitely appreciate the craftsmanship that seems to have gone into FreeBSD (a nice summary of which is presented here).

The rag-tag "throw a zillion monkeys at the problem" chaotic nature of the Linux evolution doesn't help for things like consistancy - something that I appreciate in FreeBSD. Then again, I'm a Win32 coder at heart... :op

who can post a few links to good Lisp reference sites?

• Association of LISP users : Best place to start browsing
• CMU Common LISP : Best LISP implementation available on Linux
• Common LISP the Language : The language reference for the most commonly used LISP variant
• The Common LISP Hypermedia Server : a big LISP open-source application which is a great thing to download, examine, and learn from

Unfortunatly, most functional programming languages are toys that sometimes get used in big projects.

For a laugh, why don't you email that comment to Erik Naggum... Anyway, functional languages, CL especially, are the most scalable in my (or opinion experience).

Before anyone flames me to a crisp, I'd like to point out how bad the I/O is in Lisp

Ummmm, no. I write little Lisp programs in lieu of shell scripts or Perl. And I've written a package to process CVS logs (terribly painful format to parse, btw), which chows through megabytes of logs ridiculously fast.

Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).

CLISP compiles to bytecode, and CMUCL compiles directly to native code. Both are completely free, with source code and everything.

but for the most part you can do them easier and faster with C, also it's nigh impossible to do very low level things with Lisp (At least from with what's available)

So use FFI. Call your C function from Lisp, and be happy.

Lisp is truely the language of the theoretical math major.

To be sure, but it should be the language of everybody else too.

:-)

--

Unfortunatly, most functional programming languages are toys that sometimes get used in big projects.

For a laugh, why don't you email that comment to Erik Naggum... Anyway, functional languages, CL especially, are the most scalable in my (or opinion experience).

Before anyone flames me to a crisp, I'd like to point out how bad the I/O is in Lisp

Ummmm, no. I write little Lisp programs in lieu of shell scripts or Perl. And I've written a package to process CVS logs (terribly painful format to parse, btw), which chows through megabytes of logs ridiculously fast.

Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).

CLISP compiles to bytecode, and CMUCL compiles directly to native code. Both are completely free, with source code and everything.

but for the most part you can do them easier and faster with C, also it's nigh impossible to do very low level things with Lisp (At least from with what's available)

So use FFI. Call your C function from Lisp, and be happy.

Lisp is truely the language of the theoretical math major.

To be sure, but it should be the language of everybody else too.

:-)

--

Which book do you have? It may or may not be a good place to start. (Graham's own ANSI Common Lisp is a good starter.)

There are plenty of good implementations. XAnalys Lispworks, Corman, and Franz have free trial versions of their environments which are suitable for learning. Also CLisp is a free (GPL) Common Lisp for Windows. All of the preceding except for Corman are also available for various Unices (although there may well only be free trial versions for Linux), and CMUCL is also available there. You'd be hard pressed to go too far wrong with any of those (I use Lispworks for most of my work and like it).

Which book do you have? It may or may not be a good place to start. (Graham's own ANSI Common Lisp is a good starter.)

There are plenty of good implementations. XAnalys Lispworks, Corman, and Franz have free trial versions of their environments which are suitable for learning. Also CLisp is a free (GPL) Common Lisp for Windows. All of the preceding except for Corman are also available for various Unices (although there may well only be free trial versions for Linux), and CMUCL is also available there. You'd be hard pressed to go too far wrong with any of those (I use Lispworks for most of my work and like it).

Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

• Learn about functional programming with Haskell and OCAML, and SML/NJ
• Learn about logic programming with one of the Prolog implementations.
• Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org
• Read up on Scheme and get a Scheme programming environment. PLT Scheme looks pretty good.
• Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak).

While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

Yeah, let's show those phonies by getting our own real free speech impediments!

CLISP
CMUCL
---

Yeah, let's show those phonies by getting our own real free speech impediments!

CLISP
CMUCL
---

In the Free world, CMUCL has kernel-level threads support (for FreeBSD and Linux), but only in the current development versions.

In the commercial world, Franz's Allegro CL has OS-native threads on Unix, Linux, and Windows.

One of the advantages of Lisp is that it makes it very easy to get working code written very quickly, giving you time to change your design if need be, and to go back and optimize only the parts of the code that need it (no point optimizing code that gets run .001% of the time). One of the disadvantages is that it makes it easy for poor programmers (or naive Lispers) to write amazingly inefficient code that works correctly. But well written Lisp runs comperable to or faster than C++. Both CMUCL and ACL compile to the native architecture, of course.

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. (~30% slower at things like matrix multiplication, bench it yourself) , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros'
A simple example is a 3-way if-then. (:less, :greater, :equal).
A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)

For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!

They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!

If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)

As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good. :)

Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as


(defun twofish-make-fun (key)
(compile nil `#'(lambda (block) (twofish-encrypt block ,key)))


This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)

There are some nice advantages to having a simple syntax. :)

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)

Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false. :) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.

In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.

These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.

(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. (~30% slower at things like matrix multiplication, bench it yourself) , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros'
A simple example is a 3-way if-then. (:less, :greater, :equal).
A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)

For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!

They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!

If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)

As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good. :)

Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as


(defun twofish-make-fun (key)
(compile nil `#'(lambda (block) (twofish-encrypt block ,key)))


This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)

There are some nice advantages to having a simple syntax. :)

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)

Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false. :) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.

In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.

These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.

(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. (~30% slower at things like matrix multiplication, bench it yourself) , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros'
A simple example is a 3-way if-then. (:less, :greater, :equal).
A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)

For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!

They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!

If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)

As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good. :)

Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as


(defun twofish-make-fun (key)
(compile nil `#'(lambda (block) (twofish-encrypt block ,key)))


This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)

There are some nice advantages to having a simple syntax. :)

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)

Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false. :) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.

In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.

These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.

(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago.

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' For example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the first example of aspect-oriented programming. As another example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer?

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual.

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago.

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' For example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the first example of aspect-oriented programming. As another example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer?

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual.

It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.

Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.

My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).

Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.

For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.

Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.

There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.

Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.

So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.

If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book.

As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way:

• make something that is simple enough for almost everyone to understand
• give away your source code
• explain how to weave your source code in with other systems

In the case of AOLserver, for example, Jim Davidson and Doug McKee had only a few months to build the whole server from scratch. They wanted users to be able to write small programs that ran inside the server process. They therefore needed a safe interpreted language so that a programming error by one user didn't crash the server and bring down all the Web services for an organization.

Tcl was available. Tcl was easy to download and designed to fit inside larger application programs. But the Tcl interpreter as distributed had one terrible bug: it wasn't thread safe, i.e., you couldn't have two copies of the Tcl interpreter running inside the same program at the same time. Doug and Jim had to read through the Tcl source code and modify it to be thread safe. So it was critically important for them that Tcl was open-source and simple enough so as to not require months or years of study to understand the whole system. Compare this to Lisp. Some of the best and brightest computer scientists raised money to build commercial Lisp implementations that they then went out and hawked in an indifferent and confused marketplace. They succeeded only in breaking their hearts and their investors' wallets. A handful of academics produced free open-source implementations, notably CMU Common Lisp (see http://www.cons.org/cmucl/) and various versions of Scheme (see http://www-swiss.ai.mit.edu/scheme-hom e.html; Scheme 48 is the closest to Tcl in spirit). But these multi-megabyte monsters weren't designed to fit neatly into someone else's program. Nor was there any document explaining how to do it.

Lisp developers have the satisfaction of knowing that they got it right 30 years before anyone else. But that's about all they have to show for 40 years of hard work and hundreds of millions of dollars in government and private funding. These days, most former Lisp programmers are stuck using Unix and Microsoft programming environments and, not only do they have to put up with these inferior environments, but they're saddled with the mournful knowledge that these environments are inferior.

All the three bigger vendors (Franz, Xanalys and Digitool) provide advanced graphical IDEs. Unfortunately there is no free IDE per se as far as I know, but Xemacs with ILISP makes for a pretty nice environment for the free Common Lisp systems.

If you'll excuse me ranting for a bit, but I find it baffling how many people seem to think that if they haven't heard about something, it doesn't exist. Even rabid users of obscure operating systems turn their brain off when it comes to programming languages, industrial applications of computers, and what not, and loudly proclaim that the most popular choice is the only choice.

The world is a big place. There is an enormous number of multi-billion dollar "niche" markets you have never heard about out there.