5 ms·

The best thing that exists in Haskell and nowhere else I've found isn't a library at all: It's the experience of grubbing around in unfamiliar libraries (in my

The best thing that exists in Haskell and nowhere else I've found isn't a library at all: It's the experience of grubbing around in unfamiliar libraries (in my case a database lib and a visualization lib), not knowing much Haskell and struggling to get the damn thing to compile. The very first time I got the types to line up, the program ran and I had my timeseries graph from the database. This is a magical, life changing experience. Any other language I've used would have been many iterations of, "this is null", "you passed a string where it was supposed to be a list of strings" (looking at you python)! Now that I know it's possible, I much prefer to do my thinking up front, and know that there's a compiler out there that's got my back :-)

alipang 13y ago
That's a property of libraries as well, for instance avoiding the perturbation problem at compile time with with ekmett's AD library. Many Haskell libraries are focused on allowing you to define entities that correspond to your desired semantics, while many libs in OO-languages are just about constructing the correct object-graph that happens to give you the result you want.
- gnuvince 13y ago
  Could you please elaborate on this perturbation problem? It's the first time I hear that term.
  - eru 13y ago
    http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differentiation/ http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differenti... was linked in the reddit comment.
vidarh 13y ago
I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that. Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).
- dllthomas 13y ago
  I think better guidance and inspection in figuring out type errors would be of huge value in Haskell.
  - boothead 13y ago
    Have a google for "hole driven development haskell" for a few possible ideas.
    - tel 13y ago
      Oh! Yes! Coding in Agda is incredible sometimes.
    - dllthomas 13y ago
      Right, I didn't mean to imply there was nothing interesting happening in that direction!
- mietek 13y ago
  > I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. When do you determine you've gotten it to execute correctly? Achievement Unlocked: You Can Stop Testing Now?
  - coldtea 13y ago
    That you get the results you expect. How is that any different from Haskell? You think that merely lining up types and having it compile determines that it also "executes correctly"? There are also algorithmic and other mistakes.
    - asdasf 13y ago
      >How is that any different from Haskell? With haskell, the compiler verified tons of possible errors to guarantee against them. With smalltalk, you verified those tons of possible errors yourself. People make mistakes.
6d0debc071 13y ago
> Any other language I've used Have you tried Lisp? I've always found that to be a really friendly environment when it comes to working out why something doesn't work. :)
- tel 13y ago
  Haskell doesn't need to provide a nice environment for working out why something didn't work—the compiler tends to just tell you precisely why your program isn't working. It's a bit cryptic to learn its language to start, but I seriously executed a 10 module refactoring yesterday by just going in, changing the core code, and then letting the compiler spit out a categorical list of each place that broke and the exact fix needed. Edit: that said, it still has one. GHCi is a nice Repl.
nawitus 13y ago
Isin't that true for statically typed languageS?
- boothead 13y ago
  Partially, but not the the same level as Haskell. It's pretty easy to get broken code past the compiler in C# for example.
  - nawitus 13y ago
    Could you give some concrete examples?
    - boothead 13y ago
      NullReferences in C# (and lots of other languages).
    - Peaker 13y ago
      First example is nullability. Anders says ~50% of production issues with c# involve null deference errors. Haskell tags in compile time which types may or may not be null. In c# if your method is supposed to return one thing and set an object attribute of another, and you forget setting the attribute, the compiler won't help. In Haskell, you don't use mutability much, instead you return both things. If you forget to return it you get help from the compiler. Another example: in Haskell, you write a sort function but you forget to handle the base case (always returning an empty list instead). You get an inferred type like: sort :: Ord a => [a] -> [b] Which tells you you forgot to actually return the elements. Another example, in Haskell you can represent a red black/avl/b tree while also type encoding all the invariants. For rbtree this type level encoding is about 7 short lines long. Then all the dozens or hundreds of lines of code implementing the tree are guaranteed to maintain the invariants, no unit testing needed at all. Another example, ST is a monad that let's you write deterministic imperative computations that can be wrapped with a pure interface (hiding the imperative innards). A small RankNType and a phantom type are used to tag both the ST computations and the mutable data, giving a compile time guarantee that mutable data doesn't leak between different computations. This guarantee means you can trust ST computations to actually be independent and thus the pure interface is safe.
arh68 13y ago
Though it won't surprise you, OCaml development is very similar. You're right: it's like shining a UV light on my code and seeing all the type mismatch bugs.

alipang 13y ago

That's a property of libraries as well, for instance avoiding the perturbation problem at compile time with with ekmett's AD library. Many Haskell libraries are focused on allowing you to define entities that correspond to your desired semantics, while many libs in OO-languages are just about constructing the correct object-graph that happens to give you the result you want.

gnuvince 13y ago
Could you please elaborate on this perturbation problem? It's the first time I hear that term.
- eru 13y ago
  http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differentiation/ http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differenti... was linked in the reddit comment.

vidarh 13y ago

I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that. Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).

dllthomas 13y ago
I think better guidance and inspection in figuring out type errors would be of huge value in Haskell.
- boothead 13y ago
  Have a google for "hole driven development haskell" for a few possible ideas.
  - tel 13y ago
    Oh! Yes! Coding in Agda is incredible sometimes.
  - dllthomas 13y ago
    Right, I didn't mean to imply there was nothing interesting happening in that direction!
mietek 13y ago
> I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. When do you determine you've gotten it to execute correctly? Achievement Unlocked: You Can Stop Testing Now?
- coldtea 13y ago
  That you get the results you expect. How is that any different from Haskell? You think that merely lining up types and having it compile determines that it also "executes correctly"? There are also algorithmic and other mistakes.
  - asdasf 13y ago
    >How is that any different from Haskell? With haskell, the compiler verified tons of possible errors to guarantee against them. With smalltalk, you verified those tons of possible errors yourself. People make mistakes.

6d0debc071 13y ago

> Any other language I've used Have you tried Lisp? I've always found that to be a really friendly environment when it comes to working out why something doesn't work. :)

tel 13y ago
Haskell doesn't need to provide a nice environment for working out why something didn't work—the compiler tends to just tell you precisely why your program isn't working. It's a bit cryptic to learn its language to start, but I seriously executed a 10 module refactoring yesterday by just going in, changing the core code, and then letting the compiler spit out a categorical list of each place that broke and the exact fix needed. Edit: that said, it still has one. GHCi is a nice Repl.

nawitus 13y ago

Isin't that true for statically typed languageS?

boothead 13y ago
Partially, but not the the same level as Haskell. It's pretty easy to get broken code past the compiler in C# for example.
- nawitus 13y ago
  Could you give some concrete examples?
  - boothead 13y ago
    NullReferences in C# (and lots of other languages).
  - Peaker 13y ago
    First example is nullability. Anders says ~50% of production issues with c# involve null deference errors. Haskell tags in compile time which types may or may not be null. In c# if your method is supposed to return one thing and set an object attribute of another, and you forget setting the attribute, the compiler won't help. In Haskell, you don't use mutability much, instead you return both things. If you forget to return it you get help from the compiler. Another example: in Haskell, you write a sort function but you forget to handle the base case (always returning an empty list instead). You get an inferred type like: sort :: Ord a => [a] -> [b] Which tells you you forgot to actually return the elements. Another example, in Haskell you can represent a red black/avl/b tree while also type encoding all the invariants. For rbtree this type level encoding is about 7 short lines long. Then all the dozens or hundreds of lines of code implementing the tree are guaranteed to maintain the invariants, no unit testing needed at all. Another example, ST is a monad that let's you write deterministic imperative computations that can be wrapped with a pure interface (hiding the imperative innards). A small RankNType and a phantom type are used to tag both the ST computations and the mutable data, giving a compile time guarantee that mutable data doesn't leak between different computations. This guarantee means you can trust ST computations to actually be independent and thus the pure interface is safe.

arh68 13y ago

Though it won't surprise you, OCaml development is very similar. You're right: it's like shining a UV light on my code and seeing all the type mismatch bugs.