3 ms·

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 wha

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 14y ago
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 14y ago
  It turns out that purely functional data structures are useful anyway as a solution to concurrency, though.
  - Drbble 14y ago
    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.
fdr 14y ago
Hm. I think this is false, in at least one large domain: data management, and that's quite a whopper. Jeff Davis wrote about it better than I can: http://thoughts.j-davis.com/2011/09/25/sql-the-successful-cousin-of-haskell/ http://thoughts.j-davis.com/2011/09/25/sql-the-successful-co... 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.

eli_gottlieb 14y ago

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 14y ago
It turns out that purely functional data structures are useful anyway as a solution to concurrency, though.
- Drbble 14y ago
  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.

fdr 14y ago

Hm. I think this is false, in at least one large domain: data management, and that's quite a whopper. Jeff Davis wrote about it better than I can: http://thoughts.j-davis.com/2011/09/25/sql-the-successful-cousin-of-haskell/ http://thoughts.j-davis.com/2011/09/25/sql-the-successful-co... 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.