6 ms·

I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or a

I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity. However - when one (ie, a Haskeller) says that the code must universally pass 100% strong static type verification coverage -- arguably SO MUCH worse cost/benefit than unit testing -- and you say "no that's impractical" it's suddenly a different game. The elephant in the room is this. Haskell and strongly typed languages are highly impractical, academic pursuits. They do not at all respect the dynamism of the real world. You can certainly build production systems in any language including Haskell but by picking Haskell you are throwing sticks between your legs unnecessarily.

astuary 7y ago
Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. I agree that haskellers have a tendency to disregard the cost of using sophisticated type machinery. Which is unfortunate because haskell's greatest strength (IMO) is its ability to opt in to strong static verification for the 10% of code where it provides the most value.
- wellpast 7y ago
  > Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do-able" but only in a sense. And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind.
  - rawburt 7y ago
    This is opinion. Haskellers have opinions too. Whatever you like and whatever gets the job done: bravo
    - wellpast 7y ago
      Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is death to productivity/throughput when you compare it to alternatives. The death part can be argued --the best leg Haskellers can stand on afaict is that overall throughput is increased due to decreased attention to the kinds of bugs prevented by strong typing. This needs to be proven by them. Otherwise -- by definition -- strong type systems are asking you to take special care to meet a type proof that is not necessary to do to implement correctness in other PLs. Every time I've implemented a solution in a strongly typed system I always run into the type prover complaining about something that Might be but that I can prove is not the case. Here is the limit of the type checker - it is simply not aware enough to understand what we're doing. So it puts needless requirements left & right. This is hostile to productivity. Now you go.
      - hderms 7y ago
        I believe you're exaggerating the frequency that the compiler rejects valid programs. It happens, but no more frequently than random runtime type errors occur in dynamic code. In any case, one can just as easily argue that the value of static types come not just when the code is first written, but under the legion of modifications that need to occur. Not to mention how self documenting it is which also aids modification. Some people just don't like static typing, which is fine, but making the statement that it's categorically worse is hard to defend.
        wellpast 7y ago
verttii 7y ago
> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage. Obviously, these things are not totally mutually exclusive though.
- wellpast 7y ago
  If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster. What are the two static & dynamic languages you’re comparing by the way?
  - verttii 7y ago
    For example now I'm building a Servant API on Haskell. It's basically a strongly typed API that you don't need to validate with tests. You only need to test the handlers that handle business logic. In other languages with a less sophisticated type systems I would need to build validation functions manually and obviously test them. Hell, an interpreted language might even boot up with functions that have faulty code, ultimately producing runtime errors when invoked. Haskell generally would not (because of the type system). Adding type constraints basically limits the range of possible inputs/outputs, requiring you to write far less tests.
  - mbrodersen 7y ago
    My examples would be Javascript vs Typescript. I am SO much more productive in Typescript than in Javascript and the number of bugs have dropped substantially.
mbrodersen 7y ago
> by picking Haskell you are throwing sticks between your legs unnecessarily. You clearly have no idea how types work and how to use it to make you more productive as a developer. Being able to switch from Javascript to Typescript made me so much more productive.

astuary 7y ago

Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. I agree that haskellers have a tendency to disregard the cost of using sophisticated type machinery. Which is unfortunate because haskell's greatest strength (IMO) is its ability to opt in to strong static verification for the 10% of code where it provides the most value.

wellpast 7y ago
> Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do-able" but only in a sense. And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind.
- rawburt 7y ago
  This is opinion. Haskellers have opinions too. Whatever you like and whatever gets the job done: bravo
  - wellpast 7y ago
    Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is death to productivity/throughput when you compare it to alternatives. The death part can be argued --the best leg Haskellers can stand on afaict is that overall throughput is increased due to decreased attention to the kinds of bugs prevented by strong typing. This needs to be proven by them. Otherwise -- by definition -- strong type systems are asking you to take special care to meet a type proof that is not necessary to do to implement correctness in other PLs. Every time I've implemented a solution in a strongly typed system I always run into the type prover complaining about something that Might be but that I can prove is not the case. Here is the limit of the type checker - it is simply not aware enough to understand what we're doing. So it puts needless requirements left & right. This is hostile to productivity. Now you go.
    - hderms 7y ago
      I believe you're exaggerating the frequency that the compiler rejects valid programs. It happens, but no more frequently than random runtime type errors occur in dynamic code. In any case, one can just as easily argue that the value of static types come not just when the code is first written, but under the legion of modifications that need to occur. Not to mention how self documenting it is which also aids modification. Some people just don't like static typing, which is fine, but making the statement that it's categorically worse is hard to defend.
      - wellpast 7y ago

verttii 7y ago

> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage. Obviously, these things are not totally mutually exclusive though.

wellpast 7y ago
If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster. What are the two static & dynamic languages you’re comparing by the way?
- verttii 7y ago
  For example now I'm building a Servant API on Haskell. It's basically a strongly typed API that you don't need to validate with tests. You only need to test the handlers that handle business logic. In other languages with a less sophisticated type systems I would need to build validation functions manually and obviously test them. Hell, an interpreted language might even boot up with functions that have faulty code, ultimately producing runtime errors when invoked. Haskell generally would not (because of the type system). Adding type constraints basically limits the range of possible inputs/outputs, requiring you to write far less tests.
- mbrodersen 7y ago
  My examples would be Javascript vs Typescript. I am SO much more productive in Typescript than in Javascript and the number of bugs have dropped substantially.

mbrodersen 7y ago

> by picking Haskell you are throwing sticks between your legs unnecessarily. You clearly have no idea how types work and how to use it to make you more productive as a developer. Being able to switch from Javascript to Typescript made me so much more productive.