Looming Lisp Boom?(groups.google.com)
groups.google.com
Looming Lisp Boom?
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/79ade0f0e4232fe2/5a46764b5073dfd3
21 comments
On the topic of SBCL:
A few days ago I downloaded SBCL 1.0.13 on my WinXP laptop and have been playing around with it to get back into Lisp. So far its worked to go through some exercises. I'm using Paul's "ANSI Common Lisp" book which I needed for one of my CS programming classes years ago. Last serious Lisp programming I did was at Interleaf, when they were Interleaf, so I've got a lot of cobwebs to brush off. I've got some specific tools I want to implement, so I'll probably run into issues with the incomplete port and if I can carve out the time, have no problem helping out.
SBCL seems to work pretty well on Windows, but it doesn't have threads on Windows. As far as I know, no Common Lisp has native threads on Windows. I think Allegro and Lispworks have their own threading systems, but can't make use of more than one CPU/core.
I agree wholeheartedly about your #3 (lack of standard implementation). For me, the most insightful line in the OP was:
> "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.
> "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.
Yep. It'll probably happen in conjunction with The Year Of The Linux Desktop.
Is that before or after Duke Nukem Forever?
Lisp will hardly ever make it into the corporate hierarchies, where non-coding bosses want you to write in the dumbest possible language. And unfortunately without conquering this market a true boom is impossible.
Perhaps for this reason Lisp became an individualist, niche language.
Perhaps for this reason Lisp became an individualist, niche language.
non-coding bosses
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."
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."
pg said it best "The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it."
From my experience in different companies, big and small, decisions are made based on the number of factors:
* 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.
* 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.
How about another one that also applies to open-source software:
* Corporation to blame for its problems and shortcomings.
* Corporation to blame for its problems and shortcomings.
Instead of "dumbest possible", I'd say "most constrained".
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.
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.
Agreed, and looks like the competition between bigger groups of replaceable people vs. smaller groups of brighter people will keep going in this industry for decades, until something changes from the roots, if at all.
You seem to be advocating DSL's, which is incidentally one of the strong points of Lisp.
Granted, DSLs are easily expressible in Lisp, but pretty much anything is expressible in Lisp. If you want some sort of guarantee that your DSL is limited in some way, you would need to write additional Lisp code to enforce those constraints. But if the constraints map nicely to the constraints in a more limited language, you get the constraints effectively for free by choosing the limited language, while trading off the power of Lisp.
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. :)
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. :)
If and only if the constraints map nicely. Otherwise you're out of luck.
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.
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.
Change the dates on this thread from 2008 to anything from 2000-2007 and you can find a thousand other threads just like it on c.l.l.
The short answer - don't hold your breath.
The short answer - don't hold your breath.
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