6 ms·

The future of Lisp...

42 points by hassy 18y ago

icey 18y 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.
- deleted 18y ago
  [deleted]
- hassy 18y 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 18y ago
    Obviously meta-optimizing semantic evolutionary search -> Common Lisp duh. http://code.google.com/p/plop/ http://code.google.com/p/plop/
  - Hexstream 18y ago
    Big problem --> New DSL --> Common Lisp
    - greendestiny 18y ago
      And without the generalities?
    - gaius 18y ago
      I think most new DSLs are either Ruby under the hood, or extensions to Tcl or Guile.
      - Hexstream 18y ago
        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.
        gaius 18y ago
        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.
  - icey 18y 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.
    - nihilocrat 18y ago
      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".
  - dimitar 18y 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 18y 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
    - hassy 18y ago
      > 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.
Kaizyn 18y 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 18y ago
  I've not heard of that. Can you provide more info on how/why the standardization process happened prematurely?
  - Hexstream 18y 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.
    - rbanffy 18y ago
      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 http://{$language}.org. Smalltalk suffers from the same problem - too many different implementations, and no obvious path to follow.
      - Hexstream 18y ago
        Just use SBCL. Problem solved. It's a great implementation with a big following among Lispers.
        rbanffy 18y ago
        It took me a while to get to that decision.
ramchip 18y 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.
Hexstream 18y ago
"the community is not making an effort to make CL seem cool." Sorry if we value being over pretending to be...
- hassy 18y ago
  my point is you are, but few people are aware of it.
jstraszheim 18y 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 18y ago
  Clojure, my friend. You may have said you wanted to use Jython. Spelling does make a big difference in this case.
miked 18y 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 18y 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 18y ago
There's also Factor, which is pretty much becoming a postfix Lisp.
- jamesnvc1 18y 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 18y 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 18y ago
  I had no problem getting Clojure running on Eclipse. I much prefer emacs though.
pg 18y 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 18y ago
  Because Lisp has about a million pounds of stigma attached to it.
  - deleted 18y ago
    [deleted]
  - pg 18y ago
    Even at current exchange rates, that's a lot of money.
- megaduck 18y 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 18y 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.
samuel 18y 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).
- eru 18y ago
  Yes, PLT-Scheme is nice.
- hassy 18y 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.)
JulianMorrison 18y 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.

42 points by hassy 18y ago

icey 18y 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.

deleted 18y ago
[deleted]
hassy 18y 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 18y ago
  Obviously meta-optimizing semantic evolutionary search -> Common Lisp duh. http://code.google.com/p/plop/ http://code.google.com/p/plop/
- Hexstream 18y ago
  Big problem --> New DSL --> Common Lisp
  - greendestiny 18y ago
    And without the generalities?
  - gaius 18y ago
    I think most new DSLs are either Ruby under the hood, or extensions to Tcl or Guile.
    - Hexstream 18y ago
      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.
      - gaius 18y ago
        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.
- icey 18y 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.
  - nihilocrat 18y ago
    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".
- dimitar 18y 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 18y 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
  - hassy 18y ago
    > 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.

Kaizyn 18y 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 18y ago
I've not heard of that. Can you provide more info on how/why the standardization process happened prematurely?
- Hexstream 18y 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.
  - rbanffy 18y ago
    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 http://{$language}.org. Smalltalk suffers from the same problem - too many different implementations, and no obvious path to follow.
    - Hexstream 18y ago
      Just use SBCL. Problem solved. It's a great implementation with a big following among Lispers.
      - rbanffy 18y ago
        It took me a while to get to that decision.

ramchip 18y 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.

Hexstream 18y ago

"the community is not making an effort to make CL seem cool." Sorry if we value being over pretending to be...

hassy 18y ago
my point is you are, but few people are aware of it.

jstraszheim 18y 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 18y ago
Clojure, my friend. You may have said you wanted to use Jython. Spelling does make a big difference in this case.

miked 18y 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 18y 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 18y ago

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

jamesnvc1 18y 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 18y 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 18y ago
I had no problem getting Clojure running on Eclipse. I much prefer emacs though.

pg 18y 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 18y ago
Because Lisp has about a million pounds of stigma attached to it.
- deleted 18y ago
  [deleted]
- pg 18y ago
  Even at current exchange rates, that's a lot of money.
megaduck 18y 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 18y 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.

samuel 18y 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).

eru 18y ago
Yes, PLT-Scheme is nice.
hassy 18y 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.)

JulianMorrison 18y 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.