From ... From: Erik Naggum Subject: Re: creation of lisp machine/lispOS Date: 1997/04/30 Message-ID: <3071377465763593@naggum.no>#1/1 X-Deja-AN: 238358249 References: <1997Apr21.172333.12018@wavehh.hanse.de> <335E3B92.1A16@nospan.netright.com> <5jt0vo$4b3$1@trumpet.uni-mannheim.de> mail-copies-to: never Organization: Naggum Software; +47 2295 0313; http://www.naggum.no Newsgroups: comp.lang.lisp * Chris Bitmead uid | Personally I think if you're going build something which is basicly not | compatible with the rest of the Universe you might as well go the whole | hog and use the the most pure language (i.e., Scheme), and make it a | SchemeOS. Oops! Don't want to start a flame war. I'd be reasonably | happy as long as Scheme could be used as seamlessly as lisp. Condidering | the problems Guile have had I'm not sure that would be easy. there's something I don't understand about Scheme proponents. I recognize that the language is smaller and (for some values of "elegant") is more elegant than most, but if everything that people want to do is so "impure" as not to make it into the standard, doesn't the overall result get much _less_ elegant than if you decided to offer some practical, reasonable way to do it? after all, when a Scheme implementor has no "defstruct" in the language specification, he's going to add his own, because they are necessary when programming anything non-trivial and any programmer will look for them. now, whatever he comes up with, it does _not_ meet the Scheme standard of supreme elegance (otherwise it would have been in the language), so he will instantiate the practical-vs-elegant argument every time he makes a design decision for something that is obviously needed yet too ugly to make it into the standard. I contend that this argument destroys the basis for the argument for superior elegance, in fact contradicts it fundamentally: if X number of very good people can't agree on one particular solutionbeing the most elegant, what are the chances that somebody else, who is not among them, will find it when it is needed, and much more of a hurry? what are the chances that it will be vastly less elegant than any of the options under consideration? I, too, can look at R4RS and admire its clarity, its elegance, and its succesfull minimalism, but when I look at Scheme programs that try to do more than trivial tasks, or at Scheme systems that try to give people a framework to work in, I get the "perl experience" -- heaps of ugly but useful hacks to get some short-term job done. seems to me that the flip side of the "only the most elegant are admitted" argument is that there is no lower bound on the ugliness of what is _not_ admitted, yet necessary to get there in practice, and so anything goes. with less stringent demands on elegance for admittance, the standards might just be attainable for more people. (I'm not talking about the great masses inflicted on C++/Perl, but very good programmers who do have a job to do, too.) maybe this is just my experience, but when I write in C, I think "it needs to work sufficiently well" (I don't have time to make it always correct unless I'm implementing fundamental library functions). when I write in Lisp, "it needs to work correctly, but if it contains an interesting problem, I want to find a good general solution". usually, I have the time to find a good general solution to those interesting problems. from what I see of Scheme code, I get the impression that Schemers still think "it needs to work correctly", but that they are willing to reimplement basic functionality all over the place in lots of different ways, mostly to tweak some of the parameters that gave them the most minimalistic and locally most elegant solution to their problem the last time they saw it. in sum, I think Scheme the language is elegant and beautiful, but since so little has been offered to me by those who crafted the elegance, I'm left with a lot of random inelegance in practice. this is in fact why I don't like Scheme. #\Erik -- if we work harder, will obsolescence be farther ahead or closer?