Subject: Re: Free ? From: Erik Naggum <erik@naggum.no> Date: 1997/04/16 Newsgroups: comp.lang.lisp Message-ID: <3070138406039580@naggum.no> * Hrvoje Niksic | It was my misexpression. Again, the question stands -- *why* is that so? | Is it that complex to write a good CL implementation, so that people have | to work full-time on it, or...? it is not particularly hard to implement Common Lisp from Guy Steele's Common Lisp the Language from 1984. it is _much_ harder to implement from Common Lisp the Standard (ANSI X3.226). to implement a full Common Lisp system, however, requires a lot more than just the language. this is really no different from other languages, except that it is useful to implement this from inside the Lisp, and that effectively means doing more initial work before payoff time. | Why are the current Lisp implementations an exception? my experience with programmers of free software and their undiminished need for rewards for their work (only in different ways) indicates that the incremental rewards for enhancing a language environment that leaves (or is believed to leave) little room for personal invention preclude serious investment in a Common Lisp system. another "problem" is that just about anybody can "contribute" something to those relatively simple stand-alone Unix tools, and they grow to become quite sophisticated, but each incremental improvement is (immediately) gratifying to the programmer. before you can start improving on Common Lisp, you need a few years of experience with it, and a real implementation to boot. more often than not, any improvements you might have in mind are already in the language, and your adding non-standard ways to do it is only going to hurt your users. look how Emacs grows as an example: rarely are new language features or fundamental functions contributed, but often packages, small incremental improvements, etc. (e.g., a few people ask why I don't write new packages for Emacs. however, they wouldn't notice that I implemented `encode-time', `decode-time', and `format-time-string' to get rid of the annoying hacking of `current-time-string'. nor would they see the enhancement to the Lisp reader and printer that allows Emacs Lisp macros to use `make-symbol' or `gensym' correctly. to do so, I made the first step towards packages in Emacs Lisp, and the other day I taught `intern' to recognize keywords. almost all of this is already in (and taken from) Common Lisp.) #\Erik -- I'm no longer young enough to know everything.