From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!npeer.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Free software (was Re: Where's your Lisp software, Janos Blazi?) References: <3b97d110_1@news.newsgroups.com> <87elpjn19q.fsf@nkapi.internal> Mail-Copies-To: never From: Erik Naggum Message-ID: <3208931568084195@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 67 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Sep 2001 09:52:53 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader2.kpnqwest.net 999942773 193.90.206.190 (Sat, 08 Sep 2001 11:52:53 MET DST) NNTP-Posting-Date: Sat, 08 Sep 2001 11:52:53 MET DST Xref: archiver1.google.com comp.lang.lisp:15940 * jacobian@pacbell.net (Gavin E. Mendel-Gleason) > I do feel I have the right to be demand this as a consumer of products. Do you also feel you have the right to get the source material for movies you see? Actors learn to act based on published plays, which is source code for the stage performance, and playwrights learn to write new ones based on how old ones were written. This is undoubtedly useful within the profession, but as a _consumer_? The Free Software movement is also directed towards developers, not consumers. My interest and investment in Free Software has been to advance education. My acquisition editor at Prentice Hall told me that good authors have read at least 1000 times more than he publishes, and that the actual published book is often no more than a fifth of the volume of the text that has been written on it. > I feel I have this right in the same way that I feel I have the right to > demand that I be able to purchase a car that has good gas mileage. But do you demand the schematics and engineering documentation on the car? > While not releasing the source may avoid this issue entirely, it is a > rather extreme solution. In lisp it would be easy to have the convention > that packages would designate the boundaries based on what is an external > and what is an internal symbol. Or you could publish the source code for exported packages. Allegro CL comes with (well, you have to sign a license and send it in, but it is cost-free) sources to the Common Lisp package. You can actually get a lot of customizations in there, and it does not change much from release to release, either. > Emacs has managed to give away its source and support massive > extensibility and it has not collapsed under the weight of backward > compatibility. That is not _quite_ true. For those of us who have worked on Emacs for a good number of years, the inability to separate internal from external symbols and functionality has always been a source of problems. Users depend on bugs, implementation quirks, and information they should not have needed and whent they get it, could only misuse. Most of my gripes with Emacs come from its lack of commitment to a specification -- that is, people add stuff all the time without consideration for a planned design, and backward compatibility problems set in as soon as it has been released: reversing a bad design decision in Emacs is nigh impossible. > Open source may not be the only model that gives extensibility though. > It is simply the most obvious, especially when coming from a > *nix/c/windows world. This is odd to hear. The Unix world has had scripting languages forever, and those are essentially "half-open source": You get source access to all the scripts, and you can extend the system freely with scripts that tie well into the functions-on-disk (executables) that are designed to be building blocks. Unix has taught users to expect parts of their system to be _in_ source form. Take Perl (please! :), which excellently shows this point. Few people venture into the Perl sources itself, but lots of people deal with other people's Perl code. > It may be that an appropriate solution to the overly static nature of > applications is to make them programming languages themselves. Lisp of > course is well suited to deliver in this area. Precisely, and that is why I think Open Source in the Common Lisp world is a very different beast from what it has to mean in th Closed Source world. In effect, Common Lisp is already half-open by virtue of its retention of source-level information in the compiled system. ///