Rue the day...

[Donn Cave]

Quoth Steve Arnold <sarnold at arnolds.dhs.org>:
...
| In a sense, a language is just another tool (albeit, a rather
| important one) and you should generally choose the right tool for
| the right job.  The practical answer to this is dependent on both
| the tools the programmer is familiar with, and the project 
| requirements.
...
| However, I have seen too many projects (most of them in the millions 
| of $'s range) have trouble because of a poor choice in languages and 
| tools (and lack of SE knowledge, no process, etc, etc).  This 
| happens mostly because some management dweeb only hears industry 
| hype and propaganda (can you say Java?), and many programmers seem 
| actually afraid of learning another language.  IMHO, a competent 
| programmer (and any software engineer) should not care if he/she 
| already knows a particular language or not.  They should be good at 
| what they do regardless.

Note an apparent contradiction at the first clip point and the second.
At first, which tools the programmer is familiar with does matter, then
later he or she shouldn't care.  Which is it?  I personally like to
mess around with new languages (or I used to anyway, recent experiences
with a couple of modern interpreted languages make me wonder), but it
seems to me you were right the first time.

There's an interesting essay out there somewhere (should be accessible
from one of the main Erlang sites) from a consultant who was brought in
to rescue an Erlang shop that had sort of gone off track through their
unfamiliarity with Erlang's OTP system.  As I remember it, the reasonably
high productivity of Erlang itself gave them a false sense of confidence
that led them to write off OTP as something they didn't need.  The
consultant came in, set them straight on that matter and their project
was eventually back on its way to greatness.  The moral of the story varies -
hire that consultant, take OTP seriously even though it's a lot to learn -
but at any rate if you buy the basic argument, a software engineer who
casually takes on a new language for his or her new project is asking
for trouble, bound to make mistakes like that.

Obviously there does have to be some movement, or we'd all be working
with assembly language, and I'm sure that programmer conservatism
often goes beyond what's productive.  Those last two sentences just
sounded a bit too glib, and what's worse, they're too similar to the
phrasing used by C++ et al. advocates - if you're a professional
software engineer, you should be able to use whatever tool.  If it
has dangerous or awkward weaknesses, you're supposed to know them and
account for them as appropriate - are you a professional or not, so
what's the problem?  I don't think that's realistic.

	Donn Cave, donn at u.washington.edu