4 ms·

I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code avai

I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code available in any language. You might as well code to the language's greatest strength. I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has. Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax. My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.

stcredzero 16y ago
common errors in other languages -- your segfaults and NPEs and buffer overflows I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp. (But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)
- rtperson 16y ago
  > I'd be surprised if that's an issue in Python, Ruby, or Lisp. I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
  - chc 16y ago
    Ruby's method_missing, the equivalent of Smalltalk's doesNotUnderstand:, is a plague on Ruby programmers. It might mean something returned nil, it might mean the wrong type got passed or returned, it might just mean that you forgot to include a module — but you will run into them more times than you can count while you're developing a Ruby app. (Or at least I will. I don't know. Maybe everybody else has better luck with their libraries or is just more studious than I am.)
    - stcredzero 16y ago
      Do you have unit tests with good code coverage?
  - anamax 16y ago
    > I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." Duck typing means that I can run an incomplete program, that is, one that will misbehave for certain inputs. It turns out that running incomplete programs is incredibly useful. Yes, I can spend time up front to fake a complete program and remove the fakeness as I provide additional completeness, but ....
- kscaldef 16y ago
  NilClass DoesNotUnderstand ... is morally equivalent to an NPE in my book.
- chc 16y ago
  But the thing is, null/nil/incorrect type references (the cause of NPEs and doesNotUnderstand:s) aren't a problem in Haskell. If you try to pass the wrong type, you'll know right away, before you even get to your hand-written tests — and values that might be Nothing (the Haskell nil) are a different type than normal values. A plain-jane String that is always a list of characters is a different type than a Maybe String and the compiler will catch the mistake for you if you forget that.
tomjen3 16y ago
I haven't had enough experience with Haskell to do so, but it is my understanding that one can interface with C (and would need to do so, to get a native GUI on Windows, access the registry, etc). Those are no doubt buggy to some degree.
- rtperson 16y ago
  Actually, having used the interfaces to OpenGL, SDL, GLFW, and several other native C libraries, I have to say this isn't the case at all. Haskell's FFI is pretty clean, which shouldn't be too surprising, since Haskell compiles natively, and so isn't relying on some VM translation layer. The headaches you have with, say, Java's JNI simply don't happen. The headaches you run into have more to do with getting Haskell to recognize where the relevant dev and runtime libraries are, especially on non-Unix systems where library locations are not standardized. It's possible, but you end up having to hack the Cabal package, a process that is not particularly well documented at the moment. Another issue is simple bitrot. Many libraries in Hackage were developed by students who have no interest in maintaining their thesis work post-graduation.

stcredzero 16y ago

common errors in other languages -- your segfaults and NPEs and buffer overflows I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp. (But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)

rtperson 16y ago
> I'd be surprised if that's an issue in Python, Ruby, or Lisp. I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
- chc 16y ago
  Ruby's method_missing, the equivalent of Smalltalk's doesNotUnderstand:, is a plague on Ruby programmers. It might mean something returned nil, it might mean the wrong type got passed or returned, it might just mean that you forgot to include a module — but you will run into them more times than you can count while you're developing a Ruby app. (Or at least I will. I don't know. Maybe everybody else has better luck with their libraries or is just more studious than I am.)
  - stcredzero 16y ago
    Do you have unit tests with good code coverage?
- anamax 16y ago
  > I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." Duck typing means that I can run an incomplete program, that is, one that will misbehave for certain inputs. It turns out that running incomplete programs is incredibly useful. Yes, I can spend time up front to fake a complete program and remove the fakeness as I provide additional completeness, but ....
kscaldef 16y ago
NilClass DoesNotUnderstand ... is morally equivalent to an NPE in my book.
chc 16y ago
But the thing is, null/nil/incorrect type references (the cause of NPEs and doesNotUnderstand:s) aren't a problem in Haskell. If you try to pass the wrong type, you'll know right away, before you even get to your hand-written tests — and values that might be Nothing (the Haskell nil) are a different type than normal values. A plain-jane String that is always a list of characters is a different type than a Maybe String and the compiler will catch the mistake for you if you forget that.

tomjen3 16y ago

I haven't had enough experience with Haskell to do so, but it is my understanding that one can interface with C (and would need to do so, to get a native GUI on Windows, access the registry, etc). Those are no doubt buggy to some degree.

rtperson 16y ago
Actually, having used the interfaces to OpenGL, SDL, GLFW, and several other native C libraries, I have to say this isn't the case at all. Haskell's FFI is pretty clean, which shouldn't be too surprising, since Haskell compiles natively, and so isn't relying on some VM translation layer. The headaches you have with, say, Java's JNI simply don't happen. The headaches you run into have more to do with getting Haskell to recognize where the relevant dev and runtime libraries are, especially on non-Unix systems where library locations are not standardized. It's possible, but you end up having to hack the Cabal package, a process that is not particularly well documented at the moment. Another issue is simple bitrot. Many libraries in Hackage were developed by students who have no interest in maintaining their thesis work post-graduation.