Common Lisp needs to be more different
There's an idea going around that Common Lisp needs to be more practical so that more people will use it. Practical is good. But I don't think that Common Lisp is going to win any converts by being more like other languages.
Common Lisp (the standard) hasn't changed in a while. And Greenspun's tenth rule is catching up with it. Other languages are adopting ideas from Lisp (and let's admit it: from other great high-level languages, too). Common Lisp is losing its upper hand.
What made Common Lisp great in the past was that it had all of those big, bulky features designers of other languages didn't think they could afford. While the other mainstream languages were worried about compiling efficiently and running in as little memory as possible, Lisp was busy adding features that were expensive at the time (garbage collection, dynamic dispatch, recursion, bignums, etc). Those features made Lisp huge compared to other languages. Lisp defined a niche in the programming language domain: a language that ran slowly but let you program fast. Now that computers are fast and memory is cheap, just about everybody has most of that stuff.
Not all of the good features made Lisp big-boned. Some were just very powerful ways of defining computing---code as data, bootstrapping, and reflection. Those definitions allowed for meta-programming, language-oriented programming, and a powerful debugging system.
Reflection has made its way into other languages. Sometimes it is in a hacked-together form. But it is there, nonetheless. Code as data and bootstrapping don't seem to be as common. However, the main advantages of these---meta-programming, language-oriented programming, debugging, and a fast implementation time---are creeping into other languages. Parsers and code generators help these things out. Debugging is basically a standard feature in many languages now.
Which is all great. Share the love. It's all good. I'm glad other languages are prospering. But the niche of Lisp is getting overcrowded. The advantages Lisp has are not so great anymore. The argument that Lisp is better because of its feature set is not as strong as it used to be.
So what should Lisp do? It should get fatter! It needs to keep adding more, powerful features to itself. Features that bog down the computer. Really expensive, cutting edge ideas that free the programmer from mundane tasks. There's plenty of research out there!
And, in fact, this is being done. Many packages out there are not just libraries to interface something. A lot of them are wholesale language extensions! Examples include:
- ContextL: Context-oriented programming in CLOS
- Screamer: Non-deterministic programming (with a constraint programming system built on top)
- A variety of persistence layers
- I'm sure there are more out there. Please let me know if you know of more!
Plus: There are more and more libraries on the Libarary page of Cliki all the time! Common Lisp is really progressing.
Subscribe
Comments
STM
another that jumps to mind is Software Transactional Memory http://en.wikipedia.org/wiki/Software_transactional_memory.
This post is a great answer to my previous comment about Lisp needing a new killer app.
It's my personal opinion that the killer app is persistence. If you don't have to worry about Databases EVER and your app just runs and keeps track of it's own stuff somewhere on disk, then that's a crazy productivity boost. I don't even care if my performance sucks because of it.
CL-STM
Check out the library. I don't know how complete it is.
http://common-lisp.net/project/cl-stm/
I have been looking for transparent persistence (that works transparently) for a while. I hate to push my objects to relational databases.
Fat stuff
I have lots of really FAT stuff on my Lisp Machine waiting to be reinvented. The McCLIM guys are working on the user interface and on the editor (CLIMACS). There are some interesting things done. We need more of that. Other things that could be reinvented: Statice the database (there are already some projects, Franz has a new DB, ...), the incremental C compiler written in Lisp (you can develop in C like in Lisp), the whole color and image manipulation stuff (that is FAT), tools like KEE and ART (which combine objects, frames, and rules). There are also lots of other FAT tools nobody understands (check out AP5 for relations and transactions in Lisp: AP5. Then there are extensions like LOOM and PowerLOOM that extend Common Lisp to be even more flexible.
I kind of agree that Lisp should be and stay different. But it should not drift into esoteric. What I think is the next wave: make the libraries good enough for application development (not just for web apps) and teach more developers how to create applications in Lisp. The first wave of reinventing open source Lisp was driven by people taking over the old compilers and make them work again. The next wave was then libraries and exploring applications (many web applications). We are at the end of this wave now. There is enough infrastructure for (open source and commercial) Lisp to be viable development platforms. We need to make people aware of that and help them take advantage of that.
Transparent pesistence
You have a good point: Lisp designers, whether they knew it or not,
were designing for the hardware of the future, while C focused on the
hardware of the day. Now that there's so much memory, and now that
garbage collection technology is so good, Lisp is much more practical.
Perhaps there are two ways to go. First, say that Lisp's time has
come, and now we can take over the world. The problem is, exactly as
you say, it's easy for other languages to borrow Lisp's ideas, and a
lot of that is happening. Second, do what we did before: design for
the hardware of the future. But then Lisp will seem impractical, and
again be marginalized.
I'm only slightly serious about the above, but it's kind of an
interesting way of looking at things. As you say, there are plenty of
great novel things, like ContextL, that work just fine in today's
hardware. Meanwhile we need to fix the libraries problem, and things
like that, to make Lisp more viable and popular.
As for transparent persistence, absolutely. Statice was a good first
try, but it was less "transparent" than one would like, and it wasn't
as efficient as it might have been. After I did Statice at Symbolics,
we started Object Design and did transparent persistence for C++ and
then for Java. Object Design never even though about doing Lisp,
because it didn't make business sense; the market was far too small.
And for technical reasons, you can't do it the same way you can do
C++, or the way you can do Java. Now I'm working in Common Lisp
again, but due to architectural reasons, our product has to use an
underlying relational database. So we have a Lisp-to-relational
layer.
(This is for a large, high-speed, high-availability transaction
processing system, a new airline reservation system initially for Air
Canada, being done at ITA Software. We have maybe 500KLOC of Common
Lisp, not counting many third-party libraries, and maybe 50 Common
Lisp developers working on it. Other parts of the system are in Java
and Python.)
I hope someone take a good stab at a transparent Lisp database system
with good performance and real transactions.
Post new comment