Subject: Re: [executables] was: why Haskell hasn't replaced CL yet?
From: Erik Naggum <erik@naggum.no>
Date: 2000/02/28
Newsgroups: comp.lang.lisp
Message-ID: <3160693199764094@naggum.no>

* not.for.email@not.for.spam
| When you deliver an application, you have to take into account that the
| users might not have access to your Lisp environment.

  well, this is the meaningless part.  when people deliver applications,
  they take for granted that you already have the relevant portions of the
  environment the application needs in the shape of DLLs (or other forms of
  shared libraries and resources) to make it run.  if you don't, you're
  expected to download it, or in the worst case, get the application with a
  bunch of such libraries.

  therefore, the question is: what's considered the application?  the DLLs
  and the whole shebang or _just_ the executable?  in my view, it doesn't
  make sense to separate them (neither in the case of C nor CL), but in the
  minds of people who compare sizes of executables, the DLLs are somehow
  irrelevant, but if they are made aware of them for some languages, like
  some not-so-helpful Lisp people seem to force them into, they will also
  count the runtime system.  this is a very bad move.  don't call attention
  to these things, and they'll never notice them the exact same way they
  never notice the multimegabyte DLLs they install for other packages.

| You also have to take into account that they might want the application
| delivered to their email inboxes, and that they might have a limit on the
| size of an incoming message.

  sorry to say so, but this is a specious argument at best.  people need to
  install some form of runtime system library _once_, and can thereafter
  accept any small "executable" = application.  this is not a big deal.
  what's necessary to ship for Common Lisp programs is usually much smaller
  than you need to ship for other languages once you're past this point.

| As another example, suppose I'm a naive user who uses your program from
| my text-editor, invoking it with a filter-region command, to capture its
| output in my edit buffer.  If I know someone else who has the same
| program written in C++, and I've noticed that they can do the
| filter-region thing in a tiny fraction of a second, but I always have to
| wait almost a full second, I might start to envy them, and wish mine were
| written in C++ instead of Lisp.

  this would have been a useful piece of input if it were true.  it isn't.
  that is, it used to be true 20 years ago, and today it's stale myth.

| In the real world, we have to keep the users happy.

  well, in the mythical world, the users aren't happy.  in the real world,
  they don't care what language is used as long as they get what they want,
  and users put up with a _lot_ of compromises.  speed is no longer an
  issue, since the hardware new stuff is being deployed on is really fast.
  (just trust me on this if you don't believe it.)

| We have to instead say something like, "yes, a Lisp program does take 750
| ms to start running, but here are the ways you can mitigate that, and
| here are the advantages you get for tolerating that."

  do tell me just _why_ do we have to lie?  this is so blatantly stupid I
  get _sick_.  on my system, the default Allegro CL starts up in about 20
  ms and with one my applications which has a lot of startup-time
  compucation, it takes about 35 ms on a bad day.

| If we evade the question, the users will assume the worst.

  and some will think _we're_ lying when we tell them that the startup-time
  of a C++ program (and certainly a Java program) is longer than that of a
  full-blown Common Lisp system.  do you know how we can deal with that,
  considering your strong desire to perpetuate old myths?

  you're welcome to the real world any time, but if you have nothing more
  to contribute than trite old myths, you're part of the problem of the
  mythical world Lisp _still_ has to fight, not part of any solution in the
  real world.

#:Erik