Re: Executables: Why all the abuse?

From: Christopher C. Stacy (cstacy_at_news.dtpq.com)
Date: 02/03/04 

Date: Tue, 03 Feb 2004 09:30:22 GMT

>>>>> On 02 Feb 2004 23:55:15 -0800, Duane Rettig ("Duane") writes:

 Duane> cstacy@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon ("Cameron") writes:
 Cameron> I suspect that a lot of these people have written small
 Cameron> applications and want to share them on the net.
>>
 Cameron> I think that the community is turning away trend setters and influencers
>>
>> Common Lisp was not designed for delivering small applications
>> and most of the vendors are not interested in that market.

 Duane> Why do you say that?

Lisp was developed for programming large systems, with the first
application domain being Artificial Intelliegence, followed by
object-oriented operating systems, followed by general purpose
applications (often leveraging those other two Lisp areas).

Common Lisp has been used in embedded systems, but those were
not small programs. When Lisp people have focused on smaller
programs, they have changed the language into something with
a new name, such as Scheme (academic instruction purposes and
concise demonstrations of theoretical language power) or Dylan
(with more modularity and deployment features in the language).
In some cases, limited versions of Lisp have also been developed
as application extension languages, which are typically small
programs, but those are not Common Lisp (and are usually interpreted
by a large runtime system, anyway). Finally, people use many
varieties of Lisp to implement domain specific languages which
may have compilers that emit small programs.

As for the claim about most the major vendors not being interested,
I simply observe they have not spent the resources to create a Lisp
compiler that delivers "hello world" in a 1 KB stand-alone image
that scales up linearly with the program functionality to the size
of the "large" (ha ha) 2 to 3 MB program's images.

One reason for this is the fact of Common Lisp's large core library.
There is no ANSI subset, and the standard provides no support or
guidance in creating one. And the typical implementation strategy
involves a proprietary dynamic linker, and FASL files. To reduce
program delivery size, there is also sometimes a GC-based un-linker
("tree shaker'), although that may result in image that's more
fragile in the face of certain kinds of bugs.

Meanwhile, the bigger commercial vendors (Franz, Xanalys, MCL)
focus on providing connectivity features such as networking,
database, GUI, distributed object procedure calling, multi-media
content location and management, and native platform bindings,
which are not the hallmarks of trivial little applications.
They also sometimes invest in layered products such as expert
system shells. This is on top of being fairly busy working
on the quality of the runtime and compiler.

As a language, Common Lisp came out of the original "big hard
problems" community, and I think it shows it.

And as I said, I don't see the problem with this. As an application
developer (and once-upon-a-time Lisp vendor), I haven't seen any
customers who are willing to pay much for me shipping them "hello world".
In the past 15 years, computer hardware has caught up to requirements
of Lisp applications, and compared to 99% of the programs in the
world today Lisp now seems relatively svelte.

The only area where the "small program" issue seems relevent these days
is in personal mobile computing. It remains to be seen how those power
curves will go. Maybe more work will be needed to deliver Lisp programs
on those kinds of devices, or maybe I'll just be able to run Genera on
my cell phone in a few years.

Relevant Pages

  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... by what I have heard about that language. ... as with Lisp and Java, ... That's Emacs-lisp, not Common Lisp, major differences, even ... If you like Emacs as ...
    (comp.lang.lisp)
  • Re: An Acceptable Lisp
    ... improvements that could be made to Common Lisp, ... By universal [Lisp] I mean the one, which will be accepted by all the ... Surely, I don't know, if such a language is at all possible, and, even ... Speaking about high-level, I know, that I've made an undersupported ...
    (comp.lang.lisp)
  • Re: Survey: Do you use the "2" in Lisp-2?
    ... Why You should Not Use The Jargon Lisp1 and Lisp2 ... Graham's On Lisp, I'm wondering what the advantages of a Lisp-2 ... For another example, consider today's PHP language. ... Now, the question is, why do Lisps before Common Lisp have this multi- ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... But it's true because of macros. ... indistinguishable from native Lisp - extend the language itself. ... it is because Common Lisp has extensibility at many points built in. ...
    (comp.lang.lisp)
  • something i dont understand...
    ... that i don't understand has to do with the use of lisp as a programming ... language for "large" applications. ... i see centers around providing ".exe" like applications that someone ... application application is written in mumps. ...
    (comp.lang.lisp)