Taking a step back

Ivan Perez ivan.perez at keera.co.uk
Tue Oct 20 19:39:46 UTC 2015


On 20/10/15 19:35, Gregory Collins wrote:
> On Tue, Oct 20, 2015 at 7:45 AM, Jeremy <voldermort at hotmail.com 
> <mailto:voldermort at hotmail.com>> wrote:
>
>     I'm interested in why you think recent changes are making Haskell
>     a less
>     viable alternative to mainstream languages.
>
>
> [...] Of course, these hypothetical productivity benefits are 
> extremely difficult to quantify (and Lord knows, we've tried), but 
> that's not at all true for the "con" arguments:
>
>   * how many Haskell programmers are there in industry? If I lose my
>     local expert who is trying to push us to use this thing, can I
>     hire another?
>   * how many lines of code are written in Haskell globally vs other
>     languages?
>   * how much tooling will I have available to help me if I choose
>     Haskell vs. a "safer" technology like Java, Python, or Go?
>   * how many open source libraries will I have available to me to
>     handle common tasks, and what is their quality?
>   * how likely am I to encounter bugs in the compiler or base libraries?
>
We actually get these questions from potential clients *all the time* 
(in particular, everyone asks 1 and 3). I don't always have a convincing 
answer.
> The point Johan is trying to make is this: if I'm thinking of using 
> Haskell, then I'm taking on a lot of project risk to get a 
> (hypothetical, difficult to quantify) X% productivity benefit. If 
> choosing it actually *costs* me a (real, obvious, easy to quantify) Y% 
> tax because I have to invest K hours every other quarter fixing all my 
> programs to cope with random/spurious changes in the ecosystem and 
> base libraries, then unless we can clearly convince people that X >> 
> Y, the rationale for choosing to use it is degraded or even nullified 
> altogether.
Not even that. Learning and some tooling costs can be amortized over 
time, but a regular and frequent cost tied to upgrades in the ecosystem 
may be really hard to estimate in advance. This makes profit, viability 
and deadlines, mid-term and long-term, really hard to estimate and 
fulfill. (I've also tried, and often failed.)

If clients (supervisors, project managers, <your company>) have *any* 
doubts that using the language may be cost-effective, they won't go for it.

Cheers

Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/ba570c68/attachment.html>


More information about the Libraries mailing list