Slashdot Mirror

Ask, and ye shall recieve. Not really Microsoft, but it sees all the API, plus it comes with source code (not "open source" though).

I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages

The vast majority of Common Lisp implementations have either a native code or through-C compiler, and at least two (Corman Lisp and SBCL) of them only come with a native code compiler.

Objectively, CMUCL can produce flotaing point code at least 5% faster than GCC on a non-trivial (the "Coyote Gulch" ephemeris calculator) benchmark. Of course, bechmarks are objective and misleading, and your assertion was subjective and misleading, and there's plenty of testimony (from real users writing non-trivial applications, not just some random bums paid off by the Scheme Underground) that Lisp is faster than C++.

Scheme seems like it has lost the intelligent simplicity of Python in favour of clumsy "special character" based syntax,

while Common Lisp has many detractors that don't complain much of details. Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?

Of course, your own assertion that Lisp is ugly and slow is stated authoritatively, even while you admit that you've "not coded a line yet," certainly could give someone the wrong impression.

Sure.

Common Lisp

ANSI Common Lisp standard (X3.226-1994)

Popular commercial implementations:

Allegro Common Lisp
Xanalys Lispworks
Macintosh Common Lisp
Corman Common Lisp

Popular free implementations:

CMUCL
CLISP
Open MCL
SBCL
GCL

All of these implement the Standard, some better than others. All have interesting extensions which are not portable. All bring different elements of interest to the table of developers looking to solve different problems.

Perl and Python haven't for whatever reason needed to be forked to provide a better implementation for a specific market segment. While large applications are being written in these languages, they're obiviously not in environments where the demand on the engines is high enough to warrant someone funding a fork and a port. (say, Perl for Palm, or Embedded Python, or Enterprise Ruby, whatever -- there is no complete "Python Compiler", for example, that I'm aware of at least). Though ActivePerl et al should be acknowlegded.

BEA has JRockit which is its own JVM, though it may well ship Suns class library. They felt that they wanted a better JVM to meet their markets needs better than IBM and Sun were.

Put an implementation to work and the market will fork it as necessary. Just ask MS.

That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule.

• CMU CL: natively compiled
• SBCL: natively compiled
• MCL: natively compiled
• OpenMCL: natively compiled
• Xanalys LispWorks: natively compiled
• Allegro Common Lisp: natively compiled
• Corman Common Lisp: natively compiled
• Scieneer Common Lisp: natively compiled
• Embeddable Common Lisp: natively compiled, via GCC
• GNU Common Lisp: natively compiled, via GCC
• GNU CLISP: bytecode compiled
• Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor

CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.

CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...

SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).

Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users :-).

I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).

Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.

Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.

Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.

There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.

CMUCL
SBCL
LispWorks
Corman Lisp

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

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.

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.