Issues And Problems With Lisp

There are lots of pages on Wiki dedicated to dissing Lisp (as well as responding dissing from the Lisp community).

Many of them focus on the SocialProblemsOfLisp (and SmugLispWeenies) - the observation that the Lisp community (or vocal elements thereof) can be a royal pain to deal with. This has arguably limited Lisp's adoption by the programming community at large. Others focus on economic issues which - while important - are tangential to the language itself (the "LispSucks because it doesn't have an ArmyOfProgrammers argument". This may be a valid argument why Lisp isn't selected for more projects; however it is a management/economics issue and not a technical issue).

This page, on the other hand, desires to focus on the technical aspects of Lisp, in particular those that are problematic and/or contribute to Lisp's not being more widely adopted. (Or at least those issues that are perceived as problematic - something a Lisp expert sees as a perfectly acceptable state of affairs may well be seen by others as unacceptable; far too often the two camps seem uninterested in finding common ground here).

Contributions to this page should be limited to technical issues with Lisp - either the language definition itself, or the various implementations thereof which are available. Complaints about the SmugLispWeenies, etc., belong on some of the other pages above (and those pages are already full of them).

In the interest of avoiding debates on minutiae, complaints about "car" and "cdr" probably should be sent elsewhere as well.

It is traditional and very common to have the "'use lists for everything' (ULFE) mentality that defeats the advantages of abstraction." (Jonathan Bachrach, MIT Lisp fan and Lisp-dialect little language author, http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy). The emacs/xemacs split was fueled in part by disagreement over the utility of abstract data types (search for "abstract data type" in http://www.jwz.org/doc/lemacs.html). Lisp's ULFE strengths do not entirely carry over to a more abstract approach to design and implementation. Jkraskal said "The cons cell is a holdover from the jurassic era", which is perhaps a bit too strong, but...

Jonathan Bachrach is mainly a Schemer. The Scheme standard doesn't define a lot of data abstraction capabilities beyond lists because it tries to be a minimal language. Unfortunately, this means that if you want to use Scheme code for demonstrating concepts (that's an important use of Scheme) and have it run on many Scheme implementations, you don't have a lot of choices than use lists (or vectors). This problem doesn't exist for CommonLisp.

EssExpressions. Not an uncontroversially bad thing - many Lisp users like EssExpressions and see them as a good thing. They are, of course, simple-to-parse, conceptually powerful; and an economical representation of an AbstractSyntaxTree. However, many find them difficult to read (especially without an editor that provides syntax highlighting and the like); and while computers have no problem parsing nesting parentheses that go ten levels deep, many humans do. Some feel that EssExpressions make Lisp a WriteOnlyLanguage. Some in the Lisp community rebut that programmers who don't like EssExpressions are simply hesitant to adopt anything that doesn't use the Algol/C style syntax; however many recent programming languages enjoying widespread adoption are decidedly un-Algol like in their syntax.
While technically it's possible to alter the syntax of Lisp to be more like AlgolLanguage (see the "loop" macro as an example), there's been great resistance in the Lisp community to do so--and for good reason, too. Things like the precedence of operators complicates the writing of macros--and macros are perhaps the reason for writing in Lisp. In this regard, I'm fascinated by the SweetExpressions proposal, because it attempts to improve on the syntax of Lisp in a way that's compatible with macros. I, personally, am attempting to implement it, so that I could see if they actually work as advertised (at a snail's pace--or rather at the pace of a tired snail walking home from a funeral). Some SmugLispWeenies recoil in horror at the proposal, though--which is understandable, given all the horrible attempts made previously. --Alpheus
Related criticism can be found toward bottom of UniversalStatement.

I had that problem as a Lisp newbie (a perception of bad readability of EssExpressionss). I don't have it anymore. You could make up a similar argument for the inherent bad readability of Japanese because it doesn't use Latin characters. It's purely a matter of getting used to. Lispers like EssExpressionss because they have some technical advantages, and those are perceived as more important than some superficial readability purportedly improved by some irregular syntax.

The sheer size of CommonLisp. This complaint doesn't apply to SchemeLanguage and other Lisp dialects... but CommonLisp is a pretty big language, with a steep learning curve. A CareerLanguage. It is a very powerful language in the hands of a wizard; junior programmers often have a hard time with it. (An all-too-common response from some in the Lisp community is that one should avoid hiring junior programmers in the first place; this severely misses the point in my opinion.) And unfortunately, much of the size is the result of integrating several incompatible Lisp dialects, and there are numerous constructs in the language that do similar-but-not-identical things; which one to use in a given situation (setf or setq?) is not often clear. CommonLisp could use some serious ReFactoring. (Conversely, Scheme could use a seriously beefed-up library...)

CommonLisp is a small language compared to other modern languages. Lisp generally draws a different line between what is supposed to be the language and the library from what is usually the case in other languages (and intentionally so), this makes it harder to understand the organization of the language at first. CommonLisp doesn't have a good architecture with regard to how its features are layered into separate building blocks (modules, packages, components, whatever). Instead, all of CommonLisp is in one big package. I think this is sometimes a problem.

I don't see so many overlapping features in CommonLisp. You can always use setf and not use setq at all. Do you have some better example?

Despite the size of the language, it's missing support (in the language standard) for several key domain-independent concerns. Networking. Concurrent programming. Graphics. One can get hold of external libraries and the like to do all of these things, but having these standardized is highly beneficial. While other languages are far from perfect in this regard, they make available "de facto" standards far more visible than CommonLisp. (Following discussion moved to StandardLibrariesDontMakeForPortability).

The widely acknowledged best, or just most widely used, solutions for those domains change over time. At the time ANSI CommonLisp was finalized, it would have probably needed to standardize filenames to be of the 8+3-letters kind. It's good that it didn't submit to fashion trends at that time, and it's good that it doesn't do this today. It's important to understand that this was never the goal of the ANSI CommonLisp standard. The goal was to standardize features that the designers were sure would stand the test of time. The rest is up to concrete implementations.

Overly flexible - Individuals can/will bend it in their image making little sub-languages that fit how they think, making maintenance potentially hair-raising. A common characteristic of a HackerLanguage. Also a common characteristic of any library written for that exact same program. There's not a whole lot of difference between (custom-hacker-lingo (lambda (each) (valid? each)) list) and list.customHackerLingo(function(each){each.isValid();}).

The underlying problem probably is that writing macros is like writing a compiler for some language - the macro definition has to provide some good error reports when a macro is not properly used. When this is not the case, using a macro can be tedious.

PinkyAndTheBrainLanguage. It is commonly assumed that a programmer doing Lisp will be using Emacs, ILISP, some large interactive Lisp, and ASDF or defsystem. Debian usually helps too. In the process, they're expected to give up their text editor of choice, make, and the concept of an edit-compile-run cycle. For many programmers, this (combined with the large size of CommonLisp) is too much of a learning curve.

Yes, learning Common Lisp implies a steep learning curve. You really need to want to learn the language, especially because the rewards will only become clear later on. However, I think that any attempt to decrease the learning curve considerably by removing some of these requirements will decrease the value of the complete package, and experienced Lispers will most likely not accept that.

For certain programming tasks, languages like JavaLanguage and VisualBasic are arguably more productive than Lisp - these tasks include things that are frequently done. CrudScreens and other custom business forms are a fine example - is there any tool in the Lisp community comparable to VisualStudio or the like, allowing controls to be dropped on forms such that business majors can become productive programmers? While such tools are decidedly not appropriate for many things (and I wouldn't use MIS-degree programmers for much else besides this sort of task) - this seems one area for which the Lisp community hasn't a good answer. (Dismissing the whole domain as irrelevant to "real" programmers is not an acceptable answer).

Why is this a problem? This question ("Why is this a problem?") may not be completely understandable. Do you mean that one can always find a language which happens to have special features that other languages don't have? Todd Proebsting of Microsoft argues that disruptive technologies always have some disadvantages, which they eventually shore up or mitigate. http://web.mit.edu/webcast/ailab/mit-ll2-s2-09nov02-80k.ram

OK, let's try again: Why is it a problem that you have to switch to different languages, depending on the task?

Frankly, this isn't a problem, because the complaint is pointed squarely at the IDE, not at the language. This issue is utterly non-sequitur, and should be removed from the list. The reason Lisp environments lack GUI builders or other kinds of "wizards" is because nobody has written one for it yet. Remember, VisualBasic is still BASIC. No amount of fancy-pants, lacy, or frilly front-end, code-generating wizards will obscure this fact. Indeed, it can be argued that these wizards exist precisely because of the limitations of the core language used to glue all the parts together.

VisualStudio may be a good standard for CRUD GUI screens, but is has increasingly become obsolete and sub-standard for Code Browsing and refactoring, compared with EclipseIde or IntellijIdea. In any case LISP suffers in more serious area than CrudScreen, Say you want to study, integrate with, extend, use a largish package, an open source one for that reason. If that package is in Java you're much more likely to hit the ground running in half an hour, whereas in advanced languages like Lisp, Ocaml, Haskell etc, even if you have the right package (much less find the right package these languages) it may take you a lot longer and a lot more effort than you can afford to. You don't remember exactly the name of a function ? Just press ctrl-space and you'll find it. You find a better way to use some features ? Refactoring is trivial. You don't know where this code is coming from ? Just use the code browser, find cross-references, constructors, implementors, anything you feel like it. The lack of such features impacts big projects much more seriously than CRUD screens.

Commercial Lisp IDEs provide these features as well.

Not free (as in free beer) -- I am interested in using Lisp. But I would like to use open source lisp for my project. But using CLISP is not full feature yet (compare to lisp work or even corman lisp) I mean, lisp is here for 50 years but open source implementation of lisp still lack supports for GUI and ODBC database? Opensource Lisp IDE is too much Text oriented, while in eclipse lots of point and click and refactoring support is there.
- "Real programmers don't need no stinkin' ..." Ah, never mind, just joking. Personally, I don't much mind the text orientation. I use Slime as my "IDE", and it keeps improving at a rapid rate. But it is very much Emacs-based. I have not given any of the existing Lisp GUI IDEs much of a try.
Get lost in numbers of functions, Not IDE friendly language. (WHAT?!?!) In java or C++ I can type variable name and press ctrl-space and I get a list of function that i can call that object. Now how would I do that in lisp? given me a string,i would be lost about how to do anything with it. Yes you can read the hyperspec, But then what would the IDE be good for?
- Now how would I do that in lisp? You wouldn't. Lisp is a language. You'd use your IDE for that function.
- Which brings me to, Not IDE friendly language. How, in the name of your favorite god, can Lisp not be IDE-friendly, when the source text literally is a pre-parsed AbstractSyntaxTree? In order to support the very feature you claim can't be done with a Lisp-based IDE, IntellijIdea or Eclipse must parse and construct an AbstractSyntaxTree of your module first! An IDE designed for Lisp can take your variable, and just do a search through its AST. It's not hard; it's been done before (search Youtube for the LispMachine videos).
- In Lisp, the main namespace partitioning scheme is based on packages. I agree that it's unfortunate that all of the standard symbols are in a single package -- there's no built-in partitioning to help with the sort of thing you're talking about. On the other hand, the Hyperspec is arranged topically, and each main topic has a "dictionary" section that lists related operators. A good IDE can make it easy for you to call up the Hyperspec when needed. I've not seen an IDE that will pop you over to a topical section of the Hyperspec, but that could certainly be done. It would be possible, I think, to emulate the OO IDE behavior you mention. Given an object whose class is known, I think in most CommonLisp one could look up all the multimethods that can take that class as an argument. So to say that the language is inherently not IDE friendly is wrong; in fact, it's easier to gather the metadata about Lisp programs that's needed for such features than in most other languages. It's just that AFAIK nobody has done the work.
- Also, the Interlisp tradition was highly IDE-based; you apparently edited structure rather than text. Sordid history; hopefully it will return, because it was a loss; definitely one of the IssuesAndProblemsWithLisp. http://alu.cliki.net/AudioVideo#ip

Need bigger library. Take java as example, Its popularity comes from the fact that many of its library are standardized. (To whoever thinks Swing sucks, I still ove it given the fact that I have it and it sucks less that those lisp binding to any GUI frame works, and Swing is Free). Not counting GUI. The Thread and Socket and Database Support are lacking. Many newbies jumps into Java because It get many hard parts done. And they share lots of common knowledge in library. How would I be able to join open source community which use 1000 $ LispWorks as their lisp VM? In java world, even a 12 grade student with internet connection can afford to write full fledge application with free java SDK, including Network, Thread, GUI, etc.

I start to like lisp a lot but my favorite industry language will still be java. I came from the java world and i must admit that i am spoiled by how much common knowledge about library java people share.

Also, It's true that No matter how good lisp is, if it can not talk to the world easily, it's pointless (I don't want to hunt for trying to learn new socket API every time I change my lisp implementation, not knowing both lisp and VB then one will be more willing to learn VB since thy can be sure to at least talk to the world with COM).

Is "use lists for everything" really a technical problem? I regularly use strings, objects, arrays, hash tables ...

These are all still concrete data types; a higher degree of abstraction would be to use e.g. sequence, with the implementation possibly being either a list or an array, etc. And does the language have versions of its strongest tools for non-lists? Map, apply, reduce...Can you set up a structure that includes a list as a subelement and then cdr over it? If you write it all yourself, yes. What comes most naturally is what the language provides.
- In SchemeLanguage, I can see adding map-by-field and reduce-by-field (or [map|reduce]-by-accessor] as an extension of SRFI-9 records. Of course, most Scheme students are never told about records or structures in the first place, or most of the other language features and libraries for that matter, but that's one of the SocialProblemsOfScheme? rather than a technical one. - JayOsako
- There are functions are general to sequences (lists, vectors, etc), and those specific to lists. SORT works for sequences, so you can even use it to sort the characters within a string. However, CDR is conceptually weaker than SUBSEQ for general sequences, so CDR is reserved for lists.
- You might find certain data types in need of bulking up. Maybe there could be more operations on hashtables. However, Common Lisp's criticism is it's a big language, and there's features hard to find elsewhere like true multidimensional adjustable arrays, arrays with fill pointers, symbols...

To me this sounds more like a social problem caused by people learning lisp from obsolete dialects. I include elisp in 'obsolete': I don't think the emacs/xemacs split was so much to do with abstract data types as with opaque data types: had there been some reasonable support for defining structured objects in elisp whose contents could be inspected from lisp code when necessary, I doubt there'd have been the same amount of argument over how to represent an event.

JWZ's history (http://www.jwz.org/doc/lemacs.html) mentions data types as only one of many, many issues, and only in regard to keymaps, at that.
- Hence the "in part" above. It was important enough to warrant a fair bit of discussion in the e-mail exchange though.

I tend to get internal conflicts when people start talking about the environmental objections. For every person saying "I have to give up my favourite editor, make, autoconf, edit-compile-run?" there's someone else saying "why doesn't it come with an IDE like Visual Studio/Eclipse/whatever?" For me, the productivity gain in not having to edit-compile-run was worth the learning curve of finding another way to work than make, and I'd welcome further advances in IDE support - provided they don't lose the flexibility that I currently have in emacs. You are free to disagree with me, but again I think this is social not technical

With "doesn't make easy things easy", I think you're right on the money. -- DanBarlow, feel free to remove attribution if refactoring

Many people go on record saying that they'd use Lisp, if only there were a canonical implementation with universal bindings to utilities for common tasks.

I don't understand this. That would be very easy to arrange; if that's supposed to be all that is standing between Lisp and a wider popularity, surely it would have already happened. Which "utilities for common tasks"?

Many non-academic lisp users who want to enjoy the benefits of being able to run their programs on more than just one platform with one lisp have been driven to Python and Ruby. Lisp has CMUCL, SBCL, commercial derivitives, CLISP, OpenMCL, and others. A novice doesn't have the knowledge to choose which (nor should they have to!). This hurts lisp more than any of these other reasons, because it drives people away before they even really start. Further, because the lisp environment developer community is split, less progress is made and more effort is duplicated. Is this a technical problem, a social problem, or both? -- DaveFayram

CLOCC is making strides in this area - the portability packages are generally very good. The technical problems are mostly in installing packages, as CLOCC requires either defsystem or asdf and neither is trivial to setup. The social problems are that few people know about CLOCC, and newcomers see the bewildering array of CMUCL/CLISP/Corman/SBCL/Allegro/Lispworks/OpenMCL, realize that none of them takes care of everything they need to get started, and then run away in frustration. -- JonathanTang

I tried and failed to install CLOCC last November; I was just curious about one little piece, so I gave up in disgust fairly easily. Is CLOCC something important, so I should try again and learn about it? And if so, is there a trick to make it easier? I don't recall realizing it needed defsystem/asdf.
- I tried and also (mostly) failed to install CLOCC; I got it working in the end, but it took a week to set up the environment and write a simple echo server, and I've since forgotten how I got it working (it was the December before last, I think). CLOCC has most of the libraries that other languages take for granted: I was using it for networking, but it also has threads, gray streams, shell access, filename utils, and a bunch of other miscellaneous utils. Their eventual intent is to become like CPAN or PEAR, but they have a ways to go. -- jt

Interesting. Does it have Dorai Sitaram's regular expressions? -- dm

Not sure. Website is http://clocc.sourceforge.net/. I didn't see it in CVS, but I could've missed it. It does have the clunit and the utilities from OnLisp. Also saw some GUI stuff, but I'm not sure how good it is. The main open-source CL GUI is McClim?, but suffers from the same problem as the rest of Lisp: they try to solve the hard problems (presentations, recording) before solving the problems that people care about (a nice-looking widget set). -- jt

As a general philosophy, that is arguably the right approach. I've dealt with nice-looking widget sets that were a horror to actually use before, and I think such things are a waste of time. This is a kind of premature optimization, after all; they should get it working right first before optimizing the appearance. I don't know about McClim? in particular, though; my GUI work has all been in Java, C and C++ (X11 and Amiga). -- dm

But if a project doesn't pass the short term (attracting users), there won't be a long term. If I were developing a GUI app in CL, I wouldn't use CLIM (McClim? or otherwise), simply because that's not the face I want to present to users (who, after all, don't care how easy it was to program). Indeed, I can't stand to use Lispworks on Linux because the Motif interface it ships with is butt-ugly. I have similar issues with Emacs. I'd rather write Scheme with KWrite, which has nowhere near the power, but is much prettier and better-behaved, using native widgets. Prettyness shouldn't matter, and it usually doesn't with technical aspects, but it's the first thing a user sees, and usually determines whether or not they'll spend enough time with the product to appreciate its technological superiority.

A lot does depend on the amount of resources that can be thrown at the project. A Microsoft product can afford to be butt-ugly, because they've got the marketing clout to force it onto your desktop anyway, so you're stuck using it while they fix up the interface (look how long it took to get from Win3.1 to XP). But a small open-source project needs to attract developers fast, and usually developers come to a project because it looks like it'll be popular with users. Look how successful Gaim is; that's a system where the code is pretty bad yet the user interface is slick.

The McClim? source code is generally highly regarded in the Lisp community, BTW, and the developers on it are pretty good. I just think that the project would be more successful if they got something that looks good out there fast, instead of spending time to make it work right. WorseIsBetter. -- JonathanTang

Those are all good comments with elements of truth, but it is an incomplete analysis. Consider: "But if a project doesn't pass the short term (attracting users), there won't be a long term"...that's a strong tendency, not an absolute, but more importantly, the question of what attracts users varies both with the project and with the user.

I've been using Linux since patch level 0.99; it's looking pretty good these days, but it used to be quite ugly. Yet it succeeded long ago in some ways. In other ways it still hasn't (e.g. in displacing Windows on the desktop). This is similar to Unix itself; things can and do win on the basis of things other than appearance. X11, too...when it was first introduced, every desktop was very ugly. But it was a networked GUI. That functionality won out.

On the other hand, these days there's glutt of music players, so why shouldn't people prefer the prettier one over the ugly one, all else being equal?

So it depends.

BTW WorseIsBetter is fascinating, but it, too, is an incomplete analysis of a complex subject.

-- DougMerritt

EditMerge? with WhyWeHateLisp perhaps?

Definitely not. That and similar hate pages are fairly free-for-all, anything goes, whereas up at the top of this page, he said "This page, on the other hand, desires to focus on the technical aspects of Lisp"...and I think it's good to have a separate page for those technical-only issues.

Beyond performance, none of it is technical only because of TuringComplete. It runs. Nobody disputes that.
- Disagreed, ease of expressiveness is a major concern for programming languages (and one which Lisp fans claim superiority on). If TuringCompleteness was the only criteron; we would all still program in CeeLanguage for everything. It's not. [We wouldn't even have made it to 'c']
- Ease of expressiveness is not technical, or at least not exclusively technical. It's a WetWare issue.
- Expressiveness is a measurable characteristic. CommonLisp allows functionality to be provided more concisely than, for example, JavaLanguage. Bug counts have been demonstrated to be proportional to lines of code across different languages, so the ability to provide the same functionality with less code is an important technical benefit. The WetWare issues do arise, of course, when one considers techniques that trade clarity for brevity. More expressive languages make this less of a concern.
- Static and/or type-heavy languages tend to be more verbose. It's a tradeoff they make for improving the depth of machine-detectable problems. This tradeoff is generally a bigger scope than just Lisp.
- CommonLisp has optional typing that is not particularly verbose.
Plus, although the name WhyWeHateLisp is in jest, the fact is that most of us don't hate Lisp. Too much attempt to discuss Lisp in a critical fashion starts to resolve around the SocialProblemsOfLisp--a topic that generates far more heat than light--and this page was created to avoid that specifically.
Perhaps the title should be ObjectiveIssuesAndProblemsWithLisp? or the like. However, very few objectively measurable claims have been stated that I know of. Sometimes there are technical issues that bring up tradeoffs, but weighing the tradeoff weights is still a gray art. And sometimes something objectively measurable may be made "worse" in order to make something subjective "better". Thus, drawing a hard line in the sand between objective and subjective may not be practical even if it was possible.

Perhaps try refactoring WhyWeHateLisp and then merge that into this topic?

Lisp Debuggers

Trying to understand a stack trace in CMUCL or SBCL or CLISP is extremely difficult for a newbie.

Actually I was having severe problems even with SLIME. My suggestion is get a couple of pages of sample code with a deliberate error, bring up the stack trace in front of a newbie and see if they can locate the problem. I'm guessing this will prove to be pretty hard.

I assume this is a historical gripe, on modern SBCL

 (defun foo (x) (+ x 1))
 (defun bar (x y) (list (foo x) (foo y)))
 (bar 2 "oops")

produces a backtrace like this (frames below BAR dealing with the REPL machinery elided for brevity):

 0: (SB-KERNEL:TWO-ARG-+ "oops" 1)
 1: (FOO "oops")
 2: (BAR 2 "oops")

I'm not sure how that counts as "difficult to figure out". Of course it is a trivial example, but a hairy backtrace is a hairy backtrace in any debugger that doesn't lie. Other implementations may be less nice, of course -- but issues with a specific implementation should not be considered issues with the language.

Build systems

The ubiquitous make and its various wannabe replacements are not appropriate for Lisp because of its rather different models of compilation, execution, and loading. That's not a problem per se. The problem is that no single, universally-used replacement exists. ASDF seems very popular, but one also encounters systems set up to use mk-defsystem or its predecessor. Both ASDF and mk-defsystem are a bit problematic to use on Windows; they're easiest to use with symlinks, which Windows lacks. Neither system is set up to work with self-discovered or automatically-generated dependencies, as is possible with languages that require explicit #include or import directives in the source. The standard REQUIRE and PROVIDE functions could be used to build somewhat self-describing systems of dependencies that could be extracted; but they are deprecated and underspecified.

I understand that it's somewhat common to "roll your own" build system, sometimes layered on top of ASDF or mk-defsystem. This all seems like a rather sad annoyance.

See http://cl-cookbook.sourceforge.net/systems.html for a rudimentary introduction to the topic.

-- DanMuller

I might recomend that you look into asdf-install at http://www.cliki.net/asdf-install it resolves dependancies as well as installing the named library. I think it can be set up to use mk-defsystem too. -- mp

Garbage collection: There are serious issues in the garbage collectors of both SBCL and Allegro Common Lisp. See the following discussion on sbcl-devel:

http://groups.google.com/group/sbcl-devel/browse_thread/thread/f70c47e9f22d158a/

"If I use the straight-forward Lisp approach (code is included below), LispWorks runs repeatedly in about 12-seconds; SBCL runs in about 26-seconds but cannot run a second time because it enters the LDB during GC.

[...]

how to explain why Lisp lets itself get into a place where it cannot recover memory. All of the memory allocated during the call to parse-text is garbage; it can all be freed. But both SBCL and Allegro are unable to freed the memory without running out of memory during the process."

PinkyAndTheBrainLanguage for end-users as well as developers

Non-commercial Lisps assume not only that the programmer will be using a specific environment: They assume that the end-users will be using the same environment (EMACS included). When you compile a Lisp program to native code using a non-commercial compiler like SBCL, what you get with the least effort is a file whose name ends in .fasl, that can only be run by loading the Lisp's REPL and (LOAD)ing the .fasl file into the Lisp.

With additional trouble, you can get a "stand-alone" executable that bundles the entire Lisp environment (REPL, compiler... everything except EMACS) with your program, and that will display the REPL when your program's entry function returns, allowing the end-user to dittle around with your program. This executable is always gigantic (the entire Lisp library is statically linked in), takes a long time to load, and for most free Lisps, will display a banner on STDOUT that in some cases cannot be turned off (which causes problems if STDOUT is meant to be read by another program, rather than the end user). The Lisp debugger is always available to end users, so if there's a bug in your released program, end users will be able to see the names of functions and even mess around with the variables.

What it all boils down to is that if you release a Lisp binary, you must either bundle your Lisp environment somehow (if your Lisp doesn't do it for you), or you must assume that your users will already have the required Lisp environment, and that they know how to use it and they really like working with EMACS.

For server environments, Lisp programs are best when they don't have to interact with programs that do things the Unix way (that is, through stdin and stdout, and via command-line arguments). This means that rather than writing CGI scripts in Lisp (the long startup time and the compulsory banner make this a bad idea), it would be preferable to run your Lisp Web site on a Web server that is written in Lisp. (Barring that option, you would have to set up a scheme (I said scheme, not Scheme!) that involves Unix domain sockets and a helper FastCGI script, which would have to be written in something other than Lisp.)

LispWorks claims to be able to create stand-alone binaries, but it costs thousands of dollars, so I haven't seen whether the binaries are anything like those that SBCL generates.

Actually, implementations can generate a no-REPL at end (simply make the "entry function" be #'(lambda () (main) (ext:quit))) (except in SBCL, it's (sb-ext:quit)). ALso, there are bannar-suppresion options in every implementation I've seen.
ECL can do it: http://ecls.sourceforge.net/new-manual/ch24s06.html The generated executable is small, and it is dynamically linked with ECL's runtime.

Contributors: DougMerritt, JonathanTang, ScottJohnson, DaveFayram, AnonymousDonors, others?

CategoryLisp