Subject: Re: Which one, Lisp or Scheme? From: Erik Naggum <erik@naggum.no> Date: 1997/01/24 Newsgroups: comp.lang.lisp,comp.lang.scheme Message-ID: <3063102967705823@naggum.no> * Martin Cracauer | CMUCL is as fast and even smaller than most commercial implementations on | Unix. The only things I miss are threads and a better garbage collector | (although CMUCL's superior warnings help not to produce as much gargabe | in first place). ah, agreed, but CMUCL is a breed apart from the rest. it compiles to native code directly for a number of platforms, which is a formidable task, and it is exceptionally good at helping the programmer declare types of values when it could have used a hint. the code it generates is also quite good. however, this is not the norm for free Lisp implementations. out of the several hundred free Lisps and Schemes out there, most are toys. they may be fun toys, but they are still toys. I think this is because it is so easy to write a toy Lisp or Scheme, and so hard to write a fully functional Lisp system. | A commercial implementation has a nice environment, nice browsers, maybe | an editor in Common Lisp and therefore controllable from Lisp and I found | it very valuable to have such a visualization toolkit around when I | learned Common Lisp. But I think Eric missed the point here. well, those have been immaterial to me, but I'm sure we meet different aspects of Lisp systems according to our experience. I have never used a real Lisp system for real until I got Allegro CL, so I was impressed by how much the system knew about itself, how much time the source code manager saved me, how well the debugging is integrated with the cross-referencing utilities, etc. example: I have about 200 functions in a package I'm writing, spread across several files, and I can ask who calls a given function, directly or indirectly. I know which functions and files to recompile after changing a macro by asking for who uses it. I can ask the system to tell me which functions bind, set, and/or reference a variable. I have needed this functionality for _years_, not just in Lisp. Allegro also has search lists that can do wondrous things, too. it's everything _outside_ of the common Common Lisp stratum that impresses me most. | In fact, I already had an argument with the author of Xlisp about it | after some magazine compared Lisp and perl (that is Xlisp and perl) and | headlined that Lisp is slow. | | The problem here is that people choose a free implementation by other | criteria than speed and then complain it is too slow because they | underestimated the amount of efficiency they give up. I see a possible pattern here. if C was slow on some machine or in some particular implementation, nobody would blame C or headline that C is slow. the myth is that Lisp is slow, and every time somebody meets a slow Lisp, that myth is reinforced. that you can compile with CMUCL at high speed settings and beat the sh*t out of C is just as much as an aberration as C running under some bounds-checking and memory-tracking package is slow. yes, we all know that Lisp can be incredibly fast. we all know that Scheme can be statically typed, too, as in the Stalin compiler. neither changes the naive perceptions and the myths that will be reinforced the next time a small, neat, fun toy, somewhat like SIOD, is released and tested by somebody who carries those myths with him. that's how I meant that the free Lisps have mostly worked to turn people away from Lisp. I didn't mean that you can't find free Lisps that people would have flocked to if they would only get over their prejudices. I meant that they don't, because of the many toys they have used and think are the norm. it seems, for instance, that in educational settings, Lisp and Scheme are not at all presented with anything resembling speed in mind, and so students who are used to C and C++ and ads reading "X compiles Java at over 10,000 lines per second", will have trouble _not_ remembering that speed was never discussed, that their compilers and interpreters were slow, etc, etc. I mean, we have people come in here and state that Lisp is an interpreted language at least once a week! it's an image problem, and it's a tragic element of that story that as Lisp implementers focus on other things, students and amateur programmers are turned into speed fanatics because that is the only forte of those other languages and systems. (and never mind that Allegro CL for Linux produces code that runs rings around C++ under Windows NT on the same machine. *sigh*) #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.