Subject: Re: Help required on Limitations of Lisp From: Erik Naggum <clerik@naggum.no> Date: 1997/11/11 Newsgroups: comp.lang.lisp Message-ID: <3088257863633044@naggum.no> * David Hanley | Some 'applications' are actually a number of small executables. For | example, the product I'm working on now is ~25 executables. if each one | require static binding to ~1.5 MB, w're talking ~40 MB in | statically-bound code. It would be nice if some of this could be | alleviated with a lisp DLL or VM. why static binding? would you still need 25 executables in Lisp? * (whoever) | > > 3) Programming enviorments are typically several years behind | > > those available in many other languages. that's because those other languages _require_ such environments to be useful, while Lisp systems get by easily without. it doesn't make sense to do more than is necessary to solve a given problem, especially if what you do extra has zero impact on your earnings and a major impact on your costs. to make C++ usable at _all_, it _has_ to have those environments, so it makes perfect business sense to build them, too. note that C++ programmers are approaching Lisp programmers in terms of productivity through the use of these environments, but Lisp programmers are still way ahead. also note that Lisp was years _ahead_ of other languages for a long, long time, and that many of the ideas from the Lisp world have been adopted by the other world. also note that Lisp systems have remained largely constant in size since about 1990, even falling in size, while Microsoft products easily require 100 times more memory and 50 times more powerful CPUs to do exactly the same ting (as far as user productivity is concerned) as they did in 1990. why are people still concerned with the size of Lisp programs? * David Hanley | Well, it depends. If it's going to be distributed, it helps. It would | be tough to write 'zip' in lisp with most common lisp systems, because of | executable size. However, some modern applications are large enough that | an extra 1.5 MB might not matter. if people insist on running every function from the command line, then it's going to be a problem, but I never saw anybody complain about Word Macros in Visual Basic on the grounds that you had to load all of Word 7 to run a snippet of code. or that to run an X application you had to fire up X first. or that to run a Unix command you had to boot a machine, log in and run a shell. all of these environments issues are taken for granted. in other words: it depends on what you consider your environment. when most users spend their entire working day in a single application, what good does it really do to complain about the size of a standalone program when a function call would have far smaller costs when run inside an application the user is already running than a standalone program could ever hope for? #\Erik -- if you think this year is "97", _you_ are not "year 2000 compliant". see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.