[Haskell-cafe] Re: Libraries for Commercial Users

[Iain Barnett]

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091025/c4c5aa38/attachment.html