5 ms·

This is exactly the sort of thing Haskell is great at. First, the type system catches all sorts of errors at compile time (both null-pointer and printf issues c

by tikhonj 15y ago

This is exactly the sort of thing Haskell is great at. First, the type system catches all sorts of errors at compile time (both null-pointer and printf issues cannot come up in Haskell). However, more fundamentally, Haskell code just naturally provides much more information to static analysis tools than any other language I've worked with. Even if the level of tooling is not there yet (I haven't worked on any large projects, so I am not entirely familiar with it) the potential for these tools is much greater in Haskell. I think programs like HLint are already very thorough. I've just been using Haskell as more of a hacker language than a "bondage and discipline" language and haven't bothered with these tools :)

DanWaterworth 15y ago
Whenever I try to write code in Haskell that produces a type error I think, "there's another bug that would have been introduced in a lesser language".
- LearnYouALisp 15y ago
  Would a type error necessarily produce a "bug" in a program?
  - DanWaterworth 15y ago
    It certainly would if it was not detected before the code was deployed. Depending on how strongly typed the language is, it may cause an error at runtime, which isn't ideal, or it would go undetected until it caused a myriad of seemingly unrelated symptoms, which is much worse. Unhandled null references are the most common type error that other languages don't catch as readily (I fairly frequently try to write code that doesn't handle the not found case in a map lookup), but there are so many times when I've tried to write code that the compiler has rejected, but that wouldn't have been picked up in other static languages.
    - LearnYouALisp 15y ago
      Thank you for explaining. I had thought of type errors as different representations of numbers, for example.
syaramak 15y ago
I'm curious to know if this is because Haskell doesnt support nulls or is there something else that makes it better at catching type errors.
- DanWaterworth 15y ago
  Not having nulls for every type is just the tip of the iceberg, there's so much information contained within the type of values and it's so easy to add even more.
- masklinn 15y ago
  It's better at catching type error in general (because it's much stricter in its handling of types), having moved the concept of nullability into the type system is just an (easy to understand, for most developers) example of that. But it goes beyond that, even more so as the haskell culture builds upon this and actively encourages taking advantage of the type system by encoding as many things as possible in the program's types, where they can be statically checked.
- Tuna-Fish 15y ago
  Haskell's type system is really not at all comparable to the ones found in c and Java. Not only is the Haskell type system Turing-complete, I'd be willing to argue that it's more expressive (and I mean the type system itself, not the whole language...) than a lot of mainstream languages. Basically, it's a whole different animal from the things most programmers call type systems. For example, the type system doesn't just handle values, doing actions is also managed by the type system. The type of main is IO (), which roughly means "do something with side-effects". If I write a function that reads in a file and returns a string, it's type is not String, it's IO String, or, "do an action, which causes a String to be returned". I can shuffle this around at will, and use the IO monad to handle running the program in correct order. And IO is just a single way of managing order -- continuation passing is just another monad in the type system, that didn't even need any additional code in the compiler to implement. But what really makes the difference from Java or C++ imho is the type inference. Basically, if you never write a type declaration, the only time the type system bothers you is when there really is a bug in the code. Psychologically, this is a big deal. In Java, the type system is a chore that makes me type unnecessary things. In Haskell, the type system is a compile-time check that catches a lot of real errors.
joeyh 15y ago
I agree, however I find keeping good code coverage in tests is still important in haskell. The other day I had to fix a bug that I had introduced while running hlint in a module that was not being tested. Oops. WRT hlint, I've not seen it point out any actual bugs in code, it only finds ways to golf it, in my experience. It doesn't even find a few common performance impacting mistakes like length foo > 0 ==> not (null foo). OTOH, its quite a beautiful tool, especially if you look at the implementation of checks, which is this simple and beautiful: error = take (length x - 1) x ==> init x

by tikhonj 15y ago

DanWaterworth 15y ago

Whenever I try to write code in Haskell that produces a type error I think, "there's another bug that would have been introduced in a lesser language".

LearnYouALisp 15y ago
Would a type error necessarily produce a "bug" in a program?
- DanWaterworth 15y ago
  It certainly would if it was not detected before the code was deployed. Depending on how strongly typed the language is, it may cause an error at runtime, which isn't ideal, or it would go undetected until it caused a myriad of seemingly unrelated symptoms, which is much worse. Unhandled null references are the most common type error that other languages don't catch as readily (I fairly frequently try to write code that doesn't handle the not found case in a map lookup), but there are so many times when I've tried to write code that the compiler has rejected, but that wouldn't have been picked up in other static languages.
  - LearnYouALisp 15y ago
    Thank you for explaining. I had thought of type errors as different representations of numbers, for example.

syaramak 15y ago

I'm curious to know if this is because Haskell doesnt support nulls or is there something else that makes it better at catching type errors.

DanWaterworth 15y ago
Not having nulls for every type is just the tip of the iceberg, there's so much information contained within the type of values and it's so easy to add even more.
masklinn 15y ago
It's better at catching type error in general (because it's much stricter in its handling of types), having moved the concept of nullability into the type system is just an (easy to understand, for most developers) example of that. But it goes beyond that, even more so as the haskell culture builds upon this and actively encourages taking advantage of the type system by encoding as many things as possible in the program's types, where they can be statically checked.
Tuna-Fish 15y ago
Haskell's type system is really not at all comparable to the ones found in c and Java. Not only is the Haskell type system Turing-complete, I'd be willing to argue that it's more expressive (and I mean the type system itself, not the whole language...) than a lot of mainstream languages. Basically, it's a whole different animal from the things most programmers call type systems. For example, the type system doesn't just handle values, doing actions is also managed by the type system. The type of main is IO (), which roughly means "do something with side-effects". If I write a function that reads in a file and returns a string, it's type is not String, it's IO String, or, "do an action, which causes a String to be returned". I can shuffle this around at will, and use the IO monad to handle running the program in correct order. And IO is just a single way of managing order -- continuation passing is just another monad in the type system, that didn't even need any additional code in the compiler to implement. But what really makes the difference from Java or C++ imho is the type inference. Basically, if you never write a type declaration, the only time the type system bothers you is when there really is a bug in the code. Psychologically, this is a big deal. In Java, the type system is a chore that makes me type unnecessary things. In Haskell, the type system is a compile-time check that catches a lot of real errors.

joeyh 15y ago

I agree, however I find keeping good code coverage in tests is still important in haskell. The other day I had to fix a bug that I had introduced while running hlint in a module that was not being tested. Oops. WRT hlint, I've not seen it point out any actual bugs in code, it only finds ways to golf it, in my experience. It doesn't even find a few common performance impacting mistakes like length foo > 0 ==> not (null foo). OTOH, its quite a beautiful tool, especially if you look at the implementation of checks, which is this simple and beautiful: error = take (length x - 1) x ==> init x