Slashdot Mirror

AT&T's Globeview 2000 (an ATM phone switch I think, telecoms is not my speciality) uses Harlequin's (presumably now xanalys) Real Time Lisp (a variant on their ordinary Lisp). It certainly garbage collects in real time meaning their is an upper bound on the length of a pause due to GC and a guarantee of maximum CPU overhead due to GC.

Those resources might be valuable, but so is the ability to add a new voicemail service to your phone switch without dropping existing calls (which rebooting the switch would do).

Here's a press release with some marketing details

Here is a list of online books and references which I found useful:

• Common Lisp: A Gentle Introduction to Symbolic Computation -- David S. Touretzky
• Successful Lisp: How to Understand and Use Common Lisp -- David B. Lamkins
• CLtL2: Common Lisp the Language, 2nd Edition -- Guy L. Steele
• HyperSpec: The ANSI Standard for Common Lisp -- Kent M. Pitman
• CLOS: Common Lisp Object System -- Daniel G. Bobrow et al
• MOP: The Meta Object Protocol
• CLIM2: Common Lisp Interface Manager 2.0
  The CLIM perspective, user's guide, and specification.

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)

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

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.

You ask the wrong questions. Lisp is not used to solve common problems, people gravitate towards Lisp because their problems cannot be solved by the 'common' languages.

Anyway, take a look at:

• www.franz.com (the "applications" link)
• Lisp on the Deep Space 1 spacecraft
• Why Lisp?
• Lisp 'portal'

• A URL
• A mailto: URL
• An email address
• A pathname (ala the Common Lisp notion of pathname, namely a structured object that represents a filename)
• A MIME object dropped onto the clipboard

Notably, if it's a file reference, validate against /etc/magic to determine whether the method we think we're going to apply to it is actually appropriate to what's in the file.

A "controller" part would be the provision of control to select the method by which the object is to be viewed. Which leads naturally to the "view" portion of the paradigm...

Although Python is elegant, it was not designed as a beginers language. Almost no languages have been designed in this way, with Basic (and Pascal) being the ones I can think of. But I would not advocate the use of these languages.

My choice would be (although I don't like it for general purpose programming) ML. This has been designed from the ground up to be syntatically and semantically well designed and provide all of the facilities for well formed design and implementation. It can (and is being) be extended to provide a whole specification language with facilities for ensuring that the final code matches the specification. The MLWorks enviroment provides a nice front-end on many platforms. It's also got a really simple syntax, and can be made to do some really powerfull things (like infinite presision arithmetic.)

I guess you folks missed this one:

HARLEQUIN LISPWORKS FLIES ON NASA'S DEEP SPACE 1
Cambridge, Mass., May 21, 1999

link to pressrelease

Harlequin LispWorks is supporting the operation of the Remote Agent
Experiment (RAX), activated this week on NASA's Deep Space 1 spacecraft.

See The memory management reference for four separate definitions of "byte". It took us a while to get it down to four.

Well anyone looking for speed in a dynamic, object-oriented language might want to check out the Dylan programming language. It is considerably more abstract than Java (Dylan programs are significantly shorter), yet Dylan code is probably faster in most cases.

There are two main implementatin of Dylan:

an open-source implementation for Unix-compatible systems: http://www.gwydiondylan.org/


and a free version of Harlequin's commercial implementation for Win32: http://www.harlequin.com/products/ads/ dylan/