
Why is Haskell used so little in the industry? - Cieplak
http://stackoverflow.com/questions/2284875/why-is-haskell-used-so-little-in-the-industry
======
ajross
Tough love: because Haskell proponents spend all their time ruminating on the
beauty and purity of their preferred language instead of writing useful and
novel software.

No one whines about why, say, coffeescript is used so little in the industry.
They just _go out and use it_.

( _Edit: to be clear, I'm not comparing coffeescript and Haskell as languages.
I'm comparing the cultures around them. One "team" has a new toy and is
excitedly building stuff with it; there's now a whole community of great stuff
available with real applications. The other... has some interesting tools
available if you look, but no energy. And they spend their time wondering why
and NOT excitedly building stuff._ )

~~~
mquander
Should I be reading something out of this comment other than a totally
ridiculous insult? I would flag it and move on if it wasn't coming from
someone whose contributions I normally enjoy.

\- You seem to be saying that Haskell people are per capita less productive
(or more "whiny?") than people writing in other languages. I have no idea why
you think this is true, because I don't know any good way to even find out how
many people know Haskell. Please show even the slightest bit of evidence.

\- Are you kidding me? Go Google _"coffeescript usage"_ (better yet: _"why
coffeescript"_ ) and see page after page of people writing why they're using
Coffeescript, why they're not using Coffeescript, asking if anyone else is
using Coffeescript, telling people to use Coffeescript, ad infinitum. People
like to talk about who is using every single piece of technology on this
planet.

~~~
ajross
The meaning of "tough love" is that I'm trying to provide some needed advice,
which I recognize in advance may be misinterpreted as an insult. I meant it
sincerely.

I don't care whether or not people "talk about" Haskell, that's not my point
at all. People will start using it (which is the answer to the linked
question) when Haskell starts _doing things_ that are better than what is
available elsewhere. It isn't.

If it's a better environment for doing, say, MVC web frameworks then make
something that competes with rails. If it's faster than C (I hear this a lot),
then write some system middleware that clearly improves on the existing stuff.
And stop asking why people aren't using it!

------
6ren

      > Haskell is a language that rewards those who sit back and deeply analyse the
      > problem, and them produce a beautiful solution.
    

Upfront design is the opposite of agile. As Douglas Adams said, knowing what
the problem actually is is often the difficult bit. The very concept of
"correctness" rests upon you already knowing the problem well enough to
precisely define it.

Haskell is to programming as pure mathematics is to accounting.

 _EDIT:_ The idea of agile is iteration (aka trial-and-error). While Agile
aims at understanding client needs, the concept derives from experimentation -
part of the scientific method. It's also used in engineering research, _I
haven't failed 1000 times, I've discovered 1000 ways that don't work_ ; in
human-powered flight (reconfigurable hardware for new trials every day,
instead of twice a year) going back to the Wright Brothers trying to
understand flight _control_ \- they invented the wind-tunnel, to iterate
designs quickly, easily, cheaply, safely (and spent 3 years on it even so).
Even pure mathematicians iterate, trying different approaches.

Trial-and-error is a given in research, differing only in the level/domain of
interest.

~~~
astrodust
Good luck achieving your sprint deliverable when all you have is some _ideas_!

That's one of my main misgivings about a hard-line agile approach. It is good
for shops focused on engineering simple problems or doing routine technical
work. It breaks down completely in more research-driven domains.

The hard problems are the ones where you bang your head against the wall with
no tangible progress, simply exploring the problem domain until you can get
some traction, find a way to solve it, but often your first few attempts lead
to a sub-optimal solution you'd hate to commit to.

Agile says go with it, fix it later. This is why we get stuck with crappy
standards we'd all want to go back in time to fix.

Some things require a more artistic approach where you grind away at the thing
until it's actually solid.

If Haskell is pure mathematics then there's no way you can shoehorn that into
an agile box.

~~~
binspace
Actually, agile methodologies are good for situations where the problem itself
(and even customer base) is in flux and not fully known (ie consumer facing
web startups). Agile methodologies help lay a roadmap to facilitate
communication and prioritization to/from developer, project management, and
the customer(s).

The solution may or may not be difficult, but finding the right problem to
solve is paramount.

The quality of the solution is often a product of the quality of the people
working on the problem. Oh, and don't run out of money :-)

~~~
astrodust
My experience is there's a tendency to ship the first viable thing that comes
out and deal with the rest on an as-needed basis. This is fine for stuff that
can survive being a bit ramshackle at first if you can refactor it later, but
some things are highly resistant to later refactoring.

~~~
binspace
Shipping quickly is often a strategy used to discover the problem space. Some
things _should_ be done as quickly as possible and some things _should not_.
The developers/tech management are responsible for forseeing such cases.

Hopefully the initial developers are good ones. If not, I'm sorry and I hope
they pay you well. I've been there :-|

------
igorgue
I love Haskell, I've been programming on it for about 5 years ,never
professionally of course, but Haskell is just hard for everyone.

Look, what's a Monad?

Is it a "wrapper around function invocations"?
(<http://c2.com/cgi/wiki?OnMonads>)

Or "a parameterized type which is an instance of the Monad type class, which
defines >>= along with a few other operators. In layman's terms, a monad is
just a type for which the >>= operation is defined"
(<http://stackoverflow.com/a/194207/29253>) this definition is so bad,
starting by the fact that a class aint what you think it is if you come from
Python or Ruby.

Most people would just wait for "Learn Haskell The Hard Way" to finally
understand some of its concepts that get overcomplicated by Haskellers because
they want to be the only ones understanding it. I'm generalizing of course,
but sometimes it feels that way, at least to me, since I don't have a CS or
Math background.

~~~
jonathansizz
Yes, Haskell _is_ hard for everyone. Maybe I can speak on behalf of the stupid
majority, but (having spent quite some time trying to learn Haskell) perhaps
many of us who have at one time or another taken an interest have at some
point ceased to find the effort worthwhile?

The most annoying thing is that there seems to be an implicit assumption from
a sizable part of the Haskell crowd that Haskell is demonstrably the
programming pinnacle toward which all serious coders should be aiming; those
of us who fall short of this goal must therefore feel chastened and
embarrassed at our obvious inferiority.

Well, at some point when I was grinding through _Real World Haskell_ , trying
to build software that actually did something useful, I just reached the point
where I simply couldn't be bothered any more. But more fundamentally than
this, I no longer believed that Haskell was better than all the other
languages out there (because I can accomplish so much more so much quicker
with several other languages that I know). And this _is_ the assumption; just
hang out with the Haskell community to see this.

------
adam-f
My experience with it has been mostly fighting with enabling various language
extensions to get some (real) sample programs working. The algol languages are
much easier to debug compile issues, Haskell's purity makes certain issues
non-obvious and complicated.

Also, I think Stevey satirized the situation quite nicely.

[http://steve-yegge.blogspot.com/2010/12/haskell-
researchers-...](http://steve-yegge.blogspot.com/2010/12/haskell-researchers-
announce-discovery.html)

------
balloot
I would say there's two clear reasons functional languages are relatively rare
in the professional world:

1) Functional languages are difficult to grasp. Maybe it's the way CS is
taught, but I've never heard someone say "Haskell just comes intuitively to
me, but I just can't get how to work effectively in PHP". You hear the same
statement the other way around all the time. The bottom line is if you have
multiple tools to do the same job, and one has a huge learning curve and one
has a tiny learning curve, the choice of tool is obvious.

2) Haskell doesn't have a clear application it's "good" at. If you learn PHP,
Python, or Ruby, you can throw together a web application with little effort.
If you learn Javascript, you can easily do front end web stuff, or if you're
more adventurous, get into Node.js. If you learn the C family of languages you
can write iOS apps, OS kernels, or games. What do you do with Haskell? I
dunno.

~~~
DanWaterworth
> What do you do with Haskell?

Write massively concurrent and parallel programs with tools that, practically
speaking, lead to a massive reduction in race conditions.

------
secoif
OT, but does anyone else notice that almost every interesting discussion on
StackOverflow is deemed 'unconstructive' or 'not a real question' or
'subjective' then closed?

Things like "What's the best x…" might not have a definitive, objective
answer, but many _good questions only have subjective answers_. I wish they
would reconsider this asshat of a policy because they're stifling a lot of
good discussion that the community clearly wants to have, and finds
constructive, regardless of what the moderators believe.

------
BasDirks
Contrary to popular believe in our community, many programmers are of average
intelligence, discipline and curiosity. Haskell (as well as plenty of other
technologies) will be too much effort for this group. Is this a taboo? Or
elitist?

I wonder why people desire so for the mainstream adoption of Haskell. I smell
empty motives. Haskell seems to have done fine without mainstream recognition.

------
DanWaterworth
I don't know why people say Haskell is difficult. It's certainly different,
but once you know Haskell (which is perhaps the difficult step) you'll find
that you can, and that you are even encouraged to, hand over much of your
responsibility to think to the type checker.

Haskell makes you lazy, in a good way.

------
jonathansizz
Answer: it should be clear by now that the mainstream has decided that any
viable language must have an Algol-like structure. It's as simple as that;
that's what industry languages look like. They are familiar, comfortable and
just have an 'industrial' feel to them.

~~~
eli_gottlieb
There are several other issues than just that.

Haskell's bondage-and-discipline insistence on functional purity makes it very
difficult to mix multiple kinds of effects. If you only use one kind of
effect, There's a Monad for That (and you probably don't even have to
understand monads!), but once you want to use multiple kinds, you suddenly
need to really understand monad machinery (transformers, combinators, etc.).
And if you're avoiding monads and comonads, you have to use entirely separate
purely-functional data structures.

In addition, Haskell's strong emphasis on statically-determined behavior over
run-time decision making creates a language prone to unextensible software.
It's not that functional programming and static typing are not useful; it's
that industrial programming can take much better of object-oriented and
dynamic features, specifically the modularity and extensibility of classes and
virtual methods, than of functional and static features. Haskell is suitable
for code that you write once, perfectly, but industry needs a language for
software you write again and again, never quite right but good enough to ship.

~~~
philwelch
It turns out that purely functional data structures are useful _anyway_ as a
solution to concurrency, though.

~~~
Drbble
Immutable structures, yes. And you can get those without Haskell's other
baggage. Haskell is great for research in persistent data structures because
it is impossible to cheat. But then it is more industry-practical to port the
algorithms than write an application in Haskell. check out Google's MapReduce
and Flume papers, for example.

------
carterschonwald
Who cares? Those who choose to use Haskell and leverage its awesome win! :-)

------
demian
So, basically, nobody uses haskell because nobody uses haskell.

~~~
nullspace
Network effects are hyper-exponential. I don't have citation for this, but it
would explain why most things don't get mainstream attention even if they are
good.

------
nullspace
I have been learning Haskell off and on for the last few weeks, and I can
already see the elegance of it. It's given me some perception about how I can
improve my code on more mainstream languages.

I'll probably continue writing toy code with Haskell, but which is the most
popular programming language that encourages a functional programming
paradigm?

~~~
Drbble
Clojure. But it's dynamically typed, not statically typed. And it is mostly
eager not lazy, but is growing more laziness/fusion features.

OCaml, static and functional, but eager not lazy, but it lacks JVM
compatibility (and FFI to non-functional C doesn't help very much) so it tends
to only work for problems that don't need to third party libraries.

~~~
jonathansizz
No they aren't. The question was "which is the most popular programming
language that encourages a functional programming paradigm?". Common Lisp is
easily the most popular language that fits this description. Both Clojure and
OCaml are still very much niche languages, and certainly cannot be described
as popular.

------
lcargill99
Because language wars.

------
maeon3
The internet is an extremely efficient judge of usefulness. If your pet
language isn't taking off like a rocket and displacing the competitors, then
it's because it isn't much better (maybe even worse) than the existing
solutions.

~~~
majormajor
Most web apps have a very low bar of good enough when it comes to language
requirements. Especially when solid frameworks have already been written for
alternative languages. Right now I'm doing Rails—Ruby isn't the absolute first
language I'd choose, all things being equal, but it's good enough that I don't
have a lot of motivation to use something else.

(Previously, though, I was doing work on ancient Java servlets apps without
any additional framework. That was frustrating enough to make me look for
something else!)

