From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Why Arc isn't especially OO References: <3C1703A8.2F2929AD@nyc.rr.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3217299021996648@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Dec 2001 06:10:24 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1008310224 193.71.66.49 (Fri, 14 Dec 2001 07:10:24 MET) NNTP-Posting-Date: Fri, 14 Dec 2001 07:10:24 MET Xref: archiver1.google.com comp.lang.lisp:22378 * James A. Crippen | I understand his purpose perfectly. CL is really too large for the | purpose he applied it to. If you don't need CLOS or hash tables for | instance, then you're losing lots of code space in your binary. I do not understand this position at all. Regardless of the "tree shaking" issues, "too large language" is simply false. The concept of a language being "too large" is vacuous. Just because starting up a new process is thought to be slow, does not mean that the language is too large. First, startup time has nothing to do with language size. Second, code size has nothing to do with startup time. Third, neither has binary size or disk footprint or any of the other numerous idiot measures of size. As a matter of counter-evidential fact, most of the Schemes I used before I came to my senses are still way, way slower to start up than the Common Lisps I have used, especially with actual code being used, and Scheme is about the smallest language you can get. Execing a new image is usually quite expensive, but forking is not, at least under reasonable Unices, so it should be possible to fork a running image of a large binary with almost no overhead. Reasonable Unices even do copy-on-write and will not waste memory needlessly, either. This means that the startup time has become _completely_ irrelevant. Furhtermore, the one-thread-per-connection model is inefficient compared to a tightly integrated I/O loop because a context switch is so much more expensive than merely running the same code with several file descriptors. Making languages smaller to get faster startup time in a system that has decided on the fork and exec model appears to me no smarter or effective than shaving to lose weight. | And the Lisp Hacker that has not written their own Lisp-like language is | not the true Lisp Hacker. Nor is he who has not seen the folly of the endeavor in time. /// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.