

Programming language choice - sometimes there is none. - RiderOfGiraffes

Over in the discussion of this topic:<p><pre><code>    http://news.ycombinator.com/item?id=901101
    Seven Languages in Seven Weeks
    http://rapidred.com/blog/seven_languages
</code></pre>
people were talking about how useful it is for programmers to know non-mainstream languages.<p>jlgosse said:<p><pre><code>    http://news.ycombinator.com/item?id=901335
    I love that you are supportive of random
    languages! I feel bad for you because you
    will never find a job working in any of
    those languages.
</code></pre>
In the reply, dschobel said:<p><pre><code>    But there's a high correlation between
    companies which trust their programmers
    to use the right tool for the job and
    companies which "get it" (*it* being how
    to develop and maintain technology).
</code></pre>
This is absolutely true, but there are two main points I'd like to make.<p>Firstly, the real benefits in having knowledge of (but preferrably experience and skill in) other languages, is not getting a job using them.  The real benefit is to <i>you</i>, the programmer, having more ideas, knowledge, tools and skills under you belt.  Even if you only ever program in C++ or Java or PHP, learning Lisp or Haskell or Prolog or Lucid will make you a better programmer.  No longer will every problem look like a nail, because no longer will you only have a hammer.<p>Along with that, though, is the questionof experience.  Reading about these techniques and ideas doesn't really help, you have to use them for real to get the benefit.<p>In medicine there is the mantra "See one, do one, teach one."  It applies equally in programming.<p>Secondly, a point about companies employing programmers.  When tendering for a contract in my field, it is often required that the bidder attest to the fact that the system is written in ...<p><pre><code>  &#62; a well-known, mainstream language that
  &#62; supports modern programming techniques.
</code></pre>
They then usually add a phrase that makes it clear that they mean C++, and if your system isn't written in C++ then you won't pass the first phase of reviews.<p>You, as I do, may howl and rage at such short-sightedness, but there are industries where such things are stated in contracts.<p>For example (and this is <i>not</i> my area) can you imagine supplying an Air Traffic Control system written entirely in Scala?  Technically it may be a brilliant choice, but in the ultra-conservative world of ATC (and other safety-critical fields), systems written in what they will see as an untried, untested language, by programmers who by necessity only have a year of experience <i>in that language,</i> are a dangerous experiment.<p>"Nobody ever got fired for buying IBM" is still a prevailing mantra, only now it's about langauges, as well as hardware.  You can't supply anything other than COTS (Commercial off-the-shelf) hardware, by which they mean PCs.<p>In the fast-paced, nothing is the same week-to-week world of web development and web-based applications it doesn't matter, but in my world it does.<p>I just thought it might be interesting for some of you to hear about a different context.
======
RiderOfGiraffes
Clickable:

<http://news.ycombinator.com/item?id=901101>

<http://rapidred.com/blog/seven_languages>

<http://news.ycombinator.com/item?id=901335>

------
ErrantX
The ATC example is probably fairly bad one - because the real reason they
would want it in C++ is that there are a bazillion very good C++ programmers
they can grab to fix stuff in emergencies.

Finding a solid Scala programmer in a pinch is less easy

(we do some work on Bank software and they do the same thing pretty much)

~~~
RiderOfGiraffes
Summary: The point stands - the customer sometimes demands C++.

(Note: I am the OP - it's my example.)

I think you are supporting the example - the point you make is a large part of
the ATC reasoning. Customers demand that their systems are written in a
language that they feel confident they can, in a pinch, take over and hire
programmers to fix. They believe they can do that for C++, they don't know
anything about anything else.

We also have to put code in escrow for this very reasons. We have to provide a
package that can be put on a stock piece of hardware and then build the
deliverable. Then the auditor checks that the code "looks reasonable," at
which point the repository is put on some external device and locked in a
safe.

They believe that if it's in a language they've heard of, and have heard is
popular, then they can go out and hire programmers to work on the code if they
ever have reason to do so.

~~~
ErrantX
No my point was that if a critical bug appears in the system and you, the
original contractor, has dropped off the radar (or whatever) they stand a much
higher chance of finding someone to fix it.

This is what we do for Bank software; they find a critical flaw that needs
fixing and it is our job to hunter-killer for it and work with their team to
nail it and integrate the solution.

I agree with the point you were making; just I felt the example was more
driven by a different need (one very specific to that piece of software)

(or look at it another way there is much more likely to be a C programmer with
experience in ATC software, an important sub-skill in this case, than a Scala
one :D)

~~~
RiderOfGiraffes
I suspect we are in "Violent Agreement". I also believe the chances of
finding, say, a good enough Scala programmer to fix this software that has a
problem are actually higher than the chances of finding a good enough C++
programmer to fix this other software that has a problem.

I have no evidence, the reasoning is outlined in my other comment. I suspect
we agree on all major points, and that things should be better than they are.

------
tybris
I'm just going to repeat it until every programmer in the world gets it:
context is everything.

~~~
bonsaitree
In truth, most of this conservatism is cultural rather than driven by any cost
or fundamental technical issue.

Though heavy exceptions do apply when dealing with system call interfaces to
hard real-time kernels used in avionics software and medical applications such
as heart pacemakers.

