Zach's Journal - Lisp executables

I can't help it if I know what "compile" actually means!

It would be less insulting if it referenced a less contrived scenario.

Exactly. I attended a few lisp user group meetings a few years ago. At the time I was fairly experienced with Scheme, but not with Lisp (and unaware of Lispers' reputation for being smarter-than-thou). I stopped going after realizing that most of the members were stuck on showing how inferior any other language is, and not too interested in helping others reach their level of understanding.

I agree, and I agree that mentioning SAVE-LISP-AND-DIE early is helpful. I think the problem is that mentioning SAVE-LISP-AND-DIE without making clear that CL and C(++) simply don't work the same way is also bound to create many more misunderstandings down the road: Personally, I remember far more cases where newbies were put off by SAVE-LISP-AND-DIE than newbies who found that it really was what they expected; while it did create an executable, a common test case was to create a hello world (or otherwise functionally trivial program) program and then create an executable. Depending on the implementation you're using, you're very likely going to get a huge executable compared to compiling a similar C/C++ program, precisely because you /do/ need to include the whole runtime environment.

The initial reaction frequently is a (very understandable) case of disappointment: if your hello world takes 12MB to deliver, how large would anything more useful be? While this doesn't scale like that for real programs, you won't get that across if you don't point out that creating stand-alone Lisp executables isn't the most common way to run (even less to develop) Lisp programs in most implementations. So it's not a matter of providing easy answers or being a jerk; it's a trade-off between providing easy answers with misleading implications which often (but certainly not always) lead to confusion/disappointment later on or providing a more accurate answer which doesn't reinforce misguided assumptions (but still answers the question). Granted, there may be many people who use the latter option as an excuse to be a jerk at the same time, but that's an entirely different point ;-)
I think a helpful starter is to point out that Lisp development cycles are indeed different than C/C++ development cycles, just as they differ in Perl, Ruby, Python, Java, Javascript, etc. Yes, it's good to know that you can deliver a standalone executable when you need it, but it's misleading to advertise that as the recommended/best way. I'm not saying that Cusp does that, and I'm sure it'll be very useful for people who use Cusp; I just think that this point is something one should keep in mind. I've seen the same "why can't I just create an executable" question arise frequently in other contexts (e.g. Perl or Java), and it's rarely as much of a problem as new users initially make it out to be.

I don't think it matters much to many of the people able to implement it in open source Lisps. There is in general a lack of manpower for improving Lisp implementations, and specifically few people devote their time to changing the implementation to match outside expectations. It doesn't happen automatically; people like Jasko have to perceive a need and meet it by doing the work.

Not everyone agrees on the needs and the priorities for fixing them. One way to get someone else to agree with the need and priority is to apply money. There are cheaper ways, but usually they involve charm and persuasion...