<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
On Wed, 2009-02-25 at 08:35 +0000, Rob Charlton wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Michael Richter wrote:
> Why do you think people stay away from functional programming
> languages in droves?
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
The reason nobody has asked this is that for one of several reasons the
answer is fixed in advance:
1) The development team is a team of programmers who know X
2) We are writing a system for operating system Y for which the only
applicable language choice is X
3) We are extending / improving product Z which is written in X and
we're not about to re-write it
4) The CTO is a fan of language X and has already hired X experts to get
the job done
5) The engineering manager wants to play it safe, follow the herd, and
develop the system like "everyone else does", using language X
6) We are doing work for a customer, and the customer says use language X
</PRE>
</BLOCKQUOTE>
<PRE>
</PRE>
To me this is answer #3 from my original post: the needs of the user.
<OL TYPE=1>
<LI TYPE=1 VALUE=1>If the development team is most familiar with/capable of X, then X is the only rational choice in a competitive (read: non-academic) environment. Time to market kills quality dead in almost, but not quite, all business situations.
<LI TYPE=1 VALUE=2>Again this is a user need. The choice was made because their (presumably rational) choice of platform dictated their choice of language.
<LI TYPE=1 VALUE=3>No expansion needed.
<LI TYPE=1 VALUE=4>This is a variant of your 1, albeit a variant that is unfortunate.
<LI TYPE=1 VALUE=5>This is similarly a variant of your 1, one that is less unfortunate. It is a relatively sound engineering principle to go with proven technology unless the proven technology proves incapable of the task.
<LI TYPE=1 VALUE=6>Again this is a user need. Presumably the customer in question is using one of your six explanations in their own decision.
</OL>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
There is a rock solid business case for picking Erlang in a lot of
circumstances which the CEO/CTO/CFO/Engineering manager could be
convinced of I'm sure, but they would have to put aside the
considerations above which may not be possible.
</PRE>
</BLOCKQUOTE>
<BR>
You get no disagreement from me on this. I would never choose Erlang for any of my embedded work nor my device drivers back when I did those two. But for a lot of my software I'd have murdered my own grandmother in a slow and gruesome fashion to have access to something like Erlang. (The closest I got was using QNX for a while whose message-passing style made me understand and appreciate Erlang instantly on contact.)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
For my own company, we started using Erlang because we believed in the <BR>
ideas in Joe's thesis paper and wanted to give it a try. We can't use it <BR>
for all our work: the Symbian OS development that we do pretty much <BR>
dictates C++ and Lua, Blackberry dictates Java, other embedded phone <BR>
work dictates C. But our server products can be written in whatever we <BR>
like. And we like Erlang :)<BR>
</BLOCKQUOTE>
<BR>
And I am insanely jealous. Trust me. <IMG SRC="cid:1235555301.30881.39.camel@isolde" ALIGN="middle" ALT=":D" BORDER="0"><BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> <<A HREF="mailto:ttmrichter@gmail.com">ttmrichter@gmail.com</A>> (<B>GoogleTalk:</B> ttmrichter@gmail.com)<BR>
<I>When debugging, novices insert corrective code; experts remove defective code. (Richard Pattis)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>