Slashdot Mirror

Incidently, I'll even grant to you the fact that the reason Smalltalk and Lisp are slower relative to C is not completely GC, but just the nature of the languages.

CMU Lisp

CMU floating point bench marks

The other thing is that I feel I'm getting a bad rap here. I'm not against GC in languages, but there are cases where you don't want the unpredictability of GC and manual memory management makes sense. Are you trying to say that GC is appropriate for all problems?

Of course these kind of engineering decisions need to be made on a case-by-case basis. By the way, commercial Lisp vendors do offer hard real-time GC systems.

Harlequin's memory management services (scroll to the bottom)

You might want to moderate down the Lisp advocacy that follows this sentence. :)

To read about the "New Jersey" mentality, you want to do a search for Gabriel's paper on Lisp (I think it's called "Good News, Bad News, How to Win Big"). A keyword search for "Gabriel Worse is Better" should turn up the correct paper. (The term "New Jersey" is also documented in the Jargon file.) Basically, the New Jersey mentality is characterized by "simplicity at the expence of correctness, completeness, and elegance". The previous poster called UNIX a "monster" because it is designed improperly, with all sorts of silly kludges to get it around arbitrary limits (e.g. number of file descripters per process, length of a file name, etc.) or simplistic solutions to hard problems (e.g. the "pc-lusering " interrupt problem described below). Languages like C/C++ have some truly awful kludges in them because they lack garbage collection, or a good exceptions mechanism, etc. Sure, C is really simple, and yeah, UNIX and its attendant scripts and shells and whatnot are really easy to use---but there's a lot of stupid things in there that shouldn't be.

The canonical example of the "New Jersey approach to design" (given in Gabriel's paper) is of interrupt handling. If a hardware interrupt occurs while a program is in kernel mode (i.e. the program made a system call), the right thing to do is to back the program back out to just before the system call, handle the interrupt, then retry the system call automatically. Instead, UNIX aborts the system call and returns an error to the program (EAGAIN). The program must test for this error and explicitly retry the operation.

The other poster described "C machines", so I won't go over that again.

I do want to address two more of your comments, "C is a very general, low level language" and "it is more easily translated into machine code than Lisp". While I agree with you that C is a low-level language, I'd have to take issue with your use of the adjective "general". I don't think C is a general-purpose language any more than I think IA32 or SPARC assembly language is "general purpose". C excels at being a portable assembly language, but I doubt it is appropriate for large projects (but that's just my oh-so-humble opinion).

As far as your assertion that C "is more easily translated into machine code than Lisp", I would also have to disagree. Certainly there are computers more amenable to Lisp (e.g. the SPARC with hardware support for pointer tagging), but that doesn't automatically mean Lisp is going to be slower than C on some random computer. In fact, CMU Common Lisp (a free Lisp that runs under UNIX) generates codes that run as fast as comparable C programs. Check out Martin Cracauer's floating point benchmarks in CMU CL and C.

CL has several advantages over both Perl/Python and C/C++.

• Like Perl and Python, Lisp provides an interactive environment. You can make changes to a running program without having to restart it. Plus, modern Lisps give you a real garbage collector, not a simple reference counter like in Python (although newer versions of Python may have a better GC).

• Like C/C++, Common Lisp is compiled. Unlike C/C++, CL allows you to call the compiler interactively---again, you never have to restart your program. Compiled Lisp code is about as fast as comparable C or C++ code. In fact, most interactive environments compile code on the fly as you type expressions in!

• Like Python and C++, Common Lisp also provides a robust and rich object system, called CLOS. I haven't done much with CLOS, although I like the idea of multiple inheritance and the ability to dispatch methods based on more than one object (Lisp methods and generic functions can dispatch on any of their arguments).

• Unlike C and Perl, Lisp is pretty clean, syntacticly. You never have to remember operator precedence or any of the funky variable naming rules. Lisp is case insensitive, although it is pretty easy to override this.

Several Lisp environments are available, both commercial (Franz, Harlequin) and free (CMU Common Lisp). There's a complete web server written in Lisp, the Common Lisp Hypermedia Server. If you want to learn more about Lisp, check out the Associate of Lisp Users and browse through the section on tutorials and books (a good book, by David Lamkins, is called Successful Lisp).

Not all is happy in Lisp-land, though. There's no archive network like CPAN or CTAN, so you'll have to go digging when you want a regexp package (although I can tell you to look at SCSH for that). While commercial Lisp environments from Franz and Harlequin are available on Windows, the only free Lisp I know of that has been ported to windows is Clisp, which "only" has a byte-compiler (like EMACS). CMU CL, the best free Lisp around, only runs under UNIX. I also don't know of an equivalent to mod_perl that embeds Lisp in Apache, although if you use CL-HTTP this isn't an issue. Still, Lisp may deserve your attention. As old as the language is, Lisp is still years ahead of its time.

Try extracting the nth element from a list in C++ in less than O(n) using the standard linked list data structure. You could make a fortune with that algorithm ;) In my experience most Lisps in serious use are at least bytecode-compiled and most are compiled to native code.

A list is not the only data structure available in Lisp. For instance, Common Lisp has arrays just like C/C++ and they're as fast with proper type-declarations. Lisp is not inherently slower than C/C++; you just have to work a bit more to make it as fast. A Lisp program could be faster than C because it's easier to implement better algorithms in Lisp or because the Lisp compiler is better than the C compiler. The important thing in optimizing Lisp is to declare types and to avoid dynamic memory allocation during speed-critical code.

I've seen some numerical code go faster in CMUCL (a high quality free Common Lisp compiler for Linux/*BSD) than the equivalent in g++ (with all relevant optimizations, 10% difference in speed in favor of CMUCL), just because the CMUCL compiler is excellent in number crunching.

For more information see Association of Lisp Users, CMUCL is available at www.cons.org.

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?