----- "Theodore Tso" wrote: > So the critical matter is not the richness of the toolset, or the > number of programmers, or the average performance of the language --- > if you can find a talented Java programmer, who understands > performance issues and who isn't afraid to dive into the dozens of > layers of Eclipse or Java class libraries to understand why some > application class has become O(n**4) --- or heck, understands what the > big-O notation means in the first place (you can write fast, > performant code in any language, just as you can write Fortran in any > language). No, the key is which language you are most likely to find > a large pool of good, talented programmers who are willing to > volunteer for your project; not just now, but also 10-15 years from > now. > I'd suggest that the only programming languages likely to meet that > test are C, Perl, and Python, but what's important is the criteria and > understanding why that's important.
I do agree with this point. 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. 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. -- Ean Schuessler, CTO Brainfood.com [email protected] - http://www.brainfood.com - 214-720-0700 x 315
_______________________________________________ Spi-general mailing list [email protected] http://lists.spi-inc.org/listinfo/spi-general
