Books of Note

Practical Common
LispThe best intro to start your journey. Excellent coverage of CLOS.

ANSI Common
LispAnother great starting point with a different focus.

Paradigms of Artificial Intelligence
ProgrammingA superb set of Lisp examples. Not just for the AI crowd.

Thursday, November 11, 2004

Lisp RAD 

I was just reading about Gambas on OSNews today. It's basically a Visual Basic-like RAD development environment for Linux. It has a graphical designer and allows you to hook easily to databases. Finally, when your application is complete, the IDE creates an installation package for Mandrake, Debian, Redhat, or Suse. That rocks!

The obvious question is why doesn't something like this exist for Lisp? Lisp, it seems to me, is the ultimate RAD language. It would be really nice to be able to create a graphical program in Lisp and then have it all packaged up for easy installation on a non-Lisp-user desktop.

Today, Lisp seems to suffer from some of the same issues that Java does on the desktop, only worse. In the Lisp/Java world, deploying an application always starts off with downloading and deploying the underlying language runtime, before the application is deployed. The fact is, users don't want to know that a certain application is even developed in Lisp/Java/whatever; they just want it to run well. Heck, even experienced Lisp hackers are scared of a CMUCL build. As a result of this problem for Java, it has largely retreated back to the server where it dishes out web pages, etc. Lisp has the same problems, but Lisp runtimes are not as easy to deploy, are not very standardized in their interfaces to operating system, etc. At least Java has freely available desktop runtimes that work well across platforms. With the exception of perhaps CLISP, Lisp doesn't. Even the commercial Lisp implementations (which have licensing terms that all but prevent mass desktop deployment), while they have an Emacs-like IDE, don't seem to have what I would call a RAD environment (the difference is subtle--IDE to me just means integration of the editor, debugger, etc., whereas RAD implies a GUI design environment, deployment wizards, etc.).

As with any musing like this that gets overheard in the open source world, this posting will probably draw a lot of "okay, so quit griping and get coding..." replies. I'm hopeful that maybe somebody can point me at a Lisp RAD environment that I may have overlooked. Note that I'm not just looking for an IDE that integrates an editor an a REPL. Emacs/SLIME/SBCL do that perfectly for me right now. The perfect environment would be something like an SBCL base, hooked to a GTK+ API and RAD screen development application, with a push-button packager that will roll up an application into a single OS installation program, at least for Linux. In other words, imagine VB or Delphi using Lisp instead of BASIC or Pascal.


Doesn't the LispWorks implementation allow for massive
desktop distribution? I thought that was the big win for

Well, at least Allegro does do pretty nice application delivery, and across platforms, as well. The problem, of course, is that Allegro is very expensive, and delivery requires runtime licenses, further increasing cost.

On the other hand, if you do buy the necessary Allegro licensage, it delivers very nicely. Indeed, I would say it delivers more nicely than Java, which always requires gathering up jvms, jres, additional jar files, etc. etc.

Of course, this doesn't directly address your point about *desktop* applications, since CL still seems to be woefully short of UI toolage. And it doesn't address the ability to deliver *inexpensive* or free applications.

Once you have GTK+ bindings, you can just use Glade as your GUI designer. Granted, the packaging problems remain, but solving the GUI design problem is important, too.

I suppose that once you have a working tarball template, the distribution becomes easier as well. For example, after having solved dist/installation problems with photoblogger, I don't expect to have to solve them again.



Interesting. I see my comments and the other two are almost non-overlapping in area of interest. This shouldn't be surprising, because I do mostly server sort of applications, and not much GUI development (my applications get their GUI either from a relatively thin client application or from a browser).
This suggests to me that there may be two questions to be unpacked from here and addressed somewhat separately: (1) is the perennial "how the heck do I develop GUI applications in lisp" with a couple of extra trimmings: how do I make them cross-platform portable? and can't I have one of those graphical tools to design them? (2) is "how do I deliver a lisp application without requiring my users to install a lisp environment and compile source code?"
These both seem interesting to me.

Once upon a time there was an amazing RAD development environment on MacOS, called SK8. SK8 was written in Common Lisp, and you could write SK8 programs using either Common Lisp or a HyperTalk-influenced scripting language (compiled incrementally to Common Lisp and thence to native code) called SK8Script.

Every GUI widget supported by MacOS was a SK8 object. You could build UIs by instantiating a bunch of objects and sticking them together, double-click them to open them up and write behavior into them, build new widgets from scratch by instantiating graphical elements and sticking them together, then scripting their behavior, and finally, save the whole pile as a double-clickable application.

If some group of Lisp enthusiasts wanted to build a new-generation SK8 on a free Lisp, that would blow some minds. I'd be interested. I worked on the original SK8.

Nikodemus Siivola has written about SBCL distribution on his blog in response to this. The posting in question is here, but for some reason I don't have permission to access it, so you should probably read at the main blog where it is visible.

You got your wish - Mikel posted on his blog that he and another SK8 developer are assembling a team to develop an open source project called Skate to fill this niche.

Isn't the answer a bit obvious, make a full Ansi version of Lisp * which compiles to byte code, so that it can run on the a JVM!

* why is JLisp still at alpha and no code on sourceforge? Is it perhaps dead from lack of interest?

If you use Java byte code, you could even use WebStart to launch an application from a web page!

I thought Lisp was supposed to be used by smart people :-p

There is a CL implementation called Armed Bear Common Lisp (ABCL) that runs on the JVM.

Perhaps interest in JLisp evaporated because ABCL comes very close to full conformance to the ANSI standard.

ABCL's Web page says that its CLOS implementation is "intolerably slow" and that it doesn't work properly.

I've never actually run the thing: I don't have a JRE on my system.

Post a Comment

Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours?