Executables: Why all the abuse?
Cameron MacKinnon
executable of a Lisp application. It's often his first post, and often
his last.
I suspect that a lot of these people have written small applications and
want to share them on the net. They're likely to be some of the most
effective proselytizers of Lisp, introducing compelling apps to others,
some of whom will get the source and become lispers themselves. What do
they hear?
- You can't do that
- You can only do it with the commercial lisps
- You can do it, but the binary will be 11MB
And those are just the serious answers. Some comedians try to convince
the OP that he should be comparing the download size with all the C
libraries that his users wouldn't have to download if the app was in C.
Others suggest that what he really wants is a batch file, a lisp
environment and a hassle, um, fasl file.
Coders might not have that much web space or transfer available. End
users might not want an 11MB download. Even though that's only two or
three mp3 tracks, I think people expect a certain amount of
functionality out of code that size, and a minor app is likely to be
viewed as hopelessly bloated.
Maybe it would be instructive to look at how other languages handled
this chicken-and-egg problem:
Perl started small (even Perl 4 was only a few hundred k) and
ingratiated itself with the sysadmin crowd. It didn't bulk up until it
was in the indispensable category.
Sun sued Microsoft to stop the distribution of a buggy and incompatible
Java, tried to get the court to compel Microsoft to distribute an
updated version, and paid HP and others (presumably) lots so they would
distribute Java with new PCs.
Java, Macromedia Flash, Realaudio and other applets benefit from
Netscape's plugin paradigm - if the end user doesn't have the plugin,
the content creator can direct the browser to get it from the plugin
creator's website. The end user only downloads it once, the content
creator doesn't pay for the bandwidth, and the process is sometimes
painless.
My reading of the Lisp 1.5 manual suggests that users demanded and got
ways to manually remove parts of lisp even then, though the scarce
resources were RAM and tape capacity.
Yes, if I were more skilled I'd understand
http://www.unlambda.com/lispm/explorer-source/explorer-lispm-sources/band-tools/tree-shake.lisp
and hack it into CMUCL. As it is, all I can do is suggest and hope and wait.
I think that the community is turning away trend setters and
influencers, precisely the people it needs, with its attitude of "If you
want to eat hippopotamus, you've got to pay the freight." They come,
they're mocked and they go away again, to continue dining on python,
camel and java.
--
Cameron MacKinnon
Toronto, Canada
"I am the Lorax. I speak for the tree shakers."
Christopher C. Stacy
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.
I don't know why you would think that people who have written
small applications as you describe are industry "trend setters".
If they are focused on delivering toy programs, and don't have
the patience to study and learn to understand the benefits of
something that is too complex to be easily absorbed, then it
seems to me that they are more likely to just be following
whatever trends are popular.
Cameron> What do they hear?
Cameron> - You can't do that
Cameron> - You can only do it with the commercial lisps
Cameron> - You can do it, but the binary will be 11MB
Actually, they are told about the implementations that are better
at delivering small executables, such as Corman Common Lisp and ECL.
They are also informed that Xanalys Lispworks can easily deliver
applications that are about 2 MB.
Most importantly, they are told about the trial educational versions
of the commercial quality Lisp systems, which can be used to learn
about programming in Lisp before even making a monetary investment.
But there's no getting around the learning investment.
We're not interested in "Lisp For Dummies In 21 Days".
In over four decades, we have seen languages come and languages go,
and are not very worried about popularity contests. Lisp is not well
suited to be the most popular language available, and that's fine.
Thomas F. Burdick
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net.
Where did you get that idea? If they'd written small applications
they wanted to share, don't you think they might mention it, at least
in passing?
This is a potential market for Lisp, nowadays, and there are good,
low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
constrained space. It works nicely. If anyone asks, "How do I
deliver my app that I have 3/4 developed?" They'll get good advice.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Henry Hansen
hoping that some gem will be revealed. Something to Lisp like
freepascal is to pascal. For the people that find these threads
annoying, easy solution, don't read them.
Now, didn't Lisp have origins on very low end hardware? Doesn't that
mean that the essence of the language can be implemented in a small EXE?
Could some type of linker strip out portions of the runtime library
that aren't required?
Cheers.
Cameron MacKinnon <cmack...@clearspot.net> wrote in
news:lN6dndzx4MH...@golden.net:
Pieter
> This is a potential market for Lisp, nowadays, and there are good,
> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> constrained space. It works nicely. If anyone asks, "How do I
> deliver my app that I have 3/4 developed?" They'll get good advice.
Would you mind terribly muvh to please explain how to do this? I assume
that you are talking about Common Lisp? I have versions for both Windows
and Linux and really would appreciate some information about this.
Regards
Pieter
Rayiner Hashem
to integrate with the rest of the C-using world. They see the standard
Lisp runtime model to be superior. In that, they have an excellent
point, but also miss the realities of the market. The market has
settled on "the way things are." You can either lament it in
perpetuity, or adapt to it. Runtimes are just hard to sell. Even
*Microsoft* is having a hard time convincing everyone to download the
.NET framework to use .NET apps! If CMUCL spit out a small binary that
linked with "libcmucl.so" or "cmucl.dll" end-user Lisp apps would
become much more palatable. It doesn't matter if the binary is 500KB
but libcmucl.dll is 11.5MB --- the difference in perception is huge.
Another part of the problem is that, for the markets where CL is used
right now, distribution really isn't a factor. Not a whole lot of
commodity, end-user apps are written in CL. I get the impression that
many Lisp'ers are perfectly fine with this, and really don't care if
Lisp sees more widespread usage. However, today is a better day for
Lisp in the mainstream than any other in recent memory. People are
actually paying attention to more than just C and C++. Java and C#
have both come along and (especially the latter) reintroduced people
to some good Lisp ideas. Perl, Python, Ruby, etc, are getting very
popular, and are turning on a lot of people to dynamic typing. Many of
the old arguments against Lisp (its slow, memory-hungry, etc) are
easier to refute not just because of better compilers, but because the
competition has gotten slower. A good, natively-compiled Lisp program
can be a good bit faster and more memory-efficient than a Java
program. Now isn't that a great argument? Lisp does more than Java, is
more productive than Java, and well, its faster too! That might not
lead to Lisp world domination, but might expand the Lisp userbase
quite a bit, and bring with it the niceities that come with popularity
--- better/more bindings, more libraries for new things, better
implementations, etc.
Ray Dillinger
>
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
>
This is one case where Scheme is a lot better than Common Lisp.
As a much smaller language, it's easy to make small scheme
runtimes.
There are also a number of good free Scheme-to-c systems that
produce compilable C code, and at least one good free all-the-
way-to-machine-code compiler.
So if you want to write in a lispy langauge and deliver small
or medium-sized executables, the easiest way is to write in
Scheme.
Bear
Christopher C. Stacy
Rayiner> I think the fundemental problem is that a lot of Lisp'ers
Rayiner> don't want to integrate with the rest of the C-using world.
This is belied by the increasing attention paid in recent years to
"binding" libraries, utilizing both the "foreign function" calling
and the JAVA communication systems (not to mention the vendor
supplied interfaces to COM and CORBA).
But that's an entirely different issue from "delivering an executable".
You seem to be conflating binary interoperability or leveraging
libraries with delivery issues, something about the sizes of
stand-alone executable images versus those that require a
seperate run-time library.
Users don't know (nor should they care) about those details.
On Windows (or even Linux) Users do not download DLLs or EXEs.
They download a self-contained bundle that automatically
installs the files, and runs scripts that do all the other
setup (Registry, desktop icons, query for options and user
preferences, process lanching, etc.)
And for Lisp, you do exactly the same things on those
platforms, using exactly the same tools.
Rayiner> *Even *Microsoft* is having a hard time convincing everyone
Rayiner> to download the .NET framework to use .NET apps! If CMUCL
Rayiner> spit out a small binary that linked with "libcmucl.so" or
Rayiner> "cmucl.dll" end-user Lisp apps would become much more
Rayiner> palatable. It doesn't matter if the binary is 500KB but
Rayiner> libcmucl.dll is 11.5MB --- the difference in perception is huge.
I don't follow your reasoning here. If Microsoft can't convince
people to download a runtime library, why would it be desirable
for Lisp to require a special runtime library? You appear to
be saying that a "huge" improvement in the perception of the
Lisp program if it's smaller.
Who are you imagining has a problematic perception?
A few people who come to this newsgroup? Is there some reason
to believe that they represent a typical application customer?
Their fixation with small deliverable images under 2 MB for
toy programs does not correspond to any customer that I know.
The only time that users might even be aware of the size of a
program is if (assuming it's not distributed on CD) it takes
too long to download, or is too big to fit into memory.
But a 3 MB Lisp image would certainly not be considered a
very large download -- that's the same as one MP3 song.
As far as memory issues go: the only critical programs would be
the permanently resident "system tray" applets. On my Windows
machine, those seem to range from just over 2 MB (scanner buttons)
to 5 MB (Weather icon) on up to 14 MB (Palm sync/alarm, instant
messaging background). And of course Lisp can dump out those
same kinds of applications in the same amount of space and formats.
If people want to continue to claim there are problems with Lisp
in this area, they need to describe the customer environment that
they are talking about
Meanwhile, I just don't understand what alleged problems are
being presupposed in this thread -- I don't see or experience
them and they don't correspond to any of visible customer base.
My suspicion is that these messages are quasi-trolls from people
who aren't really writing programs and are just making excuses.
Perhaps they spend their time going around looking for a silver
bullet that will save them from having to actually do anything,
and are disappointed that the highly touted Lisp (like the other
languages) doesn't provide them with a magical software fairy.
The suggestion that people are "abusing" them contributes
to this theory.
Duane Rettig
> >>>>> 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.
Why do you say that?
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Bulent Murtezaoglu
[...]
CCS> Users don't know (nor should they care) about those details.
CCS> On Windows (or even Linux) Users do not download DLLs or
CCS> EXEs. They download a self-contained bundle that
CCS> automatically installs the files, and runs scripts that do
CCS> all the other setup (Registry, desktop icons, query for
CCS> options and user preferences, process lanching, etc.) [...]
That's right, mostly. One thing I have not seen mentioned re: exe's
that has been important for me for at least the past 4-5 years is
getting rapid feedback from unsophisticated Windows users with
broadband. User here means client. E-mailing "Here, click on this
URL, run that exe and tell me what you think" _is_ important for rapid
progress in remote work (for values of remote varying from 1 to 10k
miles). I don't think "get this bundle, unzip, run install, let it
grind and then run it" would work as quickly especially when you just
need the client to spend a minute on whatever it is you are showing
him. Shipping off libraries in advance doesn't quite work -- people
don't seem to use the same machine and windows users have this
tendency to reinstall their OS often. Anyway, this is a moot point as
we _can_ generate single exes from most lisps.
cheers,
BM
Cameron MacKinnon
> Common Lisp was not designed for delivering small applications
> and most of the vendors are not interested in that market.
It's difficult to see how vendors can grow the market if they ignore the
small end. Development shops want experienced programmers, and
inexperienced programmers don't start out by building large
applications. So there will always be a bigger pool of developers
working in the languages that are suitable for small apps, leading to
development shops picking those languages for larger apps.
The other languages that aimed at large systems were Ada and PL/1.
> I don't know why you would think that people who have written
> small applications as you describe are industry "trend setters".
"Industry" calls IBM and asks what the safe choice is this year, thus
coding in Java and XML. People learn a programming language because:
1. MS/Sun/IBM shilling it to abet or avoid platform lock-in
2. Taught in school. See 1.
3. The US DoD says so
4. UNIX is written in it
5. A kid/grad student writes a nifty app and posts the source
If you're trying to increase the popularity of a language and you're not
one of the above named entities, #5 is your only hope.
> If they are focused on delivering toy programs, and don't have
> the patience to study and learn to understand the benefits of
> something that is too complex to be easily absorbed, then it
> seems to me that they are more likely to just be following
> whatever trends are popular.
Most large programs start small, but there are many small programs that
don't aspire to be large. To disparage these as toys is to disparage the
vast majority of software. And anybody who shows up in c.l.l sure isn't
following a popular trend.
> We're not interested in "Lisp For Dummies In 21 Days".
> In over four decades, we have seen languages come and languages go,
> and are not very worried about popularity contests. Lisp is not well
> suited to be the most popular language available, and that's fine.
It's not the dummies you need to worry about. It's the people who've
heard such great things, decide to check it out and are appalled to
discover that nearly a decade after "The Internet's a passing fad" Gates
threw in the towel and wired his OS for TCP/IP, Lisp still has no
standard network API. It was difficult for me to reconcile this with a
living language.
The kids that come to c.l.l asking how to package their apps are the
future of Lisp. Or some other language. Treat them well.
I do appreciate the pointer to ECL and other lisps which can generate
small footprint executables, Christopher. But I did look at a
representative sample of prior threads, dating back about six months,
before my original post. And I wouldn't say that those who ask get a
warm welcome.
Espen Vestre
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I don't understand his. I make executables all the time.
They are:
1) completely standalone.
Much more standalone than any of the usual Windows stuff. It's a drag-
and-drop install on linux and Mac OS X. Unfortunately, Windows users
don't expect installing to be that easy, so while my application _can_
be installed by dragging and dropping a single binary on Windows too,
the users expect me to give them the usual installer thing, so I have
to go through the ordeal of using those crappy installer-makers. Sigh.
2) small if the application is small
Ok, they're not very small, almost 10MB gzipped, but then I build them
with all whistles and bells turned on so that I can deliver the next
version as a "automatic patch" (a fasl file downloaded and LOADed
at runtime). For less demanding programs which needn't be that dynamic,
the binaries are 2-3MB (compressed).
The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
worth its money, which includes free distribution of those "standalone
applications".
--
(espen)
Cameron MacKinnon
> This is one case where Scheme is a lot better than Common Lisp.
> As a much smaller language, it's easy to make small scheme
> runtimes.
Agreed. If only Scheme, rather than Java, had become the lingua franca
of cellphones! But having read about tree walking and tree shaking, I
wonder why it isn't more often used. Having the huge language and then
removing everything you don't need gives the best of both worlds.
I haven't yet declared my fealty to either the Scheme or Lisp camps. To
one looking at the whole continuum of computer languages, Lisp and
Scheme appear so far from everything else, and so close to each other,
that the constantly erupting flamefests seem quite comical.
--
Cameron MacKinnon
Toronto, Canada
"[the] politics are so vicious precisely because the stakes are so small."
Espen Vestre
> at runtime). For less demanding programs which needn't be that dynamic,
> the binaries are 2-3MB (compressed).
Or even less:
[ev@merced:/tmp]$ ls -l lisp-hello.gz
-rwxr-xr-x 1 ev ev 1052828 Feb 3 09:36 lisp-hello.gz
[ev@merced:/tmp]$ gunzip lisp-hello.gz
[ev@merced:/tmp]$ ls -l lisp-hello
-rwxr-xr-x 1 ev ev 2883612 Feb 3 09:36 lisp-hello
[ev@merced:/tmp]$ ./lisp-hello
(hello world)
[ev@merced:/tmp]$
--
(espen)
Espen Vestre
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I don't understand this. I make executables all the time.
They are:
1) completely standalone.
Much more standalone than any of the usual Windows stuff. It's a drag-
and-drop install on linux and Mac OS X. Unfortunately, Windows users
don't expect installing to be that easy, so while my application _can_
be installed by dragging and dropping a single binary on Windows too,
the users expect me to give them the usual installer thing, so I have
to go through the ordeal of using those crappy installer-makers. Sigh.
2) small if the application is small
Ok, they're not very small, almost 10MB gzipped, but then I build them
with all whistles and bells turned on so that I can deliver the next
version as a "automatic patch" (a fasl file downloaded and LOADed
at runtime). For less demanding programs which needn't be that dynamic,
the binaries are 2-3MB (compressed).
The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
Christopher C. Stacy
Duane> cst...@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.
Tim Bradshaw
> Maybe it would be instructive to look at how other languages handled
> this chicken-and-egg problem:
Yes, I think so
>[...]
> Sun sued Microsoft to stop the distribution of a buggy and
> incompatible Java, tried to get the court to compel Microsoft to
> distribute an updated version, and paid HP and others (presumably)
> lots so they would distribute Java with new PCs.
Let's take this one. Sun and others started with an acceptably good
language, with an acceptably designed set of libraries, then did some
very clever marketing (applets, gradually shifting to server side
stuff with a couple of strong sidelines based around being a language
that average programmers could actually reliably use (unlike C/C++),
portable GUIs, and not getting screwed by MS), and throughout this
whole process they spent lots and lots of money, which they had to
spend.
I suggest precisely this strategy for Lisp. We have the decent
language and possibly enough libraries to start. We need the
marketing, and the money. Cheques, in sterling, should be made
payable to the `Bradshaw retirement fund', thanks.
--tim
Christopher C. Stacy
Cameron> Christopher C. Stacy wrote:
>> Common Lisp was not designed for delivering small applications and
>> most of the vendors are not interested in that market.
Cameron> It's difficult to see how vendors can grow the market if they ignore
Cameron> the small end. Development shops want experienced programmers, and
Cameron> inexperienced programmers don't start out by building large
Cameron> applications.
1. The size and format of the executable program image
have nothing to do with the scenario you are presenting,
unless you are postulating a company that ships "hello world"
class programs written by inexperienced programmers.
2.Where I come from, inexperienced programmers are supervised
and are given a small confined piece of a (large) product
to work on. The image size is irrelelvent.
If you're argument is that the language is too complex for
beginners to master, that's another matter entirely.
In that case, use some other language, or invest in
properly training your programmers.
Cameron> "Industry" calls IBM and asks what the safe choice is this year, thus
Cameron> coding in Java and XML. People learn a programming language because:
Cameron> 1. MS/Sun/IBM shilling it to abet or avoid platform lock-in
Cameron> 2. Taught in school. See 1.
Cameron> 3. The US DoD says so
Cameron> 4. UNIX is written in it
Cameron> 5. A kid/grad student writes a nifty app and posts the source
Cameron> If you're trying to increase the popularity of a language and you're
Cameron> not one of the above named entities, #5 is your only hope.
Kids writing "nifty apps" in their spare time and giving them away for
free are not industry movers and shakers. Maybe when they grow up
they will learn Common Lisp and write something significant.
Cameron> It's not the dummies you need to worry about. It's the people who've
Cameron> heard such great things, decide to check it out and are appalled to
Cameron> discover that nearly a decade after "The Internet's a passing fad"
Cameron> Gates threw in the towel and wired his OS for TCP/IP, Lisp still has
Cameron> no standard network API. It was difficult for me to reconcile this
Cameron> with a living language.
I have a standard network API I use portably on two platforms and two
different Lisp implementations. It took me about two hours to write it.
I didn't like the ones that were available for free downloading.
Cameron> And I wouldn't say that those who ask get a warm welcome.
I just spent about $300 of my own money helping you with advice.
Sorry I wasn't warm enough; I have to get back to work now.
Joe Marshall
> Agreed. If only Scheme, rather than Java, had become the lingua franca
> of cellphones! But having read about tree walking and tree shaking, I
> wonder why it isn't more often used. Having the huge language and then
> removing everything you don't need gives the best of both worlds.
It is difficult to determine what you don't need even from the
sources. Since FUNCALL and APPLY can call anything passed to them,
you have to compute what might be passed. If you have a call to
INTERN or READ anywhere, you can generate arbitrary symbols at
runtime, and unless you can prove that they do *not* end up being
FUNCALLED, then the entire lisp system is accessible.
> I haven't yet declared my fealty to either the Scheme or Lisp
> camps. To one looking at the whole continuum of computer languages,
> Lisp and Scheme appear so far from everything else, and so close to
> each other, that the constantly erupting flamefests seem quite comical.
Agreed.
--
~jrm
Pascal Costanza
Henry Hansen wrote:
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
> freepascal is to pascal. For the people that find these threads
> annoying, easy solution, don't read them.
>
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
> Could some type of linker strip out portions of the runtime library
> that aren't required?
The important point here is that Lisp is a dynamic language. People who
ask for compilability to .EXE files are expecting Lisp to behave like
static languages they already know. That's not the right model to
approach something like Lisp. You won't get the important aspects when
you start with such a mindset.
As others have already pointed out, someone who has already implemented
a considerable program in Lisp wouldn't ask this kind of question,
because it becomes clearer the more experienced you get how to deal with
these things.
The situation is not unlike the situation in Java: The only platform on
which you can deploy a Java program without shipping an additional JVM
and/or requiring more installation work from the user is Mac OS X. On
all other platforms, a Java program is far away from being a
double-clickable .EXE file. Yet this didn't prevent Java from succeeding.
It's just one of those typical hurdles a Lisp newbie has to face with.
There's no way around this. IMHO.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Edi Weitz
> That's right, mostly. One thing I have not seen mentioned re: exe's
> that has been important for me for at least the past 4-5 years is
> getting rapid feedback from unsophisticated Windows users with
> broadband. User here means client. E-mailing "Here, click on this
> URL, run that exe and tell me what you think" _is_ important for
> rapid progress in remote work (for values of remote varying from 1
> to 10k miles). I don't think "get this bundle, unzip, run install,
> let it grind and then run it" would work as quickly especially when
> you just need the client to spend a minute on whatever it is you are
> showing him. Shipping off libraries in advance doesn't quite work
Right - but as I said in another thread there are (even free) tools
like "Inno Setup"[1] which, if necessary, will hide all this
complexity from the user. I have a hard time imagining a client who
wouldn't want to go through a simple routine like that. Windows users
launch these "installers" every day and they really don't care if they
install one file or one hundred.
Edi.
Rob Warnock
+---------------
| ... If CMUCL spit out a small binary that
| linked with "libcmucl.so" or "cmucl.dll" end-user Lisp apps would
| become much more palatable. It doesn't matter if the binary is 500KB
| but libcmucl.dll is 11.5MB --- the difference in perception is huge.
Done. All you need is a CMUCL core image with a "#!" reader macro
that acts like a comment, then concatenate the following onto the
front of your FASL files (as noted):
#!/usr/local/bin/cmucl
;;;; Hack to allow CMUCL FASL files to run as shell scripts.
;;;; Usage: cat {this_file} foo1.x86f ... fooN.x86f > foo ; chmod +x foo
;;;; The last "fooN.x86f" should have a top-level form which starts the app.
(let* ((my-name (second *command-line-strings*))
(stream (open *script-name* :element-type '(unsigned-byte 8))))
(dotimes (i 9) (read-line stream)) ; Eat header text from stream, then
(load stream :contents :binary) ; pass rest to FASLOAD.
(continue)) ; Keep LOAD of script from falling into FASL file(s).
The "libcmucl.so" is actually two files, a small executable (".../bin/lisp")
and a larger core file (".../lib/cmucl/lib/lisp.core"), but the point is
that it would be shared by all of the "executables" you deliver.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Cameron MacKinnon
> Cameron> It's difficult to see how vendors can grow the market if they ignore
> Cameron> the small end. Development shops want experienced programmers, and
> Cameron> inexperienced programmers don't start out by building large
> Cameron> applications.
>
> 1. The size and format of the executable program image
> have nothing to do with the scenario you are presenting,
> unless you are postulating a company that ships "hello world"
> class programs written by inexperienced programmers.
*Precisely*
Where "company" is a high school kid, and "hello world" is the next
great Internet app, which *you* could have written in about 20 hours, if
only you'd thought of it first.
> 2.Where I come from, inexperienced programmers are supervised
> and are given a small confined piece of a (large) product
> to work on. The image size is irrelelvent.
Where I come from, they're unemployed, or still in school. And more
interested in singlehandedly writing some odd app (that I'll find
utterly banal, but which will appeal to the teenage mind) than signing
up for a death march in a cube farm.
> Kids writing "nifty apps" in their spare time and giving them away for
> free are not industry movers and shakers. Maybe when they grow up
> they will learn Common Lisp and write something significant.
Shaun Fanning. Linus Torvalds. Richard Stallman. Justin Frankel. Marc
Andreessen.
I guess there's hope for Stallman, if you can convince him that lexical
scoping is the way to go.
The next generation is out there somewhere, coding who knows what.
Likely not in CL.
> I have a standard network API I use portably on two platforms and two
> different Lisp implementations. It took me about two hours to write it.
> I didn't like the ones that were available for free downloading.
This sounds neither standard nor portable. And only two hours work!
> Cameron> And I wouldn't say that those who ask get a warm welcome.
>
> I just spent about $300 of my own money helping you with advice.
Had I asked for any advice, I'd be grateful, I'm sure.
> Sorry I wasn't warm enough; I have to get back to work now.
Had I been referring to myself, I'd have used the personal pronoun.
Cameron MacKinnon
> The important point here is that Lisp is a dynamic language. People who
> ask for compilability to .EXE files are expecting Lisp to behave like
> static languages they already know. That's not the right model to
> approach something like Lisp. You won't get the important aspects when
> you start with such a mindset.
We agree that a complete CL application with a REPL has tremendous power
and extensibility. And that people who show up on c.l.l asking "how to
compile?" almost certainly aren't using all of that power, and probably
don't even realize it.
But they know what they want, or think they do -- one file, which they
can send to an end user, whose operating system will do the right thing.
If we say to them "you don't want to do that" or "you could do that in
C", then they will go back to C.
Not every program needs the full, dynamic power of Lisp. Some programs
need to be reasonably small.
AND (key point) if these people get a lecture and some sarcasm instead
of (or in addition to) what they ask for, they're just going to quit Lisp.
There are several people whose *only* post on c.l.l was to ask "the
question". Either they're now happy lurkers (speak up, please!) or that
was their one and only question and they left happy, or they left
disgusted and went back to [your inferior language here].
Several more people basically said "hear, hear" in this very thread.
Perhaps an improvement to the FAQ? Explaining what they'll lose,
pointing at some incisive article or example, but then saying "and if
you still really want to do this, here's the lisps that give the
smallest executables, and how to go about it."
Pascal Bourguignon
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I've got two small CGI in Common-Lisp that are around 1MB:
$ du -shc /local/html/cgi/vacation*
12K /local/html/cgi/vacation
1017K /local/html/cgi/vacation-clisp
1.1M total
$ du -shc /local/html/cgi/en-ligne*
24K /local/html/cgi/en-ligne
897K /local/html/cgi/en-ligne-clisp
921K total
Granted, 99% of that is the clisp image and executable, they're small
programs, and 1MB for a Hello World may still seem big, but that's
quite acceptable, for a stand-alone program.
With clisp you can also concatenate all .fas files needed for your
program in load order and prefix it with a #!/bin/clisp line to get a
very small "executable".
$ ls -lh tar-backup
-rwxrwxr-x 1 pascal regular 74K 2004-01-17 21:11 tar-backup*
$ head tar-backup
#!/usr/local/bin/clisp -q -ansi -K full
(SYSTEM::VERSION '(20020129.))
#0Y UTF-8
#Y(#:|(DEFINE-PACKAGE COM.INFORMATIMAGO.CLISP.TAR-BACKUP
#16Y(00 00 00 00 00 00 00 00 00 01 DA DB 30 02 19 01)
...
The problem is that Unix (and MS-Windows) is C centric. We'd need to
have the distributions integrate a Common-Lisp runtime along with
glibc. Perhaps having a libcl.{so,dll} containing the run-time and
image? It would be probably easier to generate from a Common-Lisp
implemenation in C, such as gcl, ecl or clisp than from those that are
implemented in Common-Lisp such as cmucl, sbcl or openmcl.
$ ls -lh /lib/libc.so.6
-rwxr-xr-x 1 root root 1.5M 2003-03-27 21:39 /lib/libc.so.6*
A compressed clisp runtime and base image library is 1.8M.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Michael Manti
<t...@famine.OCF.Berkeley.EDU> wrote:
> Cameron MacKinnon <cmack...@clearspot.net> writes:
>
> > At least once a month, someone asks how to deliver a "standalone"
> > executable of a Lisp application. It's often his first post, and often
> > his last.
> >
> > I suspect that a lot of these people have written small applications and
> > want to share them on the net.
>
> Where did you get that idea? If they'd written small applications
> they wanted to share, don't you think they might mention it, at least
> in passing?
>
> This is a potential market for Lisp, nowadays, and there are good,
> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> constrained space. It works nicely. If anyone asks, "How do I
> deliver my app that I have 3/4 developed?" They'll get good advice.
Why would a fledgling CL developer investigate how to deliver an app
only after developing it that far? That would be poor planning on her
part. I suspect that most potential app developers would check means of
delivery even before beginning development on their apps.
Casual empiricism: Most questions I've seen in the c.l.* hierarchy
w.r.t. delivering an app appear to be by someone who has played with
the language and is excited enough to contemplate developing her first
app in that language.
Michael
Pascal Costanza
> Pascal Costanza wrote:
>
>> The important point here is that Lisp is a dynamic language. People
>> who ask for compilability to .EXE files are expecting Lisp to behave
>> like static languages they already know. That's not the right model to
>> approach something like Lisp. You won't get the important aspects when
>> you start with such a mindset.
>
> We agree that a complete CL application with a REPL has tremendous power
> and extensibility. And that people who show up on c.l.l asking "how to
> compile?" almost certainly aren't using all of that power, and probably
> don't even realize it.
>
> But they know what they want, or think they do -- one file, which they
> can send to an end user, whose operating system will do the right thing.
>
> If we say to them "you don't want to do that" or "you could do that in
> C", then they will go back to C.
>
> Not every program needs the full, dynamic power of Lisp. Some programs
> need to be reasonably small.
Sure, and there is clisp, ECL, OpenLisp, and the like to do these things.
The point is that there is no single right answer to this question.
Small programs are different than big programs. Some programs are better
provided as source code while others are better provided as compiled
libraries and/or .EXEs. And so forth.
In the non-Lisp world, these different deployment scenarios are offered
by different languages. In Lisp, you can get everything from a single
environment. It's very likely that you will shift your ideas what should
be deployed how in Lisp.
The typical answer here to the question whether one can create .EXE
files is not "No, because you don't need this.", but "Yes, but you will
probably change your ideas whether you really want this or not."
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Bulent Murtezaoglu
[...]
EW> Right - but as I said in another thread there are (even free)
EW> tools like "Inno Setup"[1] which, if necessary, will hide all
EW> this complexity from the user.
Thanks. I have the wise installer under 'free installer' bookmarks
(www.wise.com) and seem to remember it being free at some point.
Apparently not, as of now.
EW> I have a hard time imagining a
EW> client who wouldn't want to go through a simple routine like
EW> that.
Oh they would. I wouldn't want them to if it can be helped though.
In any event LW does this just fine (as do others under windows, I
imagine).
EW> Windows users launch these "installers" every day and
EW> they really don't care if they install one file or one
EW> hundred.
That's right, but for really short stuff (getting comments or
confirming that you understood what they wanted by sending a dummy
implementation etc.) I don't want to do that to people. I find very
short turn around time invaluable and the quicker/less hassle I make
it the more likely it is that the guy'll spend the minute as soon as
he gets my message. I'd prolly look into fasl loading through
compressed http streams for stuff like that and ship off a base test
jig with an installer _once_ if I couldn't do the single exe scheme.
But this is a "collaborative remote development w/o filesystem access"
scenario which is distict from the regular complaint we get here
(which I don't even understand well enough to rephrase).
cheers,
BM
Rayiner Hashem
> "binding" libraries, utilizing both the "foreign function" calling
> and the JAVA communication systems (not to mention the vendor
> supplied interfaces to COM and CORBA).
cooperating at an organizational level. Systems built on C tend to
have a certain way of doings things. Programs are compiled binaries,
and libraries are native shared objects. Existing systems built on C
are very much oriented towards managing programs using this model, and
users are used to dealing with programs that use this model.
> Users don't know (nor should they care) about those details.
> On Windows (or even Linux) Users do not download DLLs or EXEs.
> They download a self-contained bundle that automatically
> installs the files, and runs scripts that do all the other
> setup (Registry, desktop icons, query for options and user
> preferences, process lanching, etc.)
Users don't often have to deal with these things (but do when
something inevitably goes wrong!), but developers do. Its a lot easier
to sell Lisp to a potential developer if they can use it within their
existing, familier framework.
> I don't follow your reasoning here. If Microsoft can't convince
> people to download a runtime library, why would it be desirable
> for Lisp to require a special runtime library?
Its slightly more subtle than that. Microsoft doesn't ship a library,
it ships a runtime. Its not just a DLL you stuff into a folder, but
rather a large program that must be installed seperately. In theory,
both should behave the same way, but in practice, they don't. Current
systems are set up to handle shared libraries very well. Basically,
you put the library in a known directory, and the system finds
everything else automatically. It is much harder to install a runtime
reliably, because you have to get correct paths set up (where to
packages live, etc). Its really a by-product of the C-oriented design
of current systems. So I'm suggesting a Lisp runtime library, not a
Lisp runtime as CMUCL is currently.
> You appear to be saying that a "huge" improvement in the perception of the
> Lisp program if it's smaller.
Not so much for users, but a Lisp runtime that behaved similarly to a
C runtime would be a lot easier to sell to developers. Developers are
already having a problem with the Java/C# way of handling the runtime
issue, and currently, Lisp really isn't much better. (Well, CMUCL/SBCL
isn't much better --- I don't own Allegro, so I won't comment on it).
> Who are you imagining has a problematic perception?
> A few people who come to this newsgroup? Is there some reason
> to believe that they represent a typical application customer?
They might not represent a typical application consumer, but I have a
hunch there are some "on the edge" developers in there that could be
Lisp users if the system were more accessible to them.
> Their fixation with small deliverable images under 2 MB for
> toy programs does not correspond to any customer that I know.
The internet makes small application size rather important. A one-time
download for a Lisp-library is one thing, but repeated downloads of
2MB for small apps is another. Application size might not matter to a
customer installing shrink-wrapped software off a CD, but a whole lot
of the interesting stuff in the software market is not happening in
the shrink-wrapped world. These days, everything from media players to
AIM clients are small, free programs distributed over the internet.
Not to mention the whole "Open Source" thing :) Adobe most likely
isn't going to write the next version of Photoshop in Lisp, but its
entirely possible that someone may decide to write what becomes a
popular chat client in Lisp. Any new developers is better than no new
developers.
> As far as memory issues go: the only critical programs would be
> the permanently resident "system tray" applets. On my Windows
> machine, those seem to range from just over 2 MB (scanner buttons)
> to 5 MB (Weather icon) on up to 14 MB (Palm sync/alarm, instant
> messaging background).
Those numbers seem very large. These apps should take a few hundred KB
if they are making proper use of shared libraries. Also, that
situation is slightly different for UNIX machines. UNIX machines have
lots of little daemons running in the background, so paying a 2MB
penalty for each one would significantly change the hardware
requirements of the system.
> My suspicion is that these messages are quasi-trolls from people
> who aren't really writing programs and are just making excuses.
Oh come on. Not everyone is a troll in disguise. In reality, some
people have certain needs, and are wondering if Lisp meets those
needs, and if not, why not*. For example, I'd love to do GUI apps in
CL. However, I am completely uninterested in Windows, and there are no
complete CL bindings for GTK+ or Qt. So my current GUI app is being
written in --- C++ :-/ And assuming I did manage to develop the app in
Lisp, I'd have to package it, and it'd be a lot easier to package
something if I had a binary and a library, rather than if I had to
deal with getting cmucl set up correctly on a number of different
platforms. These are all factors beyond my control, dictated by the
system I work in. Some languages (eg. Ocaml, Dylan) are more flexible
in this regard than others.
*Now, as for the question about why people keep bringing this up, when
it has been answered before, repeatedly. I'll be generous and assume
that this is a sign of laziness, rather than trolling.
Pascal Costanza
> So I'm suggesting a Lisp runtime library, not a
> Lisp runtime as CMUCL is currently.
Did you check http://www.eligis.com ?
Did you check all of http://alu.cliki.net/Implementation ?
Do you really think there is something missing?
Or do you really expect that all vendors should support the particular
deployment model that you have in mind?
Ingvar Mattsson
[ SNIP ]
> And those are just the serious answers. Some comedians try to convince
> the OP that he should be comparing the download size with all the C
> libraries that his users wouldn't have to download if the app was in C.
> Others suggest that what he really wants is a batch file, a lisp
> environment and a hassle, um, fasl file.
>
> Coders might not have that much web space or transfer available. End
> users might not want an 11MB download. Even though that's only two or
> three mp3 tracks, I think people expect a certain amount of
> functionality out of code that size, and a minor app is likely to be
> viewed as hopelessly bloated.
If we look at typical sizes of what people (seemingly) are happy to
download, "for checking things out", look at the size of current PC
game demos. Admittedly, this is not a "small example", but that should
(ideally) be downloadable either as "lisp + demo" and "demo", in
program bundles (zip files, tar.gz or whatever is convenient), with
either a "install" or "load" script and/or as a "runnable compressed
archive" (probably only relevant for Windows) that unpack the relevant
files into the relevant directories and works "with a single click".
Hexen II - 11.6 MB
Quake III Arena - 46 MB
These are (probably) self-extracting archives inside a .EXE file
prepared with InstallShield.
//Ingvar
--
(defun m (f)
(let ((db (make-hash-table :test #'equal)))
#'(lambda (&rest a)
(or (gethash a db) (setf (gethash a db) (apply f a))))))
Daniel Barlow
> Not to mention the whole "Open Source" thing :) Adobe most likely
Which you're quite right not to mention, because Open Source is about
distributing the _source code_, not the binaries.
The answer to "how do I distribute my app as source code" is, as far
as I'm concerned, very very simple. You package it with an asdf
system definition, pgp-sign the package, upload it somewhere, and
create a cliki page with a :package link pointing at it. Now all the
asdf-install users can get it (conceded, it helps to get your pgp key
signed by a few people)
> Those numbers seem very large. These apps should take a few hundred KB
> if they are making proper use of shared libraries. Also, that
> situation is slightly different for UNIX machines. UNIX machines have
> lots of little daemons running in the background, so paying a 2MB
> penalty for each one would significantly change the hardware
> requirements of the system.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3451 dan 15 0 42992 36m 8276 S 0.0 29.5 6:52.50 emacs
5482 dan 16 0 84408 25m 23m S 0.0 20.8 1:49.42 MozillaFirebird
20270 dan 15 0 608m 6728 24m S 0.0 5.3 0:26.29 sbcl
3394 root 5 -10 34948 4980 16m S 1.0 3.9 5:00.72 XFree86
6605 dan 15 0 8156 4464 4376 S 0.0 3.5 18:05.24 xterm
3433 dan 16 0 8448 2444 5000 S 0.0 1.9 1:22.32 sawfish
741 root 15 0 2256 2248 2020 S 0.0 1.8 0:00.10 ntpd
4430 news 15 0 2876 1852 1660 S 0.0 1.5 0:00.14 leafnode
13941 dan 16 0 8156 1584 4376 S 0.0 1.2 0:00.64 xterm
4218 dan 15 0 8156 1488 4376 S 0.0 1.2 0:04.71 xterm
18475 dan 15 0 8156 1396 4376 S 0.3 1.1 0:04.58 xterm
From the RES column it looks like I'm paying a number of 2Mb penalties
here already. Do journalists care? Are the analysts up in arms about
it? Is this going to be the sticking point that prevents Linux from
succeeding on the desktop? Somehow I doubt it. The other machine I'm
using right now (an x86-64 box over ssh) is running a process called
"kflux.rss". It has 17 Mb resident of a 54M virtual size, and I'm
given to understand it's a /screensaver plugin/. The days when typical
small apps consumed a "few hundred k" went out at about the time
OpenLook took off, I'll bet.
I believe it's reasonable for new users to ask about "standalone
executables". They want to check that the system they're about to
invest significant time into learning is actually capable of
delivering the products that they hope eventually to be able to write.
I don't think it's a failing of Lisp that it doesn't have a standard
way to address this perceived problem; if the users stick with Lisp
they will eventually realise that the picture is more complex than
they initially thought and realise that the question is ill-posed. I
do think that the posters on c.l.l could work on a better and more
reassuring response than "don't worry about it now, trust us, you can
work something out when you actually need it".
Here's a couple of starting points:
http://alu.cliki.net/Frequently%20Asked%20Questions
http://ww.telent.net/lisp/according_to/hello-world.html
-dan
Joe Marshall
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
>
> And those are just the serious answers. Some comedians try to convince
> the OP that he should be comparing the download size with all the C
> libraries that his users wouldn't have to download if the app was in C.
> Others suggest that what he really wants is a batch file, a lisp
> environment and a hassle, um, fasl file.
Often, these posters aren't interested in solving a problem but are
rather more interested in trolling.
If someone wants to distribute a C program, they zip up the executable
with the dll's and the lastest version of MFC and put it into a
install script.
If someone wants to distribute a Java program, they take the hierarchy
of class files, turn it into a JAR file and tell the user to get the
latest JRE from Sun.
So why are these acceptable, but the notion of zipping up a fasl file
and asking the user to get a lisp runtime is such a burden? Why is it
unacceptable to launch a program via a batch script, but perfectly
fine to launch it via a `shortcut'? Why is it unacceptable to simply
paste the lisp image onto the tail end of the launcher program?
Why does anyone *care* what the deliverable format is if they are
going to zip it all up anyway?
Matthias
> Often, these posters aren't interested in solving a problem but are
> rather more interested in trolling.
This is also my impression. A nice way of dealing with this class of
questions would be a FAQ with an "Why is CL not popular?" item. This
item would discuss
* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
but you can't generate exes either. The last time an exe-only
application was shipped by a major software company was in 1982 [1].)
* The speed thing.
(Maybe that's outdated: once some people believed if CL does
numerics as speedy as Fortran all Fortran developers would switch to
CL. Counterexamples are again: Java, Pearl, Python which /are/
popular but typically much slower than CL.)
* The garbage collection thing.
(Nobody buys that anymore. If anyone does: Counterexamples are...)
* Maybe a personal anecdote. (But CL is /extremely/ popular! I like
it a lot. And so does my colleague. Better of course would be a
link to a collection of success stories.)
If information like this was available in a FAQ one could easily point
newcomers there: They'd have their answers and people would save time.
When I google for "LISP FAQ" I get a number of results. Is any FAQ
considered especially relevant? Could one transfer that to a Wiki and
work together in creating a useful and up-to-date FAQ? Has it already
been done?
---
[1] The figure 1982 is made up.
Paolo Amoroso
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
The implementation notes document included in GNU CLISP provides
interesting information on this. The ideas about application delivery
may be useful even with other Common Lisp implementations.
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
What about Lisp Machines? :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso
> Thomas F. Burdick wrote:
>> This is a potential market for Lisp, nowadays, and there are good,
>> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
>> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
>> constrained space. It works nicely. If anyone asks, "How do I
>> deliver my app that I have 3/4 developed?" They'll get good advice.
>
> Would you mind terribly muvh to please explain how to do this? I assume
> that you are talking about Common Lisp? I have versions for both Windows
> and Linux and really would appreciate some information about this.
If you are wondering about GNU CLISP, the procedure(s) for delivery
applications are explained in the implementation notes document
included in the system.
Paolo Amoroso
> Coders might not have that much web space or transfer available. End
You might want to check SourceForge.net, Savannah.org and
Common-Lisp.net.
Frank A. Adrian
> I think that the community is turning away trend setters and
> influencers, precisely the people it needs, with its attitude of "If you
> want to eat hippopotamus, you've got to pay the freight."
Why do you think that "the community" needs "trend setters and
influencers"? Are you so insecure that you need to be trendy or seen to
be influencial?
Let me put it another way - "the community" was hideously savaged by
association with this type of people in the early '80's. This type is
more interested in their image than in the substance of the technology or
the good of "the community" and will jetison the later at the drop of a
hat (or more precisely, the "introduction of the new, new thing").
P.S. What the hell do you mean by "the community", anyway?
> They come,
> they're mocked and they go away again, to continue dining on python,
> camel and java.
People stupid enough to do so deserve their fate.
faa
Hannah Schroeter
Matthias <n...@spam.pls> wrote:
>Joe Marshall <j...@ccs.neu.edu> writes:
>> Often, these posters aren't interested in solving a problem but are
>> rather more interested in trolling.
>This is also my impression. A nice way of dealing with this class of
>questions would be a FAQ with an "Why is CL not popular?" item. This
>item would discuss
>* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
> but you can't generate exes either. The last time an exe-only
> application was shipped by a major software company was in 1982 [1].)
The "Pearl" you probably mean is written "Perl". There's a programming
language which is written "Pearl" but you probably don't mean it
(it's some kind of mostly event based realtime programming language
thing, and there are IIRC compiled implementations where at least the
code efficiency will probably be better than that of Perl).
>* The speed thing.
> (Maybe that's outdated: once some people believed if CL does
> numerics as speedy as Fortran all Fortran developers would switch to
> CL. Counterexamples are again: Java, Pearl, Python which /are/
> popular but typically much slower than CL.)
>[...]
Kind regards,
Hannah.
Duane Rettig
> >>>>> On 02 Feb 2004 23:55:15 -0800, Duane Rettig ("Duane") writes:
>
> Duane> cst...@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?
[ histories elided ... ]
> 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.
Well, yes, that's true, but you certainly have an outdated view of
what is small and what is large. And 1 Kb is unrealistic nowadays,
even for highly compact languages. I've heard more things along the
lines of 50 - 100 Kb as realistic tiny-programs, and even up to a
megabyte is acceptable as a small program (no, I have no references,
it's just the "feel" I get from seeing what's out there, what sells,
and what is available in hardware).
So a 2 Mb program is not "small", but it certainly is not large
either. And as memory gets even more and more dense, as long as
CL can stay as small as it is currently without bloating up too
much, it fits into more and more devices.
Let me ask you this - using Moore's Law, even as applicable to
embedded systems, and assuming that in 10 years you buy a
refrigerator that is attached to the rest of your kitchen and
orders the milk online for you when it is low, how much memory
do you think will be in that embedded processor? Do you really
think that they will starve such systems with less than 100 Mb
of memory? And that will be considered a _tiny_ system!
[ more history , etc elided ...]
> As a language, Common Lisp came out of the original "big hard
> problems" community, and I think it shows it.
I agree with the first part, but not the second. If the feel of
lisp's size showed it's origins in "big problem" thought, then
you wouldn't be able to make the following statements, because
by Moore's Law and (is there a Gates' law? :-) the lisps would
then tend to have a base size of 300 Mb, rather than the 2-10 Mb
they are now:
> 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.
Precisely. Why do you think that is? You don't think the vendors have
had anything to do with that?
> 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.
Well, to the extent that personal mobile computing stays stagnant,
I suppose that there would be no reason to want to do a me-too
cell-phone operating system. But why would we ever conclude that
things would stay stagnant? And why limit personal mobile computing
to cell phones? We already have more power than old style mainframes
hanging off our shoulders; why do we think that the "cell-phones"
of the future won't be our main computing devices by then?
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Thomas F. Burdick
> Thomas F. Burdick wrote:
> > This is a potential market for Lisp, nowadays, and there are good,
> > low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> > of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> > constrained space. It works nicely. If anyone asks, "How do I
> > deliver my app that I have 3/4 developed?" They'll get good advice.
>
> Would you mind terribly muvh to please explain how to do this? I assume
> that you are talking about Common Lisp? I have versions for both Windows
> and Linux and really would appreciate some information about this.
All of the Lisps listed above are Common Lisps. CLISP is a very
portable, byte-compiled implementation of CL. I've delivered a
smallish application using CLISP; I did a full CLISP build telling gcc
to optimize for size, stripped the resulting binary, and delivered a
system based on that and a normal CLISP core file. IIRC, the base
system was 800k or so on Linux/x86.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Joe Marshall
> If the feel of lisp's size showed it's origins in "big problem"
> thought, then you wouldn't be able to make the following statements,
> because by Moore's Law and (is there a Gates' law? :-)
Yes there is!
Moore's law: The number of transistors on a chip doubles about every
18 months.
Gates's law: The speed of software halves every 18 months.
Steven E. Harris
> If you have a call to INTERN or READ anywhere, you can generate
> arbitrary symbols at runtime, and unless you can prove that they do
> *not* end up being FUNCALLED, then the entire lisp system is
> accessible.
Are there Lisp systems that allow one to disable INTERN and READ after
the code has been compiled, so that no new, "unexpected" code paths
could be introduced? While I appreciate that one usually has the full
power of the reader and compiler available in a Lisp program, I can
imagine many programs for which these facilities wouldn't be
necessary at deployment time.
--
Steven E. Harris :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com
Duane Rettig
So then, all we have to do is bide our time; in 5 years, CL will
be the smallest _and_ fastest software in the world!
Daniel Barlow
> This is also my impression. A nice way of dealing with this class of
> questions would be a FAQ with an "Why is CL not popular?" item. This
> item would discuss
I think this (a) has been done to death already, and (b) is a very
good way of telling the prospective new user that Lispers are
defensive and feel themselves to be persecuted. So, I propose an
alternative -
Q: Why is CL not popular?
A: Because not very many people know about it yet.
and if the questioner looks disbelieving and starts muttering about
stuff he was forcefed in college, just roll your eyes and add "hell,
that was years ago".
> When I google for "LISP FAQ" I get a number of results. Is any FAQ
> considered especially relevant? Could one transfer that to a Wiki and
> work together in creating a useful and up-to-date FAQ? Has it already
> been done?
There's no canonical and up-to-date FAQ that I'm aware of. I created
a page on the ALU Wiki some time ago, to which all new contributions
(and some selective stealing from the old CLL FAQ, omitting for
example "where can I get PCL" or anything which refers CLTL2 as a
language reference) are welcome
-dan
Henrik Motakef
> > If you have a call to INTERN or READ anywhere, you can generate
> > arbitrary symbols at runtime, and unless you can prove that they do
> > *not* end up being FUNCALLED, then the entire lisp system is
> > accessible.
>
> Are there Lisp systems that allow one to disable INTERN and READ after
> the code has been compiled, so that no new, "unexpected" code paths
> could be introduced? While I appreciate that one usually has the full
> power of the reader and compiler available in a Lisp program, I can
> imagine many programs for which these facilities wouldn't be
> necessary at deployment time.
There certainly are Lisps which allow (or require, for licensing
reasons) the (file-)compiler to be absent from a deployed image. The
situation is basically the same - the deployed Lisp program does not
run in a conforming Lisp implementation any more.
Joe Marshall
>>
>> Gates's law: The speed of software halves every 18 months.
>
> So then, all we have to do is bide our time; in 5 years, CL will
> be the smallest _and_ fastest software in the world!
As part of the work I do here at Northeastern, I had to install the
.NET development environment. This weighs in at around 3GB.
The CADR had an *address space* of about 3MB. (And the original CADRs
had up to 192K of memory.)
Thomas F. Burdick
Erik Winkels
>
> I've delivered a smallish application using CLISP; I did a full
> CLISP build telling gcc to optimize for size, stripped the resulting
> binary, and delivered a system based on that and a normal CLISP core
> file. IIRC, the base system was 800k or so on Linux/x86.
Hey, that fits on a funny looking CD!
Christopher C. Stacy
>> Kids writing "nifty apps" in their spare time and giving them away for
>> free are not industry movers and shakers. Maybe when they grow up
>> they will learn Common Lisp and write something significant.
Cameron> Shaun Fanning. Linus Torvalds. Richard Stallman.
Cameron> Justin Frankel. Marc Andreessen.
The only person in your list who I know enough about to make a
comparison is Richard Stallman. He was not writing toy programs
in high school. He matriculated from Harvard and then went to work
at MIT in the research lab there, where he wrote his programs in Lisp
(and also assembly language and TECO. My own background involves no
formal education, but a few years later I joined him at that lab,
so I am quite familiar with the people and what the environment
was like there. It did not correspond to what you seem to be imagining.
Christopher C. Stacy
So you admit that you are a troll.
Plonk.
Christopher C. Stacy
[ a bunch of stuff]
Perhaps I am not expressing myself very well, but I
believe that we are in complete agreement on all the
points that I raised, and therefore your questions
all sounded rhetorical to me.
Alan Shutko
> I guess there's hope for Stallman, if you can convince him that
> lexical scoping is the way to go.
Actually, there's work on lexical scoping in Emacs going on, and RMS
seems amenable. There are cases in Emacs where dynamic is good, and
it'll stick around, but I think long-term lexical will be used for
most places it is in CL.
AFAIK, RMS's objection to CL is that he thinks it's just too big of a
language to embed in Emacs, and not worth it....
--
Alan Shutko <a...@acm.org> - I am the rocks.
Reflected by the ever-burning sign of the god who happened by.
Thomas Lindgren
Joe Marshall <j...@ccs.neu.edu> writes:
> As part of the work I do here at Northeastern, I had to install the
> .NET development environment. This weighs in at around 3GB.
"But that's different!" :-)
Personally, I don't see the big problem. High-level languages, CL and
others, in my experience produce compact code. Programs also tend to
be parsimonious with resources unless written by novices. (Both of
these properties as compared to conventional commercial software
packages.) Furthermore, portability is generally excellent: once the
underlying language has been ported to the new platform, the remaining
effort is small. (And isn't it's nice that a third party thus can do
most of the work, without even peeking at your code?) My hypothesis is
that the reverse of Greenspun's 10th is a major reason for those
properties.
The people who ask about generating executables probably(?) worry
about whether app delivery, upgrade, and support is incomprehensible
and painful. Maybe a HOWTO or tutorial would be the right thing in
that case, just to show that it's not a problem in practice. At least
it would make a reasonable FAQ.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Steven E. Harris
> The situation is basically the same - the deployed Lisp program does
> not run in a conforming Lisp implementation any more.
It's non-conforming in the sense that it doesn't provide services that
the program doesn't use? That sounds tolerable.
Let me be more clear: If one could remove all the functions and data
from an image that are not required by a given program, the image
could be made much smaller. Consider, for example, a program that adds
a few numbers and prints a result. Surely such a program wouldn't need
much of Common Lisp to get its work done. Maybe the "printing a
result" part would involve streams, which might involve CLOS, and the
dependencies would climb from there.
Is this kind of pruning of unused capability what "tree shaking"
refers to?
n++k
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
Say I'd like to make a demo (http://www.scene.org/) in Common Lisp. I
haven't yet tried, but it poses an interesting problem to the
implementations i've seen, because to be allowed in a competition, a
demo must be:
- standalone
- below a certain size (64k for the intro category, 10M - 20M for a
demo), counting the media assets used (music, sound, textures,
models)
- reasonably fast
It's a rather niche market, but it's a shame, Common Lisp would seem
like an ideal environment to 'grow' a demo in. As a demo is an
artistical product, it would benefit from a shortened feedback loop
between the act of coding (poiesic process) and the act of
experiencing its results (esthesic process)
One very messy way to still use common lisp would be to use it for
prototyping, and somehow, from the same code, produce a c
representation of it for releasing, with just the proper dependencies.
Henrik Motakef
> Henrik Motakef <usenet...@henrik-motakef.de> writes:
>
> > The situation is basically the same - the deployed Lisp program does
> > not run in a conforming Lisp implementation any more.
>
> It's non-conforming in the sense that it doesn't provide services that
> the program doesn't use? That sounds tolerable.
Of course, in many cases it is. Otherwise nobody would use this
feature.
> Let me be more clear: If one could remove all the functions and data
> from an image that are not required by a given program, the image
> could be made much smaller. Consider, for example, a program that adds
> a few numbers and prints a result. Surely such a program wouldn't need
> much of Common Lisp to get its work done. Maybe the "printing a
> result" part would involve streams, which might involve CLOS, and the
> dependencies would climb from there.
>
> Is this kind of pruning of unused capability what "tree shaking"
> refers to?
Yes, at least as I understand it. But to make this possible, the
program has to be written in a specific way from the beginning. For
example, a general "plugin" mechanism where each plugin can internally
use all of CL (as discussed in another recent thread) would probably
be impossible.
This may or may not be a worthwhile tradeoff. There are other
tradeoffs between, say, speed and genericity, like whether you
implement something with a generic or an ordinary function. Generally,
it seems to be best to allow both styles, but in the case of
genericity vs. image size, it seems to me that you have to decide
pretty early in the development cycle - a CL program meant to run in a
size-optimized, functionally restricted environment will probably be
quite different from one that can assume all of Common Lisp being
available.
André Thieme
> Right - but as I said in another thread there are (even free) tools
> like "Inno Setup"[1] which, if necessary, will hide all this
> complexity from the user. I have a hard time imagining a client who
> wouldn't want to go through a simple routine like that. Windows users
> launch these "installers" every day and they really don't care if they
> install one file or one hundred.
I personally "hate" these installers for little applications.
If I want to download a little tool, lets say a ftp client, an auto
reminder, etc. I would prefer it much more if it is one .exe or a zipped
file that I can simply unzip where I want and that's it.
When I don't want to use this application anymore I can simply delete
the directory and forget it. When it was installed with an installer I
need to run an uninstaller.
Even big applications like Mozilla can be easily "installed" by just
unpacking a zip file.
Of course this "zip trick" could also work for CL apps. I could simply
write a 20k .exe file that runs Lisp and loads/executes my program that
I shipped with the packed file.
For some small applications, maybe a nice Minesweeper or Solitair game
an single, clickable .exe file is simply the best (for me).
To reduce the size of this binary one can simply upx them:
http://upx.sourceforge.net/
(also works under linux, open source)
This sounds like a fair solution to me.
André
Cameron MacKinnon
> Cameron MacKinnon <cmack...@clearspot.net> writes:
>>At least once a month, someone asks how to deliver a "standalone"
>>executable of a Lisp application. It's often his first post, and often
>>his last.
>
> rather more interested in trolling.
I have to emphatically disagree. There are trolls out there, but these
people aren't them. Their question is quite a reasonable one, given a
background in other programming languages. And the fact that a
continuing stream of people shows up here and asks more or less the same
question ought to highlight an area where the documentation could use
improvement.
> If someone wants to distribute a C program, they zip up the executable
> with the dll's and the lastest version of MFC and put it into a
> install script.
It should be remembered how this process came about: In the Windows
world, where the dll search path was short and hardcoded, the namespace
was 8.3 (with the last 3 being .dll) and the libraries in rapid flux and
buggy, this led to "DLL Hell" - installing or removing application B
made application A buggy or unusable, for reasons unclear to the end user.
Early install "shield" programs were as bad as the disease, but the name
of the market leader gives a clue as to the origin - to shield users and
developers from the pain of a poorly designed shared library model.
On the UNIX side, many developers, even today, continue to ship
monolithic, static binaries. This avoids support calls caused by the
user having subtly different library versions. The user pays, because
his two apps, both statically linked with e.g. Motif, can't share memory.
This is not to say that Lisp developers can't or shouldn't use
installers as well. As other posters have pointed out, some Windows
users are now so comfortable with the process that they're suspicious of
apps which don't provide one. And in recent years, progress has been
made - you don't always have to shut down all other applications before
and reboot the operating system after installing a minor app.
But it should be remembered that these installers were created to solve
problems that Lisp doesn't necessarily have.
> If someone wants to distribute a Java program, they take the hierarchy
> of class files, turn it into a JAR file and tell the user to get the
> latest JRE from Sun.
Or, if it's an applet, the browser walks the user through the process.
> So why are these acceptable, but the notion of zipping up a fasl file
> and asking the user to get a lisp runtime is such a burden? Why is it
> unacceptable to launch a program via a batch script, but perfectly
> fine to launch it via a `shortcut'? Why is it unacceptable to simply
> paste the lisp image onto the tail end of the launcher program?
It depends on the size and utility of the application. For a big enough
app, "get and install an Oracle DBMS" isn't considered an unreasonable
additional requirement. But for stuff at the smaller end, distributed
free for the asking over the 'net, every extra megabyte, prerequisite or
installation step will cause a significant fraction of end-users to
disqualify themselves.
To a certain extent, this is true of developers as well. Clicking on
"Build EXE" (is that what Windows IDE folks do these days?) or typing
"make" is universally acceptable. Finding and using an install wizard
somewhat less so. And so on.
Wade Humeniuk
>
> Say I'd like to make a demo (http://www.scene.org/) in Common Lisp. I
> haven't yet tried, but it poses an interesting problem to the
> implementations i've seen, because to be allowed in a competition, a
> demo must be:
> - standalone
> - below a certain size (64k for the intro category, 10M - 20M for a
> demo), counting the media assets used (music, sound, textures,
> models)
> - reasonably fast
I guess that leaves Java out. Common Lisp is a shoe in though, but
watch out for those media assets, they can suck a ton of space.
Wade
Duane Rettig
I think we mostly do agree, but I took exception and to regarded
as hyperbolic your statement about Lisp Vendors not caring about
delivering a 1 Kb executable. It's the old "have you stopped
beating your wife" question. Even on linux, the default gcc
compilation of hello.c is 11 Kb, and if you strip it it becomes
2 Kb. But what is more important is not the size of the executable;
it is the size in memory; when stepping hello through gdb ps tells
me that hello is consuming 1.3 Mb of memory. Not far from what
you can see in a small application in a well-configured CL
implementation
Many common lisps allow the creation of very small executables
via the #! shell construct, on operating systems which support
it. In fact Allegro CL allows such constructs to be prepended to
fasl files, so not only is the code loaded into the target lisp
small, it is pre-compiled! But we do not promulgate such tricks
because they are pretty much meaningless; what we really target
is memory size. And if we can, for any reasonable size of problem,
provide a reasonable size for the image that is generated (both
in terms of disk space and in terms of total memory footprint)
then we've done a good job at caring about image sizes.
Rayiner Hashem
Um, I don't see how an islisp link helps here, since I thought this
was a defacto CL newsgroup. I like islisp very much as a language its
severely lacking compared to CL in the department of available
libraries.
> Did you check all of http://alu.cliki.net/Implementation ?
Most of them. Because of my platform (Linux/KDE), architecture (x86),
and budget (cheap), CMUCL/SBCL are really the best choices. Both are
excellent compilers, but don't support binary distribution with a
shared runtime.
> Do you really think there is something missing?
I think the Lisp equivilent of GCC is missing. Something free that has
very good performance, runs on lots of platforms, has very good
language compatibility, and has broad support.
Of course, that's just me. Yet, that was my whole point in getting
into this discussion. Someone accused of the poster who started this
thread of being a troll who was just looking for excuses not to use
Lisp. Depending on your situation, there may be very good reasons that
you simply cannot use Lisp for a given program.
Edi Weitz
> CMUCL/SBCL are really the best choices. Both are excellent
> compilers, but don't support binary distribution
Why not? I just shipped a CMUCL binary to a customer. It consisted of
the little 'lisp' driver program, a custom-built core file, and an
'install.sh' script that moved both of these somewhere (say,
/opt/my-app/) and created an executable shell script
/usr/local/bin/my-app that looked like
#!/bin/sh
/opt/my-app/lisp -core /opt/my-app/my-code
Presto. Just unpack the tarball and 'sh install.sh' - done. Isn't that
binary distribution?
> with a shared runtime.
Ship the normal core plus a FASL file and change your shell script to
be something like
#!/bin/sh
/opt/my-app/lisp -noinit -core /opt/cmucl/normal-core -load my-app.x86f
Edi.
mikel
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
> freepascal is to pascal. For the people that find these threads
> annoying, easy solution, don't read them.
>
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
> Could some type of linker strip out portions of the runtime library
> that aren't required?
It's easy (even without intending to) to write Lisp code that makes it very
hard to tell which parts of the runtime aren't required.
Rayiner Hashem
> distributing the _source code_, not the binaries.
No! The whole point of Open Source is making source code available.
Users should not have to deal with source code unless they want to. A
lot of people work very hard to make sure that users never have to see
the source, but always can if they need to.
> From the RES column it looks like I'm paying a number of 2Mb penalties
> here already.
That's a terrible way to measure memory usage. If I add up the RSS
entries on my machine right now, I get way more memory than is
actually in use. And I'm not using swap either. But in either case, I
thought we were talking about 2MB in terms of binary-size. After all,
what was all that talk about it only being as large a download as a
single MP3 file? The actual memory usage of the binary is going to be
a lot higher than the size of the binary on disk. For reference, even
a fairly significant KDE app like Quanta is only 1.5MB on disk. Of
course, that's with 30MB of supporting libraries, but those are only
loaded once so nobody cares. Heck, even d2c produces 500KB stand-alone
executables, and that's without (if I understand correctly) a
tree-shaker. Of course, KDE has 30MB of shared libs, and d2c has 20MB,
but those are a one-time cost, not a recurring one. Given that, CL
code should easily compile to svelte executables a few-hundred KB in
size. I think the biggest issue is that none of the free
implementations really do it.
Christopher C. Stacy
Duane> cst...@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
>> [ a bunch of stuff]
>>
>> Perhaps I am not expressing myself very well, but I
>> believe that we are in complete agreement on all the
>> points that I raised, and therefore your questions
>> all sounded rhetorical to me.
Duane> I think we mostly do agree, but I took exception and to
Duane> regarded as hyperbolic your statement about Lisp Vendors not
Duane> caring about delivering a 1 Kb executable.
I was reponding to the troll, who was claiming that Lisp can't
deliver small stand-alone executables (which is true, if you
adjust the parameters down the point of nonsense).
My point was that that's nonsense, which is why the
vendors don't (and should not) care about it.
Joe Marshall
> Joe Marshall <prunes...@comcast.net> writes:
>
>> If you have a call to INTERN or READ anywhere, you can generate
>> arbitrary symbols at runtime, and unless you can prove that they do
>> *not* end up being FUNCALLED, then the entire lisp system is
>> accessible.
>
> Are there Lisp systems that allow one to disable INTERN and READ after
> the code has been compiled, so that no new, "unexpected" code paths
> could be introduced?
Er, sort of.
It would have to have `load' and `fasload' disabled as well, and of
course the debugger, too. The problem is that even something as
simple as (+ a b) *could* end up running any piece of arbitrary code
(consider if A isn't a number) and the tree shaker has no reason to
believe that it won't.
--
~jrm
Duane Rettig
> >>>>> On 03 Feb 2004 14:02:44 -0800, Duane Rettig ("Duane") writes:
>
> Duane> cst...@news.dtpq.com (Christopher C. Stacy) writes:
> >> >>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
> >> [ a bunch of stuff]
> >>
> >> Perhaps I am not expressing myself very well, but I
> >> believe that we are in complete agreement on all the
> >> points that I raised, and therefore your questions
> >> all sounded rhetorical to me.
>
> Duane> I think we mostly do agree, but I took exception and to
> Duane> regarded as hyperbolic your statement about Lisp Vendors not
> Duane> caring about delivering a 1 Kb executable.
>
> I was reponding to the troll, who was claiming that Lisp can't
> deliver small stand-alone executables (which is true, if you
> adjust the parameters down the point of nonsense).
But this argument becomes specious, if the parameters are adjusted
down to the point where it is nonsense even for languages that
are _known_ for their ability to deliver small applications.
The "troll" you responded to had a good point, and never
mentioned any actual sizes. And your response was:
| Common Lisp was not designed for delivering small applications
| and most of the vendors are not interested in that market.
which is half false. Many Common Lisp vendors do care to
make their product as small as possible, so as to grab as much
of the small application market as possible, as that market pushes
its way up through the barriers of those factors which limit how
small CLs can in fact get. And yes, we do get new customers
that way, as they discover that CL is not as big and bulky as
they once believed, and can indeed handle their (constantly
growing) small applications.
> My point was that that's nonsense, which is why the
> vendors don't (and should not) care about it.
Now, of course, _this_ market is one we obviously don't care
about (i.e. the 1k-byte application market) because it doesn't
exist.
I think our differences in perception stem from what each of us
views as a "small" application (or at least what each of us is
willing to admit is in fact a believable small application in
2004 terms).
n++k
The languages of implementation are indeed typically C and C++ (with
some odd bit of asm for the 4k intro competitions, even though quite a
few manage to do them in C/C++)
Java has been occasionally allowed, when the jvm was part of the
operating system the competition targeted. Competitions are targeting
consumer operating systems as a general rule, so it means having to
cooperate with C libraries or with the few runtimes already present.
UPX (http://upx.sourceforge.net/) can help with big executable sizes,
but you have to start from a reasonable point
Matthias
> >* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
> > but you can't generate exes either. The last time an exe-only
> > application was shipped by a major software company was in 1982 [1].)
>
> The "Pearl" you probably mean is written "Perl". There's a programming
> language which is written "Pearl" but you probably don't mean it
> (it's some kind of mostly event based realtime programming language
> thing, and there are IIRC compiled implementations where at least the
> code efficiency will probably be better than that of Perl).
I meant Perl. Thanks for the correction. My subconsciousness somehow
believed that this language should be spelled more complicated than it
actually is. ;-)
Daniel Barlow
>> Which you're quite right not to mention, because Open Source is about
>> distributing the _source code_, not the binaries.
> No! The whole point of Open Source is making source code available.
> Users should not have to deal with source code unless they want to. A
> lot of people work very hard to make sure that users never have to see
> the source, but always can if they need to.
And I'm greatly indebted to projects like Debian for doing this
packaging so that I as a sysadmin don't have to. Two points:
(1) The binaries on my systems were built by Debian (or by me, in a
few cases), not by the upstream author. As an author of free
software, I don't have to concern myself with "generating executables"
much beyond making sure it's somehow possible.
(2) The Debian packaging system dependency management knows how to
find shared libraries, making "standalone" so totally not even an
issue. If I as a free software author write some code that requires
additional resources (shared libraries, or a Lisp environment, or
whatever), all that the packager has to do is declare dependencies on
those external resources and they'll get downloaded when I install the
first app that needs them. There's no need for a "single .exe"
I was a bit overemphatic in my original post, but I still maintain
that distributing executables is not the primary concern of the free
software author. For the most part, that responsibility has shifted
to packagers, and if the two roles sometimes coincide, that's just
coincidence.
>> From the RES column it looks like I'm paying a number of 2Mb penalties
>> here already.
> That's a terrible way to measure memory usage. If I add up the RSS
> entries on my machine right now, I get way more memory than is
> actually in use. And I'm not using swap either. But in either case, I
> thought we were talking about 2MB in terms of binary-size. After all,
If you trace backward through the thread, you'll find that we were
talking about memory usage at this point: you said "UNIX machines have
lots of little daemons running in the background, so paying a 2MB
penalty for each one would significantly change the hardware
requirements of the system": given the current price of hard disks, I
find it hard to believe you were talking about binary size here.
> but those are a one-time cost, not a recurring one. Given that, CL
> code should easily compile to svelte executables a few-hundred KB in
> size. I think the biggest issue is that none of the free
> implementations really do it.
It's quite rare that my fasls get as large as a few hundred kB, actually.
-dan
Erik Winkels
>
> Given that, CL code should easily compile to svelte executables a
> few-hundred KB in size. I think the biggest issue is that none of
> the free implementations really do it.
Have you checked out ECL?:
http://ecls.sourceforge.net/ecldev/devel_2.html#SEC3
Erik
--
"With the emergence of the mushroom cloud over its headquarters, Gartner
believes it's time for people to start investigating some other means of
settling conflicts than war." -- Ralph Wade Phillips in the Monastery
Christopher C. Stacy
Duane> The "troll" you responded to had a good point, and never
Duane> mentioned any actual sizes. And your response was:
He was rejecting the information given him about the small sizes and
formats of the deliverables that most implementations do generate.
Duane Rettig
I entertained the possibility that my rememberance of how this
thread started was in error, since my news reader doesn't have
a previous article for the one by Cameron MacKinnon to which you
responded. So I went back to Google, and it looks like Google's
memory of it is similar to mine; his article was the first one
in this thread.
Actually, I was incorrect on one point; he did mention two actual
sizes:
- He mentioned that lispers tell him that his application
would be 11 Mb (it's probably true that he is told that,
and it is completely unnecessary).
- He talked about the original size of Perl, which was probably
also accurate, though it was probably only binary size that
he was describing.
So if it is the 11Mb lower limit that you are talking about him
rejecting, then OK, but I agree with him; it is possible in Allegro
CL to create much smaller lisp images, and the in-memory usage
can also be made much smaller, as well. It is also true that we've
had some bugs where modules get inadvertently loaded in when
undesired, but the point there is that we consider these to be bugs,
and fix them as quickly as possible.
Marc Spitzer
> On 3 Feb 2004 16:22:46 -0800, hel...@mindspring.com (Rayiner Hashem) wrote:
>
>> CMUCL/SBCL are really the best choices. Both are excellent
>> compilers, but don't support binary distribution
Code has been commited to allow cmu to create exe's on freebsd. I
think sbcl can also do it. I do not know about openmcl.
marc
Edi Weitz
Just to make this clear: There's nothing in the above quote that was
written by me so I wonder why the message has to start with "Edi Weitz
wrote."
Edi.
Camm Maguire
executables for maxima, acl2, and axiom in the Debian GNU/Linux
distribution. While complete independence from standard
(i.e. non-lisp) system shared libs is possible, its more efficient in
a setting like this to dynamically link against libc, for example,
as is the case in the three aforementioned programs. Installing these
packages does not require GCL to be installed.
Take care,
Marc Spitzer <mspi...@optonline.net> writes:
> Edi Weitz <e...@agharta.de> writes:
>
> > On 3 Feb 2004 16:22:46 -0800, hel...@mindspring.com (Rayiner Hashem) :
> >
> >> CMUCL/SBCL are really the best choices. Both are excellent
> >> compilers, but don't support binary distribution
>
> Code has been commited to allow cmu to create exe's on freebsd. I
> think sbcl can also do it. I do not know about openmcl.
>
> marc
--
Camm Maguire ca...@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Christopher C. Stacy
Duane> cst...@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On 03 Feb 2004 21:29:45 -0800, Duane Rettig ("Duane") writes:
Duane> The "troll" you responded to had a good point, and never
Duane> mentioned any actual sizes. And your response was:
>>
>> He was rejecting the information given him about the small sizes and
>> formats of the deliverables that most implementations do generate.
Duane> So if it is the 11Mb lower limit that you are talking about him
Duane> rejecting, then OK,
He was persisting in his arguments after people pointed out that:
Duane> it is possible in Allegro CL to create much smaller lisp images
Did you notice that he went away after he was all done trolling?
Tim Bradshaw
>
> Now, of course, _this_ market is one we obviously don't care
> about (i.e. the 1k-byte application market) because it doesn't
> exist.
I suspect it does exist, still, although not in general machines. I
admit to not having looked that recently (say within the last 2
years), but there certainly were an awful lot of microcontrollers sold
which had maybe a couple of K of ROM and some small number of bytes of
RAM. I'd guess that these things are still used, and possibly used in
enormous numbers, since in the market they're aimed at getting things
very cheap is a significant win, and the computastional requirements
are not very large. It may be though that you can put hundreds of K
of ROM on them for nothing (literally...) now though.
Of course, if this market still exists it's probably not interesting
for CL, even though it may be very large.
--tim
Thomas F. Burdick
> hel...@mindspring.com (Rayiner Hashem) writes:
>
> >> Which you're quite right not to mention, because Open Source is about
> >> distributing the _source code_, not the binaries.
> >
> > No! The whole point of Open Source is making source code available.
> > Users should not have to deal with source code unless they want to. A
> > lot of people work very hard to make sure that users never have to see
> > the source, but always can if they need to.
>
> And I'm greatly indebted to projects like Debian for doing this
> packaging so that I as a sysadmin don't have to. Two points:
>
> (1) The binaries on my systems were built by Debian (or by me, in a
> few cases), not by the upstream author. As an author of free
> software, I don't have to concern myself with "generating executables"
> much beyond making sure it's somehow possible.
And in the case of CL, it's possible to tackle both at the same time,
using asdf and asdf-install. Sure, you have to wait for it to build,
but you don't have to do it yourself. It's almost as good as binary
packages.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Paolo Amoroso
> On 3 Feb 2004 16:22:46 -0800, hel...@mindspring.com (Rayiner Hashem) wrote:
>
>> CMUCL/SBCL are really the best choices. Both are excellent
>> compilers, but don't support binary distribution
>
> Why not? I just shipped a CMUCL binary to a customer. It consisted of
> the little 'lisp' driver program, a custom-built core file, and an
I ship a CMUCL application based on McCLIM in a similar way.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Tim Bradshaw
>
> The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
> worth its money, which includes free distribution of those "standalone
> applications".
That's always the hidden subtext to these questions: you are not
allowed to use a commercial product to answer them. Remember that all
commercial software is evil, written by horrible, people who all want
to destroy the world while getting rich, crushing the proletariatand
who will generally be first up against the wall come the revolution.
Rayiner Hashem
> the little 'lisp' driver program, a custom-built core file, and an
> 'install.sh' script that moved both of these somewhere (say,
not support the type of binary distribution I'm talking about --- a
native-compiled executable and a shared library for the runtime. As
for why I'm talking about this sort of binary-distribution
specifically, well, that's kind of the way the thread headed after my
first post.
Duane Rettig
> Duane Rettig <du...@franz.com> wrote in message news:<4ad3ze...@franz.com>...
>
> >
> > Now, of course, _this_ market is one we obviously don't care
> > about (i.e. the 1k-byte application market) because it doesn't
> > exist.
>
> I suspect it does exist, still, although not in general machines. I
> admit to not having looked that recently (say within the last 2
> years), but there certainly were an awful lot of microcontrollers sold
> which had maybe a couple of K of ROM and some small number of bytes of
> RAM.
I'd be interested in seeing any specs for such hardware. For the
past 30 years, as soon as memory of one size became prevalent and
its cost came down to match memory of smaller size, the smaller sized
chips/boards became obsolete, because there was never any reason to
spend the same money for less RAM as to get the larger RAM. In fact,
the only reason that _might_ have kept such older chips/boards
around was compatibility, but the smarter hardware always allows for
pin-compatible upward mobility (unless it is so cheap as to be throw-away,
in which case the whole model becomes obsolete and is replaced by the
next generation). It might be interesting to see what the smallest
processors (perhaps divided into two categories: general purpose and
special-purpose) are that are currently sold.
> I'd guess that these things are still used, and possibly used in
> enormous numbers, since in the market they're aimed at getting things
> very cheap is a significant win, and the computastional requirements
> are not very large. It may be though that you can put hundreds of K
> of ROM on them for nothing (literally...) now though.
Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
> Of course, if this market still exists it's probably not interesting
> for CL, even though it may be very large.
At issue is the size of the markets for machines of various sizes.
Imagine a curve, where if you plot the size of memory in computing
devices against the number of units sold, you would get a sweet spot
at some size of memory which happens to be a the lowest end of the
mass-production scale; i.e. if you make a 1M chip and it costs you
less to make a 500K chip, but a 250K chip costs the same as a 500K
chip, then the sweet spot in the curve will hover around those units
which use the 500K chip. That sweet spot is moving rapidly, according
to Moore's Law, and to the extent that it is close to the point where
CLs can operate comfortably, we in the CL business most _certainly_
should be interested in it. We have to be careful not to let ourselves
get trapped in "codgerism" (I just coined this term) where we old
codgers can't imagine a world where so much memory is available for
so cheap, and thus we imagine the curve I am describing as being
further down the scale than it really is, and thus miss a potential
market.
mikel
With OpenMCL, binary distribution means dumping a memory image and
distributing it with a copy of the (472K) lisp kernel. Maybe it also means
including a small shell script to launch the kernel with the image.
But this is mostly irrelevant on Mac OS X, where if you are distributing a
'binary' for easy launching, you are probably distributing an application
bundle. It's straightforward to package an OpenMCL application as an
application bundle, although there are a lot of fussy steps that aren't
necessarily obvious. The mac-lisp-ide mailing list at common-lisp.net is
working on making things easier.
Cameron MacKinnon
I mentioned commercial Lisps in my original posting, which wasn't a
question.
For people whose business model (or hobby) is delivering small apps to a
comparatively large audience for free, I don't think commercial
offerings are precluded at all, provided that the runtime isn't licensed
on a per-user basis.
Perusing c.l.l[1], most posers of the question have either mentioned a
specific Lisp implementation (some commercial, some free), or explicitly
stated their price point with words like inexpensive or free.
Even if we say that all the rest of the posts have a "hidden subtext",
they'd still be a small minority. But I'm not willing to engage in this
sort of paranoia.
[1]
http://groups.google.com/groups?q=executable+group:comp.lang.lisp&hl=en&lr=&ie=UTF-8&start=10&sa=N
Cameron MacKinnon
> I'd be interested in seeing any specs for such hardware. For the
> past 30 years, as soon as memory of one size became prevalent and
> its cost came down to match memory of smaller size, the smaller sized
> chips/boards became obsolete, because there was never any reason to
> spend the same money for less RAM as to get the larger RAM. In fact,
> the only reason that _might_ have kept such older chips/boards
> around was compatibility, but the smarter hardware always allows for
> pin-compatible upward mobility (unless it is so cheap as to be throw-away,
> in which case the whole model becomes obsolete and is replaced by the
> next generation). It might be interesting to see what the smallest
> processors (perhaps divided into two categories: general purpose and
> special-purpose) are that are currently sold.
See www.microchip.com (a representative manufacturer with a broad line).
Briefly, the chips range from about 1/2k to 128k of flash or one time
programmable ROM, and a few tens of bytes to a few k of RAM. C, Forth
and assembly are the tools of choice. Odd, non Von Neumann architectures
are common. Millions of units. Lisp would need to be CONSless.
Somewhat bigger than that, there's 32 bit MCUs with specialized DSP
units. These would have enough horsepower to run a Lisp, but garbage
collection would have to be realtime, and the coders would want to do
their inner DSP loops in assembly anyway.
> Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
Scheme for Lego Mindstorms: http://www.cs.indiana.edu/~mtwagner/legoscheme/
Cameron MacKinnon
> I mentioned commercial Lisps in my original posting, which wasn't a
> question.
My original post was, obviously, a question. But the question was "Why
does the lisp community abuse those who ask how to create executables?"
Henrik Motakef
> That's always the hidden subtext to these questions: you are not
> allowed to use a commercial product to answer them. Remember that all
> commercial software is evil, written by horrible, people who all want
> to destroy the world while getting rich, crushing the proletariatand
> who will generally be first up against the wall come the revolution.
Oh come on. There is not always this hidden subtext, and you should
know perfectly well that the strawman you make up does not reflect the
position of most users (or implementors) of free/open source Lisps, at
least not of those who speak up in cll.
The CMUCL/SBCL/ECL/CLISP guys do not seem to be on a Djihad against
commercial software vendors for all I can tell. Neither is Franz,
Inc. I guess, who wrote a lot of free Lisp stuff, and a GNU-derived
license for it to boot. Neither can I imagine most of the authors of
asdf-installable free libraries, or much of the stuff available in the
CMU AI repo for that matter, to secretly be members of stalinist
organizations.
Did it ever occur to you that people who just want to try Lisp, not
doing anything too serious and hence not willing to spend a lot of
money (it has become quite unusual to have to pay anything before you
can use a language; except for Delphi and VB6, I can't think of many
popular languages that do not have a free implementation) and who
already decided to use a Unix platform (which today basically means
"any non-windows platform") could indeed be better served by a free
implementation than with, say, a trial version of Lispworks or
Allegro? It can be just a simple, completely rational decision - can
you live with heap-size/time/delivery/whatever restrictions, or would
it be better to ignore the "upgrade" path to a fully supported version
and use a fully functional version of a Lisp system that has more
features right now, for zero cost, but might not have all the features
you'll get once you shell out the money for a full version? This is
something that everyone has to decide based on the specific
requirements for a concrete project, neither decision is morally right
or wrong.
There are good arguments for free software, and they do not have much
to do with the stereotypical raving zealot you imply, and there are
good arguments against it. There are also stupid arguments on both
sides, but I'd rather not have these discussed on cll frequently, and
so far my impression is that the discussion style of the resident
free-software camp has been pretty civilized (the occasional die-hard
GNU troll did happen, but went away quickly, without getting too much
support). Please keep it at that level. The "Lisp community" might be
small (or non-existing as such), but there is room for both views.
Frank A. Adrian
> I suspect it does exist, still, although not in general machines. I
> admit to not having looked that recently (say within the last 2
> years), but there certainly were an awful lot of microcontrollers sold
> which had maybe a couple of K of ROM and some small number of bytes of
> RAM. I'd guess that these things are still used, and possibly used in
> enormous numbers, since in the market they're aimed at getting things
> very cheap is a significant win, and the computastional requirements
> are not very large. It may be though that you can put hundreds of K
> of ROM on them for nothing (literally...) now though.
You can now get 64K of RAM with little cost and the lowest amount of RAM
(other than for very specialized SoC custom designs) that I could find
was about 4K. Most also come with external mem I/F's and enough ROM to
hold a fairly comlete Lisp system. My gut feel says that you could keep
an entire Lisp runtime (ANSI compliant, sans #'compile & friends) on a
sub-$5 chip (in quantities of 10,000 or more :-) these days. Now what
you'd want to do with it that didn't require more RAM (other than gretting
your system's code out quickly - which is probably a win in itself) is, of
course, another question.
faa
Fred Gilham
Cameron MacKinnon <cmack...@clearspot.net> writes:
Your term "abuse" is certainly open to debate, but I'll assume for the
moment it's not too far off the mark. The reason people in
comp.lang.lisp react negatively to such questions is because they are
part of a class of questions which can be phrased something like the
following:
"Why is Lisp so weird?"
The most common variation on this is something like
"Why isn't Lisp more like XXXX?"
where XXXX is the latest horrid offering from the
programming-language-hype community.
The consensus among many Lisp aficionados is that Lisp is some kind of
local maximum in the programming universe, and when someone new comes
along and suggests "improvements" to make it more like the other
programming languagues, they are pessimizing rather than optimizing.
The other point is that people who come along asking questions like
the above often have the attitude that they are uttering profound
originalities, whereas because Lisp is so old, most everything that
can be tried has been tried in Lisp.
There's also the "cave man" view of Lisp:
"Ugh! Lisp different!! Me *suspicious*!!!"
This wears thin after a while.
Let's say someone comes, and says, "Can you make executables with
Lisp?" A perfectly correct answer would be "Yes, there are several
ways of doing it." But then you find that they really want something
just like what C does. But Lisp is different from C, and has a
different mind set. People who complain about that mark themselves as
poor candidates for learning Lisp, and probably not worth the trouble
of helping.
--
Fred Gilham gil...@csl.sri.com
The nice thing about being a celebrity is that when you bore people,
they think it?s their fault. --- Henry Kissinger
Henry Hansen
news:401f4...@news.athenanews.com:
> It's easy (even without intending to) to write Lisp code that makes it
> very hard to tell which parts of the runtime aren't required.
I think I see your point: a macro driven indirection of sorts makes it
difficult to trace dependencies. Do some Lisp programs dynamically
modify their runtimes, morphing in a sense?
also ...
Are you aware of any Lisp interpreters that manifest themselves inside a
database? For example, similar to stored procedures in SQL Server.
Seems to me this macro capability would work very well in this context.
Thanks!
Scott Schwartz
examples do exist. Siskind's stalin compiler is a beautiful example
of how lisp can do the right thing. It takes lisp source and gives
you a small, fast, native executable. No ideological arguments, just
great results!
Thomas F. Burdick
Great results? When my Stalin program destroys the material basis for
its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
am *not* willing to lose basic dynamicity! Give me C++ before a
"Lisp" that's not dynamic!
Thien-Thi Nguyen
> My original post was, obviously, a question. But the question
> was "Why does the lisp community abuse those who ask how to
> create executables?"
"how can i cover up, or otherwise hide
and keep undisclosed, my experiments inside?"
"experiment? or experience? is there no locus
whereby these concepts may share spotlight, focus?"
"wtf! back off! i just wanna deliver a package.
(my users don't grok w/ the low-level hackage.)"
"what is the high high? where is the low low?
truth and fidelity are less if you go slow?"
"it's sad that i have to join the accusers:
those who have wisdom are the self-same abusers."
"but how should i cover up, or otherwise feign
and keep undisclosed, my experience gained?"
"experience? or excrement? is there no forum
where politely put questions are met w/ decorum?"
"wtf! back off! my name is not Abigail.
maybe this OT spew we can take to private mail?"
"how does the lie lie? why does the flow flow?
are you afraid to admit that you really don't know?"
"too bad we've botched our chance at self-censorship.
some idiot poet has made an attempt at svelte mentor quips."
Joe Marshall
> mikel <mikel...@sbcglobal.net> wrote in
> news:401f4...@news.athenanews.com:
>
>> It's easy (even without intending to) to write Lisp code that makes it
>> very hard to tell which parts of the runtime aren't required.
>
> I think I see your point: a macro driven indirection of sorts makes it
> difficult to trace dependencies. Do some Lisp programs dynamically
> modify their runtimes, morphing in a sense?
Some do. Some do it unintentionally. Some problems can be difficult
to solve without dynamically modifying the runtime. You have to weigh
the advantages of doing so (possibly easier development) against the
disadvantages (unintended interdependencies, deployment issues).
Those with less experience at doing this are more likely to make
mistakes.
--
~jrm
Matthew Danish
If, by the right thing, you mean the same thing that C programs do, then
perhaps. But most Lisp programmers are interested in better behavior
than what C programs exhibit.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Jens Axel Søgaard
> On Thu, Feb 05, 2004 at 01:56:54AM -0500, Scott Schwartz wrote:
>>That is certainly how most Common Lisp folks seem to feel, but counter
>>examples do exist. Siskind's stalin compiler is a beautiful example
>>of how lisp can do the right thing. It takes lisp source and gives
>>you a small, fast, native executable. No ideological arguments, just
>>great results!
> If, by the right thing, you mean the same thing that C programs do, then
> perhaps. But most Lisp programmers are interested in better behavior
> than what C programs exhibit.
Stalin takes a Scheme program and compiles it to one (large)
C file importing code for the runtime. The C file is then compiled
to one standalone executable.
(If my memory serves me right)
--
Jens Axel Søgaard
Ray Dillinger
>
> Let's say someone comes, and says, "Can you make executables with
> Lisp?" A perfectly correct answer would be "Yes, there are several
> ways of doing it." But then you find that they really want something
> just like what C does. But Lisp is different from C, and has a
> different mind set. People who complain about that mark themselves as
> poor candidates for learning Lisp, and probably not worth the trouble
> of helping.
Excuse me. I have not made such a request on the newsgroup, and I
am not a newbie, but "just like what C does" *IS* the expectation
that I have to conform to in order to produce software that other
people can use. I have to deliver an executable that my customer,
client, or user can use and treat in exactly the same way that he
or she treats all other executables - most of which are built
with C++ systems - or my user base will ignore my program to death.
That means it needs to be statically linked machine code that they
can invoke from a unix command line in exactly the same way they invoke
other statically linked machine code executables.
I can't ask my user base to install strange packages and configure
runtimes, or enter commands into an unfamiliar CLI (the lisp shell)
etc just to use my little program; Every thing they need to do, no
matter how insignificant to me, is something that can go wrong for
them making it unusable.
I can afford dynamic links to Libc, perhaps, or other libraries that
exist on every unix system. But if there are lots of systems out
there that don't have it, or configuration that homer husband and
harriet housewife can mess it up by doing wrong or failing to do,
then I want it statically linked.
Bear
Ray Dillinger
>
> Scott Schwartz <"schwartz+@usenet "@bio.cse.psu.edu> writes:
>
> > That is certainly how most Common Lisp folks seem to feel, but counter
> > examples do exist. Siskind's stalin compiler is a beautiful example
> > of how lisp can do the right thing. It takes lisp source and gives
> > you a small, fast, native executable. No ideological arguments, just
> > great results!
>
> Great results? When my Stalin program destroys the material basis for
> its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
> am *not* willing to lose basic dynamicity! Give me C++ before a
> "Lisp" that's not dynamic!
Wrong user set. We're programmers; we want the debugger, so we can
figure out why the crash happened and fix it. The rubber hits the
road when I deliver a system to a farmer in northern minnesota who's
using it to schedule his crop rotations and equipment maintenance.
What the hell is he going to do with a debugger window?
Bear