3 ms·

"It doesn’t really. I’m not claiming this works with standard Haskell practice." Then I don't understand where you disagree with me. I'm not saying assoc-in is

"It doesn’t really. I’m not claiming this works with standard Haskell practice." Then I don't understand where you disagree with me. I'm not saying assoc-in is impossible; just that it's impractical. We can write assoc-in with dynamic types, but that doesn't integrate with existing functions, and is generally a pain to work with. Alternatively we can try and to statically type it, but then we run into the limitations of Haskell's type system. assoc-in is a solution that doesn't really work in Haskell, because the constraints of the language prevent it. Adding static typing to a language adds practical limitations in exchange for compiler guarantees.

tel 9y ago
I disagree it’s impractical—it’s just not valuable. Assoc-In reads as convenient to you, and it is if you’ve already thrown away type information, and reads as destructive to me, a force for destroying information. Lenses aren’t better because they’re inconvenient but happen to work with types. They’re better because they properly relate to the typing context and persist important information. Lenses in dynamically typed languages don’t exploit this fact and usually are implemented in a way that’s “easy” but destructive. What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction. To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze. I want my programs to have meaning both as runtime interpretations and as logical statements. I can choose other type systems to satisfy this balance, but if you just side with “power to create” then I think you lose big.
- weavejester 9y ago
  "What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction." That's not quite how I see things: I see static typing as a constraint that trades solutions for guarantees. "To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze." I don't believe that power and convenience should be pursued above all other considerations; if I did, do you think I'd use a language where data structures are immutable by default? Immutability is a significant constraint, yet clearly I think it worth the cost. Constraints like static typing and immutability are useful only if the guarantees they deliver are worth more than the solutions they remove. You say that assoc-in is "not valuable", because it cannot easily be written without discarding type information; it's a net loss, because type information is more valuable to you. Where we ultimately disagree, I think, is the value we place upon static types. I don't think they're particularly valuable at all. Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. But my problem is not that you disagree with me over how valuable static types are, but that you seem to think they're not a trade-off. Forgive me if I've misunderstood you, but you don't seem to acknowledge that static types have any disadvantages associated with them at all.
  - tel 9y ago
    > Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. This value difference is indeed core. I value them exactly as "information that can be discerned from reading a program without having to try to execute it in your brain". There is a cost to retaining this information in that there exist programs which have operational meaning but lack this structure. At the same time, I think that this information is incredibly valuable. So, yes, if you don't see the benefit then there's little more to say.

tel 9y ago

I disagree it’s impractical—it’s just not valuable. Assoc-In reads as convenient to you, and it is if you’ve already thrown away type information, and reads as destructive to me, a force for destroying information. Lenses aren’t better because they’re inconvenient but happen to work with types. They’re better because they properly relate to the typing context and persist important information. Lenses in dynamically typed languages don’t exploit this fact and usually are implemented in a way that’s “easy” but destructive. What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction. To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze. I want my programs to have meaning both as runtime interpretations and as logical statements. I can choose other type systems to satisfy this balance, but if you just side with “power to create” then I think you lose big.

weavejester 9y ago
"What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction." That's not quite how I see things: I see static typing as a constraint that trades solutions for guarantees. "To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze." I don't believe that power and convenience should be pursued above all other considerations; if I did, do you think I'd use a language where data structures are immutable by default? Immutability is a significant constraint, yet clearly I think it worth the cost. Constraints like static typing and immutability are useful only if the guarantees they deliver are worth more than the solutions they remove. You say that assoc-in is "not valuable", because it cannot easily be written without discarding type information; it's a net loss, because type information is more valuable to you. Where we ultimately disagree, I think, is the value we place upon static types. I don't think they're particularly valuable at all. Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. But my problem is not that you disagree with me over how valuable static types are, but that you seem to think they're not a trade-off. Forgive me if I've misunderstood you, but you don't seem to acknowledge that static types have any disadvantages associated with them at all.
- tel 9y ago
  > Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. This value difference is indeed core. I value them exactly as "information that can be discerned from reading a program without having to try to execute it in your brain". There is a cost to retaining this information in that there exist programs which have operational meaning but lack this structure. At the same time, I think that this information is incredibly valuable. So, yes, if you don't see the benefit then there's little more to say.