5 ms·

What do you mean by ADTs introduce unnecessary coupling of information? ADTs allow you to clarify and safely handle otherwise vague data. Maybe I'm misunderstan

by s4vi0r 9y ago

What do you mean by ADTs introduce unnecessary coupling of information? ADTs allow you to clarify and safely handle otherwise vague data. Maybe I'm misunderstanding, but your comment reads to me like you're in support of stringly typed programming.

wellpast 9y ago
> ADTs allow you to clarify and safely handle otherwise vague data. This is false. You can program with clear, strong, safe semantics without needing to taxonomize/classify your business domain/entities with ADTs. In most business applications, ADTs hurt you: they are used to pre-classify the world in ways (unnecessary ways) that very frequently collide with future system evolution & future use-cases.
- always_good 9y ago
  That doesn't seem to have anything to do with ADTs but rather all code in general. I'm not sure how "// request.user will be undefined or { id, uname }" is any more future durable or omniscient than `Request.User : Guest | LoggedIn User`. The latter just encodes the possible states directly and explicitly. Your line of reasoning is like saying that Mongo lets you adapt to future requirements better than Postgres because you don't have a schema.
  - wellpast 9y ago
    > The latter just encodes the possible states directly and explicitly. The very concept of "possible states" is the problem. By deciding that your domain entity has possible valid states in all situations (which is more or less what an ADT is saying), therein is the coupling, the pain, the productivity impediment. Not only do you not need to say that for all moments and places in my program a person must have a { id, name, uname, age, etc, etc }, it hurts you to assert that because the future is always much more creative than you and will soon put demands that exceed the assertion. > Your line of reasoning is like saying that Mongo lets you adapt to future requirements better than Postgres because you don't have a schema. Yes, that's precisely correct. As anyone who has had to collaborate across multiple features and/or teams can attest. In a NoSQL like system, I can bring in a new fact/information without flinching. In Postgres, I have to negotiate with the schema system and all of the consumers of the data, which obviously isn't necessary b/c NoSQL. (What Postgres may buy you is some transactional semantics and other relational db goodies etc but it is certainly not buying you adaptability/agility over the NoSQL/NoSchema store.)
    - s4vi0r 9y ago
      Can you clarify your argument/provide a possible solution? Your line of thinking seems kind of absurd to me - "Hey, we can't possibly predict our data model requirements in the future, and explicitly encoding them into a schema/ADT/etc hinders flexibility (and somehow productivity?)" doesn't really hold up to scrutiny. Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. I feel like the same applies to ADTs - of course its more flexible to just have a free floating `name: String` or whatever, but then you also get to have the fun of validating your data all day as opposed to letting your compiler do the dirty work for you.
      - wellpast 9y ago
        > Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. It sounds like you don't really need clarification, that you've learned the same lessons I have, but that you're just prioritizing differently and explicitly choosing "stability and safety" over flexibility (adaptability/agility). I go the other way. The biggest software costs in my experience are wanting to pivot on this or that business idea/requirement but being severely hindered[1] due to some unnecessary data taxonomization decisions that are so woven into the code (via ADTs/entity types) presumably for "safety" or "stability". By locking things down with ADTs and type taxonomies you most certainly get stability, I won't argue with that. But that stability by definition is rigidity. I want things to be dynamic. I want to be able to readily change my code assets because in most business operations the future demands that. Do you get "safety" with this stability as well? Probably, perhaps - but this would warrant a whole conversation about what is safety. In a dynamic/agile business environment, I personally will give up a little bit of safety for agility and dynamism. Because having an easily-fixable bug show up in production is far less costly to me than being paralyzed by an increasingly rigid/"stable" system that is hard to modify for future purposes. And even if I'm truly worried about bug volume, I can decouple that concern with the code agility concern. That is, I don't have to weave my bug mitigation concern into my codebase via hard type taxonomies. I can use other measures like code reviews, QA & testing, etc. and turn the knob up or down on these as a I see fit. The systems that weave all these concerns together in my experience always become harder and harder to bring new capability into. This is and should be no surprise, though. The world does not fit neatly into static, hard-line taxonomies. Our OCD minds would love it if it they did and people really try to make it fit into that (hence all the ADT hoopla we see everywhere) -- but in my experience the world always finds creative ways to frustrate our taxonomies...and systems that predicate themselves on a taxonomy always get frustrated by that. [1] Severely hindered means that something that should take very little time with very little impact on your app suite and very little coordination across the codebase(s) and team(s) instead requires all of these things.

by s4vi0r 9y ago

wellpast 9y ago

> ADTs allow you to clarify and safely handle otherwise vague data. This is false. You can program with clear, strong, safe semantics without needing to taxonomize/classify your business domain/entities with ADTs. In most business applications, ADTs hurt you: they are used to pre-classify the world in ways (unnecessary ways) that very frequently collide with future system evolution & future use-cases.

always_good 9y ago
That doesn't seem to have anything to do with ADTs but rather all code in general. I'm not sure how "// request.user will be undefined or { id, uname }" is any more future durable or omniscient than `Request.User : Guest | LoggedIn User`. The latter just encodes the possible states directly and explicitly. Your line of reasoning is like saying that Mongo lets you adapt to future requirements better than Postgres because you don't have a schema.
- wellpast 9y ago
  > The latter just encodes the possible states directly and explicitly. The very concept of "possible states" is the problem. By deciding that your domain entity has possible valid states in all situations (which is more or less what an ADT is saying), therein is the coupling, the pain, the productivity impediment. Not only do you not need to say that for all moments and places in my program a person must have a { id, name, uname, age, etc, etc }, it hurts you to assert that because the future is always much more creative than you and will soon put demands that exceed the assertion. > Your line of reasoning is like saying that Mongo lets you adapt to future requirements better than Postgres because you don't have a schema. Yes, that's precisely correct. As anyone who has had to collaborate across multiple features and/or teams can attest. In a NoSQL like system, I can bring in a new fact/information without flinching. In Postgres, I have to negotiate with the schema system and all of the consumers of the data, which obviously isn't necessary b/c NoSQL. (What Postgres may buy you is some transactional semantics and other relational db goodies etc but it is certainly not buying you adaptability/agility over the NoSQL/NoSchema store.)
  - s4vi0r 9y ago
    Can you clarify your argument/provide a possible solution? Your line of thinking seems kind of absurd to me - "Hey, we can't possibly predict our data model requirements in the future, and explicitly encoding them into a schema/ADT/etc hinders flexibility (and somehow productivity?)" doesn't really hold up to scrutiny. Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. I feel like the same applies to ADTs - of course its more flexible to just have a free floating `name: String` or whatever, but then you also get to have the fun of validating your data all day as opposed to letting your compiler do the dirty work for you.
    - wellpast 9y ago
      > Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. It sounds like you don't really need clarification, that you've learned the same lessons I have, but that you're just prioritizing differently and explicitly choosing "stability and safety" over flexibility (adaptability/agility). I go the other way. The biggest software costs in my experience are wanting to pivot on this or that business idea/requirement but being severely hindered[1] due to some unnecessary data taxonomization decisions that are so woven into the code (via ADTs/entity types) presumably for "safety" or "stability". By locking things down with ADTs and type taxonomies you most certainly get stability, I won't argue with that. But that stability by definition is rigidity. I want things to be dynamic. I want to be able to readily change my code assets because in most business operations the future demands that. Do you get "safety" with this stability as well? Probably, perhaps - but this would warrant a whole conversation about what is safety. In a dynamic/agile business environment, I personally will give up a little bit of safety for agility and dynamism. Because having an easily-fixable bug show up in production is far less costly to me than being paralyzed by an increasingly rigid/"stable" system that is hard to modify for future purposes. And even if I'm truly worried about bug volume, I can decouple that concern with the code agility concern. That is, I don't have to weave my bug mitigation concern into my codebase via hard type taxonomies. I can use other measures like code reviews, QA & testing, etc. and turn the knob up or down on these as a I see fit. The systems that weave all these concerns together in my experience always become harder and harder to bring new capability into. This is and should be no surprise, though. The world does not fit neatly into static, hard-line taxonomies. Our OCD minds would love it if it they did and people really try to make it fit into that (hence all the ADT hoopla we see everywhere) -- but in my experience the world always finds creative ways to frustrate our taxonomies...and systems that predicate themselves on a taxonomy always get frustrated by that. [1] Severely hindered means that something that should take very little time with very little impact on your app suite and very little coordination across the codebase(s) and team(s) instead requires all of these things.