Why is Haskell used so little in the industry?
stackoverflow.com
stackoverflow.com
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.)
Reading the Javascript code is pretty much unavoidable with Coffeescript because debugging utilities don't exist for it at all.
Interoperability matters.
It's also deployed to Heroku. You wouldn't know it's written in Haskell if I didn't tell you.
Saying that X (CoffeeScript) proponents make more useful/novel software than Y (Haskell) proponents is pretty crazy.
Haskell lacks that culture, as evidenced by the premise behind this question.
I'm a casual Haskell enthusiast and have no trouble finding interesting useful Haskell apps. But that may be because I now know where to look. Or have taken the time to find things.
So Haskell has a culture of making things but may lack the "show it off" part.
- 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.
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!
> Haskell is a language that rewards those who sit back and deeply analyse the
> problem, and them produce a beautiful solution.
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.
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.
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 :-)
Hopefully the initial developers are good ones. If not, I'm sorry and I hope they pay you well. I've been there :-|
Seriously though, in situations where lives are dependent on the solution working correctly, the process that is used to build the solution needs to take into account human error and have rigorous testing.
i.e. I also wouldn't trust a person who "though about and can 'prove'" a solution in Haskell to control that radiation machine without extensive testing.
The worst case is millions of dollars spent to build a product only to discover that there are issues late in the testing phase. Wouldn't is be less risky to experiment and validate assumptions earlier in the cycle?
Agile as opposed to methodology X is a bit fuzzy here, as I'm sure testing is extensive and expensive and the feedback cycle is inherently longer, so change is more expensive.
However, it seems that early feedback and validation of design is even more important in these circumstances, since changes late in the product development process and orders of magnitude more expensive than changes early in the process.
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.
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.
Also, I think Stevey satirized the situation quite nicely.
http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
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.
Write massively concurrent and parallel programs with tools that, practically speaking, lead to a massive reduction in race conditions.
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.
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.
Haskell makes you lazy, in a good way.
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.
Without any real data other than my own anecdotal experience, I think the principal problem with Haskell is not the semantics or the syntax, but the usability of the entire toolchain and ecosystem, as well as just not catching a lucky break that could allow it to overcome those shortcomings or have them ignored. Consider the string rather than list-oriented nature of "sh" and family: just about everyone I know feels that was a bad idea, yet we live with it because of some artifacts of it being in the right time and place.
I don't know if anyone has the resources and the focus on usability of the Haskell toolchain, or if the community feels a drive to improve in these aspects to take on those problems collectively: finding a better way to render type errors doesn't seem high on the list, as far as I know. I hope something improves though: that new deferred type-error mode in GHC looks pretty awesome, and a step in the right direction.
I look forward to trying Haskell again. Some time.
(but you are right, in that adoption plays a crucial role in adoption ;).)
[1]: https://research.microsoft.com/en-us/um/people/simonpj/paper...
I'll probably continue writing toy code with Haskell, but which is the most popular programming language that encourages a functional programming paradigm?
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.
What? Eager sequence functions are the exception, not the rule; most are lazy.
(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!)