

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

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

------
pg
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
Because Lisp has about a million pounds of stigma attached to it.

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

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

------
jstraszheim
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
Clojure, my friend.

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

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

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

------
Kaizyn
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
I've not heard of that. Can you provide more info on how/why the
standardization process happened prematurely?

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

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

~~~
rbanffy
It took me a while to get to that decision.

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

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

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

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

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

------
Hexstream
"the community is not making an effort to make CL _seem_ cool."

Sorry if we value _being_ over _pretending to be_...

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

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

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

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

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

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

