7 ms·

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

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
        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.
- tome 7y ago
  astuary is not suggesting opting out of Haskell’s type system. He/she is suggesting using constructs whose interaction with the type system is straightforward.
- mbrodersen 7y ago
  > And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind. Not my experience at all. I switched from Javascript to Typescript and I am way more productive now. So it is definitely not in general true that "the programming ergonomics will be terrible vs. a language designed with typelessness in mind".

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
      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.
tome 7y ago
astuary is not suggesting opting out of Haskell’s type system. He/she is suggesting using constructs whose interaction with the type system is straightforward.
mbrodersen 7y ago
> And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind. Not my experience at all. I switched from Javascript to Typescript and I am way more productive now. So it is definitely not in general true that "the programming ergonomics will be terrible vs. a language designed with typelessness in mind".