What feature would you most like to see in Lisp?

[Kompottkin]

Having a supported threading API would be a great improvement.

Doesn't Portable Threads work? Granted, I've never used it, but it looks nice, and hey, it's even documented! What more can one wish for?

[dmitry_vk]

Doesn't Portable Threads work? Granted, I've never used it, but it looks nice, and hey, it's even documented! What more can one wish for?

It works. But it is just one of a couple of portability layers. And I don't feel too well mixing libraries that use different portability layers for the same thing. They might have some things implemented differently, slightly different semantics (e.g., do newly created threads inherit dynamic bindings?), slight incompatibilites, etc... Like, e.g. if I create a thread with clim's threading, can I use it with bordeaux-thread?
Having an agreed spec would resolve this.

[Ali Clark]

Not sure which has the best support, but from the cliki threads page at http://www.cliki.net/thread

Bordeaux-threads seems to support a couple of implementations and was last updated in July.
http://common-lisp.net/project/bordeaux-threads/

[Wodin]

I'd like to have standardized support for threads. Having threads is a must for many things: for web-apps, for GUI apps (actually, for almost everything except command-line apps). There is threading support in many implementations, but API and semantics differ. Having a supported threading API would be a great improvement.

Or perhaps threads are the wrong answer :)

The Problem with Threads

[Unne]

That link about threads is interesting, because it's exactly the problem Clojure claims to (try to) solve. I'm not sure I've drunk the Clojure Kool-Aid yet and I don't have enough experience in concurrent programming to form a very well-informed opinion, but based on what I do know and what I've seen, it looks good.

I'm finding that most of the other things I've ever wanted from a Lisp are already in Clojure too...

• Libraries in abundance. It's hard to beat Java in that department. As Kompottkin said, a well-established, high-quality, cross-platform GUI library already exists for Java, thus it also already exists for Clojure. Clojure also has officially-supported Qt4 and OpenGL bindings. And a mature standard threading library and socket library and so on. And it's all as well-documented as you could ever hope for.
• Cross-platformness and an avoidance of the "which implementation should I pick?" problem in Common Lisp. Clojure runs the same anywhere the JVM runs. This also helps with the "how do I deploy this app?" problem. I don't have to worry about whether ADSF works right on Windows, because Java packages essentially work the same everywhere.
• A benevolent and wise dictator. It's highly arguable whether this is a good thing, but I think it is. Rich has an overall vision and it helps the language end up more unified and directed. Clojure isn't being written by a committee, and that's a really good thing in my mind. There's no widespread "implementation-dependent" or "undefined behavior".
• Modernity. "It's there for historical reasons" is such a common phrase when you talk about Common Lisp, and it's understandable, but Clojure doesn't have to care about backward compatibility. A lot of the warts and sharp corners of Common Lisp can be sawed off when you redo it all from scratch. New features can be added, crappy features can be removed, broken features can be fixed. This is a benefit of any young language but it's a nice one.
• More Ruby-ish/Perl-ish features like pretty literal arrays and hashes and regexes. The collection system in Clojure is awesome. Common Lisp has arrays and hashes but they aren't as first-class as lists. Clojure arrays/hashes/sets/lists are all equal members of society.

And so on. Much of the above is subjective, but Clojure hits most of the things on my list.

[findinglisp]

...Clojure hits most of the things on my list.

I think Clojure gets a lot of things right, but I'm not totally sold. In particular, using the JVM was, IMO, the wrong way to go. I know Rich has strong reasons for doing so, and getting libraries in play was good, but I have never seen another language take off when it's tied to the runtime of yet another language. Jython and JRuby are interesting, but not the dominant versions of those languages, even with some ability to use Java libraries, etc. You can see some of the negative aspects of using the JVM when it comes to the loop syntax. Because Rich doesn't control the underlying runtime, he had to create something that's a bit twisted, IMO, to deal with the limitation of not having proper tail recursion.

[Unne]

It's a question of Clojure + JVM, or Common Lisp + Windows/Linux/OS X/others + a C compiler. Either way you're tied to and limited by your platform. How many Lisps have threading on Windows right now? How many even work cross-platform at all? How many libraries do? Look at ASDF for a good example of the bad side of using an operating system as your platform rather than a VM. The JVM has a very good compiler and garbage collector; how much time has been spent re-inventing those things for all the various Lisps? They're free in the JVM, and already mature and fast and stable and work on any OS.

There are tradeoffs though, yeah. Clojure is tied to a product that's largely under the control of a mega-corp. (Java is open source nowadays, but I would imagine forking Java just to run Clojure on it might be a bit impractical.) But the admittedly nasty loop/recur is a small price to pay for all the benefits of a nice VM, in my opinion. It's not much worse than throw/catch or labelled-block returns in many languages, and in Clojure you could hide loop/recur with macros if you wanted. The JVM may be getting tail-call optimization, in which case Clojure will get it too. Sun seems to be moving to make the JVM better for dynamic languages, so maybe your concerns are more valid in theory theory than in practice. For now.

Jython and JRuby are bolted on to the JVM as an afterthought, and yeah, they'll never be as popular as the canonical C versions of themselves. They have to go through contortions to get the JVM to work like the C versions. Clojure is designed for the JVM, so it's not competing with itself, and it can work more smoothly and integrate more fully with Java than Jython/JRuby ever could.

[findinglisp]

It's a question of Clojure + JVM, or Common Lisp + Windows/Linux/OS X/others + a C compiler. Either way you're tied to and limited by your platform. How many Lisps have threading on Windows right now? How many even work cross-platform at all? How many libraries do? Look at ASDF for a good example of the bad side of using an operating system as your platform rather than a VM. The JVM has a very good compiler and garbage collector; how much time has been spent re-inventing those things for all the various Lisps? They're free in the JVM, and already mature and fast and stable and work on any OS.

Whether Lisps have threading on Windows right now is purely a function of their implementations and whether that's important to them. Remember that many of the Lisps out there are based on very old implementations that have literally been in existence for decades (CMUCL -> SBCL, KCL -> ECL, MCL -> ClojureCL, etc.). In many cases, the primary implementations were built for Unix which have had very scatter-shot threading support. Put all that together and you have a mess that's going to take a while to work out. Threading support is starting to happen in standard Lisps, but it's admittedly a mess. Nobody screams about this fact more than I do.

A better comparison might be between other dynamic languages like Perl, Python, and Ruby, which all run on Windows with threading today (typically with green threads today, but threads all the same). Given these other languages, I'd just propose that any lack of features on Windows for Lisp is a self-inflicted problem, nothing inherent to not using the JVM as a foundation.

Actually, however, Armed-Bear Common Lisp (ABCL) does use the JVM.

There are tradeoffs though, yeah. Clojure is tied to a product that's largely under the control of a mega-corp. (Java is open source nowadays, but I would imagine forking Java just to run Clojure on it might be a bit impractical.) But the admittedly nasty loop/recur is a small price to pay for all the benefits of a nice VM, in my opinion. It's not much worse than throw/catch or labelled-block returns in many languages, and in Clojure you could hide loop/recur with macros if you wanted. The JVM may be getting tail-call optimization, in which case Clojure will get it too. Sun seems to be moving to make the JVM better for dynamic languages, so maybe your concerns are more valid in theory theory than in practice. For now.

Actually, I think you have that backwards. The concerns are valid in practice now. There is no debate that Clojure had to compromise functionality and syntax in order to fit within the limitations of the JVM. If Sun fixes the JVM (and I'm sure they will, but I'm making the point), then Clojure has the opportunity to fix some of that. Over time, I have no doubt that Clojure will get better, but it will always be subject to the limitations that Sun puts on the system. Whether that's a problem in the long term remains to be seen. Again, I have nothing fundamentally against Clojure or the tradeoffs made in creating it. Indeed, I think it's a splendid piece of work and there is much that Lisps in general can learn from its new and interesting features. The JVM thing just gnaws at me.

Jython and JRuby are bolted on to the JVM as an afterthought, and yeah, they'll never be as popular as the canonical C versions of themselves. They have to go through contortions to get the JVM to work like the C versions. Clojure is designed for the JVM, so it's not competing with itself, and it can work more smoothly and integrate more fully with Java than Jython/JRuby ever could.

So, two things... First, it isn't competing with itself, but it is competing with other Lisps. It will have to distinguish itself to gain long term momentum. Second, it can "work more smoothly and integrate more fully with Java" because it accepts the limitations of the JVM as a given and re-labels them "features." In other words, it's a two-way street on JVM compatibility.

Boiling this down some... Clojure is a (Faustian?) bargain: if you're willing to accept some compromise in functionality to deal with limitations of the JVM, you'll get a language with Lisp syntax that runs the same everywhere the JVM runs and can take advantage of Java libraries. That's it. Whether that excites you or not depends on whether you're cool with that compromise.

All that said, if it was me working in a Java shop and I wanted to slip in a little Lisp, I'd probably reach for Clojure or ABCL to get the job done. That would be an externally-imposed limitation, however. I don't think I'd set that limitation for myself if I had the option.

[Unne]

Whether Lisps have threading on Windows right now is purely a function of their implementations and whether that's important to them. Remember that many of the Lisps out there are based on very old implementations that have literally been in existence for decades (CMUCL -> SBCL, KCL -> ECL, MCL -> ClojureCL, etc.). In many cases, the primary implementations were built for Unix which have had very scatter-shot threading support. Put all that together and you have a mess that's going to take a while to work out. Threading support is starting to happen in standard Lisps, but it's admittedly a mess. Nobody screams about this fact more than I do.

But that's what I mean by theoretical concerns vs. practical concerns. Any implementation COULD have all the things I mentioned on my list, in theory, but how many do right now? I don't have a while to wait for things to sort out, so what are my options if I want to quickly and easily write a cross-platform multithreaded GUI app this afternoon? Not 2 or 10 years from now? That's why Clojure is exciting to me. Lack of those features is a self-inflicted problem in CL that could be fixed in theory, but it's still a problem, and Clojure solved it. Maybe it's not ideal, but at least it's a solution that exists right now.

Actually, I think you have that backwards. The concerns are valid in practice now. There is no debate that Clojure had to compromise functionality and syntax in order to fit within the limitations of the JVM.

What are some other specific examples of functionality and syntax compromises besides loop/recur that are due to limitations of the JVM? Maybe there are some I'm not aware of. I don't know the JVM itself that well. I know that most of the many horrid limitations of Java don't exist in Clojure at all.

So, two things... First, it isn't competing with itself, but it is competing with other Lisps. It will have to distinguish itself to gain long term momentum.

I think Clojure has potential to attract people from Java as much as attract people from other Lisps. The set of Java developers is a lot larger than the set of Lisp developers, so maybe Clojure has a chance even if it's rejected by Lispers. People using Java right now are the ones really in need of dire help anyways. It also has potential to attract people like me who desperately want to use Lisp but who find Common Lisp to be showing its age and lacking in many areas.

[Ali Clark]

It also has potential to attract people like me who desperately want to use Lisp but who find Common Lisp to be showing its age and lacking in many areas.

Are the problems in CL really too much to solve retrospectively? Surely the language itself wouldn't prevent CL from adopting things from more modern languages? By that I mean, if CLOS could have been added inside the language, then why couldn't the same be said for modernisation?