You made a point. I've been rumbling on this lately, and I'm sharing my current conclusion here to hear HNers' opinions.
Let's consider Common Lisp. Newcomers and outsiders complain that CL doesn't catch up because there aren't free CL environments around with a thoughtless setup (I've been in this camp too). However, if you read comp.lang.lisp, it jumps into your eyes that many lispers are accomplished and sharp programmers. Still, they haven't fixed such "issues" once and for all. So, what's the real deal? I think that here lies an explanation: such issues are not such an issue to experienced programmers. That is, if you can't setup a CL system, you simply are not skilled enough as a programmer. Get over it. I think the same applies to other systems like Haskell, GNU/Linux, Emacs and so on.
What do you think? Thanks.
EDIT: Of course, there are other causes to consider... for instance, since most CL developers work on *nix, there is less work done on Windows. I think that installing a CL environment kind of fires the Law of Leaky Abstractions: you'll have to deal with some nitty-gritty details...
I don't think it works like that. Put enough barriers to adoption (lack of: easy install, good documentation, friendly community, good error messages, bug free implementation, good libraries) in front of your prospective hacker audience and you'll find that adoption will suffer.
Not because they're not experienced enough or because in principle they can't make it work (I'm sure they could) but simply because there is only so much time.
If you haven't reached a certain level of confidence that a path is the right one within a given amount of time the natural thing for an experienced programmer is to abandon the path, after all, there are so many technologies to choose from that you can't afford to invest too much time into something that feels like a dead-end, even if in the longer term it might turn out to be great.
> I don't think it works like that. Put enough barriers to adoption (lack of: easy install, good documentation, friendly community, good error messages, bug free implementation, good libraries) in front of your prospective hacker audience and you'll find that adoption will suffer.
I can see your point, and I agree on principles. I disagree on "good documentation", "friendly community", "bug free implementation", "good libraries"... If there are either lacking of "good documentation" or "bug free implementation" or "good libraries", that just means a language either is academic or not ready yet for production, thus you'd better skip it. About "friendly community", I'd rather say that there are self-selecting communities. For instance, many people complain about "social problems" of Lisp, yet I had a very nice experience while asking even controversial questions on comp.lang.lisp.
> If you haven't reached a certain level of confidence that a path is the right one within a given amount of time the natural thing for an experienced programmer is to abandon the path, after all, there are so many technologies to choose from that you can't afford to invest too much time into something that feels like a dead-end, even if in the longer term it might turn out to be great.
That's why I've resolved to put my time only in both time and battle tested languages like Common Lisp and Erlang.
That is, if you can't setup a CL system, you simply are not skilled enough as a programmer. Get over it.
"Can't" is not at issue here - with enough effort, anyone can do just about anything. The question is whether it's actually worth the effort.
Given a choice between languages A and B, both of which have very enthusiastic userbases that are utterly convinced that their language is the One True Programming Language, but neither of which I've actually spent enough time with to know whether it will be worth the investment, which one will I spend the time to learn to work with?
A smart programmer will pick whichever one gets up and running the quickest so that he can actually see what coding is like in that language, as opposed to configuring/installing/compiling sources/tracking down a supported version/etc. Why waste time doing all that stuff when if you just hop to the next language over you can have it all for free? Not to mention that problems setting up a dev environment are loosely predictive of future problems dealing with deployment, hiring extra hands, getting support when things go wrong, etc...
Common Lisp is getting its clock cleaned by Clojure because the Clojure folks know that lowering barriers to adoption is a critically important thing when people are faced with such a glut of choice.
But then again, I've never gotten the sense that the CL folks actually want more people using it, that community seems to be more than happy to remain an elite insider's-only club that is - obviously - smarter than everyone else. Which explains a lot of the hate for Clojure - it's bringing powerful tools to the unwashed masses, and it turns out they wield them quite effectively, shedding some serious doubt on the implicit assertion that you have to be really, really smart to use any sort of Lisp.
> "Can't" is not at issue here - with enough effort, anyone can do just about anything. The question is whether it's actually worth the effort.
Perhaps I should have said "with little effort", then. If you can't setup a system with just little effort, you are not skilled enough as a programmer. See, Ewjordan, I understand your frustration. I've had my share with setting up "newbie-hostile" systems, and you know what? As a consequence, I now understand better how things work, and I can setup whatever system faster. I have "graduated" from Ubuntu to Debian user, I now use Emacs as my only editor, and so on. Little improvements... Still learning. Oh, and I'm faster at tracking down and fix issues which I or my coworkers stumble upon.
> A smart programmer will pick whichever one gets up and running the quickest so that he can actually see what coding is like in that language, as opposed to configuring/installing/compiling sources/tracking down a supported version/etc.
Would we really call her a smart programmer? A street-wise programmer maybe. Being such a programmer could be your goal? That's fine. Have fun and make a lot of money. I think a really smart programmer will pick the language which will pay more dividends in the long run. Kind of choosing a Vim clone over a regular editor.
> Why waste time doing all that stuff when if you just hop to the next language over you can have it all for free?
Because not all language are created equal and you sometime have to choose between fighting the system in the beginning and fighting the language in the long run.
Of course, you'll have an hear for practical considerations too. For instance, I'm currently learning Common Lisp over Scheme because even if I like Scheme better, CL has a wider user base and a proven track record.
> But then again, I've never gotten the sense that the CL folks actually want more people using it
I agree. Most of them don't seem interested. And I think I understand why. CLers are an old community and a lot of newbies jumped in, whined about things not working and left. Their hears are full. However, if you ask for help and ask for it smartly, you'll get answers, you'll - you won't believe this! - you'll get even code written for you.
P.S.: Sorry, but I don't have time to review this post. Bye.
That is, if you can't setup a CL system, you simply are not skilled enough as a programmer
But these things are unrelated! Your ability as a Lisp programmer is entirely unrelated to your ability as a Windows/Linux/whatever sysadmin/build engineer/whatever. If anything it's the old "it works on my computer" excuse that (bad) tech support trots out. That's the thing that sets the Clojure guys apart, they actually are interested in making it possible to take it for a spin.
I'm reminded of the difference between PADI and BSAC, two competing dive schools. PADI says let's get you in the water as soon as we can, don't worry, it's only a swimming pool and we have instructors and lifeguards on hand, and when you're ready we'll go out to sea and continue learning there. BSAC says study in a classroom for 6 months, then let's go dive a wreck at 50m...
> Your ability as a Lisp programmer is entirely unrelated to your ability as a Windows/Linux/whatever sysadmin/build engineer/whatever.
Are we sure? Isn't this a case of Law of Leaky Abstractions? We may think we can and should ignore issues related to underlying hardware, but reality is we can't and we shouldn't. As programmers we need a bit of knowledge about system administration too, even when we are working on a virtual machine.
Kudos to Clojurers! Maybe there is more enthusiasm and understanding about newcomers in Clojure because it is a new language. That is, the are not under the Curse of Knowledge.
We should acknowledge that Haskellers are trying to meet the needs of newcomers too, by releasing the Haskell Platform.
Yes and no. If you are experienced programmer, then you'll have no problems with "issues". On other hand, why should you waste your time with new language?
Each year there is new programming language or framework that "will change the computing". Oh come on. We all know that Windows will become lousy implementation of Unix. We also know that all programming languages eventually will have half-assed implementations of Lisp features. Why you should learn Haskell when Lisp is more superior?
Let's consider Common Lisp. Newcomers and outsiders complain that CL doesn't catch up because there aren't free CL environments around with a thoughtless setup (I've been in this camp too). However, if you read comp.lang.lisp, it jumps into your eyes that many lispers are accomplished and sharp programmers. Still, they haven't fixed such "issues" once and for all. So, what's the real deal? I think that here lies an explanation: such issues are not such an issue to experienced programmers. That is, if you can't setup a CL system, you simply are not skilled enough as a programmer. Get over it. I think the same applies to other systems like Haskell, GNU/Linux, Emacs and so on.
What do you think? Thanks.
EDIT: Of course, there are other causes to consider... for instance, since most CL developers work on *nix, there is less work done on Windows. I think that installing a CL environment kind of fires the Law of Leaky Abstractions: you'll have to deal with some nitty-gritty details...