Why Common Lisp Bothers Me

Summary: "Because I'm used to something else."<p>- executables: [1] - library: while there are certain libraries that are harder to set up in CL than Ruby/Python, the provided example of list and string functions is laughable. [2] [3]<p>[1] <a href="http://www.xach.com/lisp/buildapp/" rel="nofollow">http://www.xach.com/lisp/buildapp/</a> [2] <a href="http://cl-cookbook.sourceforge.net/strings.html#number" rel="nofollow">http://cl-cookbook.sourceforge.net/strings.html#number</a>

I don't consider the executable critique to be legitimate. Java cannot run without a JRE, and arbitrary Lisp code cannot run without the entire Lisp image without losing runtime compilation. It would be possible to forbid (eval ...) and friends from a source program, and then save a Lisp image sans compilation machinery, but that is a lot of work to save a few megabytes and you would break compatibility with existing code in the process.

The only thing about Common Lisp that bugs me is that it seems increasingly unlikely that we'll see an updated spec. It kind of sucks for anyone who wants to create a new CL implementation because of all of the anachronisms in the ANSI spec. Additionally, new things like concurrency end up getting done a bunch of different ways between implementations which kind of screws up code portability.

Yeah, this was frustrating to me as well. oconnore's point is valid, in that CL is not the only language to behave this way --- but Java (his example) is more up front about it :) (that is to say, learning Java, you learn this limitation quickly, and it's not a problem because most machines have a JRE; CL you might go some distance before you have to look up what's going on, and once you do you realize how few machines have a CL).<p>Don't get me wrong, I still love me some common lisp --- but I agree with Britton that the issue shouldn't be dismissed as meaningless.

Clojure is popular for these exact reasons. Clojure apps are deployed like any Java app, and they can access the huge library of Java.<p>Java also deploys an image that needs to be executed in a runtime, but the industry is so familiar with the JVM that it is a moot point.

Here's an example of building an executable using CLISP on windows: <a href="http://grault.wordpress.com/2009/10/30/common-lisp-gui-application-shipment-delivery-on-windows/" rel="nofollow">http://grault.wordpress.com/2009/10/30/common-lisp-gui-appli...</a>

(deliver 'my-main-foo-function "/Users/joswig/lispfoo" 0)<p>Delivers an executable as a single file in LispWorks. Most implementations have something similar depending on what kind of architecture they are based on). Exceptions are Lisp to C compilers and Lisp Machines. But it is unlikely that you will use one of them.

I had the same issue learning the standard library. It's huge, redundant (I think...), and has completely unsearchable names and no organization or hierarchy.<p>I seem to remember sbcl having some way to compile real executables though, someone back me up on this?