Why Common Lisp Bothers Me | Hacker News Reader

Why Common Lisp Bothers Me

lovehateubuntu.blogspot.com

17 pointssemmons32 comments

Summary: "Because I'm used to something else."

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

[1] http://www.xach.com/lisp/buildapp/ [2] http://cl-cookbook.sourceforge.net/strings.html#number

Buildapp looks like a very nice solution to a long standing Common Lisp problem. When I was still reading comp.lang.lisp, seemed like every request for how to build an executable turned into a long diatribe about how "you really don't want to do that", "you're thinking in the UNIX way, not the Lisp way", yadda yadda yadda. Now, that question can be just be answered with the buildapp URL.

Agreed that thinking Common Lisp lacks adequate ways to manipulate sequency things is quite funny. The main problem is the lack of definitive libraries for things that were not included in the standard 20 some years ago.

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.

I don't think anyone's concerned about the executable size. It's annoying, but unless you have a lot of should-be-small executables, it doesn't matter.

However, exposing the innards of a program on event of an error can be undesirable. CL's behavior of dropping you into the debugger is great when you're writing software that doesn't have to be delivered, or that is entirely open-source, but you can't do closed-source executables that way.

CL's default behavior drops you into the debugger. That can be customized in delivered applications to do whatever you want. I sell binary-only command-line CL applications to non-technical users and they don't need to know that Lisp's behind it at all.

Interesting. How hard is this to do? I don't know much about CL.

Wrap something like this around a main startup function for your application:

    (handler-case (main-user-function)
      (error (c)
        (princ "a serious error, I'm quitting")
        (quit))
      (condition (c)
        (princ "we have a problem")
        (when (y-or-n-p "abort?")
          (abort))))

It handles conditions of class ERROR in the first clause and conditions of class condition (all kinds of stuff that one can signal) in the second clause. The variable 'c' would be the condition object. You could inspect it and print more useful help, show dialogs, look for restarts and more.

That's not CL behavior - that's something an implementation in development mode does. The Common Lisp standard does not specify the presence or absence of a debugger

You are free to handle all errors in your application and never drop into a debugger. Common Lisp comes with a 'condition system' that let's you handle errors, recover from errors, show users possible restarts and more.

The precise form of the debugger is not specified, but a debugger is described in the standard in chapter 9 and its behavior is roughly outlined in the description of DEBUGGER-HOOK and INVOKE-DEBUGGER.

that are just code examples how to use the provide interface, not real debuggers and not a description how a debugger should work.

    1.4.3 Sections Not Formally Part Of This Standard

    'Within the concept sections, subsections whose names begin with the words
    ``Note'' or ``Notes'' or ``Example'' or ``Examples'' are provided for
    illustration purposes only, and are not considered part of the standard.'

I'm not talking about the examples. The normative parts of the standard do talk about a debugger.

it is not even explained what a debugger is. The glossary has two sentences that uses the word 'might' to describe possible functionality. The documentation of INVOKE-DEBUGGER and the debugger hook just describes how the thing is called. What it is and what it does is not described. Is it a REPL? Does it have any commands? What does it print on entering? How are restarts presented? Are restarts presented? What functionality does it provide? Can I get a backtrace? How? I don't see anything like that described.

I agree that it is not specified in detail. I disagree with your assertion that the standard "does not specify the presence or absence of a debugger." A debugger's presence is specified. Its behavior is not.

Things would be better for Lisp if it were as easy for non-hacker end users to obtain and install the needed Lisp system.

A Google search for java runtime results in top hits like "Download Free Java Software", "Java Downloads for All Operating Systems", "Java SE Downloads" (with the pertinent phrase visible, "What Java Do I Need?").

A search for Lisp runtime results in top hits like a chapter from the gigamonkeys.com Lisp book, an irrelevant question thread on StackOverflow, and a somewhat relevant page about the Lisp runtime that comes with Autodesk.

I can imagine that doing something like, say, making an easy-to-find, easy-to-download, easy-to-install package of CLisp, tossing in wx widget bindings for good measure, would go a long way toward making distribution of Lisp software easier.

What 'Lisp runtime'?

Save the Lisp image to a single executable. Done.

What you would like is a "download it here" link on http://lisp.org/

It's not as trivial as that.

That's true, but compare JRE install base to lisp runtime install base. People know how to deal with JRE (install, upgrade, remove) by now. Do you want to teach someone how to deal with lisp runtime?

Many Lisps make it a single executable file. Can you deal with that?

Me? Sure. Users? Does it create an installer, uninstaller, set of icons, executable with no manual dependencies?

Besides - that's not the real problem here. It's always "possible" to do something. But if a random developer gets to write some software and still doesn't know that he can package it into a single executable... maybe there's something wrong on a different level (accessible documentation?)

Maybe he should read the documentation that is there in the first place.

What kind of installer do you need for a single executable file?

Registry entries (for Windows deploys), data files, silly DRM stuff, etc. You'd want an installer/uninstaller for your more complex deployments.

But that's not something one should reasonably expect from a Lisp REPL or compiler; that's just packaging, and there are installers out there that excel at that. I suppose it would be expected that modern Lisp IDEs have support for that.

LispWorks for example is installed with one of the usual installers. Including documentation, icons, data files, etc.

On the Mac I would use LispWorks to create the usual application directory that can be dragged into the systems' application folder - the usual and easiest way to install applications on the Mac.

LispWorks has a delivery guide that explains how to deliver applications on Unix, Windows, Linux, FreeBSD and Mac OS X.

http://www.lispworks.com/documentation/lw60/DV/html/delivery...

Editing the manifest file to make a jar file double-clickable is pretty straight forward. Is there a comparably simple method for Common Lisp?

Buildapp, mentioned elsewhere in this discussion, looks like a good solution. But, as with most things Common Lisp, it is tied to a specific distribution (in this case, SBCL).

> Editing the manifest file to make a jar file double-clickable is pretty straight forward

In what platform?

> Java cannot run without a JRE

Yep... As I recall from responses to this critique, 99.9% of C programs cannot run without support from libraries either, usually already installed with the OS. Even though the executable size looks small, you still end up loading up a large code image into memory as you statically include all those dependent user mode libraries.

I have not tried it myself, but I remember reading something that suggested you could install part of the Lisp image on your system and have a slimmed down executable that knows how to autoload the main image (there was some kind of bootstrapping technique in there).

In a sense, this is an advantage with a Lisp binary as compiled by SBCL in that almost everything you need is bundled into the one image (easy to deploy!)...with the caveat, of course, that you will still need whatever external libraries the binary requires.

Note that I have little experience with other Lisp systems -- and not enough experience, really, with SBCL to be more than a novice on this subject. Like others, though, I was looking for the "how to make an executable" answer, and what I found satisfied me. I can mix Lisp binaries with other stuff I use at work.

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

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.

So, Java is popular because it is popular... ugh. :P

Clojure is popular for these exact reasons. Clojure apps are deployed like any Java app, and they can access the huge library of Java.

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: http://grault.wordpress.com/2009/10/30/common-lisp-gui-appli...

(deliver 'my-main-foo-function "/Users/joswig/lispfoo" 0)

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.

I seem to remember sbcl having some way to compile real executables though, someone back me up on this?

Reply on news.ycombinator.com