3 ms·

First, the title annoys me: "Why not X?" is almost always the wrong question to ask, because it implies that X is so great that don't even need a reason to use

First, the title annoys me: "Why not X?" is almost always the wrong question to ask, because it implies that X is so great that don't even need a reason to use it. If you want me on board, the relevant question is "Why X?". Second, A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster seems fallacious to me. It might as well be that because Haskell is hard, only people with a deep understanding and appreciation of computer science ever venture into it. So, in other words, Haskell programs are good because they're written by very bright people thinking very hard about what they are doing. The same reason old mainframe code works well and average PHP doesn't.

neilk 15y ago
I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you from all that; it's easily the highest level language in common use. It's that Haskell insists on program correctness. You have to consider the entire range of values that any function could ever process. And due to its purity, Haskell applies a razor to your thought process, cutting out all unjustified or implicit assumptions. Luckily it also gives you tools of unparalleled flexibility when it comes to creating abstractions. Creating a new abstraction (like the composition of two functions) isn't just as easy as function application, that's how you do function application in Haskell. Typically with less syntactical fuss than it takes Java to initialize a variable.
- mseebach 15y ago
  No, I have not worked with Haskell. I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.
  - outworlder 15y ago
    Really? Try harder :) Remember that the "inputs" in non-pure languages are not only the function arguments, but can be global variables, objects (singleton or otherwise), external files, and so on. These are all inputs. Plus, Java's type system is a toy compared to Haskell.
    - mseebach 15y ago
      Try harder what? Not seeing bugs I don't see? Yes, I'm aware what "inputs" are. One property of what I consider well written software is the absence of global state. "External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful. > Plus, Java's type system is a toy compared to Haskell. Plus, so what? I'm not even beginning to compare Java with Haskell.
      - jerf 15y ago
        '"External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful.' I would point out that Haskell can in fact do useful things, so these problems must have been solved. It is a common misconception that Haskell has "problems" with external state, when in fact what it has a way of explicitly managing such state where almost any other language does not. It isn't so much that Haskell is lacking the ability to manage external state as that other languages lack the ability to manage external state, and end up with a solution that from the Haskell point of view looks like a punt rather than a great solution. But it's difficult to explain how that works in an HN comment; I'd suggest Learn You a Haskell up through the Monad chapter, then spending some time with STM until you grok how and why the type system actually manages to guarantee proper use of STM at compile time. This is interesting because STM has proved effectively intractable in languages that can't maintain the STM constraints at the type level. While the course I've just recommended may take a week of education, that's about all it would take; it's not months, and it's actually a very valuable perspective to gain on the problem of creating quality code I'd recommend to anyone.
  - SkyMarshal 15y ago

neilk 15y ago

I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you from all that; it's easily the highest level language in common use. It's that Haskell insists on program correctness. You have to consider the entire range of values that any function could ever process. And due to its purity, Haskell applies a razor to your thought process, cutting out all unjustified or implicit assumptions. Luckily it also gives you tools of unparalleled flexibility when it comes to creating abstractions. Creating a new abstraction (like the composition of two functions) isn't just as easy as function application, that's how you do function application in Haskell. Typically with less syntactical fuss than it takes Java to initialize a variable.

mseebach 15y ago
No, I have not worked with Haskell. I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.
- outworlder 15y ago
  Really? Try harder :) Remember that the "inputs" in non-pure languages are not only the function arguments, but can be global variables, objects (singleton or otherwise), external files, and so on. These are all inputs. Plus, Java's type system is a toy compared to Haskell.
  - mseebach 15y ago
    Try harder what? Not seeing bugs I don't see? Yes, I'm aware what "inputs" are. One property of what I consider well written software is the absence of global state. "External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful. > Plus, Java's type system is a toy compared to Haskell. Plus, so what? I'm not even beginning to compare Java with Haskell.
    - jerf 15y ago
      '"External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful.' I would point out that Haskell can in fact do useful things, so these problems must have been solved. It is a common misconception that Haskell has "problems" with external state, when in fact what it has a way of explicitly managing such state where almost any other language does not. It isn't so much that Haskell is lacking the ability to manage external state as that other languages lack the ability to manage external state, and end up with a solution that from the Haskell point of view looks like a punt rather than a great solution. But it's difficult to explain how that works in an HN comment; I'd suggest Learn You a Haskell up through the Monad chapter, then spending some time with STM until you grok how and why the type system actually manages to guarantee proper use of STM at compile time. This is interesting because STM has proved effectively intractable in languages that can't maintain the STM constraints at the type level. While the course I've just recommended may take a week of education, that's about all it would take; it's not months, and it's actually a very valuable perspective to gain on the problem of creating quality code I'd recommend to anyone.
- SkyMarshal 15y ago