<br><div><span class="gmail_quote">2007/4/14, jm <<a href="mailto:jeffm@ghostgun.com">jeffm@ghostgun.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

There are quite a few pages and blog entries around by people advocating<br>one language or another for various reasons. What I'm wondering is: Are<br>there any academic articles evaluating the selection of a programming

<br>language as part of business strategy? I've managed to find a few papers<br>about Information Systems, etc and business strategy including one<br>journal almost devoted entirely to the subject, but am unable to find

<br>anything specific to language selection. This seems strange as the US<br>DoD developed Ada and Ericsson developed Erlang in response in part to<br>business needs. If anyone knows of any good references please send them

<br>my way.<br></blockquote></div><br>It's probably more accurate to say that Erlang was developed in an Ericsson<br>laboratory in response to a perceived technology need. Bjarne Däcker's<br>thesis gives some good background on this:

<br><br><a href="http://www.erlang.se/publications/bjarnelic.pdf">http://www.erlang.se/publications/bjarnelic.pdf</a><br><br><br>It also mentions that Erlang was banned in 1998, due to perceived business needs.<br>(For the newcomers, this ban preceded, and in part justified, the launch of 

<br>Open Source Erlang.)<br><br>I agree with Thomas that essays like "beating the averages" give an interesting<br>angle on this question. Large companies will also worry about the cost of <br>diversity and lock-in effects. This is most likely much less of a problem in 

<br>small companies.<br><br>For large companies, aspects that will have measurable consequences include:<br><br>- Cost of training support staff in several different technologies, since different <br>  products are developed differently

<br>- Difficulty in aligning user interfaces and documentation, since products do<br>  not share a common implementation base.<br>- Re-training costs when moving developers from one project to another<br>- Difficulty in moving product development responsibility from one design

center to another. - Difficulty in finding third-party suppliers and consultants for obscure   technologies. - Risk that a niche technology folds during the life of the product, forcing   an expensive redesign.

<br><br>Some would also want to include the need to use mainstream languages <br>since this is what job applicants are looking for, but I think this is largely<br>a phallacy, even though in a narrow perspective, the argument does seem

<br>to hold some merit.<br><br>Now for the problem: If you're looking to invest, say, $100 million in a <br>product development project, wouldn't you want to try to eliminate the <br>above challenges, if possible? And knowing how many other factors 

<br>influence the success of a large development project (large = more than<br>100 people involved), it is difficult to convince investors that betting on <br>some obscure technology (be it a programming language, an ASIC,

<br>cabling, or what have you) is actually going to give measurable benefit<br>in terms of faster time to market, lower cost, higher quality.<br><br>After all, the name of the game for large companies is _not_<br>programming brilliance, but being predictable and responsive in

<br>the eyes of large customers, and being able to deliver and support<br>product over many years all over the world.<br><br>Again, many of these problems are specific to large companies, and <br>Graham's "Beating the averages" holds that small companies cannot

<br>afford average performance, and thus have to be better and smarter<br>than the big companies. By avoiding many of the pitfalls of choosing<br>niche technologies, they may "safely" choose them and benefit from 

<br>the higher productivity of using sharper tools.<br><br>I saw a video of Steve Ballmer talking to people at (I think) Harvard.<br>He was talking about the four phases of a company:<br>1) You have an idea, and try to bring it to market

<br>2) You manage to get foothold, and milk it for all it's worth<br>3) You try to establish a culture for coming up with a new (1)<br>4) You recurse.<br><br>He said most companies never get past (1), while large companies

<br>are typically doing (1)-(4) simultaneously.<br><br>We often talk about programming language selection as if it were<br>all about (1), but if one could do a real life-cycle analysis, it might<br>even impress someone.<br>

<br>BR,<br>Ulf W<br>