On 25 Oct 2009, at 08:31, Magnus Therning wrote:


Also, as I'm sure you've found out re libraries, more isn't necessarily
better.  

Definitely. Choice can become a real pain, especially in the face of lacking documentation.


  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.

But if someone has already done some of the work, or an app or language is known to have been (at least) partially successful in an area, then this makes it a lot more likely to be picked, right?


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.


You could make the case, but are you saying that programmers of major languages like Java, Perl, Ruby, PHP, C#, C++... aren't self-motivated, don't enjoy their language, and aren't clever? Fact is, you'll get good and bad, self motivated and not, in every pool of developers, in every language - these aren't properties given to people by the language. If you're going to get a higher proportion of the "good" in a smaller language then that isn't necessarily offset by the risks to a project of having a smaller pool to pick from.


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.

I totally agree, you (generally) get what you pay for. What I was referring to by fancy pants code, was the Creator God-like abilities being attributed to Haskell code over other languages. What you said holds true in any language, of course.


Iain