4 ms·

I've criticized Haskell many times, and being criticized many times of that. You see, I would love to love Haskell but in practice the language just always tur

by yason 16y ago

I've criticized Haskell many times, and being criticized many times of that. You see, I would love to love Haskell but in practice the language just always turns out to be an overly intellectual exercise. Real world programs need to manage state, preferably in a very controlled way, but the bottom line is that they need to do that in some obvious and easy way. It doesn't help if you explain me that you really don't need to explicitly store state anywhere, that you can just use monads to carry it over from computation to computation. Monads are an interesting abstraction per se but I don't want to use such heavy-weight artillery to make a mere assignment, to write a pointer to memory. I want my language to put some effort in protecting myself from the hazards of unintended concurrency but when I want to do it, the language must obey. That said, Clojure is just perfect. For now, Clojure is my Blub.

klodolph 16y ago
It sounds like Haskell just isn't your style, but you're saying that Haskell is bad for "real-world" programming. And it sounds like you've never really used Haskell seriously (just a guess, most Haskellers I've met get over their monad fixation within a few months, yet you describe them as "artillery"). If you like Clojure so much, why not go champion that instead of complaining about Haskell? Besides, if you use "how easy is it to implement 'memoize'" as a benchmark then you'll always end up choosing a Lisp.
- swannodette 16y ago
  Supporting Haskell and complaining about Haskell are both valid activities. There's plenty to complain about Clojure. However, the post does point out quite succinctly that while Haskell features might be incredible for simplifying many kinds of problems, it's shocking how many simple problems become staggeringly complex in Haskell.
  - plinkplonk 16y ago
    "while $Language features might be incredible for simplifying many kinds of problems, it's shocking how many simple problems become staggeringly complex in $Language." Replace "$Language" with almost any computer language in existence and that statement is true (given appropriately chosen values of "simple problems" and "staggeringly complex"). So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ". Not saying much, really.
    - crc 16y ago
      > So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ". Though that might be the case, what doesn't change with languages is what users typically consider as simple problems. So "simple problems" are specific to user expectations, not language features. So I think the parent's point still stands.
      - plinkplonk 16y ago
        "what doesn't change with languages is what users typically consider as simple problems.". If you meant users of the language (vs users of an app built with the langauge) you are wrong. Consider Text Processing (awk vs Java , even though Java has Text processing libraries), Distributed Computation (Erlang vs C - though you can do DC with C ) , "close to the metal" coding (C vs Scheme), Continuation Passing Style (again C vs Scheme, with a different "winner"), Array processing (J vs Java), statistical code (R vs C++). What users consider "simple problems" does change with the language used, contra what you said above. And just like if you start with "Continuation Passing Style is easy" as a criterion , Scheme beats C, or "customized memory management" makes C win over Scheme, if you use "ease of memoizing a function" as a selection criterion you'll end up with a Lisp (over Haskell or C or Java). Change the criterion and a different language rises to the top. As I said earlier this isn't saying much.
        jimbokun 16y ago
        Using this same kind of (Language vs Language) comparison, what are some criteria where Haskell wins?
        plinkplonk 16y ago
        The point was, to make any language "win", just choose one of its strengths as a deciding criterion and take another language without that feature as a punching bag. So to make Haskell "win", All I have to do is state "monadic programming should be easy" or "effectful programming should be clearly distinguished from the pure functional core by the type system." or "Using typeclasses to structure my code should be trivial" And Haskell "wins" by default over other languages. That said, fwiw, in my experience the "sweet spot" of Haskell is in large + heavily algorithmic + complex code bases, where its powerful type system shines. It is very fast without sacrificing abstraction. I've built some large machine learning systems with it and I couldn't be happier. I know other people who are building trading systems in it and they seem delighted too. As I said, just my experience and I making no claim about how other languages are losers somehow because they have different goals.
- yason 16y ago
  It's not the style; it's the real world where Haskell and me have never got together very well. I would like to write in the concise, immutable, lazy, functional, and strongly typed style of Haskell and that's fine with (nontrivial) toy programs and interesting algorithm implementations, but it's the real world requirements and state management where I've always found Haskell unnecessarily burdensome to deal with. My benchmark for any language is, as a visual person, to first get stuff on the screen and then get it moving. With Haskell I always end up writing more code to deal with the state than I would like to. And by judging other people's code to do similar things (like a vector graphics on the screen in a game or demo) it doesn't seem to get too pretty there either. Haskell would be a more practical and smoother language by a tenfold if it just went ahead and accepted that I want to do impure things occasionally, and gave me pragmatic tools to do that. Don't say monads, they feel phony given the simplicity of what I need from them. I chose the word artillery because monads are a Goldbergesque way to achieve writing a pointer to some place in memory. FYI, I do champion Clojure much more than complain about Haskell, but I occasionally do the latter as well in order to reconsider my criticism. And I retry with Haskell from time to time, to see if the feel of the language would finally make me overcome the resistance.
  - dasil003 16y ago
    I've spent the last 15 years programming professionally various imperative and object-oriented languages. I think you're being too harsh on Haskell here. Certainly if you just want to quickly hack something together than Haskell is not optimal. Similarly, if you just want to create a web page that has one dynamic element in it, then a web framework is overkill and you might as well just use an inline PHP script. But the real challenges in programming are always managing complexity over time. I am far from a Haskell expert, but I am definitely an expert in many types of bugs that programmers experience in the real world. And I feel pretty confident saying that at least 90% of bugs that crop up in the real world programs are due to a mismanagement of state. Different people have developed different techniques to combat this, but pure functional programming is by far the most powerful. The TDD/BDD community often touts testing as a guarantor of quality, but as useful as testing is, it pales in comparison to the assurances of mathematical provable functions. With Haskell you spend more time developing, but you get the greatest possible assurances that A) your code is bug free and B) it will remain bug free even as the program as a whole changes. It's absolutely true that most development these days is low-budget high-priority stuff where time to market trumps long-term maintainability. However to suggest that Haskell--the strongest bastion of functional purity, and one of the few places where the mathematics behind computer science are being advanced--should water itself down to be more like 1000 other programming languages designed for getting things done™ is just plain silly. If you don't have use for Haskell's purity than don't use it.
loup-vaillant 16y ago
You never want "to make a mere assignment", nor "to write a pointer to memory". These are not problems you want solved, they are parts of a possible solution. Haskell don't need assignments nor memory writes. It solves problems (including state management) differently. You may not like that, but don't say that not using some specific low-level feature is bad by itself.
- naradaellis 16y ago
  Agreed - these notions are born out of solving problems at a lower level of abstraction. Haskell is attempting to operate above that.
- yason 16y ago
  It doesn't help to explain state in a very sophisticated way because eventually a memory write is what you're after. I'm programming on a real computer that has memory and a cpu and in order for theory and practice to meet, there must be in the language a concept of variables that somehow map to the concept of reading and writing memory. Clojure doesn't have memory access either but it has mutable containers with very controlled, concurrent accessors. Assignments and memory writes are very much problems I want to be solved and I'm just unhappy because Haskell doesn't want to help me with that except by strictly with its own doctrine. In Clojure, I can partition the program state into mutable vars and refs at appropriate levels, depending on the problem and my architecture. Most of my code is pure and in general, I don't use many of those mutable containers, but I do. If Clojure didn't have a solution for that it would remain an academic toy language.
  - knome 16y ago
    Haskell has a mutable variable implementation here: http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc/html/Control-Concurrent-MVar.html http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc... It also has a software transactional memory implementation here: http://hackage.haskell.org/package/stm http://hackage.haskell.org/package/stm STM in particular is a neat way to do concurrency. http://www.haskell.org/haskellwiki/Software_transactional_memory http://www.haskell.org/haskellwiki/Software_transactional_me...

by yason 16y ago

klodolph 16y ago

It sounds like Haskell just isn't your style, but you're saying that Haskell is bad for "real-world" programming. And it sounds like you've never really used Haskell seriously (just a guess, most Haskellers I've met get over their monad fixation within a few months, yet you describe them as "artillery"). If you like Clojure so much, why not go champion that instead of complaining about Haskell? Besides, if you use "how easy is it to implement 'memoize'" as a benchmark then you'll always end up choosing a Lisp.

swannodette 16y ago
Supporting Haskell and complaining about Haskell are both valid activities. There's plenty to complain about Clojure. However, the post does point out quite succinctly that while Haskell features might be incredible for simplifying many kinds of problems, it's shocking how many simple problems become staggeringly complex in Haskell.
- plinkplonk 16y ago
  "while $Language features might be incredible for simplifying many kinds of problems, it's shocking how many simple problems become staggeringly complex in $Language." Replace "$Language" with almost any computer language in existence and that statement is true (given appropriately chosen values of "simple problems" and "staggeringly complex"). So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ". Not saying much, really.
  - crc 16y ago
    > So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ". Though that might be the case, what doesn't change with languages is what users typically consider as simple problems. So "simple problems" are specific to user expectations, not language features. So I think the parent's point still stands.
    - plinkplonk 16y ago
      "what doesn't change with languages is what users typically consider as simple problems.". If you meant users of the language (vs users of an app built with the langauge) you are wrong. Consider Text Processing (awk vs Java , even though Java has Text processing libraries), Distributed Computation (Erlang vs C - though you can do DC with C ) , "close to the metal" coding (C vs Scheme), Continuation Passing Style (again C vs Scheme, with a different "winner"), Array processing (J vs Java), statistical code (R vs C++). What users consider "simple problems" does change with the language used, contra what you said above. And just like if you start with "Continuation Passing Style is easy" as a criterion , Scheme beats C, or "customized memory management" makes C win over Scheme, if you use "ease of memoizing a function" as a selection criterion you'll end up with a Lisp (over Haskell or C or Java). Change the criterion and a different language rises to the top. As I said earlier this isn't saying much.
      - jimbokun 16y ago
        Using this same kind of (Language vs Language) comparison, what are some criteria where Haskell wins?
        plinkplonk 16y ago
        The point was, to make any language "win", just choose one of its strengths as a deciding criterion and take another language without that feature as a punching bag. So to make Haskell "win", All I have to do is state "monadic programming should be easy" or "effectful programming should be clearly distinguished from the pure functional core by the type system." or "Using typeclasses to structure my code should be trivial" And Haskell "wins" by default over other languages. That said, fwiw, in my experience the "sweet spot" of Haskell is in large + heavily algorithmic + complex code bases, where its powerful type system shines. It is very fast without sacrificing abstraction. I've built some large machine learning systems with it and I couldn't be happier. I know other people who are building trading systems in it and they seem delighted too. As I said, just my experience and I making no claim about how other languages are losers somehow because they have different goals.
yason 16y ago
It's not the style; it's the real world where Haskell and me have never got together very well. I would like to write in the concise, immutable, lazy, functional, and strongly typed style of Haskell and that's fine with (nontrivial) toy programs and interesting algorithm implementations, but it's the real world requirements and state management where I've always found Haskell unnecessarily burdensome to deal with. My benchmark for any language is, as a visual person, to first get stuff on the screen and then get it moving. With Haskell I always end up writing more code to deal with the state than I would like to. And by judging other people's code to do similar things (like a vector graphics on the screen in a game or demo) it doesn't seem to get too pretty there either. Haskell would be a more practical and smoother language by a tenfold if it just went ahead and accepted that I want to do impure things occasionally, and gave me pragmatic tools to do that. Don't say monads, they feel phony given the simplicity of what I need from them. I chose the word artillery because monads are a Goldbergesque way to achieve writing a pointer to some place in memory. FYI, I do champion Clojure much more than complain about Haskell, but I occasionally do the latter as well in order to reconsider my criticism. And I retry with Haskell from time to time, to see if the feel of the language would finally make me overcome the resistance.
- dasil003 16y ago
  I've spent the last 15 years programming professionally various imperative and object-oriented languages. I think you're being too harsh on Haskell here. Certainly if you just want to quickly hack something together than Haskell is not optimal. Similarly, if you just want to create a web page that has one dynamic element in it, then a web framework is overkill and you might as well just use an inline PHP script. But the real challenges in programming are always managing complexity over time. I am far from a Haskell expert, but I am definitely an expert in many types of bugs that programmers experience in the real world. And I feel pretty confident saying that at least 90% of bugs that crop up in the real world programs are due to a mismanagement of state. Different people have developed different techniques to combat this, but pure functional programming is by far the most powerful. The TDD/BDD community often touts testing as a guarantor of quality, but as useful as testing is, it pales in comparison to the assurances of mathematical provable functions. With Haskell you spend more time developing, but you get the greatest possible assurances that A) your code is bug free and B) it will remain bug free even as the program as a whole changes. It's absolutely true that most development these days is low-budget high-priority stuff where time to market trumps long-term maintainability. However to suggest that Haskell--the strongest bastion of functional purity, and one of the few places where the mathematics behind computer science are being advanced--should water itself down to be more like 1000 other programming languages designed for getting things done™ is just plain silly. If you don't have use for Haskell's purity than don't use it.

loup-vaillant 16y ago

You never want "to make a mere assignment", nor "to write a pointer to memory". These are not problems you want solved, they are parts of a possible solution. Haskell don't need assignments nor memory writes. It solves problems (including state management) differently. You may not like that, but don't say that not using some specific low-level feature is bad by itself.

naradaellis 16y ago
Agreed - these notions are born out of solving problems at a lower level of abstraction. Haskell is attempting to operate above that.
yason 16y ago
It doesn't help to explain state in a very sophisticated way because eventually a memory write is what you're after. I'm programming on a real computer that has memory and a cpu and in order for theory and practice to meet, there must be in the language a concept of variables that somehow map to the concept of reading and writing memory. Clojure doesn't have memory access either but it has mutable containers with very controlled, concurrent accessors. Assignments and memory writes are very much problems I want to be solved and I'm just unhappy because Haskell doesn't want to help me with that except by strictly with its own doctrine. In Clojure, I can partition the program state into mutable vars and refs at appropriate levels, depending on the problem and my architecture. Most of my code is pure and in general, I don't use many of those mutable containers, but I do. If Clojure didn't have a solution for that it would remain an academic toy language.
- knome 16y ago
  Haskell has a mutable variable implementation here: http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc/html/Control-Concurrent-MVar.html http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc... It also has a software transactional memory implementation here: http://hackage.haskell.org/package/stm http://hackage.haskell.org/package/stm STM in particular is a neat way to do concurrency. http://www.haskell.org/haskellwiki/Software_transactional_memory http://www.haskell.org/haskellwiki/Software_transactional_me...