On 24/10/09 23:08, Iain Barnett wrote: [..]
If you're in business, you're trying to keep your costs lower than your income. That means that a language with a stable code base, good/many libraries, and a large pool of developers is a good choice.
I'm not sure it necessarily means that. There is a good case to be made for choosing a good, but obscure language, on the basis that the people who have bothered to learn it are likely to be self-motivated, enjoy the language, and quite likely be clever. Having a smaller pool of developers to choose from is not necessarily bad, as long as it is offset by a higher ratio of first-rate developers. Also, as I'm sure you've found out re libraries, more isn't necessarily better. I'd argue that many, if not most, commonly used libraries are excellent for "common" tasks, but as soon as you go into a niche many fall short of your requirements for scalability, speed, resource usage, etc. In the end you're likely to have to put considerable work into writing your own or modifying other's.
These things mean getting quicker to market, cheaper developers, and you can replace a developer if one leaves. No use having fancy pants code if you can't find anyone who understands it.
You get what you pay for, if you have extreme requirements in any area you'll have to pay well in order to get good developers who can handle the task. In my experience good developers don't produce "fancy pants code", they'll produce code that is easier to understand and maintain. The fancy parts are limited to where it is required. Cheap, mediocre developers are more likely to produce fancy-pants-looking code, that is overly complicated, harder to understand and maintain, and often is buggy. Just my 2p. :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe