<html><head><style type='text/css'>p { margin: 0; }</style><style type='text/css'>body { font-family: 'Times New Roman'; font-size: 12pt; color: #000000}</style></head><body>----- "Theodore Tso" <tytso@mit.edu> wrote:
<br><br>&gt; So the critical matter is not the richness of the toolset, or the<br>&gt; number of programmers, or the average performance of the language ---<br>&gt; if you can find a talented Java programmer, who understands<br>&gt; performance issues and who isn't afraid to dive into the dozens of<br>&gt; layers of Eclipse or Java class libraries to understand why some<br>&gt; application class has become O(n**4) --- or heck, understands what the<br>&gt; big-O notation means in the first place (you can write fast,<br>&gt; performant code in any language, just as you can write Fortran in any<br>&gt; language). &nbsp;No, the key is which language you are most likely to find<br>&gt; a large pool of good, talented programmers who are willing to<br>&gt; volunteer for your project; not just now, but also 10-15 years from<br>&gt; now.<br>&gt; I'd suggest that the only programming languages likely to meet that<br>&gt; test are C, Perl, and Python, but what's important is the criteria and<br>&gt; understanding why that's important.<br><br>I do agree with this point.&nbsp; The tool doesn't provide the talent. I'll take a good team writing in a bad language over the reverse any day of the week.<br><br>I do take issue with the "richness of the toolset" statement. NIH is a crippling disease and I think leveraging a mature code base gets you more bang for the buck than reinventing the wheel almost every time.<br><br>-- <br>Ean Schuessler, CTO Brainfood.com<br>ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315<br></tytso@mit.edu></body></html>