The future of Lisp...

http://12monkeys.co.uk/2009/01/21/the-future-of-lisp.html

by hassy • 18 years ago

42 47 18 years ago

12monkeys.co.uk

icey2• 18 years ago

It's interesting to consider Lisp as an Algol equivalent. It says something for the staying power of the language if these sorts of opinions are just now starting to gain prevalence.

I like CL, but I do think that its age is a distraction; people have a hard time getting past that sometimes.

hassy6• 18 years ago

age per se is not a problem – just look at Erlang, which is one of the "cool" languages at the moment.

the issue is, in addition to the 3 i mentioned in my post, that there isn't a problem that you think of and then you think that CL is the answer:

* an enterprisey app → Java or C#

* a web app → Ruby, Python, Perl or PHP

* an HTTP/XMPP-based server → Erlang

* a bunch of scripts to glue things together → Ruby, Perl or Python

* a desktop app → C, C++, Objective-C or C# (depending on the OS)

* ??? → Common Lisp?

sharkbrainguy• 18 years ago

Obviously

meta-optimizing semantic evolutionary search -> Common Lisp

duh.

http://code.google.com/p/plop/

Hexstream5• 18 years ago

Big problem --> New DSL --> Common Lisp

icey2• 18 years ago

Personally I think the issue is with advocacy. I would have a hard time selling Lisp at a lot of places because it's been around long enough that the management has heard of it, but they heard about it "in the eighties", which I think gives them some pause. A lot of people lump Lisp together with COBOL and the like, just out of ignorance.

dimitar• 18 years ago

There are a lot of problems that could fit in those ???.

* symbolic computation (there are many Computer Algebra Systems written in Lisp like Maxima/Macsyma, FriCAS/OpenAxiom, Reduce, bergman)

* language processing

* artificial intelligence

* generally complex and dynamic tasks in science and engineering.

Some of the software is being continually improved since the 70ties and while it doesn't have millions of people staring at it, it is useful and appreciated.

coliveira• 18 years ago

You are just showing the application areas and the "best" languages for them. If this is the way you approaching languages, then the problem is not with Lisp, but with your application area. Find an application area first, then design an environment to solve the problems of that application area using Lisp. The next step is to create a community of people interested in solving that problem, and finally offer the Lisp environment to that community.

It has worked before with:

CAD application -> Autocad Lisp

Text editor -> Emacs Lisp

Kaizyn• 18 years ago

Lisp's age is not an issue. The fact that the Common Lisp standardization process happened prematurely and effectively killed the language is a problem.

MrRage• 18 years ago

I've not heard of that. Can you provide more info on how/why the standardization process happened prematurely?

Hexstream5• 18 years ago

I think he's referring to how the standard says nothing about threads and GUIs and sockets and other crucial features. (But I think other standards like C don't even say anything about that either...)

But most implementations address those issues and there are even libraries that expose those features in a uniform way across implementations.

ramchip• 18 years ago

I've mentionned it on the Clojure thread, but I think the major distraction of CL isn't age itself but rather all the dead websites, the libraries documented by a bunch of 1998 Usenet posts, etc.

I can't even find a fairly complete and maintained GUI library. I know a lot of people do web programming, but desktop software is still alive and well. Even wxCL, which is pretty much the most complete available, has been updated on May 20, 2006, and its documentation page says "Coming soon". And the mailing list is nothing but spam. You mean this is what I'm supposed to use to build a GUI in CL?

Personally, that's why I don't use CL. It's not because of Emacs (which I use for most programming), it's not the cruft... it's the fact that I feel like I'm stepping in a graveyard and won't find anyone to help me if I try to use one of its libraries.

On the other side, I really enjoy Clojure. I know I'll always have access to the libs I need, there's help easily available, and I can really see it going somewhere better.

Hexstream5• 18 years ago

"the community is not making an effort to make CL seem cool."

Sorry if we value being over pretending to be...

hassy6• 18 years ago

my point is you are, but few people are aware of it.

jstraszheim• 18 years ago

It might be true. I like CL as much as the next guy on YC, but I would quite happy if someone offered me a paycheck to use Closure.

Hell, I'd be happy to get a paycheck using Python at this point.

(I use Java in my day job. It is alright to pity me.)

whacked_new• 18 years ago

Clojure, my friend.

You may have said you wanted to use Jython. Spelling does make a big difference in this case.

miked3• 18 years ago

I quite agree with Mr. Veldstra, and would add a few things. 1) Clojure isn't always fast, but it's fast enough. 2) When you need more speed, you can always write Java code and then trivially call into it. No need to worry that you'll be trapped by performance issues. 3) There's no need to get rid of your current Java infrastructure or code base. Clojure works WITH that code base, not INSTEAD of it. This will give most CTO's a warm, fuzzy feeling. 4) Clojure can easily and safely exploit multi-core processors, something that's about to become an issue. Given how difficult it is to make multi-threaded Java work correctly, this is a big deal. 5) It's going to make your developers a lot happier, which can produce a competitive hiring advantage. And the kind of developers you get are likely to be sharper. Given how dramatic the differences between developers can be, this is an especially important and (I think) underappreciated point.

As for CL, I think most CTO's will have a single question that's foremost in their minds: if Lisp has been around for half a century and CL for about a quarter of a century and they still don't have a good story for GUIs, sockets, and a clean-up language, why is any of that going to change if OurCorp starts using it?

gruseom• 18 years ago

It's going to make your developers a lot happier

That's pretty amusing, given that Clojure is a Lisp and we all know how unfriendly and unpopular and weird Lisp is. (You could look it up in that post you quite agree with.)

they still don't have a good story for GUIs, sockets, and a clean-up language

This reminds me of Gilbert Ryle's old line, "She came in a flood of tears and a sedan chair." What do these things have in common? And what on earth is a "clean-up language"?

most CTO's will have a single question that's foremost in their minds [...] why is any of that going to change if OurCorp starts using it?

It just doesn't matter. Lisp (including CL) is what it is, an amazing tool for those who want to take the time to learn it and a competitive advantage for those who figure out how to leverage it on a problem. It probably isn't going to become popular, and it certainly isn't going to go away. The ignorance of CTOs isn't going to affect it much either way.

MaysonL• 18 years ago

There's also Factor, which is pretty much becoming a postfix Lisp.

jamesnvc1• 18 years ago

There was actually some recent discussion about this on the Factor mailing list.

Factor's macros aren't really the same as Lisp's, as they are a compile-time optimization of dynamically-generated code, rather than a means of syntax extension. Factor does have a method for extending its syntax (called parsing words), but as of now they are not really first-class citizens in the way that Lisp macros are. There are, however, plans to remedy this and make them more declarative & easy to use.

herdrick• 18 years ago

Emacs is also the default editor for Clojure. There's an Eclipse plugin coming along but I think it's not ready yet.

schtog• 18 years ago

I had no problem getting Clojure running on Eclipse. I much prefer emacs though.

pg3• 18 years ago

Do all new languages have to be built on top of existing popular VMs? If so (a) that's a new rule, because Ruby, Python, Perl, etc, weren't, and (b) the article could have a much bolder title: it could be about the future of programming languages, not just the future of Lisp.

And if it's not the case that this principle applies to all new languages, what's special about dialects of Lisp that makes it only apply to them? Why can you build a new language with infix syntax and Greenspun's-tenth-law semantics up from scratch, but not a new Lisp?

trominos• 18 years ago

Because Lisp has about a million pounds of stigma attached to it.

pg3• 18 years ago

Even at current exchange rates, that's a lot of money.

megaduck• 18 years ago

Agreed, there's nothing special about Lisp. He could have been talking about the future of scripting languages, or the future of statically-typed languages, or anything. However, one thing is clear: The future of languages is definitely VMs. There's just too many advantages to them. I'm hard-pressed to think of a significant language in the past fifteen years that isn't VM based.

Once that's taken as a given, why reinvent the wheel? It seems like there's numerous advantages to using established VMs like the JVM or the CLR. In order to justify the engineering effort of building and maintaining a new VM, you'd have to have a compelling reason and I'm not sure that the reason is always there.

dlat• 18 years ago

What "existing popular VMs" are you talking about? Was there a widely spread VM before JVM? Perl and Python are older than Java, Ruby should be around the same age.

rbanffy4• 18 years ago

The Smalltalk VM comes immediately to mind.

miked3• 18 years ago

>> Why can you build a new language with infix syntax and Greenspun's-tenth-law semantics up from scratch, but not a new Lisp?

pg: I'm a big fan, but I think you're a bit off on this one. Costs, risks, and benefits.

Costs: with Java/.Net, you get free garbage collectors, machine code compilers, debuggers maybe, vast numbers of libraries from thousands of sources, a huge installed technology base and ecosystem. Versus almost none of that with start-from-scratch.

Risks: by staying on a known platform risk is minimized. If an organization is looking to replace/supplement language X with a new language Y, it helps that X and Y are both calling the same libraries. Developers get knowledge re-usability and the organization gets a way to easily recode new programs in X that were recently written in Y before everyone decided that Y was a mistake.

Benefits: much reuse of platform knowledge, libraries, etc., most of which have typically been heavily used and debugged (again reducing risk.)

You once pointed out that moving away from the herd's choice of languages can bestow some major competitive advantages. I agree, but think that this will work only if one doesn't acquire so many disadvantages in the switch that the advantages are obviated. Clojure on the JVM gives the best of Lisp, FP, and the JVM/Java ecosystem while minimizing the problems of each.

The languages don't "have to be built on top of existing popular VMs", but why, given all these advantages, do it any other way?

pg3• 18 years ago

How can I be off? I didn't draw any conclusions; I merely explained that the author's statement translates into one of two possibilities, and asked which they meant.

It seems to me you're saying it's the latter case: that new Lisps will get an advantage from being built on existing VMs that new "mainstream" languages don't need. Maybe. But in that case, let's follow the thread further: what is it about Lisp dialects that makes them need this extra crutch?

Not the semantics, surely. I'm sure if you gave ordinary schmoes a language that looked familiar, they wouldn't balk at it because it happened to have clean semantics. Is it merely the name "Lisp?" You could solve that problem by refusing to call it a Lisp. So all that's left is syntax. You're saying, in effect, that a language with s-expression syntax needs the extra boost of being on a popular VM to make it.

I don't know if that's true or not. It might be. But it is interesting to know that this is what the argument reduces to.

hassy6• 18 years ago

you're right in that my argument can be generalized to most (new) programming languages:

unless your programming language requires a new VM for some good reason, build it on top of an existing one.

when would a new VM be required? well, Erlang for example just could not have been implemented on top of JVM (forget for the moment that it predates the JVM by a few years). BEAM, the Erlang VM, has an overhead of ~500 bytes per process -- try that with JVM. Factor, IIRC, outgrew the JVM very quickly too – though i forget how exactly.

most of Lisp's power lies in uniform syntax which manifests itself in Lisp macros. that's not a good reason to write a whole new VM.

the reason i talk about "future of Lisp" rather than all programming languages is that at the time i was thinking about Lisp & why it remains unpopular despite being an awesome language.

ynniv• 18 years ago

No one ever completed the C-like (or JavaScript-like) lisp syntax, which I suspect could be implemented via reader macros. The question would then be, why would someone write JavaScript for execution in a lisp VM? Which would make an excellent context in which to point out that JavaScript is getting very popular, and while Rhino get some use, there is no clear winner in the non-browser JavaScript runtime.

samuel• 18 years ago

What's wrong with PLT-Scheme? It's well-documented, has a decent amount of libs and its syntax its much cleaner than CL's one, but can't find any reference about anyone using it in production code(other than Arc).

hassy6• 18 years ago

you answered your own question there. the community isn't bothered about the popular image of PLT Scheme as merely a Lisp for teaching. (whether they should be bothered or not is a whole different question, but choosing not to care ensures that PLT Scheme won't be a mainstream Lisp.)

eru• 18 years ago

Yes, PLT-Scheme is nice.

JulianMorrison• 18 years ago

ABCL, Rhino and JRuby provide a countercase by examples. Running on a VM is not enough, easy access to the VM libraries is not enough, and the version on the VM won't automatically be more popular.

The future of Lisp...

Related Stories