[Haskell-cafe] What is Haskell unsuitable for?

[Claus Reinke]

>> If you want to use cool languages, you may have to get a cool job. I  
>> know: it's easy to say and harder to accomplish.
> 
> Most functional languages (e.g. Lisp, Haskell, ...) have a challenging  
> time in industry since they require some savvy with multiple levels of  
> higher abstractions and some savvy with mathematical ideas and some  
> savvy with functional algorithms and data structures.

Javascript (the Basic of Lisps) isn't half bad, and is doing well.

But on the old topic of programming languages in industry: when 
I looked into PHP, I had my difficulties. But doing so helped me to 
understand an important aspect of programming language usage: 

    In the PhD world, people care more about their
    language than about their applications.

    In the PHP world, people care more about their
    applications than about their language.

Obviously, this is oversimplified in just about every way (you don't 
need a PhD to care about your language, not all PhDs care about
their language, some PhDs care about their applications, some
PHPs care about their language, many programmers care about
both their language and their applications, and so on). But as a 
starting point, and especially to shake up preconceived notions, 
it still helps to compress common prejudices this way.

Industry may well understand, and sometimes even already
know, when their tools are not the best. But their job is not
to use the best tools, it is to get things done (in a way that
ensures survival in their market). There is no point arguing 
with them about the quality of tools - they might even agree 
with you, and still not change anything. There is no point 
complaining that they don't understand our shiny advanced 
tools - you need to show them that these tools make a 
difference in getting things done (wrt market survival).

Industry also have their own levels of abstraction: if a 
manager makes decisions, and programmers have to
implement them, problems with the tools are hidden
from the managerial level. If managers can buy solutions,
even problems with programmers are hidden from them.
And if developers can use frameworks, configurable
management systems, and configuration management
software, they are isolated from some programming
problems (*).

So you could think about the problem of "selling" a
new language as trying to sell a new implementation
of an existing API, for which a more-or-less working
implementation alread exists. And that is the good
case - the bad case is when you're competing with
frameworks and similar infrastructure, where "the"
programming language plays a decreasingly small
role in building software.

Claus

(*) In the "you can run, but you can't hide" sense.

PS. There should be a "Haskell for PHP developers",
    so that Haskellers understand that the advantages
    of Haskell begin long before we get into advanced
    type systems, so that PHPers see that most of what
    they want to do can be done in Haskell, with fewer
    problems and without using advanced features, 
    and so that Haskellers and PHPers get together 
    about getting things done.

    (challenge for adventurous minds: since PHP gets
    most of its functionality from C-libraries: would it
    be possible to use Haskell's FFI to hook into the
    C-libraries of a PHP installation and get the best
    of both worlds, as seen from a PHP developers
    perspective?-)