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.

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.

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.

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?

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.

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.

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.

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.

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.

Commercial Lisp IDEs provide these features as well.

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

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.

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.

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

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

Not sure. Website is 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.

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 for a rudimentary introduction to the topic.

-- DanMuller

I might recomend that you look into asdf-install at 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:

"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.
Contributors: DougMerritt, JonathanTang, ScottJohnson, DaveFayram, AnonymousDonors, others?


View edit of June 24, 2013 or FindPage with title or text search