Saying Clojure is a counter example kinda ignores the big reason companies don't want to use Lisp/Haskell/etc. When you're on the JVM, you get to use that gigantic collection of Java libraries and Java community for almost no downside. With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities that they're not worth using for larger projects, in my opinion. Also with Clojure, you always fairly easily port to Java if you decide things aren't going as planned a couple of years down the line, as CodeHaus did with Scala. Don't get me wrong, I think Clojure is by far the best Lisp to choose out there for a product, but that's mainly because it has its big "Java ogre" brother standing behind it.
edit: And also, you don't need to write Java in a factories on top of factories style just because some choose to do that. The same is even more true of xml configuration.
> With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities
I'm not sure, but I think that C and C++ ecosystem has at least the same amount of libraries available as Java. And the reason why I mention this is that many Lisps have FFI which makes integrating those libraries almost seamless. Aside from Gambit-C, which compiles Scheme code to C and so supports inline C code, for example Racket has very nice DSSL for FFI, which reduces the need for glue code to one or two lines of code per imported function.
Integration with native Java libraries is easier from JVM languages, of course, but then there are many Lisps for JVM too. And for CLR, where tail call elimination exists. So if you want to write in Lisp, but are worried about lack of libraries, you really have many options. Clojure is alright, but saying that it's the only choice if you need access to libraries is not quite true.
I have to admit I'm ignorant as to what Java libraries I'm missing out on by not using a JVM language. I hear about this advantage a lot though! What are some examples of good Java libraries that aren't as good in other common languages?
....to name a few. It's probably useful to take some thing that you'll need and look in ecosystem X for it (say... .NET) and then compare what's available there to what's available on the JVM. In my experience, the JVM wins out almost every time when it comes to number of options and maturity of options.
Thank you for linking this. English is a second language to me, and reading that list i found i've been following those rules a lot and have been getting grumpy about people who didn't and made it difficult to understand them. Now i can point those people at that essay.
Right..... So you're saying that your code works? Like, it doesn't crash? That's... awesome...
Buzzword bingo does not add value. It only obscures meaning. Of course your code works. Of course you use existing technologies. That work. In existing code. That you leveraged. Using techniques. And technologies.
He was saying many other people have contributed java libraries his programs can use, so that he doesn't have to hire an expert in HTTP, or computational geometry, or many problem domains that aren't the direct concern of his application, yet are necessary for it to work.
He said it in a compact way. It's a form of compression.
These are only the relatively new additions, and there are really too many to count. I would certainly add the JDK's java.util.concurrent to the list, as well as Netty and the excellent servlet containers (Tomcat, Jetty, JBoss and others).
I think the point is that most of the time when you think "I need something that does x", there is a library for that; whether it is a core library or not. In Lisp I guess you often find something very specific that doesn't quite solve the problem you have.
Having said that, I really liked the Google Guava library, although a good bit of that stuff is working around or solving problems with Java itself.
Guava is fantastic. So many times in the last few years, I've pointed people to Guava in code reviews "hey, this thing you just wrote, Guava already has that."
If you're using another "common" language, you're probably not missing out on anything. The distinction he was making was between Java and a "not common" language, like Common Lisp, for example.
That doesn't explain the original adoption of Java, though. Put a billion dollars of marketing into Clojure and see where that gets you. Just the marketing effort alone. Do you guys remember all the managers, directors, secretaries taking Java courses because it was going to change everything? Java rode a big wave of stupid that was the internet boom.
Wish I could up this one more. I am in the process of playing with Lisp (in my case, Common Lisp, the SBCL variant to be specific) and I would love to see people with production services in any Lisp, or even Scheme.
I have been very attracted to the idea of Lisp, specifically as I discovered teepeedee and teepeedee2 as being some of the first truly fast web servers [0], and now I found wookie,[1] an evented web server running on top of libevent. I really want to play with that.
The closest thing I know of to people running "prod services on Lisp" are the Untyped guys in the Racket Scheme community [2], and not much else. I know pg and company became famous on Viaweb and Lisp, but since then there are scarce examples. However, the amount of bitching libraries and cool books (pg's book included) make me want to buck the trend and do it anyway, even if no one watches and I end up in my own ditch writing code to dig my way out for the all the unstable or non-existent pieces of code waiting for me.
The Lisp Hackers interviews are also a good resource and quite interesting. The use case I found the most surprising was a developer using CL to prototype chip ideas at Intel before implementing them in C or C++. All the interviews in one book can be found here: https://leanpub.com/lisphackers
Thanks for the list (pun kind of intended). I am well aware of Emacs (who does Lisp without SLIME, that seems painful) and Autocad.
Your list is very cool, but I meant people writing production web services and startups that are often featured here. Of them all, the most interesting one I saw a month or so ago was someone writing production services in Haskell. That generated a lot of interest, and I have not heard of anyone brave enough to do it with a Lisp, save Clojure.
I was unaware of Jak and Daxter, but I would hope people who use Common Lisp, manage their packages in Quicklisp, and do other CL stuff know what Quickdocs. I am in that camp. :-)
Lispworks is an excellent commercial IDE as well, however its editor is not as nice (but similar to Emacs) as using Emacs itself and the license is quite expensive compared to other IDEs/toolchains, but it offers greater code introspection than what is available in SLIME.
Personally, I use SLIME + Emacs as I do not do enough CL development to warrant dropping over a thousand USD for a license and I find SLIME good enough for my usage.
"I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career . . ."
I am absolutely with you there, but after writing a reasonably serious, production-level system in Clojure, I suddenly realized a fatal flaw in this and in many other hip and cool languages. It is very, very difficult to write clear, readable code.
I accept that it might just be my lack of skill, but as the stuff I was writing became more complicated, I found myself writing the Lord's prayer on the head of a pin more and more.
In the end, I started to actually long for a language that had fewer language features -- something that allowed far, far less flexibility in the way ideas are expressed. C is far from perfect, but more and more I see the wisdom of one of the early statements in the K&R in which they say that figuring out what to remove is part of the art of creating programming languages (or something like that).
There's no language in which you can't write unreadable gibberish, granted, but some of these newer languages make it damn hard to write non-trivial programs that are easily read by others.
C has quite a few features, and the language design is pretty arbitrary. (Yes, it's often based on (old) hardware, but then hardware design is pretty arbitrary.)
I haven't used Clojure much, so I'll mostly talk about Scheme. I suspect the two are similar in all important ways.
If you look at the matter critically, you'll find that Scheme (and, I suspect, Clojure) are actually simpler and smaller languages than C. Neither has nearly as much syntax. There is far less undefined behavior. C has way more corner cases than Scheme: there are a ton of C quizzes out there which basically nobody can solve; I couldn't imagine much of that for Scheme. You just have to memorize the relatively obscure rules for what types get automatically coerced to each other.
C has whole classes of hard-to-solve bugs that other languages simply do not. Bus errors, segmentation faults, buffer overflows... All the exposed low-level details obscure the meaning of the code; unless they're important to your application, they just make your code harder to follow.
Moreover, common C idioms (some of which are just workarounds for missing features) make code much harder to follow than it should be. Thanks to the use of out parameters, you never really know where the result from a function is, without reading the documentation. I recently wrote some code that depended on ioctl--that single function sometimes returned the result as the return value and sometimes modified fields inside the struct you passed into it! Hard to follow is an understatement. Errors are signalled as integers instead of some semantically meaningful data type.
Of all the languages I know, C is the one that makes it the hardest to write non-trivial programs that are easily read by others. I suspect you're just making the common mistake of confusing familiarity for some sort of innate quality.
I don't really mean to defend C (though I rather like it, despite its many flaws). I only meant to point out the wisdom (which I recall reading in the K&R) of this idea that "taking away" features might make it easier to read and debug -- and maybe even write -- programs. In fact, Scheme is a sterling example of that very principle (relative to, say, Common Lisp, and I would argue of Clojure as well).
I agree with you about Scheme, which is a very minimalistic, wonderful, eminently readable, "one way to do it" language. But Clojure has something that Scheme doesn't: a massive set of libraries. C has that as well.
That, of course, is a different subject entirely . . .
At least it's not C++, where out parameters are often written as references, which appear exactly the same as normal arguments, rather than usually having a telltale &. :)
"a language that...allowed far, far less flexibility in the way ideas are expressed"
that is a design goal of Java, and it turns out that "everything is a class" is a really expensive way to write software. As in large systems take thousands of man-years and $100MM and contain AbstractFactoryFactoryProviders. Not because the engineers are bad, but because that's what you end up with when everything is a class.
Sometimes, Scala codebases are criticized because they use monads or have too many arcane unicode symbols in them. But I'll take scalaz over AbstractFactoryFactoryProviders any day. At least scalaz makes sense.
Yes, absolutely. Anyone can add features to a bloated language. The most beautiful designs know what to leave out and why. C was one of those designs.
If you like the C design aesthetic, you should check out Go. It's like a garbage collected and yes, memory-safe version of C, which substitutes composition for inheritance and goroutines for threads.
Far be it from me to say that the choice of programming language doesn't matter, or that picking one slightly off the trodden path is not a sign of a certain openness of mind. I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career (with Julia giving it a run for its money if only it had been implemented on top of the JVM as well).
However, I've seen a clear inverse correlation between the magnitude of technical challenge and the emphasis on the choice of programming language. It is usually web application developers that spend the time and effort picking what they deem to be a modern, or "more productive" programming language. It is as it should be, because most productive languages, Clojure included, are usually more productive for applications – not complex basic algorithms, or the development of novel data structures. Application developers spend 90% or more of their time writing and debugging production code, so they'd better spend some time picking and learning a language that makes their work easier.
But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about. If your challenge is not translating a business model into code, but solving a real algorithmic or technical problem, then the programming language really doesn't matter, and you're better off sticking with the one(s) you know best.
If 95% of your time is spent thinking anyway, it doesn't matter if your language can reduce the remaining 5% of actual development by a factor of two or more. IBM's Watson would not have come about sooner if its engineers had chosen Haskell over Java.
ADD.:
"Productive" programming language are better when you need to solve the same problem over and over (say retrieve data from a database and generate HTML). But when your problem is more or less one-of-a-kind, these productivity boosts either disappear or don't matter. When you're handcrafting a magnificent chair, picking the best assembly line is irrelevant. Chances are it's been designed to solve other problems and retrofitting it to your requirements is extra work, and even if it wasn't, this chair need only be made once. Mass production tools are unnecessary.
I feel precisely the opposite way. I used to work on developing network algorithms. Our simulations used C++. It was phenomenally unproductive, because in addition to the inherent difficulty of the problem, you had to deal with the limitations of the language. Its a pain to debug C++ in a straightforward "move bits around" app. Its even more painful to get distracted by stack smashing bugs when you're trying to figure out the emergent behavior of a complex algorithm.
Which language would you have preferred? Most other languages where such bugs would be handleded by the language tend to be a lot slower. (I'm saying that as a Perl developer who occasionally has to write C because Perl won't cut it for a decent algorithm.)
There are a host of languages > 20% as fast as C (Common Lisp, Haskell, Java). I would have preferred Common Lisp but would have settled for Java. Once you're within a factor of 2-3 of C, speed rapidly becomes less important than other things except in limited circumstances. I wouldn't write an h264 decoder in Lisp, but short of that...
Ah, thanks for the answer. I was mostly curious since i work with things where algorithms need to perform in realtime, so even a factor of 2-3 is unacceptable.
Yes the Lisp > Blub argument is usually presented with the assumption that the opposing argument is that Blub > Lisp or at least that Blub = Lisp. In fact the argument is actually that Blub provides access to a vast ecosystem of algorithms written by world class programmers, each specialized in their particular domain, and therefore it's actually mathematics and algorithms (via Blub) > Lisp and self-implementation of those algorithms; or you could restate that as the efforts of scores of world class programmers > than my own efforts. Perhaps Clojure settles that gap by linking a Lisp to the JVM ecosystem, but historically that wasn't the case in these arguments.
Neither my intuition nor experience lead me to the same conclusion as you.
My intuition says that complex algorithms get even more advantage from more expressive languages. Java and C++ are usually not counted among the more expressive languages.
My experience on two* different projects in very complex domains...one where we used Java and another Clojure was that the Clojure code was more approachable and modeled the domain in an easier to understand way.
Just my 2 cents.
* One project was in the field of power systems, modeling and predicting power flow through the distribution end a power network.
* The other project was doing personalized treatment recommendations based on analysis of genetic data.
Might I add that a good tool, a good programming language, let's you think about other things than implementation detail. It let's you express things in a more direct and concise manner.
Very smart, very forward thinking people might choose Java or C/C++ because they don't want the extra effort of learning/using a new programming language. But it certainly doesn't mean it's the better choice. Lisp was for example developed explicitly for the use in artificial intelligence by John McCarthy, a very forward thinking and smart person who greatly advanced the field of AI.
I would say that when your problem is a one-of-a-kind, you'd rather think about the problem at hand and think of the implementation as little as possible.
> But it certainly doesn't mean it's the better choice.
If picking something else had the same cost, then you're absolutely right. But if implementing the production code is 6 months out of a 5 year project, even a language that is 10x more productive but takes 3 months to be proficient in (let alone to master), then it's just not worth it.
> I would say that when your problem is a one-of-a-kind, you'd rather think about the problem at hand and think of the implementation as little as possible.
Yes, but this line of reasoning may lead to Clojure, for example, in the application case and to, say, Java in the algorithm case. In the latter you play around in MATLAB for a long time; translating it later to Java is often a very technical process.
"But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about. If your challenge is not translating a business model into code, but solving a real algorithmic or technical problem, then the programming language really doesn't matter, and you're better off sticking with the one(s) you know best."
This is so true. They often use something like MATLAB or R, but that doesn't affect your essential point, which is a great one and worth thinking about. How much of what you encode is original/cutting edge thought vs routine (CRUD apps) say.
That said, that particular blade cuts both ways. There is nothing (other than inertia) stopping the "one(language) you know best" being something reasonably advanced, with decent, if not ubiquitous libraries and tooling, like Scala or Clojure or OCaml, or even Common Lisp. Why would you want to use an 'inferior' language if you know a better one? So in the end this argument may just devolve to "Most engineers in charge of implementing systems are more comfortable with Java/C++ than Clojure/OCaml".
Something of medium complexity, between the basic CRUD web app and pioneering projects like Watson, like the (Twitter)Storm library for e.g ,is much easier to do in Clojure than in Java, though it uses many java libraries (e.g: Apache Zookeeper) under the hood.
So we have $baselang for basic webapps, $coollang for medium complexity efforts, and back to $baselang for truly cutting edge work, where thinking effort outweighs coding effort. An odd dynamic, if true.
" IBM's Watson would not have come about sooner if its engineers had chosen Haskell over Java."
This is a strong claim :-)
Even IBM Watson might be easier in Haskell,(it actually uses Java, with "significant chunks" in C++ and Prolog [1]) but someone actually needs to build something like this first. FP proponents should probably focus on building existence proofs of cool systems than resort to argument (imho).
> Why would you want to use an 'inferior' language if you know a better one?
I really hate this idea because it implies that one language is completely inferior to another in every way. For example, I have heard: "Why use C when you can use C++?" The two languages often serve different purposes. There are few languages that give you as much control over performance and memory management as C. C is lightweight enough to go onto basic 8-bit microcontrollers with 64kb of memory. That is not to say that C is the ultimate language or anything, but that different languages have different strengths/weaknesses. Another simple example would be C# which is great if you have no need to deploy to anything other than windows. In conclusion the answer to your question is that someone had a particular need which was best suited to one language and thus are more comfortable in it which is why they want to use it for their next project.
"Inferior" is probably really bad wording. Let's say "more advanced". If you know C++ you will have no problem accommodating with C if it better fits your need. If you know Scala you can still program in Java if your stuck with it for whatever reason.
I write both C and C++ on a regular basis. The set of idioms used in C is radically different from what you'd find in C++ (even though a lot of C code is valid C++). When I first started working on C projects written professionally (after quite a bit of experience with C++), I was seriously thrown off by things like reinterpreting structs to treat the first element as a parent structure (essentially emulating inheritance in pure C code).
> If you know C++ you will have no problem accommodating with C if it better fits your need.
While I understand what you mean, the two are completely different. The lack of OOP in C means that you have to have a different set of programming methodologies to accomplish what you would have done with classes. So, while knowing C++ helps, it isnt the same as if your 'main' language were C.
Furthermore, one of C's strengths is it predictability. The way that is accomplished in C is different than C++.
You're fooling yourself if you think it gets that far! The grant runs out and you end up putting the MATLAB version in front-line action, complete with entire pages of code commented out: FIXME.
True, but the complication is that people building the final production system /choosing the implementation language, OS etc (engineers) are not usually the people who use MATLAB or R.(Computer Vision Researchers, say).
There might be a few (rare) people who can do cutting edge research and do production grade engineering, but I'd be surprised if this were the default for the average team member, even for a system like Watson.
That fits my interviewing experience for computer vision. Tons of people that work in MATLAB or OpenCV, throwing it over the wall to 'production'. That's not terribly appealing when you are already limiting what you can do because your CPU/GPU is running at 100%. Not too many that can actually engineer a working, performant solution.
"But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten"
This may be a reflection of the fact that people who write code, but are not really programmers, lack sufficient domain knowledge (in the field of programming) to choose anything other than the "default" choice. It's harder to go off the beaten path when one knows little about the surroundings. That doesn't mean the path is optimal though.
C++ gives you fine grained control over the machine, which is something these fields often need (I am in the computer vision/AI segment). When you are using Intel Intrinsics, MKL, etc., just to get enough performance to barely do the job, you can't afford to throw that control away to garbage collection, reference counting, and all that. I use higher level languages for the things they are great for - the 'batteries included' features of Python, for example, or the functional+high availability of Erlang. And they are great languages for what they are designed to be used for.
Not every C/C++ programmer (I say with considerable understatement) is an obsolete, corporate hack unaware of the state of the art in computer languages and tools. We wrote your compilers, your languages, your VMs, your toolsets, your OS, your math libraries, your, well, you get the idea :)
1) The issue at hand is about the choice between mainstream languages vs. niche languages. Your reply does not address this and sidetracks into a discussion about native languages vs. high-level languages.
2) Even assuming every decision to use C++ was an optimal one, what about the decision to use Java?
This may be a reflection of the fact that people who write code, but are not really programmers, lack sufficient domain knowledge (in the field of programming) to choose anything other than the "default" choice.
While this could sometimes be the case, that's mostly because they have other things to think about. Spending time on choosing and learning new languages (with their libraries and communities) can be rightly considered a manufacturing optimization. That's really important to people whose job it is to manufacture at scale, but not necessarily to those dreaming up new components. These are two different jobs. When you deal with manufacturing, you're expected to spend a lot of energy on picking the absolute best tools. But if you're handcrafting something completely different from most of what's out there, your tools and process don't matter as much. The path doesn't need to be optimal if you're the first to take it to a new destination. If you don't know if you can even get to where you're going – or if there's anything there at all – spending money on the best shoes is a premature and unnecessary optimization.
I think reducing a million lines of code by a factor of two is a huge win. Reducing it by half and having the extra type checking in Haskell would be even better. Heck, I'd also take the super fast complilation in Go with the equivalent million lines. Bottom line is that when you're dealing with that much code, those little wins do add up.
It is usually applications that have so many lines of code. Also, as others have mentioned, availability and quality of existing libraries matters a lot. It is better to link to a 1 MLOC library rather than write and debug 100KLOC yourself. Finally, tools (debuggers, profilers) often matter more than the language.
Also, these wins come at a cost (learning curve, immature implementation), which isn't worth it if more than 90% of your time is spent at the drawing board anyway.
Yes.. It reminds me of a recent interview with matz:
"The ones who do not challenge themselves to create new things are often falling behind - they learn a hip new language today and try a new web framework tomorrow, but still lack the foresight to invent and to improve."
My experiences would tend to agree with you; I worked at The MathWorks (makers of MATLAB) for a while, and I was a little surprised when I noticed that the hard-core devs who developed the guts of the language (parsers, JIT, data structures, math libs) worked purely in C++ often using EMACS or VI, and only rarely would launch a dev MATLAB GUI. I suppose it makes sense that if you're working deep in the internals, all that matters is properly handling all the possible inputs that your function can receive and not really how those inputs get there - that's the job of other teams further up the call chain :) I still found it an interesting lesson.
But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about.
Yes and no. There are a few things to keep in mind.
First, these fields have a lot of finesse for which there's no substitute for years of trial-and-error. What's the right learning rate for a neural network? (There isn't one; real NN implementations have varying strategies for adapting the LR, but even picking the right one of those requires knowledge both of how NNs work, and the data itself, since noisier data means there won't be monotonic learning progress unless one trains over the whole set-- and that's usually impractical.) What this means is that programmers tend to have a longer lifespan and you don't see as much tech churn.
Also, most machine learning programmers use different languages for exploration and production. For the former, Python, R and Matlab seem to be the favorites. For the latter, C and Java are the traditional incumbents, though I could see Scala or Clojure breaking in. Making Clojure performant isn't elegant, but (a) it's not worse than writing Java or C++, and (b) the same is true of Common Lisp. Typically, though, production machine learning doesn't (or shouldn't) have a high LOC-count, especially because most ML projects are there to do things that would sprawl into unmaintainable complexity if done by hand (e.g. speech recognition).
Clojure won't replace C for low-level system programming that requires manual memory management, but even in machine learning, that doesn't apply to most of the work-- remember: half your time will be spend looking for patterns or exploring methods, many of which won't work-- unless you're working at a very large scale. For most of ML, the performance-intensive part is linear algebra, and you usually will end up using wrappers around Lapack (which is in Fortran) for that.
What I would say about the higher end of programming is that engineers care more about "the right tool for the job" and less about "the tool I like best". They're less wedded to one technology stack, so they're willing to use Java if it's the right language for their problem. They're definitely not your typical Java jockeys, though.
ML is a great example since, as you mention your bottlenecks are likely solved by hanging your hat on Lapack and getting out. The complexity of the application derives from data manipulation and feature selection. The first is a definite win for higher-level languages and the second... might be, but is really too large a hodgepodge of techniques to say.
I'm personally beginning to find that Haskell is really nice for this situation because it helps me separate stupid-programming-bugs from improper-algorithm-implementation-bugs very efficiently. This saves a lot of time when I'm looking at the output of a high-dimensional, non-deterministic program and wonder what might have gone wrong.
And I've written some Clojure ML code that was quite close to Java speeds several years ago. For ML, you're either going to get the answer immediately or be waiting a while. As long as your constants for language choice aren't 2x-5x it's not a big deal. When everything is Fortran anyway, the constants aren't 2x-5x.
Machine learning is also, by a big margin, the most common of the areas I've mentioned and is therefore best positioned to benefit from "mass production" efficiency tools. It is moving from the master shop to the factory floor.
I kind of disagree with this. I think there are huge needs for "better language" kinds of improvements with ML that gives insight into how various pieces in a pipeline get combined, how tuning happens, how feature generation relates to input data. I don't consider ML to be terrifically repeatable today due to a lot of non-standard low-level tweaking that goes on at the top levels of work there.
I think it's definitely moving, but I don't think it's nearly as mechanized as, say, AES is, given that the tradeoffs one needs to balance are significantly more complex. You can't just Machine Learn something as much as people may try.
oh come on mods. this was well titled. you removed the mention of lisp, leaving the title as guesswork about the contents. there is no rule for keeping original titles. please don't butcher them when someone actually adjusted them well.
"...and was finally in a position to really influence our development decisions at every level. Even at the most sensitive of them all: language choice"
When people say that "programming language doesn't matter", they mean it doesn't matter within the broader context of the company. And they're right. Language choice is never the key to success for the reason for failure that we in the tech field might wish it was.
Yes, it'll matter to programmers to some extent, but just like the author talks about how quality programmers will be open to new language choices, those same programmers will be open to getting things done, regardless of language.
Fixating on a programming language choice is premature (and worse, even irrelevant) optimisation for a whole host of problems that just don't affect a startup's success that much. Things like finding the best people, getting customers, and scaling will always be the harder, more critical aspects of running a successful company.
Jao's old blog[1] is a treasure trove of information. Modern Lisp hackers like him, Zach Beane and Edi Weitz are great representatives for the Lisp community: incredibly talented and yet very humble and more than willing to help out those just starting out in Lisp.
Q: Are you convinced that you're more successful
because of OCaml?
A: <jokingly> I certainly have job security! But
seriously, I think the answer is yes, for many
reasons that are difficult to tease apart. One
of the big reasons is that it became easier to
hire great programmers. We hired many great
programmers before we switched to OCaml (and
they have since adopted OCaml) but it took more
effort to find them than it took to find great
functional programmers. It's hard to describe
how significant the effect was, but I believe
it was important; our language choice impacted
our tools and results in a positive way.
Oops, that's not the passage I was thinking of. I'll try to find it again, but basically he says that when they needed to hire programmers, instead of using a site like monster.com or jobboom.com, they went on the OCaml mailing lists, posted the offer there. They got a few responses (~15 I believe?) and of those, 10 were worth a phone interview and 5 were worth flying in to NYC for a face-to-face interview. I think they ended up hiring 2 or 3 of those candidates. He described the process as being very easy because 1) OCaml programmers are interested in working with OCaml, 2) the typical OCaml programmer is better (or at least more curious) than the average programmer, because they went ahead and learned a relatively unpopular language that's unlikely to help them get a job in 99.9% of workplaces.
Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue.
I agree that people can learn, bugs in the language can be fixed, lack of libraries can be worked around and unknown pattern space can be navigated.
As with any choice this is a trade off, in this case between time and convenience. Those ugly C-like languages have tons of cheap or free libraries, support communities with real, large scale experience and so on. Smaller languages are much more of an adventure - fun with company (your own?) money. It is not the correct choice in many cases.
None of these problems seems to matter in the beginning, when the team is small and awesome, but they do massively matter later on. The author seems to completely avoid this point, and I urge them to consider it.
Finally, having always been a deeply language agnostic developer, I find all these language-religious arguments to be a bit childish and tiresome.
> Deep down, the people in charge either didn’t think languages make any difference or, worse, bought into the silly “availability of programmers” argument. I’m still surprised anyone would believe such a thing. If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years, no matter what language my project were using, and no matter how many thousands of candidates like this one i had at my disposal.
The problem is not willingness to learn, the problem is the risk of going into a job, becoming less fluent in a language for which there are more job opportunities, and then being able to get paid as much or more with the new skills they learned.
I am very interested in learning Clojure, Scheme, Lisp. But, these languages do not provide job security unless I want to move. Companies want .Net (C# or VB), Java, and JavaScript- w/ other various associated frameworks and libraries. So I have little incentive to opt to use Lisp at work, even if given the opportunity.
I was a long time Java developer, but have been using Ruby for the past several years. It is really not as easy to find Ruby jobs locally as it is in Java or .Net, but I think it will be worth it because the # of Ruby jobs is growing. I don't see that for Clojure, though I really do wish it well. For a language to gain in the job market have, it doesn't need to be the best, it has to be fun, easy, and safe enough to use for the ecosystem to grow around it.
C++ was more fun than Fortran/Cobol.
Java was more fun than C++/.Net was more fun than Visual C++.
Groovy, JavaScript, Python and Ruby are more fun than Java.
PhP was more fun than HTML + CGI. Ruby/Rails is more fun than PhP.
Note: when I say "fun" I don't mean it in the "challenging" sense of fun like Haskell. I mean writing great, cool things quickly and understanding it easily.
Company X chooses... ocaml, in this case. Someone taking a job there either needs to know it already, or have a 'willingness to learn'. OK - I'm willing to learn it, but at what expense? I dig in to ocaml for a few years, get really good at it, and find, say, 4 years from now, that the market for ocaml developers is really bad. I've gambled and lost, even if it "paid off" for the company.
Most developers are making rather rational choices, regardless of what tech company founders would like to think.
I do run in to people who are ".net or die" and "java for everything", and they'll never ever consider bothering to learn a new tech stack. And... they chose wisely enough that they may not have to over the next 10-15 years - almost anything you'll want or need to do for a large majority of computing/development needs will probably have .net/java equivalents (whether they're the best implementations or not is irrelevant to these people). But... choosing Haskell as a sole focus... they may end up having to uproot a family to move to another location to get another equivalent Haskell job in a few years, which most people don't want to have to do.
> Give me programmers willing to learn and eager to use Lisp or Haskell (or Erlang, ML, OCaml, Smalltalk, Factor, Scala...) any day, even if we happen to be using C++, for goodness sake! Those are the ones one needs, scanty as they might be.
Does anyone hire with "eager to learn new languages" as a criterion? It'd be interesting to come up with a technical interview that would test for that. Maybe it'd go something like: "Okay, I trust you got the email yesterday with the syntax of the three languages we made up for the purposes of this test--Blub, Cruft, and Wheeze? Good. Now, we want you to code A* in Blub, and then translate this code sample from Cruft to Wheeze. You've got a half-hour."
> If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years
Between JSF, JSP, JMS, JPA, JTA, JCA, JMX, JNA, servlets, SecurityManager, AWT/Swing, and countless other frameworks and technologies, Java is so big that it would take an entire career to become an expert. I think it's reasonable for someone who has invested a lot of their career in getting experience in some of these things to want to continue working in Java rather than let those skills go fallow.
I think he's hit the supply nail right on the head.
Programmers which are more costly are more productive(as a general rule), so finding a few highly-productive professionals willing to make the right decisions, is better than hiring a gaggle of newborns who figure public static is the only way to initialize data.
Jao is awesome. He is the author of Geiser, an Emacs mode like SLIME for GNU Guile and Racket. Geiser is an invaluable tool when working with Scheme. Best of luck to him.
edit: And also, you don't need to write Java in a factories on top of factories style just because some choose to do that. The same is even more true of xml configuration.