Looming Lisp Boom?
groups.google.com
groups.google.com
No one denies the power and goodness of Lisp. Also, everybody knows its issues
1) misconceptions based on its history (it's a slow, AI language)
2) portability issues among implementations (pathnames, sockets, GUI, etc
3) lack of standard implementation
#1 is a marketing problem - tractable with effort (just look what pg's essays alone have done). #2 is a coding resource problem - many hands make light work.
For #3, once there is a platform implementation with all the right features (threads, unicode), this problem goes away. If CLisp added threads or if SBCL worked on Windows, the game would be over - other implementations would continue but there would be an unambiguous choice for n00bs. De facto portability standards would form around that implementation and the burden would be on other implementations would make it compatible with the de facto winner.
I'm not invested in any of the implementations but it looks to me like SBCL is the closest to being the full featured, cross platform, open source implementation that is currently lacking. So as a pragmatist wanting Lisp to become bigger, I have three choices:
1) through my writing, encourage people to choose SBCL
2) contribute coding help to the SBCL windows port
3) whine
Most people choose #3. I'm not confident in my coding chops to do #2, so I'm focusing on #1. I have the time and ability to write well and I hope to add momentum to the front runner and make choices easier for new users.
Of course, the foolproof way is for someone to make something indispensable using Lisp so people can't help but adopt it (like Unix/Linux did for C).
-see also Bill Clementson's take on this from a couple years ago http://bc.tech.coop/blog/060403.html
> "I believe that the lisp boom won't come before there is a canonic open source implementation and a canonic repository for libraries."
I wouldn't argue there should be One Right Way, but it'd be nice if there was a Fairly Standard Way. Even Ruby, which has an official implementation, has several other implementations that exist in parallel, so it's not like picking CLisp or SBCL to be the flagship would doom the others. Power users are still going to appreciate choice, but it'd be nice to have a default that does everything for us noobs.
Oh wait that is REALLY being done.
Perhaps for this reason Lisp became an individualist, niche language.
My impression is that non-coding bosses don't care that much, or, they care enough to recommend what they read in trade journals. Solution: Talk up Lisp (etc) in trade journals. That java is a standard because it is "dumb" is a myth. Not one CTO in a million went through a catalog of languages and said, "Nope, this has closures. Nope, this has eval()..." Otherwise, they would have come to, "Nope, this has garbage collection... We're sticking with COBOL."
* Trade journals, as you said, which appeal solely to the corporate bosses; although I'd give this a lower importance among others.
* Wages and availability of programmers in the job market.
* A chance for the boss to understand the language and/or to talk about architecture on the meetings easily, if needed. This one is interesting, as, I think, that's the main reason Java is popular. Smarter bosses can read some semi-technical journals, where "patters", "methodologies" and "common practices" are explained well for them -- just for them.
So, Java clearly wins in all 3 points, while Lisp loses in all 3.
* Corporation to blame for its problems and shortcomings.
And, just to play devil's advocate: There may actually be some benefits to coding in a constrained, regimented manner. Sure, you need to write more code to do the same thing, so an individual programmer isn't able to tackle as large a project as he would be able to in a less-constrained language. But a more constrained language is more amenable to automated analysis and may make it easier for people to work together or maintain one another's code: Lisp may allow an individual programmer to express his thoughts in a manner that is clearest to him, but it might not be as clear to others. But if you use a language that forces everyone to think the same way, then you end up with a less-concise program that perhaps more people can understand.
And, for the vast majority of projects, a highly constrained language is all you need. For most workplaces, even a language like C++ is too powerful; they will add a host of self-imposed constraints like "RAII", "no global variables" or "don't overload operators", and they may use lint-like tools to enforce these constraints.
...Or, so the argument goes. Whether or not it bears weight depends on the relative value of having many people on a project versus having a few people who are more productive... or whether it is easier for other programmers to understand more concise code versus more constrained code. I'd argue that the lack of Lisp companies dominating their competitors favors constrained code, but there is a circularity in that argument that I don't like.
The prevalence of DSLs in Lisp code poses an interesting counterpoint to Greenspun's Tenth Rule: Any sufficiently complicated Lisp program contains an ad-hoc, informally specified subset of a declarative language. :)
DrScheme's language levels, where constrained languages help beginners avoid the strange error messages one gets by accidentally invoking an advanced language feature, are unique, as far as I know. Correct me if a learning tool for any non-Lisp language has succeeded in implementing the same sort of thing. Otherwise, I think it's obvious that if you have specific desired constraints for a limited language, some kind of Lisp is your best bet.
The short answer - don't hold your breath.