3 ms·

> The Haskell type system is just a set of tools I can use to organize my software and help ensure it's both ergonomic and easy to use. If it were “just a set

> The Haskell type system is just a set of tools I can use to organize my software and help ensure it's both ergonomic and easy to use. If it were “just a set of tools” then it would be weakly typed. Tools are by their very nature a la carte and don’t insist upon themselves. Strong static typing insists itself; otherwise it’d be a la carte/optional/weak. Edit: typo

whateveracct 7y ago
I can choose how typed my code is. The existence of extremely strong typing facilities doesn't mean I have to use them to the max at every turn. Hence, the types are a set of tools I can use to craft interfaces. And the fact that I can impose constraints on my callers so that they can't accidentally call my code wrong, all the better. And in my experience, despite Haskell being quite niche, its library quality and ease-of-use is very good. The ecosystem's main weakness is lack of libraries for things period. When they exist, they tend to be nice. Types help with this directly as well.
- wellpast 7y ago
  > I can impose constraints on my callers so that they can't accidentally call my code wrong, all the better. This is precisely the mentality that impedes productivity in typical business delivery case. If your callers are not thinking in terms of contracts (precondition/postcondition) then you've hired the wrong "callers"; some amount of type checking may save you in some cases but your function contracts go far, far beyond the type signature - and here, with callers you can't trust, you're screwed anyway and types won't save you (and it sounds like they've given you a false sense of security.) Better to build a process and expertise that increases correctness for the entire function contract not just the narrow bit that can be expressed in a type.
  - whateveracct 7y ago
    Haskell function contracts don't tend to go that far beyond a type signature. Partially because what can be expressed in the type isn't that narrow nowadays. The situation you're describing is a gigantic strawman per my years of professional FP experience.

whateveracct 7y ago

I can choose how typed my code is. The existence of extremely strong typing facilities doesn't mean I have to use them to the max at every turn. Hence, the types are a set of tools I can use to craft interfaces. And the fact that I can impose constraints on my callers so that they can't accidentally call my code wrong, all the better. And in my experience, despite Haskell being quite niche, its library quality and ease-of-use is very good. The ecosystem's main weakness is lack of libraries for things period. When they exist, they tend to be nice. Types help with this directly as well.

wellpast 7y ago
> I can impose constraints on my callers so that they can't accidentally call my code wrong, all the better. This is precisely the mentality that impedes productivity in typical business delivery case. If your callers are not thinking in terms of contracts (precondition/postcondition) then you've hired the wrong "callers"; some amount of type checking may save you in some cases but your function contracts go far, far beyond the type signature - and here, with callers you can't trust, you're screwed anyway and types won't save you (and it sounds like they've given you a false sense of security.) Better to build a process and expertise that increases correctness for the entire function contract not just the narrow bit that can be expressed in a type.
- whateveracct 7y ago
  Haskell function contracts don't tend to go that far beyond a type signature. Partially because what can be expressed in the type isn't that narrow nowadays. The situation you're describing is a gigantic strawman per my years of professional FP experience.