
Where my mouth is - momo-reina
http://jao.io/blog/2013/06/19/where-my-mouth-is/
======
mynameisme
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.

~~~
lalc
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?

~~~
threeseed
The best Java libraries from my perspective are the ones for large scale
projects. You can leverage proven techniques and technologies.

e.g. [http://twitter.github.io](http://twitter.github.io) or
[http://netflix.github.io](http://netflix.github.io)

~~~
Derbasti
Is it a syntax error to talk Java without playing buzzword bingo?

"Leverage proven techniques and technologies"? What does that even mean?

~~~
threeseed
What do you mean what does it mean ?

Leverage = take advantage of

Proven = demonstrated to have worked

Techniques = using one approach versus another

Technologies = existing code

~~~
Derbasti
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.

Jesus, I hate this kind of language.

~~~
roblev
I think the OP's point was clear, Java has a big library of tested, debugged,
robust libraries.

------
sramsay
"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.

~~~
tikhonj
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.

~~~
sramsay
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 . . .

------
pron
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.

~~~
plinkplonk
"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).

[1] [http://blog.reddit.com/2011/02/ibm-watson-research-team-
answ...](http://blog.reddit.com/2011/02/ibm-watson-research-team-answers-
your.html)

~~~
pron
I consider MATLAB the thinking, or drawing board stage, to be followed by
final implementation in Java or C++.

~~~
plinkplonk
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.

~~~
RogerL
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.

------
hnha
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.

------
nemesisj
"...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.

------
momo-reina
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.

[1] [http://programming-musings.org/](http://programming-musings.org/)

------
gnuvince
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.

[1]
[http://www.youtube.com/watch?v=hKcOkWzj0_s](http://www.youtube.com/watch?v=hKcOkWzj0_s)

~~~
Cyranix
Imprecise transcript:

    
    
      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.

~~~
gnuvince
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.

------
sklivvz1971
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.

~~~
wiml
> Language choice is mostly a reliability, sustainability, maintainability and
> team-scalability issue

Yes, but aside from that, Mrs Lincoln, how was the play?

------
educating
> 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._

~~~
mgkimsal
You nailed it.

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.

------
derefr
> 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."

------
brianpgordon
> 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.

------
microcolonel
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.

------
davexunit
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.

