11 ms·

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
    This is not an opinion thing. If you’re saying that type checkers can reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of a proof to how this is possible. And what is this magic type system that can do this, bc it sounds like some super AI. The reason I’m confident in my objections is because this is what I get from static typing fundamentalists: never a concession as to its cons and costs. Is it that static typers can’t see the relative costs bc they are not using the full power of dynamic languages?
    - mbrodersen 7y ago
      > This is not an opinion thing. Of course it is an opinion thing. > never a concession as to its cons and costs. Pretty much what I get all the time from people who don't know how to use type systems productively, and then think that because they can't nobody else can. If types doesn't work for you, don't use them. They work for me so I use them.
      - wellpast 7y ago
        I can use strong typing productively. I can use dynamic systems _way_ more productively. When all things are equal, the impedance is not from lack of skill. It is staring at you straight in the face: it's a rules-based type prover that -- by definition -- significantly restricts the set of valid programs. This is the definition of a type prover. The argument should be that the value of this restriction outweighs the cost. But no one is yet making this claim. Which should make one wonder.
        mbrodersen 7y ago
        > But no one is yet making this claim. Which should make one wonder. I for one are most definitely making that claim. Based on 35+ years of programming in both single typed and typed programming languages. But clearly your experience is different.
    - mbrodersen 7y ago
- tome 7y ago
  If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.
  - wellpast 7y ago
    Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.
    - wellpast 7y ago
      And these are insanely expensive to deal with over time when you compare to the alternative.
      - mbrodersen 7y ago
        > insanely expensive Wow that sounds really expensive! How did you actually measure that in the real world?
        wellpast 7y ago
        I spent too many years programming in all kinds of dynamically typed and statically typed systems and I kept a clear head and didn't cling to a blind religious persuasion. I've also watched the performance of static type enthusiasts closely. I thought that when I updated a type that all of my running around fixing type errors had to do with me missing something but alas that was not the case. This is how the static enthusiasts do their work, all the while claiming that they are being more productive. When I call a static typer our on this the answer is always the same: "But you'd have to go update those case statements/maybe matches/type signatures anyway!" Meanwhile I'm over in a dynamic system not having to do any of that. Refactors are minimal not cross-the-entire-codebase. Static type systems are training wheels. When a static type enthusiast takes his training wheels off, the bike falls over and s/he screams "See! I told you. I'm more productive with types!" And then they put the training wheels back on and think that they have proven that static verification is superior. What they don't know is that there is enormous missed opportunity once you learn how to ride a bike w/o training wheels. The truth is you can produce much faster without a rules-based static type prover between you and your runtime environment if you know what you're doing. This should be obvious b/c in one world you have a filter/prover that you must past to ship. In the other world you do not. If the filter/prover was worth its weight then you should be able to clearly see the win. But in business systems the kinds of bugs found by filter/provers are of the "null pointer" variety -- the fastest and simplest bugs to fix when they are found; having a heavyweight filter/prover save me from these simplest of bugs to fix is simply not worth it.
- mbrodersen 7y ago
  > My claim is this is death to productivity/throughput when you compare it to alternatives. A claim with no evidence to back it up. My experience (for example) is exactly the opposite.

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
  This is not an opinion thing. If you’re saying that type checkers can reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of a proof to how this is possible. And what is this magic type system that can do this, bc it sounds like some super AI. The reason I’m confident in my objections is because this is what I get from static typing fundamentalists: never a concession as to its cons and costs. Is it that static typers can’t see the relative costs bc they are not using the full power of dynamic languages?
  - mbrodersen 7y ago
    > This is not an opinion thing. Of course it is an opinion thing. > never a concession as to its cons and costs. Pretty much what I get all the time from people who don't know how to use type systems productively, and then think that because they can't nobody else can. If types doesn't work for you, don't use them. They work for me so I use them.
    - wellpast 7y ago
      I can use strong typing productively. I can use dynamic systems _way_ more productively. When all things are equal, the impedance is not from lack of skill. It is staring at you straight in the face: it's a rules-based type prover that -- by definition -- significantly restricts the set of valid programs. This is the definition of a type prover. The argument should be that the value of this restriction outweighs the cost. But no one is yet making this claim. Which should make one wonder.
      - mbrodersen 7y ago
        > But no one is yet making this claim. Which should make one wonder. I for one are most definitely making that claim. Based on 35+ years of programming in both single typed and typed programming languages. But clearly your experience is different.
  - mbrodersen 7y ago
tome 7y ago
If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.
- wellpast 7y ago
  Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.
  - wellpast 7y ago
    And these are insanely expensive to deal with over time when you compare to the alternative.
    - mbrodersen 7y ago
      > insanely expensive Wow that sounds really expensive! How did you actually measure that in the real world?
      - wellpast 7y ago
        I spent too many years programming in all kinds of dynamically typed and statically typed systems and I kept a clear head and didn't cling to a blind religious persuasion. I've also watched the performance of static type enthusiasts closely. I thought that when I updated a type that all of my running around fixing type errors had to do with me missing something but alas that was not the case. This is how the static enthusiasts do their work, all the while claiming that they are being more productive. When I call a static typer our on this the answer is always the same: "But you'd have to go update those case statements/maybe matches/type signatures anyway!" Meanwhile I'm over in a dynamic system not having to do any of that. Refactors are minimal not cross-the-entire-codebase. Static type systems are training wheels. When a static type enthusiast takes his training wheels off, the bike falls over and s/he screams "See! I told you. I'm more productive with types!" And then they put the training wheels back on and think that they have proven that static verification is superior. What they don't know is that there is enormous missed opportunity once you learn how to ride a bike w/o training wheels. The truth is you can produce much faster without a rules-based static type prover between you and your runtime environment if you know what you're doing. This should be obvious b/c in one world you have a filter/prover that you must past to ship. In the other world you do not. If the filter/prover was worth its weight then you should be able to clearly see the win. But in business systems the kinds of bugs found by filter/provers are of the "null pointer" variety -- the fastest and simplest bugs to fix when they are found; having a heavyweight filter/prover save me from these simplest of bugs to fix is simply not worth it.
mbrodersen 7y ago
> My claim is this is death to productivity/throughput when you compare it to alternatives. A claim with no evidence to back it up. My experience (for example) is exactly the opposite.