Where my mouth is

Saying Clojure is a counter example kinda ignores the big reason companies don&#x27;t want to use Lisp&#x2F;Haskell&#x2F;etc. When you&#x27;re on the JVM, you get to use that gigantic collection of Java libraries and Java community for almost no downside. With Common Lisp&#x2F;Scheme, so much time is spent reinventing wheels due to smaller communities that they&#x27;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&#x27;t going as planned a couple of years down the line, as CodeHaus did with Scala. Don&#x27;t get me wrong, I think Clojure is by far the best Lisp to choose out there for a product, but that&#x27;s mainly because it has its big &quot;Java ogre&quot; brother standing behind it.<p>edit: And also, you don&#x27;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.

&quot;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 . . .&quot;<p>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.<p>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&#x27;s prayer on the head of a pin more and more.<p>In the end, I started to actually long for a language that had <i>fewer</i> 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&amp;R in which they say that figuring out what to remove is part of the art of creating programming languages (or something like that).<p>There&#x27;s no language in which you can&#x27;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.

Far be it from me to say that the choice of programming language doesn&#x27;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).<p><i>However</i>, I&#x27;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 &quot;more productive&quot; programming language. It is as it should be, because most productive languages, Clojure included, are usually more productive for <i>applications</i> – 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&#x27;d better spend some time picking and learning a language that makes their work easier.<p>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&#x2F;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&#x27;t matter, and you&#x27;re better off sticking with the one(s) you know best.<p>If 95% of your time is spent thinking anyway, it doesn&#x27;t matter if your language can reduce the remaining 5% of actual development by a factor of two or more. IBM&#x27;s Watson would not have come about sooner if its engineers had chosen Haskell over Java.<p>ADD.: &quot;Productive&quot; 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&#x27;t matter. When you&#x27;re handcrafting a magnificent chair, picking the best assembly line is irrelevant. Chances are it&#x27;s been designed to solve other problems and retrofitting it to your requirements is extra work, and even if it wasn&#x27;t, this chair need only be made once. Mass production tools are unnecessary.

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&#x27;t butcher them when someone actually adjusted them well.

&quot;...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&quot;<p>When people say that &quot;programming language doesn&#x27;t matter&quot;, they mean it doesn&#x27;t matter within the broader context of the company. And they&#x27;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.<p>Yes, it&#x27;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.<p>Fixating on a programming language choice is premature (and worse, even irrelevant) optimisation for a whole host of problems that just don&#x27;t affect a startup&#x27;s success <i>that</i> 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&#x27;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.<p>[1] <a href="http://programming-musings.org/" rel="nofollow">http:&#x2F;&#x2F;programming-musings.org&#x2F;</a>

People who are nervous about hiring people in a relatively unpopular language should watch this video[1] at the 1:01.00 mark by Yaron Minsky.<p>[1] <a href="http://www.youtube.com/watch?v=hKcOkWzj0_s" rel="nofollow">http:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=hKcOkWzj0_s</a>

Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue.<p>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.<p>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.<p>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.<p>Finally, having always been a deeply language agnostic developer, I find all these language-religious arguments to be a bit childish and tiresome.

&gt; 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.<p>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.<p>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&#x2F; other various associated frameworks and libraries. So I have little incentive to opt to use Lisp at work, even if given the opportunity.<p>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&#x27;t see that for Clojure, though I really do wish it well. For a language to gain in the job market have, it doesn&#x27;t need to be the best, it has to be fun, easy, and safe enough to use for the ecosystem to grow around it.<p>C++ was more fun than Fortran&#x2F;Cobol.<p>Java was more fun than C++&#x2F;.Net was more fun than Visual C++.<p>Groovy, JavaScript, Python and Ruby are more fun than Java.<p>PhP was more fun than HTML + CGI. Ruby&#x2F;Rails is more fun than PhP.<p><i>Note: when I say &quot;fun&quot; I don&#x27;t mean it in the &quot;challenging&quot; sense of fun like Haskell. I mean writing great, cool things quickly and understanding it easily.</i>

&gt; 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.<p>Does anyone hire with &quot;eager to learn new languages&quot; as a criterion? It&#x27;d be interesting to come up with a technical interview that would test for that. Maybe it&#x27;d go something like: &quot;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&#x27;ve got a half-hour.&quot;

&gt; 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<p>Between JSF, JSP, JMS, JPA, JTA, JCA, JMX, JNA, servlets, SecurityManager, AWT&#x2F;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&#x27;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&#x27;s hit the supply nail right on the head.<p>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.