Hacker News new | comments | show | ask | jobs | submit login
The future of Lisp... (12monkeys.co.uk)
42 points by hassy 3223 days ago | hide | past | web | 47 comments | favorite

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.

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?

>> 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?

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.

Sorry, my bad. Upon carefuly re-reading your original post I can see the point you were actually making, rather than the one I thought you were making. I completely agree that there is nothing special about Lisp-class languages rather than those of other classes. In fact, I would go further. Having implemented a small Scheme on .Net and also having read thru most of the Clojure code on the JVM, I'd guess that the OO/statically typed nature of both platforms gets in the way of Lisp-like languages more than those of other paradigms. So, in effect, I may "more than" agree with you.

>> 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.

Actually, my guess is that all future non-DSL languages are going to need to be built on a popular VM/framework in order to succeed, because of the advantages I listed in my earlier post. A DSL can get by without a popular platform because, by definition, it doesn't extend beyond its narrow scope and thus doesn't need access to a broad range of libraries. Also, DSLs don't tend to be performance sensitive and therefore don't need the compiler optimizations.

What I was really responding to was the fact that you are the co-author of Arc, and I was (wrongly) seeing your post in that context. My apologies for confusing the issue, although I do think that the point I'm driving at is an important one.

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.

The Smalltalk VM comes immediately to mind.

which one? Squeak first appeared around the same time as Java. was there a free, open-source, solid Smalltalk VM back when Perl, Python or Ruby were started?

The original Smalltalk VM was not open-source (the concept was not invented back then) but was very well documented and had some different implementations.

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.

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.

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

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

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.

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?

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.

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.)

Clojure, my friend.

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

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).

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.)

Yes, PLT-Scheme is nice.

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.

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

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.

So, the solution is a Lisp'09 standard that talks about GUIs, threads and sockets?

I guess the really big problem probably is that there is no canonical implementation, no obvious way to go like there is for other languages. When you want to play with Java, you grab NetBeans or Eclipse and you have Sun to turn to for a runtime. When you want to play with Ruby or Python or most newer languages, you go to http://{$language}.org.

Smalltalk suffers from the same problem - too many different implementations, and no obvious path to follow.

Just use SBCL. Problem solved. It's a great implementation with a big following among Lispers.

It took me a while to get to that decision.

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.

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?

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.

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.

I thought it was more because Lisp is "that language which will make you a better coder which I need to learn some day, but never actually do".

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

I think most new DSLs are either Ruby under the hood, or extensions to Tcl or Guile.

What?... I think the big problem with DSLs is that people think it's a complicated technique that's applicable only in a few specific, obscure cases.

It's actually a technique that scales well, in the sense that you can make languages as simple or as complex as you need, with an implementation as featureful of trivial as you need (just a bunch of macros VS a full compiler and VM complete with high-level debugger), and if you use a language like Lisp that makes it easy to prototype new languages (the lisp reader, macros and closures help a lot) you can afford to make a few DSLs just for one app if you like.

Just for my web framework in the making, I have 5 DSLs:

Purely declarative configuration management (almost done), static and dynamic HTML and CSS generation and manipulation (done, but I have plans for something better), HTML and CSS rewriting (in the making), i18n resources (in the making but very simple).

And no doubt I'll need a few more for my specific applications.

Indeed - I'm just saying that people generally aren't using LISP to write DSLs in. If I needed one now I'd probably either use Tcl as a base or write it in OCaml. LISP isn't really even on the radar for this.

And without the generalities?


meta-optimizing semantic evolutionary search -> Common Lisp



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

> If this is the way you approaching languages, then the problem is not with Lisp, but with your application area.

No, the problem is with CL (not "Lisp") if:

a) it doesn't provide something compelling enough to make me use it over another language

b) the community hasn't created enough buzz around it to place it firmly in my consciousness next to some problem domain (at least one)

> 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.

Yep, this is what needs to happen for CL to have a chance to go mainstream. The important thing is that the application area needs to be very common, e.g. webapps, and the offered solution needs to be radically better than the alternatives. Think Rails <-> Ruby back in 2005. CL may be the best thing for hardcore AI stuff, but few programmers work on hardcore AI problems.

Your examples are off btw. AutoLisp and Emacs Lisp are embedded languages, not something you'd write a whole standalone app in. It's like saying that if you want to write a spreadsheet, you should use VBA because that's what Excel uses for scripting.

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

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

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

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

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.

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.

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

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact