Could someone using Lispworks for windows please compile, tree-shake, and
deliver as a Windows .exe file, the following program, or equivalent, and
post it somewhere public, so people can use it for reference?
(format *standard-output* "X")
The reason why this is needed is that a lot of people think it will include
tens of megabytes of DLL's, will take 10 minutes to run, and won't work on a
PC that doesn't have Lispworks installed. It should only output one
character, so people can prove that it can be run more than once with output
on the same line, and that it won't output any extraneous messages such as
"press return to continue when finished viewing the output", as happens with
some other products.
I personally think having something such as this for reference can do more to
promote Lisp than almost anything else, because the biggest obstacle is
misconceptions about what Lisp can deliver at the low end, which is where
most people start. Of course this is an extreme example of the low end, but
I think that's exactly what is needed. An example so simple people can
explain it in less than a minute to someone who's only half listening with a
closed mind against Lisp. I want to be able to say, "download X.exe from
www.lispworksexamples.com and see if it displays an X on your PC without any
need to install anything. That will prove Lispworks really can be used for
developing trivial programs which can be distributed easily."
I know it will probably be a couple of megabytes, and some people will joke
about such an expensive X, but that's beside the point. Lots of people would
be glad to tolerate that much overhead, but might hesitate because they think
the overhead is many times that. Not just the size, but the complexity of
installing it, etc. With high-bandwidth network access becoming common, and
PC's with gigabytes of disk space and hundreds of megabytes of RAM, nobody
cares anymore about a few megabytes, if it's just one .exe file they can just
run anywhere with no need to install anything.
<··········@questions.com> wrote in message
·······································@4ax.com...
> Could someone using Lispworks for windows please compile, tree-shake, and
> deliver as a Windows .exe file, the following program, or equivalent, and
> post it somewhere public, so people can use it for reference?
>
> (format *standard-output* "X")
In spite of other's concerns, I have done it. The zip file contains the
code and delivery code all in one file (deliver.lisp) and the exe
(hello-world.exe). Run it in a windows console. Type at the MSDOS command
prompt:
D:\User\Wade\LWW\lisp-examples>hello-world
Hello World!
D:\User\Wade\LWW\lisp-examples>
URL: http://www.cadvision.com/humeniuw/hello-world.zip
LispWorks for Windows 4.1.20
Executable size: 2,687,004 bytes
Delivery Level: 5
If someone wants to put it somewhere be my guess. You may repost it
wherever you wish.
Wade
Oops I did not read your post well enough. The extraneous characters should
be able to be checked by running hello-world twice. If you really need a
one character program or it does not behave as hoped I can try other things.
Wade
On Sat, 19 May 2001 15:12:44 -0600, "Wade Humeniuk" <········@cadvision.com>
wrote:
>One character "X" exe.
>
>URL: http://www.cadvision.com/humeniuw/lisp-x.zip
Thanks, I'm downloading it and your bigger app and already downloaded your
"hello world." I personally think the executable size is not a real problem
for most users, because of high bandwidth net connections, multi-gigabyte
disks, multi-hundred-megabyte-RAM PC's, etc.
I was pleasantly surprised to find that I could run it 25 times per second
from a .bat file on an average 2-year-old PC. So much for Lispworks' famous
slow startup speed.
The real reason for posting this kind of program is for the benefit of those
who say "I will believe it when I see it" in response to claims that a big
Lisp environment can deliver trivial programs that can be easily installed on
random PC's. The size really is a secondary issue which is not going to be a
major obstacle for most people.
Trivial apps are important, partly because that's where people like to start
when learning, and partly because they want to be able to deliver all their
apps from one language/environment. The reality is that most apps are
trivial, and Lisp has to be able to do them to be a general purpose
programming language. These downloads show that it can. With this evidence
someone might be able to convince a big company that employs hundreds of
programmers to consider using Lisp in the future, especially if this evidence
is presented at the same time as evidence showing that Lisp can make
programmers more productive in their ordinary work. Programmer productivity
is a very hot issue which can carry a lot of weight if presented right and if
obstacles and misconceptions are overcome.
Suppose we can convince some programmers to secretly rewrite their employers'
software in Lisp, make it better than the original, and then present it to
their management as a way to quickly improve their software. The fact that
it would already be improved as of then would be very persuasive. And the
programmers can say they did it in their spare time, easily, because Lisp is
so much more productive they only have to spend a small fraction of the time
on it. (Of course they have to learn it first, but that's a different
issue.)
<··········@questions.com> wrote in message
·······································@4ax.com...
>
> I was pleasantly surprised to find that I could run it 25 times per second
> from a .bat file on an average 2-year-old PC. So much for Lispworks'
famous
> slow startup speed.
You requested that it be a console app started from within a DOS shell. No
one has made the observation yet, that by starting a Lisp Listener and
running the function hello-world within the listener is exactly the same as
running the hello-world program from within the MSDOS shell. You can just
use the LispWorks development environment as a console based shell. You can
run way more than 25 times/second. You can also interface out to other
MSDOS based programs and collect their ouptut.
Replace the concole shell with a Lisp shell.
Hello-world could then be delivered as a small .fasl file.
On Sun, 20 May 2001 08:23:02 GMT, ··········@questions.com wrote:
> Thanks, I'm downloading it and your bigger app and already downloaded your
> "hello world." I personally think the executable size is not a real problem
[...]
> The real reason for posting this kind of program is for the benefit of those
> who say "I will believe it when I see it" in response to claims that a big
> Lisp environment can deliver trivial programs that can be easily installed on
> random PC's. The size really is a secondary issue which is not going to be a
Now that you have got the demo you was looking for, don't forget to let us
know whether your colleagues--the ones who will believe it when they see
it--finally decide to use Lisp.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
If you want a bigger windows app with CAPI and everything you can download
my runner's log program. It does lots of various windows stuff. Written in
LWW.
Its at:
http://www.cadvision.com/humeniuw/runnerslog1.20.exe
Online Manual: http://www.cadvision.com/humeniuw/Manual.html
Wade
>>>>> "WH" == Wade Humeniuk <········@cadvision.com> writes:
[... WH's ruunerslog program :]
WH> http://www.cadvision.com/humeniuw/runnerslog1.20.exe
The above is 2488770 bytes with the installer.
Just to put things in perspective, a much simpler Tk/Tcl program when
"wrapped" into an .exe using Scriptics' prowrap weighs 4MB+. I believe
prowrap compresses everything also. The LWW figure is not bad at all
for something that has a GUI.
cheers,
BM
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I care. My laptop doesn't have a network card, so I have to copy stuff
> over on floppies. I _hate_ it when things that should fit on a single
> floppy 100 times over, don't.
>
> And high-bandwidth network access is not all that common, especially not
> outside the US. Most of the people I work with outside the US have slow
> dial-up modems.
>
> Care about size. Please. Unless it's justified.
I think it is justified.
Lisp has so many REAL problems to deal with that a focus on this one is wasted.
It would be cheaper for you to buy a new laptop with this problem fixed
than for you to buy a new release of any commercially produced Lisp that
someone assured you fixed your problem. My laptop cost me $1200 and it
came with a network card and a cd/dvd rom. It costs almost nothing to
distribute a cd, so comparing this problem to floppy is unfair. Some big
images might need to be compared to cd, but rarely to floppy. Further,
even a 56kb modem can transmit a couple of megabyte program inside of an
hour. As often as it's done, I think this is ok.
I don't think Lisp will be at its best delivering "hello world" programs,
and optimizing for that seems an utter waste.
Further, though I have sympathy for people at the low-end, they are
specifically electing to trade manual labor for cheaper machines.
But they do not command large numbers of sales, by definition, so a
vendor cannot afford to cater to them except where it doesn't cost them.
Ten years ago, Lisp was unreasonably large compared to other languages,
and this was was a fair criticism. But Lisp has held the line on size
as other vendors' products have explosively grown. We are finally at the
point where Lisp is not "too big". We have huge other battles to fight,
and that's where precious vendor dollars investment should go.
JMO.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I'm not so sure. Don't you think the world would be a better place if a
> small, lean Lisp could be used for a greater number of commercially
> developed applications?
I completely reject any argument of the form "but don't you want X"
because that is a one-place predicate. I only care about arguments of
the form "but don't you want X instead of Y". This forces you to keep
focus on the issue that every action you take steals time and
resources from some other action you could have taken. When you say
"don't you want small, lean", I think--"of course". But I have been
manipulated like a person is manipulated when a politician says (or is
asked to say) "don't you care about the environment?" The real hard
political questions are "do you want this environmental bill or that
educational bill". The real hard Lisp questions are "do you want lean
and small or an RMI implementation" because vendors haven't the time
to do both. And for that my answer is a good solid "if it's a choice
betwene those, let it be big, but get RMI in there". Life is hard and
one has to make choices.
I don't believe the commercially developed applications with any
reasonable chance of success are the little ones like "hello world".
I think they are all bigger than work for the example you raise, and
in most cases, while I think tree-shaking is handy, I just don't any
longer see it as a major deal. In applications I build for myself at
home, it's not worth the time to tree-shake them. I just tolerate the
extra disk. I have two 20GB disks on my machine, which I regard to be
an extremely average and affordable configuration.
Further, I don't think Lisp's strength will ever be in showing that it
can win in small applications. Certainly, it can EXPRESS such
applications, but there will always be a practical commercial bias for
arbitrary, non-technical reasons toward "commodity languages" in cases
where they yield equally useful solutions. That's sad to me, it's
milk spilled long, long ago. No use crying over it. Time to move on.
Lisp's strength is for powerful, complex, usually large applications.
Or at least for ones that would be in other languages. Maybe they're
small in Lisp source, but if the image comes out big, I don't care because
I expect them to be large images in other languages.
That's just my preference. Fine if you think otherwise. But I would
ask you to at least frame your question in terms of what you would trade
that Lisp vendors are now doing that you would have them not do in order
that they be responsive to your need. Then at least we'd be talking
about trade-offs and expenses, not just ideals in a cost-free universe.
* Thore B Karlsen wrote:
> I have a 30GB HD, and it's always full (OK, so I have 1.5GB left
> now). I run out of space and RAM more frequently with my new machine
> than I did before, on lesser machines with leaner software.
But what is filling it? I bet it isn't huge Lisp applications, and it
isn't stuff you've typed because you can't type that fast. Could it
be that C/C++ applications are kind of big too? Could it be that this
doesn't stop people buying them?
--tim
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
>
> That's just my preference. Fine if you think otherwise. But I would
> ask you to at least frame your question in terms of what you would trade
> that Lisp vendors are now doing that you would have them not do in order
> that they be responsive to your need. Then at least we'd be talking
> about trade-offs and expenses, not just ideals in a cost-free universe.
As a newcomer, using free tools, I have little right or reason to speculate
about what vendors ought to do. But you did say recently (something like):
"mine experts for wisdom, mine novices for intuitions". So here are some
more intuitions that may or may not contain some wisdom. I would feel
happiest about the future viability of Lisp if:
* Vendors do not try to play catchup and duplicate functionality available
elsewhere, but provide easy ways to exploit what is already available. You
(and others) mentioned Java. On Macintosh and Unix-like platforms, this
might be a reasonable route. Even so, I would prefer to see the vendors
collaborate on providing sane and consistent access to native free software
like GTK+, Apache, MySQL, Postgresql, etc. They could be helped by the
community in developing all the bells and whistles - and compete with each
other to provide the best possible _core_ Lisp tools. This would make it
feasible for people to develop complete, portable applications in Lisp, at
low cost, and not be isolated from the rest of the world, and not need to
gamble on proprietary value additions for their continuing survival. It
would also allow the vendors to concentrate on improving the value of their
core tools, rather than frantically trying to catch up and duplicate all
that functionality at high cost to all concerned.
* On Windows, I think it would make more sense to target the .NET runtime
which is (theoretically at least) designed to give 'alternative' languages
full citizenship rights in the Windows environment - ie. to be consumers and
producers of interoperable components. Entire systems could be written in
Lisp, and nobody (besides the developers) would need to care. Or we could
mix and match components written in Lisp, C#, whatever. All the
infrastructure is already there (or soon will be).
Thore B. Karlsen wrote:
> I'm not so sure. Don't you think the world would be a better place if a
> small, lean Lisp could be used for a greater number of commercially
> developed applications? As long as "Hello World" is 2.4MB (although I
> got it down to 650k with Corman Lisp, but you get the picture) I don't
> see that happening.
C/C++ applications are much bigger too if you count the libraries needed
for them. Under Linux libc&libstdc++ are together somewhere around 5 MB
You can deliver Lispapplications that are similar small like C++
Applications by simulating the shared-lib approach.
1) You deliver a nearly full CL image and then load your apps as FASLs
2) You load all your to be delivered apps in one executable and let the
start function dispatch on some commandline argument what app you want
to start.
> I just want Lisp to be used for other things than large industrial-type
> systems where size really does not matter.
I want this to happen too :-)
Regards,
Jochen
Thore B. Karlsen wrote:
> On Sun, 20 May 2001 02:59:46 +0200, Jochen Schmidt <···@dataheaven.de>
> wrote:
>
>>> I'm not so sure. Don't you think the world would be a better place if a
>>> small, lean Lisp could be used for a greater number of commercially
>>> developed applications? As long as "Hello World" is 2.4MB (although I
>>> got it down to 650k with Corman Lisp, but you get the picture) I don't
>>> see that happening.
>
>>C/C++ applications are much bigger too if you count the libraries needed
>>for them.
>
> No they're not. One of my projects, 10-15k lines of C++, has an
> executable of around 160k. This is with heavy use of templates, and
> statically linked with the C++ runtime library.
But in reality you will find a libc.so and libstdc++.so on each linux
system so your statically linked executable is a waste of space...
Yes you *can* do that and *yes* you will reach a smaller statically linked
executable than what you would get with lisp but I think it is neither
common use nor a particularily good idea to do so.
> Link in what you need, nothing more. And then pack it with UPX, and get
> an executable of less than 100k.
This is good for one application but statically linking all your apps is a
waste of disk *and* memory-space.
>
> Hey, if it can be done easily, why not? :)
Because you will be rather inflexible - you would have no chance to update
your application by installing new libs (bugfixes...)
You have to alternatives:
Statically linking:
The one example-app can be counted as smaller (because no additional libs
are required). But you loose hard in terms of disk and memory consumption
of multiple programs and loose a lot of flexibility and modularity.
Shared libs:
Are much more flexible and on most systems more disk and memory-friendly.
The problem is that you have to count them to the single example app
equally as you would count the lispimage.
Static linking is probably nice if you only want to use one or two
programms written in that language but if you use more than it is a waste
of space and time.
Regards,
Jochen
Thore B. Karlsen wrote:
> If I'm not guaranteed to have a shared library, I'd rather make my
> executable less than 100k statically linked as opposed to include a 300k
> shared library. If it's guaranteed to be there, I'll use it of course.
> If it's not guaranteed to be there, everyone is going to have to include
> it with their applications, and _that_ is a waste.
"We're not sure if our customers have a car so every of our drink-holders
includes one..."
;-)
Regards,
Jochen
* Thore B Karlsen wrote:
> I'm not so sure. Don't you think the world would be a better place if a
> small, lean Lisp could be used for a greater number of commercially
> developed applications? As long as "Hello World" is 2.4MB (although I
> got it down to 650k with Corman Lisp, but you get the picture) I don't
> see that happening.
> I just want Lisp to be used for other things than large industrial-type
> systems where size really does not matter.
What makes you think that the size of the null application has any
bearing on the size of interesting applications? If most commercial
applications consisted of code which prints a single string, then
sure, optimizing the size of applications which do that would be worth
while. In fact systems have done this -- on Unix the overhead for
doing this is 16 bytes (18 if you want to quote the string to avoid
shell metacharacter lossage).
But you may have noticed that actually, shipped commercial
applications tend to do a bit more than this - people just aren't
willing to pay for hello world to appear on their screens any more.
So perhaps rather than this stupid exercise of measuring hello world,
we might want to look at the difference in image size between
applications people might want to pay for.
And in fact, before doing that, you might want to look at whether
image size makes any difference at all. It surely doesn't seem to
have hurt Microsoft or Sun who both ship enormous systems - the most
recent *patches* for Windows 2000 are over 100Mb, and the Solaris 8
media is more than 10 CDs.
I can't speak for other people, but I don't generally use machines
with less than 200Mb of real memory any more - we've just bought new
machines with 640, and the next ones we buy will have more than 1Gb
I'm sure, I just *don't care* about some application being 2Mb or 18
bytes any more.
--tim
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On 20 May 2001 12:44:24 +0100, Tim Bradshaw <···@cley.com> wrote:
> >I can't speak for other people, but I don't generally use machines
> >with less than 200Mb of real memory any more - we've just bought new
> >machines with 640, and the next ones we buy will have more than 1Gb
> >I'm sure, I just *don't care* about some application being 2Mb or 18
> >bytes any more.
>
> If people stop caring you get bloat like you mentioned above. And many
> people jumped off the upgrade bandwagon a long time ago. Several people
> are stuck with old machines. Heck, I had a Pentium 120 with 94MB of RAM
> until last summer. It was working great for most of my purposes, but the
> bloat caught up with me and forced me to upgrade. I also had a dial-up
> connection, which made it a pain in the neck to download all this
> bloated crap. The majority of people still do.
Not all people have stopped caring about bloat. One of the very _reasons_
why Allegro CL has been able to stay small (and, I believe, why other CL
implementations as well have remained relatively small while other languages
have caused the very bloat that forces you to buy a bigger machine) is that
at least some development time is spent considering how much space any
particular new feature will add to a CL.
I believe that any problems a user of a CL has (including, but not limited
to image size) must be given to the vendors themselves as bug reports and
feature requests. As you have seen, there are two conflicting opinions
about whether size should be considered in lisp. I exemplify this
conflict within myself; as a user I don't want to have to consider size
in my lisp programs; as a vendor it is part of my job to consider size.
This is in fact part of the lisp gestalt; the language and implementation
do the work for you so that you don't have to worry about it. And,
indeed, most lisp programmers don't need to worry about size (it works,
doesn't it :-).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Thore B. Karlsen <········@cs.utexas.edu> writes:
> If people stop caring you get bloat like you mentioned above. And many
> people jumped off the upgrade bandwagon a long time ago. Several people
> are stuck with old machines. Heck, I had a Pentium 120 with 94MB of RAM
> until last summer.
Honestly, I suspect that's because you are a professional programmer.
At my house, gaming drives hardware upgrades. I personally don't play them.
But I let them get played on my machine because it drives the purchase of
good hardware I can then use as a hand-me-down for work. I'm not kidding.
Myst III - Exile - takes 1.2GB to install and is happiest on a high-end
graphics display. And I don't think it's atypical. Pharoah took at least
500MB to install.... A few of these games, and one needs another disk.
I expect the desire for cool games to continue to drive the market upward.
By comparison, Lisp is absolutely insignificant.
My experience is that Allegro CL development environment can work
inside of 32MB and that LispWorks feels like it needs at least 64MB.
The only reason that 64MB has ever made me sad in recent years was
when I wanted to buy a laptop for under $1000 and I found that 64MB
was still pushing it for hand-me-down cheapo laptops--most come with
32MB. But the memory upgrade is cheap enough that I finally realize
it was pointless to care--yes, cheapo laptops are sold configured with
32MB to appeal to the utmost cheapskate, but they can be upgraded for
little enough that it isn't worth it to pay more money to a vendor who
does better memory conservation when I can pay the same dollars for
general-purpose RAM that will benefit ALL my programs. RAM memory is
dirt cheap these days. No excuse for not having a ton of it.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I know I'm fighting windmills to a certain extent, but when my Pentium
> III 650 machine starts slower, executes programs slower, swaps like
> crazy, and feels more sluggish in general than my old machines used to
> feel, I can't help but think that software demands increase at a more
> rapid pace than hardware capabilities. And I don't like that, unless
> it's justified. Which in 99.9% of all cases it's not.
I absolutely agree, and one recent comforting example -- for me -- is
Mozilla. I bought my machine a few years ago -- I'm a student -- and
I've seen software rapidly exceed it with expectations. One of the
most absurd examples of this was Mozilla, which was completely
unusable on my system. With X, Emacs, and my window manager, Mozialla
couldn't quite fit in physical memory. And it seems to have about
zero locality of reference -- I literally move the mouse and it starts
swapping. But then the Mozilla developers have recently gone on an
optimizing spree and it shows -- I can run Mozilla now!
I think this is relevant to the news group because Lisp -- in my
experience -- lends itself better to after-the-fact optimizations than
does C++. I'm talking about serious programs here, of course. But
for the real stuff, which is what I use most of the time, and I
suspect most people do, the powerful type of program that's going to
be generally large by any current day's standards is *more*
optimizable more easily if it's written in Lisp than C++, etc. Which
is one reason among many that I try to work in it.
Kent M Pitman <······@world.std.com> writes:
> At my house, gaming drives hardware upgrades. I personally don't play them.
In business, the game called "Office" drives hardware upgrades.
If somebody would be able to deliver a 200K super-compact Common Lisp
program that does interesting things, it will probably be accompanied by
5MB word document describing the license terms :-(
--
(espen)
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I know I'm fighting windmills to a certain extent, but when my Pentium
> III 650 machine starts slower, executes programs slower, swaps like
> crazy, and feels more sluggish in general than my old machines used to
> feel, I can't help but think that software demands increase at a more
> rapid pace than hardware capabilities. And I don't like that, unless
> it's justified. Which in 99.9% of all cases it's not.
The solution is simple - throw away Windows and Visual Studio
:-)
Anyway, your machine doesn't start to get slower all by
itself. Most likely it is because you have installed newer versions of
the OS or programming environment, and these are targeted for a better
base HW configuration than the previous version. Stay with the old
versions, and you won't have to upgrade. This may of course affect
your ability to produce software that people will want to buy, or even
use :-)
--
Raymond Wiker
·············@fast.no
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I know I'm fighting windmills to a certain extent, but when my Pentium
> III 650 machine starts slower, executes programs slower, swaps like
> crazy, and feels more sluggish in general than my old machines used to
> feel,
You're obviously using the wrong software. I have a Pentium 200 which
runs stuff I need just fine. Noone will kill you for not using Visual
Studio. Get another job and stop your fucking whining.
--
johs
James Hague <···········@volition-inc.com> wrote:
+---------------
| It's typically more like "When I press ^F (find) in Microsoft Word,
| there's a two second pause before the dialog appears on my 333MHz
| Pentium II." Is "Get a faster machine!" really a proper response
| in such cases?
+---------------
No, of course not. The proper response is to dump Windows and run your
choice of Linux/FreeBSD/NetBSD/OpenBSD/BSDI on it together with your
favorite Common Lisp, and suddenly your system will seem *much* faster!!
-Rob
p.s. And don't throw away those old 33 MHz '486 systems, either!
Running any of the Unices, they're plenty fast as dedicated firewalls...
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
"James Hague" <···········@volition-inc.com> wrote in message
·················@newsfeeds...
> It's typically more like "When I press ^F (find) in Microsoft
> Word, there's a two second pause before the dialog appears on my 333MHz
> Pentium II."
Is that what you're crying about? In my day, we had to search through a
listing visually to find something in code! And we had to walk uphill both
ways to the computing centre to do it. And we felt damn lucky about it.
Sheesh. Kids...
faa
* Thore B Karlsen wrote:
> I'm talking about the _minimum_ executable size.
But this is not interesting, unless you really seriously think that
everything should fit on a floppy. What is interesting, if you care
about bloat is something like how executable size goes with program
complexity. So measure that.
> If people stop caring you get bloat like you mentioned above. And
> many people jumped off the upgrade bandwagon a long time
> ago. Several people are stuck with old machines. Heck, I had a
> Pentium 120 with 94MB of RAM until last summer. It was working great
> for most of my purposes, but the bloat caught up with me and forced
> me to upgrade. I also had a dial-up connection, which made it a pain
> in the neck to download all this bloated crap. The majority of
> people still do.
Well, why are these people not buying modern machines? I can see two
possible reasons:
1. They can't afford them. Not likely to be an interesting target for
applications then, since they have no money. No one who is `stuck
with an old machine' is someone you want to market software to.
2. They have principled objections. While these people might be more
interesting they're also likely to be the kind of people who run
Plan 9 or 7th edition Unix because it's small and pure. Again, I
suspect they don't correlate too well with people who are going to
spend money on applications.
The issue of bandwidth is slightly more interesting -- at least in the
UK where I live dialup connections are still the huge majority. But
then almost no commercial software ships via net download, despite the
hype.
While I don't want to defend bloat (and a 2Mb minimum image size does
*not* indicate bloat), when something becomes almost free you tend to
use a lot of it. Disk space is basically free now, memory is almost
free.
--tim
Tim Bradshaw <···@cley.com> writes:
>
> The issue of bandwidth is slightly more interesting -- at least in the
> UK where I live dialup connections are still the huge majority. But
> then almost no commercial software ships via net download, despite the
> hype.
>
I was wrong about this, it turns out. It's kind of interesting to
look at the prices of things.
My modem used to get about 4k/sec sustained download. 256 secs/Mbyte.
At (expensive) call rates of 10p / min (not sure what rates really
are: my mobile phone peak rate to a landline or same-network mobile is
10p/min, so I guess that's pretty conservative), that is 43p/Mbyte to
download a program.
Disk space - 60Gbyte disks are about L200 now - call it L300 to make
the addition easier. That's 0.5p/Mbyte. Call it 3p/Mbyte assuming you
want to mirror everything lots of times.
Memory, what is it now? L1/Mbyte? I think we pay something like that
for Sun ECC memory which is probably pretty overpriced.
So we're looking at a once-off cost to download, store, and run a
program of L1.48/Mbyte (maybe $2?). This is actually significantly
too large, since the memory cost can be amortised over n programs.
Of course I've simplified a lot here. But the issue is that size is
really cheap now.
--tim
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I'm not so sure. Don't you think the world would be a better place if a
> small, lean Lisp could be used for a greater number of commercially
> developed applications? As long as "Hello World" is 2.4MB (although I
> got it down to 650k with Corman Lisp, but you get the picture) I don't
> see that happening.
Since when does "Hello World" constitute a valid commercially
developed application? And even if it were, I'd avise you to use C
(or better still, assembler) to develop it. I've always been a strong
supporter of using the best tool for a job, and it seems to me that
developing "Hello World" for the current crop of C-machines is a job
where C or assembler really shine. Furthermore I don't see how CL
will help you write that "Hello World" better than e.g. C.
So why would your prototypical "Hello World" writer want to use CL?
Just so that he can feel better, as if CL was by its sheer nature
superior? I don't think the world will be a better place just because
all the "Hello Worlds" are written in CL instead of C. Indeed I'd
imagine the world to be a slightly worse place.
But you didn't really want to write "Hello World", you wanted to write
something that does a bit more useful, didn't you? Something where CL
provides a real advantage. But in that case why not measure the size
of those programs? The size of the CL binary will likely not increase
by much, the size of e.g. a C++ binary will very likely increase
drastically, once you start using the STL[1].
Furthermore, the last time I looked (couple of years ago), deploying a
Visual Basic application required at least 650k, yet this doesn't seem
to have hindered the development and deployment of huge numbers of
semi-professional applications in VB.
Dito for Java, actually. You might want to take a look at the
follow-up study done by Erann Gat on a study by Lutz Prechelt in
"Communications of the ACM", comparing Java and C/C++ in terms of
development time, run-time speed and image size:
"Lisp as an Alternative to Java"
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
It seems to me that while "too large delivered image size" might be a
reason named by people not wanting to use CL as an excuse, but that in
reality isn't a strong deciding factor at all.
> I just want Lisp to be used for other things than large industrial-type
> systems where size really does not matter.
And what I'm saying is that size doesn't matter for smallish desktop
consumer-type things either, and that's been the case for the last 2-3
years _at least_. Normal computers are totally over-powered for most
non-real-time consumer applications. In fact the only things that
have been pushing consumer computers in the last couple of years have
been things like DVD decoding, Video and Sound real-time recording and
editing, and Games/Simulations. Oh, that and Microsoft-style
bloatware, and even MS has struggled to make newer Office versions
slow-enough to counter the performance curve. And as can be seen,
even MS-style bloat hasn't hindered Microsoft's success.
The only area where I've encountered size restrictions that mattered
in the last couple of years has been on PDAs, where a meg plus or
minus still matters somewhat, though even that is changing quickly: I
estimate that it's only 1-2 years until I'll be running CMU CL on a
PDA. Today, I can already port CLISP to an Agenda VR3, which is more
or less a MIPS R4000 with 8MB RAM and 16MB FLASH, i.e. about as
powerful as early SGI workstations were, but for less than $200 and
less than 200g ;).
> That's true, but I can't help but dream that it would be worth it. Of
> course, it would be a gamble and people's preconceived notions about
> Lisp may sabotage it, but one can dream.
Nothing against dreaming, but it seems to me that even if I somehow
gave you a CL implementation that did Hello World in 20 bytes, people
wouldn't be flocking to CL, and rightly so. Programming "Hello World"
in CL is just a waste of resources, and optimizing CL implementations
for this sort of thing is an even worse waste, IMHO.
Regs, Pierre.
Footnotes:
[1] Even without the STL a simple "Hello World" using C++ streams
will require ~ 300 KB static stripped binary on a semi-current
Linux system. Using ECLS you can automatically generate a "Hello
World" of ~560 KB (and that leaves out only CLOS and the
compiler), and if you fiddle with the Makefile a bit to
exclude further unneeded parts you can probably go even lower
than this.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thore B. Karlsen wrote:
>
> As long as "Hello World" is 2.4MB (although I
> got it down to 650k with Corman Lisp, but you get the picture)
That's misleading. Corman Lisp compresses its heap images using a free zip
library. The heap is still expanded in memory at run time.
James
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On Mon, 21 May 2001 13:01:08 -0500, Thore B. Karlsen <········@cs.utexas.edu>
wrote:
>On Mon, 21 May 2001 09:11:48 -0500, "James Hague"
><···········@volition-inc.com> wrote:
>
>>> As long as "Hello World" is 2.4MB (although I
>>> got it down to 650k with Corman Lisp, but you get the picture)
>
>>That's misleading. Corman Lisp compresses its heap images using a free zip
>>library. The heap is still expanded in memory at run time.
>
>Hmm.. Interesting. I noticed it had something in there about GZIP
>compression, but I never quite read that part.
>
Yes, it's true. I was looking for an easy way to reduce the application size,
because I think the size of the exe file still means a lot to some people
(witness this thread). I am not crazy about trying to eliminate things--I think
a major bonus of lisp is that you can hide some kind of a shell in your program
that can take advantage of all those cool tools. If you try to shake them all
out you will be missing them. Looking at the sizes of Java and C++ programs
today (all the DLLs and jar files) I don't think it matters much.
However, I wanted to store the heap in a more compact form. I tried some smart
ways to reduce redundancy (the memory heap is obviously greatly optimized for
performance, not size) and finally decided to throw out all the convoluted stuff
I was trying and just gzip the heap. This resulted in a large compression, with
little effort, and no bugs. I use it on both the heap image as well as fasl
files (but the compression can be turned off if you want).
Overall, most of the concern with size is way outdated, though. We have more
memory and disk space than anybody knows what to do with.
Roger
"Roger Corman" <·····@corman.net> wrote in message
······················@news.callatg.com...
> However, I wanted to store the heap in a more compact form. I tried some
smart
> ways to reduce redundancy (the memory heap is obviously greatly optimized
for
> performance, not size) and finally decided to throw out all the convoluted
stuff
> I was trying and just gzip the heap. This resulted in a large compression,
with
> little effort, and no bugs. I use it on both the heap image as well as
fasl
> files (but the compression can be turned off if you want).
>
Yes, I have noticed that LispWorks images and delivered-images compress
(using zip) to about 40% of their original size. I would have thought that
the image contains mostly code (which does not compress nearly as much), but
the compression implies that their is a lot of (i would guess empty or
repetitive) data in an image. Is this correct?
Wade
On Tue, 22 May 2001 16:31:27 -0600, "Wade Humeniuk" <········@cadvision.com>
wrote:
>"Roger Corman" <·····@corman.net> wrote in message
>>
>
>Yes, I have noticed that LispWorks images and delivered-images compress
>(using zip) to about 40% of their original size. I would have thought that
>the image contains mostly code (which does not compress nearly as much), but
>the compression implies that their is a lot of (i would guess empty or
>repetitive) data in an image. Is this correct?
>
Actually code compresses very nicely too. Most code is repetitive 2, 3, 4 and
5-byte patterns that are ideal for standard compression techniques. The 4-byte
NIL probably occurs about 100,000 times, and all those occurrences should
compress down to a small bit pattern.
Roger
·····@corman.net (Roger Corman) writes:
> On Tue, 22 May 2001 16:31:27 -0600, "Wade Humeniuk" <········@cadvision.com>
> wrote:
>
> >"Roger Corman" <·····@corman.net> wrote in message
> >>
> >
> >Yes, I have noticed that LispWorks images and delivered-images compress
> >(using zip) to about 40% of their original size. I would have thought that
> >the image contains mostly code (which does not compress nearly as much), but
> >the compression implies that their is a lot of (i would guess empty or
> >repetitive) data in an image. Is this correct?
> >
>
> Actually code compresses very nicely too. Most code is repetitive 2, 3, 4 and
> 5-byte patterns that are ideal for standard compression techniques. The 4-byte
> NIL probably occurs about 100,000 times, and all those occurrences should
> compress down to a small bit pattern.
Is this, implicitly, a suggestion that a statistical analysis of a set
of important programs would yield a good (and possibly surprising)
non-RISC hardware instruction set...? Just curious.
(On a related notion, in studying the Postscript language, I found
myself wondering if rather than letting humans group instructions, one
actually ought to let the compression algorithm determine which
groupings would make good functions. PostScript (and Teco) because
the call stack and data stacks are orthogonally manipulated, seem to
me similar to virtual machines in this regard and might be good testing
grounds for such ideas.)
Or maybe there's nothing there at all. It was just an idea that occurred
to me that I probably won't ever follow up myself but that I figured I'd
mention in case someone else thought it fun.
Kent M Pitman <······@world.std.com> writes:
> Is this, implicitly, a suggestion that a statistical analysis of a set
> of important programs would yield a good (and possibly surprising)
> non-RISC hardware instruction set...? Just curious.
>
I think that a lot of the motivation behind RISC was statistical
analysis of a set of interesting programs. Not entirely for code
density though of course, not even mostly in fact.
--tim
>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
Tim> Kent M Pitman <······@world.std.com> writes:
>> Is this, implicitly, a suggestion that a statistical analysis of a set
>> of important programs would yield a good (and possibly surprising)
>> non-RISC hardware instruction set...? Just curious.
>>
Tim> I think that a lot of the motivation behind RISC was statistical
Tim> analysis of a set of interesting programs. Not entirely for code
Tim> density though of course, not even mostly in fact.
Isn't that how branch delay slots came about? (I work with
DSPs and many of them have branch delay slots, but, curiously, TI's
latest C5510 DSP got rid of all branch delay slots. I wonder why.
Their previous C54 DSP's had delay slots, and I put them to very good
use in tight loops on a TI C30 way back when.)
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> Isn't that how branch delay slots came about? (I work with
> DSPs and many of them have branch delay slots, but, curiously, TI's
> latest C5510 DSP got rid of all branch delay slots. I wonder why.
> Their previous C54 DSP's had delay slots, and I put them to very good
> use in tight loops on a TI C30 way back when.)
>
I'm not *sure*, but it may be that an out-of-order design doesn't need
explicit branch delay slots because it will reorder stuff to fill
them.
--tim
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> Is this, implicitly, a suggestion that a statistical analysis of a set
> of important programs would yield a good (and possibly surprising)
> non-RISC hardware instruction set...? Just curious.
I remember my father telling me about the Burroughs machine he was using.
It apparently used Huffman encoding for the instruction set and, I think,
the smallest instruction was 2 bits.
> actually ought to let the compression algorithm determine which
Fraser or Davidson or both published a paper in TOPLAS (leading up to their
RTL stuff) on the idea of using a compression algorithm to function-ize code
runs. You could turn the knob to get varying amounts of compression by
turning more and more things into functions. We actually implemented the
algorithm to squeeze blood out of the byte codes for an interpreter running
on 8051 VISA card terminals (it worked - we reclaimed enough space to add
the functionality required by the customer).
pt
"Hello World" in Stalin is reasonably small, just a few kilobytes, and
could be smaller still if it didn't use stdio. The only dynamically
linked library is libc, with no hidden bloat in the scheme runtime
system. Is there any reason a Common Lisp compiler couldn't do as
well?
$ ls -l hello*
-rwxr-xr-x 1 schwartz fcse 7648 May 26 00:22 hello
-rw-r--r-- 1 schwartz fcse 24 May 26 00:21 hello.sc
$ cat hello.sc
(display "hello world")
$ size hello
2992 + 472 + 356 = 3820
As the author says, "Finally a lisp compiler that does what it should."
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> "Hello World" in Stalin is reasonably small, just a few kilobytes, and
> could be smaller still if it didn't use stdio. The only dynamically
> linked library is libc, with no hidden bloat in the scheme runtime
> system. Is there any reason a Common Lisp compiler couldn't do as
> well?
This is a strange question. The answer to almost all such questions is
"it's only software" or "simple matter of programming" (SMOP).
The problem is not technical but economic. The market for delivered Lisp
applications which don't actually use any of the features of Lisp is
probably miniscule to non-existent, so the average compiler vendor isn't
going to address it if they've got anything else at all to do, which I'm
sure all of them do.
So nothing about the language keeps what you say from happening, but
that doesn't mean you should expect it to happen. Lisp vendors seem
to prefer large libraries to small ones, probaby because a serious
application will use a lot of standard stuff anyway. What's the point
in providing things most people don't need [in ths sense of paying for
it].
I strongly object to the assertion that bloat derives from simply
providing valuable functionality. Speaking of software in general, in
my experience it's much more likely that bloat derives from
inefficiency at every level: large constant factors combined with
large multipliers.
Even when compiling programs that use lots of lisp features, Stalin
still generates reasonably small executables.
Is there truly no market for nice compilers like that? That's a
shame, because I'd really like to buy one.
Scott Schwartz wrote:
> I strongly object to the assertion that bloat derives from simply
> providing valuable functionality. Speaking of software in general, in
> my experience it's much more likely that bloat derives from
> inefficiency at every level: large constant factors combined with
> large multipliers.
I think optimizing for size has to be done from early design-phases on.
AFAIK Lisp-Systems are most time used for non-trivial, complex applications
which are by themself big. To try to minimize the "minimal delivery size"
would not be in the sense of most of the customers. If you _really_ want
to use Common Lisp to build trivial commodity tools that have to be small
to be of any value, than I would recommend you to use CLISP or probably
ECLS (not tested yet).
> Even when compiling programs that use lots of lisp features, Stalin
> still generates reasonably small executables.
Depends on what "lots of lisp features" means - particularily if EVAL, LOAD
and most of the sophisticated datatypes are crippled.
> Is there truly no market for nice compilers like that? That's a
> shame, because I'd really like to buy one.
Why? Stalin is here, so if you want to use such a beast you can use that.
You will not get much more of a "stalinized" Common Lisp. I don't think
that many Lisp-Users would use _such_ a Lisp.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> If you _really_ want
> to use Common Lisp to build trivial commodity tools that have to be small
> to be of any value, than I would recommend you to use CLISP or probably
> ECLS (not tested yet).
It's wrong to think that small object files imply trivial programs.
Lots of large and complex programs compile to reasonably small
executables. As you say, it takes good engineering, but it also takes
a good compiler.
> Why? Stalin is here, so if you want to use such a beast you can use that.
> You will not get much more of a "stalinized" Common Lisp. I don't think
> that many Lisp-Users would use _such_ a Lisp.
Why on earth not?
Scott Schwartz wrote:
> "Hello World" in Stalin is reasonably small, just a few kilobytes, and
> could be smaller still if it didn't use stdio. The only dynamically
> linked library is libc, with no hidden bloat in the scheme runtime
> system. Is there any reason a Common Lisp compiler couldn't do as
> well?
1) Scheme is _not_ Common Lisp
2) Stalin is not even (complete) Scheme
I think we all agree that Common Lisp is a much bigger language than
vanilla Scheme. So why do you think a compiler that not even supports
the whole R4RS should be comparable in size to e. g. a complete Common Lisp
environment?
Stalin lacks:
- EVAL
- LOAD
- Bignums
- Ratios
- complex numbers
- ...
It's runtime environment is essentially a C-Runtime - which is no wonder
because the Stalin compiler translates Scheme-Code to the equivalent C-Code.
Even the Garbage-Collector is nothing special but the plain Boehm-GC for
C-Runtimes.
What you at least get is not much more than plain C - there are practically
no more types than in C and the runtime behavior is that of C.
If I want to code C then I take a C-Compiler...
Please don't understand me wrong - I don't want to say that Stalin (the
compiler) is bad Software but i want to say that it is not what I want from
a Lisp-System!
But to answer your question - I think it _would_ be possible to build a
similar compiler for Common Lisp - but I don't see any reason why someone
should do this. I don't think that it is easy (or even possible) to build
the dynamic features of "full" Lisp-Systems and the static system like
Stalin into _one_ Product.
> As the author says, "Finally a lisp compiler that does what it should."
hah! - I would disagree with the author (but that's my opinion)
Regards,
Jochen
"Scott Schwartz" <··········@usenet ·@bio.cse.psu.edu> wrote in message
···················@galapagos.cse.psu.edu...
> "Hello World" in Stalin is reasonably small, just a few kilobytes, and
> could be smaller still if it didn't use stdio. The only dynamically
> linked library is libc, with no hidden bloat in the scheme runtime
> system. Is there any reason a Common Lisp compiler couldn't do as
> well?
(defun test () (print "Hello World"))
(compile 'test)
(disassemble 'test)
0: 3B25BC150020 cmp esp, [200015BC] ; t
6: 7616 jbe L1
8: 80FD00 cmpb ch, 0
11: 7511 jne L1
13: 55 push ebp
14: 89E5 move ebp, esp
16: B501 moveb ch, 1
18: B854DD3F20 move eax, 203FDD54 ; "Hello World"
23: C9 leave
24: FF25E8AE0020 jmp [2000AEE8] ; print
L1: 30: E8B5CCC1FF call 2004303A ; #<function
2004303A>
=35 bytes
The Common Lisp compiler can do as well... What you are measuring is the
size of the support stuff and libraries needed to be able to run these 35
bytes of code.
In MSDOS you could write an "Hello World" in a few bytes as the support
stuff and libraries are in the system (just call the BIOS in asm in a .COM,
no need for a C lib). So what's the point?
A few years ago, I learned Lisp on a 48Kb TRS-80. Just after, I learned C on
a floppy disk only 640Kb PC XT. The C compiler fitted a 360Kb 5.25" floppy.
Even the first C++ were small pre-processors.
Now VC++ takes 127Mb (1.28 Gb if you include the docs, the common tools and
J++) and LispWorks takes 60.3Mb with the HyperSpec. BTW the W2K system
folder uses 931Mb vs. a few Mb for DOS. That's a huge amount of hidden bloat
IMO.
Talking about bloat, I've recently downloaded Netscape 6. When I look at the
5 largest process sizes on my W2K PC I see :
NS6 : 43.5 Mb (after 5 min of web surfing!)
IE 5 : 39 Mb (3 processes : 15.3+14.8+9.1)
LispWorks : 17.2 Mb (after 6 days)
Outlook Express : 17.1 Mb
XEmacs : 15.1 Mb
Only one of these processes is in lisp...
Except if you want to program a PIC16C54 micro controller (512 words program
memory) or other embedded devices (toasters, cell phones, refrigerators,
...), memory is not really a problem these days. The only remaining pb is
that not everybody has a fast Internet connection.
Let's compare the process size of full featured applications if you want
interesting data.
Marc
On Sat, 19 May 2001 13:33:24 -0500, Thore B. Karlsen <········@cs.utexas.edu>
wrote:
>Care about size. Please. Unless it's justified.
It's justified. The advantages of the language far outweigh the overhead for
most purposes, especially on modern hardware.
But we do need the requested reference program posted in public. The size is
only one issue. The Lispworks .exe file itself is 15 megabytes, and some
people seem to assume a delivered runtime program will be that much plus a
few 10's of megabytes of DLL's, and/or that it won't run without Lispworks
being installed. Those myths need to be dispelled, before a lot of people
will even consider Lisp. Once they see how easily a trivial Lisp program can
be distributed and installed, they will be more interested in considering
Lisp as a possibility.
Some people don't even believe Lisp can deliver runtimes. Showing them a
trivial program can be very effective at helping to open their closed minds.
If I just say runtimes can be delivered, they will discount that as a
possibly misinformed opinion, and never even get to the point of consciously
considering Lisp as anything more than a massive antique baroque oddity. If
I try to show someone what I can do with Lisp, all I can show them right now
is the free version of Lispworks itself, and I need the above reference
program to refute some of their most extreme objections to it.
Someone please just write a program to output one character to
*standard-output* without a newline, and deliver it as a Windows executable
which can be run from the Windows command line console window. Please post
it somewhere in public, so the whole world can see that it can be done, and
that it doesn't require anything installed other than the .exe itself. (It
has to output a character without a newline to prove that it doesn't output
an extraneous newline, as a lot of such products do. To prove it, we can run
it twice from a .bat file, to show that the character appears twice on the
same line.)
It might also help to post other Lisp runtime programs in public, especially
some sophisticated ones. But the trivial one is the one that seems to me
like it might make the most difference in getting past some closed-minded
objections. People already know Lisp can do sophisticated programs, but they
don't know it can do trivial programs.
Thore B. Karlsen wrote:
> I care. My laptop doesn't have a network card, so I have to copy stuff
> over on floppies. I _hate_ it when things that should fit on a single
> floppy 100 times over, don't.
>
> And high-bandwidth network access is not all that common, especially not
> outside the US. Most of the people I work with outside the US have slow
> dial-up modems.
>
> Care about size. Please. Unless it's justified.
You're right and this has nothing to do if the idea of "lispnewbie" is a
good one or not, but the program delivered and gzipped is 800K big - so it
would fit on a disk.
Regards,
Jochen
Thore B. Karlsen <········@cs.utexas.edu> writes:
>
> I care. My laptop doesn't have a network card, so I have to copy stuff
> over on floppies. I _hate_ it when things that should fit on a single
> floppy 100 times over, don't.
>
Why don't you set up a direct link via the parallel port? On Linux
you use the plip.o driver.
Regards,
Peter
(ps. I understand there *are* some laptops with parallel ports that
won't allow this.)
(pps. I agree with you that size matters. Having all that cheap space
and memory is producing the intellectual equivalent of a fatty heart -
a fatty brain.)