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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
