The future of Lisp...
12monkeys.co.uk
12monkeys.co.uk
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.
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?
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.
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?
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.
>> 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.
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.
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?
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.
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.)
You may have said you wanted to use Jython. Spelling does make a big difference in this case.
But most implementations address those issues and there are even libraries that expose those features in a uniform way across implementations.
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.
I like CL, but I do think that its age is a distraction; people have a hard time getting past that sometimes.
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?
meta-optimizing semantic evolutionary search -> Common Lisp
duh.
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.
* 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.
It has worked before with:
CAD application -> Autocad Lisp
Text editor -> Emacs Lisp
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.
Sorry if we value being over pretending to be...
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.