Slashdot Mirror

Emacs is still the best editor for programming in Common Lisp. With SLIME, Emacs connects to a Common Lisp compiler over a socket and allows interactive evaluation, debugging, introspection, and more. I don't know how I ever programmed without being able to C-c I * and inspect an arbitrary object, see its slots, etc.

Frighteningly enough, that might actually be possible. If you were to port Emacs to Movitz Emacs could become an operating system in actuality rather than as a joke!

http://common-lisp.net/project/movitz/

I'm not into web work too much, but I think there are some other lisp guys that are. The UnCommon Web guys might be a good place to start: http://common-lisp.net/project/ucw/

I'm actually not so much into graphics, I just want a good backend for McCLIM so I can implement a portable lisp based GUI for Axiom. I get my X server ideas because FFIs are painful and the only real alternative is the low level clx. Hence, I wish we had a high level clx :-).

Been a while since I checked out PicoGUI. Had promise, but the focus didn't seem to be on challenging X so much. Too bad in a way.

And what is the thing that recognizes, approves and executes each IL?

People. Using signed

No, no, no. The "IL" for any native code compilers are the host architecture's native instruction set.

Let's keep this discussion in context. You expressed horror at the idea of an OS that depended on a single IL. What exactly is your horror in reaction to? To answer that, we have to consider the nature of an IL. An IL exposes two things, an instruction set and a machine model. Surely, your reaction could not have been to the instruction set, as that is nearly transparent to the language-implementor. At the level of the instruction set, compiling to CIL is really no different than compiling to PowerPC or x86. It's completely transparent from the point of view of the programmer.

What you experessed horror to, whether you realize it or not, is the idea that the OS imposes a particular machine model on the program. The machine model is something that is not transparent to the language implementor or the programmer. If the IL doesn't expose arbitrary pointer arithmetic, you'll have a check of a time implementing or using a language that features pointers. Now, to finally get back to my point: while it is regrettable that the OS must impose a particular machine model, it is almost inevitable, and indeed, UNIX imposes a very specific (and often burdensome) one. UNIX is deeply intertwined with the C machine model (serially-executing, interruptable processes accessing uniform, unprotected, untyped, and contiguous memory). Of course, the machine looks nothing like that underneath. Significant layers of hardware and software are involved in making a modern superscaler multicore NUMA machine look like a PDP-11. Nonetheless, from the point of view of language implementors and programmers, that's exactly what a UNIX machine looks like.

An OS based on a safe IL will not be any less (or more) guilty of imposing a particular machine model: it will simply expose one that looks different. Implementors of unsafe languages will have to go through contortions to target such a machine, but that's really no different than what implementors of safe languages have to go through to target a UNIX machine!

Oh no doubt Linux uses gccisms. It's probably 80-90% C, and 5-10% asm, and 5-10% gcc extensions.

80-90% C is not C, it's "C-like". I personally thing its a stupid distinction, but you're the one attempting to make it (for Lisp). I'm just pointing out that, in that case, you should make it for C too.

The main issue with Lisp is the runtime environment. Would you call Lisp without garbage collection Lisp?

Without a GC? Likely not, but then again, we're not talking about removing the GC. That is not necessary to make a language suitable for writing kernels. We're talking about adding functionality to allow the specification of in-memory representation ("read-mem", "write-mem", "read-io-port", "write-io-port"). If C with an external function "read-io-port()" is still C, I don't see why the same isn't true for Lisp.

Have you even seen such a beast?

Multiple such beasts. Movitz is one such example. Sure, it's not particularly sophisticated, but that's because one guy is working on it. Popularity and suitability are two different things.

Learn Scheme or learn computing using Scheme. Or learn to appreciate art and still get something done.

Nirvana.

Have you looked at Movitz? It's a minimal operating system and lisp runtime environment for x86 PCs, which makes kernel development in Lisp practical.

Movitz is arguably the first step to a modern "Lisp Machine." Actually doing it in hardware would be foolish; even Symbolics abandoned that path. Their last-generation products were a tagged-memory RISC architecture and a VM system that ran Genera (and Symbolics Common Lisp) on top of UNIX on the DEC Alpha.

Unfortunately, the Symbolics RISC project never saw the light of day. OpenGenera, the Genera-for-Tru64, is still available, but costs thousands of dollars.

Lots of people are using Lisp to write programs under Linux/FreeBSD/Mac OS/etc. these days. CLiki is a collection of free/open-source Lisp implementations and programs. A lot of them are hosted at common-lisp.net . The Association of Lisp Users hosts conferences and serves as a center for language advocacy.

I did Verrazano (AKA Fetter). Lisp bindings generator for C++. You can track it at http://www.common-lisp.net/project/fetter.
It's still pretty rough, but Kenny Tilton just did some OpenAL bindings with them, so they're getting there :)

Common Lisp has been attracting a lot of attention lately, compared to previous activity. Several of the Common Lisp projects funded were for the purpose of improving things like foreign function interfaces, and thus speed Lisp's popularity and utility even further.

There are a lot of applications written in Lisp that are special enough and powerful enough to justify lots of attention. For example:

ACL2 : http://www.cs.utexas.edu/users/moore/acl2/
This is a high powered proof assistant and IIRC was used by AMD to verify some parts of their chip design.

Maxima: http://maxima.sourceforge.net/
This is a computer algebra system, with the ability to do things like symbolic integration. Not your run of the mill program, and very difficult to do except in a language like lisp or a similar language

Axiom: http://www.axiom-developer.org/
A second computer algebra system, with a slightly different approach than Maxima. Also extremely powerful, and is pushing the envelope of robust, literate program design for computational mathematics.

None of these has a pretty interface, granted (at least not one written in lisp) but these are not your everyday programs. Lisp is a real language in real, non-trivial use.

There are a variety of other projects being undertaken, check out http://common-lisp.net/ for many of them. And if you want to code lisp remember to explore SLIME+Emacs.

You may find Cells quite interesting. "Cells: a dataflow extension to CLOS" - http://common-lisp.net/project/cells/

Functional programming and continuations. One present day example is the UnCommon Web, which is a web application framework implemented with continuations.

Marco is the author of Uncommon Web, a continuation based lisp framework for web applications.

Last week he did a video for that, torrent here that was well received. It's still in the early stages, but combined with Lisp-on-Lines (in development) it's hopefully going to attract some mindshare.

Bill Clementson also discusses lisp webserver options in his (slighty dated - Oct-2004) blog entry

I started working with UCW/Slime/mod_lisp a couple of weeks ago, and I'm pleased to see better getting started videos, ala Ruby on Rails.

Marco is the author of Uncommon Web, a continuation based lisp framework for web applications.

Last week he did a video for that, torrent here that was well received. It's still in the early stages, but combined with Lisp-on-Lines (in development) it's hopefully going to attract some mindshare.

Bill Clementson also discusses lisp webserver options in his (slighty dated - Oct-2004) blog entry

I started working with UCW/Slime/mod_lisp a couple of weeks ago, and I'm pleased to see better getting started videos, ala Ruby on Rails.

Then answer to the original ask slashdot is, of course, LISP.

It's written "Lisp" these days, and yes, it could well be a suitable answer for the original ask slashdot question. Common Lisp has quite a decent set of Lisp-based web libraries, servers in lisp, and app. frameworks. e.g. Get Uncommon Web here - Watch the Video!

Then answer to the original ask slashdot is, of course, LISP.

It's written "Lisp" these days, and yes, it could well be a suitable answer for the original ask slashdot question. Common Lisp has quite a decent set of Lisp-based web libraries, servers in lisp, and app. frameworks. e.g. Get Uncommon Web here - Watch the Video!

Everybody complains about Linux and Window and all the other operaitng systems about being old an obsolete but I see only a few putting effort in building new operating systems like what Slate can become (in the long term) or what Movitz is aiming.

That doesn't count for anything! We all hate microsoft here, son. Heck, I was hatin' microsoft when you were still in diapers, I reckon. You want mod points, try innovating a little! Try hating something nobody else hates, like people from Luxembourg! Maybe get in on the ground floor by hating some obscure project that's not quite alpha yet, like Movitz: http://common-lisp.net/project/movitz/ .. Wait, nevermind. That one's taken. DAMN LISPNIKS! *shakes fist in rage*

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

CL has some problems with the Meta Object Protocol (MOP), which is used for reflection and to modify the object system. It's not standard, but it's supported by all major Lisp implementations---and they usually have small differences, most prominently what package they put it in. Is it in the MOP package? Or perhaps the SB-PCL package? In order to make portable code that uses the MOP, you need a compatibility layer like Closer or MOPP or CLIM-MOP.

That said, once you have all the compatibility code in place you can do amazing things with the MOP. I co-wrote a graphical object inspector that made heavy use of Lisp's introspection abilities, and Pascal Costanza added Aspect-oriented programming to Common Lisp with AspectL.

CL has some problems with the Meta Object Protocol (MOP), which is used for reflection and to modify the object system. It's not standard, but it's supported by all major Lisp implementations---and they usually have small differences, most prominently what package they put it in. Is it in the MOP package? Or perhaps the SB-PCL package? In order to make portable code that uses the MOP, you need a compatibility layer like Closer or MOPP or CLIM-MOP.

That said, once you have all the compatibility code in place you can do amazing things with the MOP. I co-wrote a graphical object inspector that made heavy use of Lisp's introspection abilities, and Pascal Costanza added Aspect-oriented programming to Common Lisp with AspectL.

A Lisp OS for x86 processors. Don't ask me if it works because I don't know. Sure doesn't look like it's very far along yet.

if you want to do web programming you have to absolutley try UnCommonWeb http://common-lisp.net/project/ucw/, it's really cool and programmed by a friend of mine ;)

They're working on it.

It would help if you thought of Common Lisp and Scheme as different languages. Then you could go and download Lisp in a Box and get started off right with Common Lisp, which has a lot of cool stuff written for it. Yes, I'm biased. :-)

The initial vision of the GNU system - remember "GNU's not Unix" - was to combine a kernel written in C for performance reasons with a userland written largely in LISP. Emacs is the only remnant of that idea, isn't even LISP in its program core, and uses its own LISP dialect instead of CLISP or Scheme. [The climacs project, a CLISP reimplementation of Emacs, tries to fix that.]

Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987. It was like seeing the light of the holy hacker grail - the first system whose userland was superior to commandline Unix in every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but its mouse-centric userland sucks IMHO]. Everything was in one language, syntax and namespace. You could hack and debug the kernel (written in LISP, too) while it was running [!], the commandline userland hooked into every aspect of the system, and could be endlessly and seamlessly extended it just through custom LISP functions and eval-ing them.

Let's dream and hope that perhaps in one or two decades, when insight into the limitations of the Unix paradigm has become common sense, we will have a free Lisp OS as the next iteration of Free Software computing...

Paul Graham's book, On Lisp, is the single best book on programming I have ever read. You can get it as a PDF from his website, for free.

You will also want to read his essay, Revenge of the Nerds, for some serious insight into why Lisp is just so darn good.

If you're just starting on Lisp, the best place to start is with GNU CLISP, although you will find yourself wanting to use Emacs with SLIME to interact with your Common Lisp environment. I use SBCL, but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL.

Take a look at Common Lisp (see: http://www.common-lisp.net/ or http://www.cliki.net/ or http://sbcl.sf.net/ ).

It is a language supporting every paradigm you'll ever need. And if not you can (portably!) code it. The hacker's language of choice.

Does anyone have a list or can at least rattle off any other gave development sdks there are for other interpteted languages (besides java). For example does ruby have any? how about lisp?

That being said, I know of two such projects in nicely working state for Common Lisp. CL-SDL provides a set of raw wrappings around SDL (and OpenGL from there), a bunch of handy utility functions on top of that, and many examples and demos. I've used it, and it is basically like using SDL in C (so you get the best of both worlds). There is also Kenny Tilton's Cello, which uses his very, very slick constraint engine to drive OpenGL, Imagemagick, and he says he has OpenAL working too (I'm not sure how relevant it is anymore, though - cross-platform audio is definitely a problem compared to video). I haven't used it yet, and it's not specifically targeted at games.

There is Isis, a new dialect of Lisp developed by the pointy-headed researchers at the MIT Media Lab for multimedia. In addition to OpenGL, GLUT, SDL, and X11 bindings, it has audio through ALSA, and comes with video capture utilities, and video and image processing tools, networking stuff, etc. That makes it Linux only though. I've installed it but haven't had time to play around too much, but it seems that it has pretty much anything you'd want!

Cliki, a wiki directory of "Links to and resources for free software implemented in Common Lisp and available on Unix-like systems."
CLOCC - the Common Lisp Open Code Collection"
common-lisp.net, providing hosting and remote repositories to dozens of Free Software Common Lisp applications.

This doesn't even touch SourceForge (which hosts another two dozen or so Lisp projects I'm aware of). When you consider how small the Lisp community is compared to the number of Perl hackers (easily in the range of 1000:1), and the number and quality of the code on just those repositories to CPAN, the productivity advantage of Lisp really does seem closer to 50x. According to your argument, all those Perl hackers should not have had any trouble in coming up with an efficient implementation by now. Yet, with less that a dozen regular hackers between them, the CMUCL and SBCL projects have produced compilers that outperform g++. At the very least, the Perl folks should not have had any trouble producing an efficient regular expression library, but here again, Lisp has them beat.

Of course, the above links point to software written in only one dialect of Lisp, Common Lisp. When you consider the software produced in other dialects, like Scheme, NewLisp, LUSH, XLISP, and Isis, the difference becomes even more apparent. To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.

I don't know if any Common Lisp implementation wants to be the de-facto open source lisp, but SBCL is very popular in the News, Web, and IRC. Throw Emacs and SLIME into the mix and you get a really nice system.

an example of an ORM for Common Lisp that uses the MOP is elephant (open source, 0.1 release alpha, uses Berkeley DB).

If you're looking for a GUI IDE, you'll have to go with one of the commercial Common Lisps, or one of the Scheme variants mentioned in other replies. However, lisp-in-a-box will get you hacking pretty fast - it's Common Lisp + emacs + slime (superior lisp mode for emacs) in one easy-to-unroll ball that should Just Work on the platform of your choice.

This link normally works, but common-lisp.net appears to be offline as I type. Google will show you the sites for various platforms

I'd like to see a standardized lisp that I can write and read as quickly and Python.

The Lisp people saw no major advantages to it other than the syntax, and they'd already gotten past that barrier

The non-Lisp people apparently didn't understand that it really was better than C++/Java

Lisp does need a better ... community ...

and one standard open source implementation.

One thing that shouldn't be missed is that object-oriented exception handling, as popularized by Java, was invented in MIT Lisp Machine Lisp. This simplified and regularized error handling tremendously, to the point where today hooks into the deepest aspects of a typical implementation of Common Lisps' debugger are reduced to about a page's worth of code to deal with stack handling. I did a little work on the CLISP backend for SLIME, and this really surprised me.

• Played Jak & Daxter or any of its sequels
• Played Abuse
• Booked a reservation on Orbitz
• Visited the campaign web sites of Bill Clinton in '96 or Howard Dean in '04
• Used the Mirai facial-animation software or watched Gollum in Two Towers / RoTK
• Used an AMD processor, parts of whose logic is validated via the ACL2 theorem-prover software
• Used GNU/XEmacs
• Used AutoCAD
• Used the lisppaste pastebot on a bunch of channels on Freenode

Not all the world is a desktop application with a GUI. Lisp and the other languages aren't going away in this space anytime soon. It's just too cumbersome to do many of these things in C++, and too slow to do them in Java (Common Lisp is usually native compiled).