I suspect LISP is too unstructured for its power. It's very hard to scale something to more than one programmer or to a large size in a completely free-form dynamic language. It's easy to blow off other peoples' feet, and totally dynamic languages with many contributors to a project often yield an unmaintainable rats' nest of mixed metaphors and hacks.

Java is one of the most successful languages for massive projects because it imposes a set of common idioms and semantics. Look at Eclipse... an absolute monster but a living, breathing, and pretty darn successful one.

I can't imagine Eclipse in Ruby or JavaScript, let alone LISP... not with the number of contributors it has. It would melt into a puddle of slag not unlike the "corium" that forms at the bottom of a melted-down nuclear reactor.

For those dismissing this as FUD and ignorance: LISP, despite its power, isn't really used for much. I think there has to be a reason for that, and I don't think "everyone is dumber than me" is a valid reason. There are tons of outstanding programmers, and the majority of them do not choose to code real-world stuff in LISP.

I suspect Ruby, which is fairly powerful but not as freeform or succinct as LISP, is more successful because it has more structure around its power. It seems to have enough structure to make large long-lived code-bases possible in the "real world." (But like I said I'm still skeptical that you could write Eclipse in Ruby.)

The question is: would it be possible to build enough structure or tooling around LISP to fix this problem? Could something like Light Table with deeper refactoring and visualization tools deliver a workable LISP environment for modern large applications? I know there were things done in the past during the "80s AI era" that might bear re-examination and resurrection.

>(But like I said I'm still skeptical that you could write Eclipse in Ruby.)

Why would anyone ever want to write Eclipse in Ruby? I have no doubt that such a feat is possible, but... why? If you're using Ruby, a monstrous IDE like Eclipse is unnecessary. If Java didn't exist, there would be no reason for Eclipse to exist, either.

There's a feedback loop. You're pointing out that Java is popular because of massive software projects, which is true, but the converse is also true--massive software projects are popular because of Java.

Eclipse was just an example. There is going to be a niche for massive projects. There's also going to be a niche for projects that live for a very, very long time and thus are touched by a massive number of programmers... which presents many of the same problems as a massive project.

Code reuse is also problematic without structure. C++ has this problem to some extent, which is why the C++ library ecosystem is so fragmented. I typically avoid using most C++ libraries, preferring C++ as high-level glue with C underneath. STL is used because it's standardized, and maybe boost, but that's it. Every C++ library has a different style, so if you use them your code ends up looking like crap... mixed metaphors everywhere. C++ isn't powerful in the same way as LISP, but it is pretty darn powerful in its own way. It lets you do things umpty-different ways, which is bad sometimes.

Common styles and idioms are very useful when you want to connect things to each other.

Ruby and NodeJS have solved this problem by having a certain amount of community standardization around idioms-- convention over configuration basically. (Or in this case convention over language restriction.) Perhaps that's one thing that could help LISP-- an attitude of "yeah, you can do it that way, but that's not standard so nobody will use your code if you do." I know it would really help the C++ ecosystem.

That niche and Java deserve each other.

There's also going to be a niche for projects that live for a very, very long time and thus are touched by a massive number of programmers

There's some overlap, but more than anything, this niche is just the one that really needs a solid unit test suite and documentation. There are excellent unit test framework packages for Ruby, and high unit test coverage is very much a part of Ruby programming culture. The documentation quality for open source Ruby projects also seems very high overall.

Community style/idiom standardization in Ruby and Node is probably a function of having a constellation of very active, popular, and often interdependent open source projects in each. When you're writing Rails gems that depend on other Rails gems, everyone is reading everyone's code, so agreeing on some style guidelines as a community makes everyone's life much easier.

I think that if someone wrote a very popular open source project (analogous to Rails) in a Lisp dialect, we might see the same thing start to evolve. And I think we're already starting to see it happening with Clojure. There's a Clojure Style Guide that's gone up on Github very recently: https://github.com/bbatsov/clojure-style-guide