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.)
Kind of an unfair comparision... Coffeescript compiles to Javascript. Sure, GHC Haskell might have once compiled to C but no one was expected to actually read the C code.
Reading the Javascript code is pretty much unavoidable with Coffeescript because debugging utilities don't exist for it at all.
So it's an unfair comparison in favor of Coffeescript because Coffeescript has inadequate tools? I don't see the rationale here. Especially since the vast majority of javascript out there is minified, especially when it has been generated by something like Coffeescript. Nobody is expected to actually read the minified code.
I said no such thing. I said coffeescript proponents don't whine about it. There's a culture in mainstream open source about "getting things done". People make stuff and show it off, and the value is what they made, not how they did it.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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!)
> 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.
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.
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 :-)
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.
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 :-|
So, I'm building a radiation therapy machine, and I want to make sure the software controlling it dispenses the right amount of radiation, not 100 times the right amount of radiation, because that level will kill the patient. And my problem is that my programming language isn't agile enough?
Yes, because agile methodologies kill people, puppies and hate freedom.
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.
Agile isn't right for all software projects. For example, mission critical applications, like medical devices, shouldn't be developed with an agile methodology. Agile is better suited for projects that can be easily and appropriately prototyped.
Why can't you have both? Maybe a different design would become apparent while developing the product, as opposed to being discovered in the analysis phase. (I'm assuming you are talking about a process with a large and separate analysis phase).
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.
Yeah, I'm not talking about process so much as languages anyway though. For all I know (I've never actually developed software for a medical device) its worthwhile to build an actual prototype in a more flexible language first. But if my code could kill someone, I want my tools to optimize correctness over flexibility in the final implementation.
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.
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.
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.
Haskell is hard because it is a very powerful and high level language, with a sophisticated compiler (type checker for highly exotic types) and runtime (lazy evaluation system, not merely a bytecode VM). Most popular languages aren't nearly as sophisticated. You can write sophisticated programs in them, but the languages aren't as sophisticated.
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?
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.
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.
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.
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.
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.
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.
49 comments
[ 3.3 ms ] story [ 102 ms ] threadNo 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'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.
Also, I think Stevey satirized the situation quite nicely.
http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
(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!)
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.
(but you are right, in that adoption plays a crucial role in adoption ;).)
[1]: https://research.microsoft.com/en-us/um/people/simonpj/paper...
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.
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.
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.
Haskell makes you lazy, in a good way.
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.
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.