4 ms·

This post is painfully confusing the important concepts of complexity & "complecting"/coupling. Javascript's this semantics may be confusing and hard to reason

This post is painfully confusing the important concepts of complexity & "complecting"/coupling. Javascript's this semantics may be confusing and hard to reason about but that is a different charge than the complecting/coupling sort of complexity which is the _much, much_ bigger problem in the world of building software systems. The much bigger problem with a Person class is not to do with this or that programming language vagaries vis a vis the this keyword. The bigger problem exists in all programming languages: ADTs like Person classes introduce unnecessary coupling of information -- and this is what really matters: this is what hurts productivity. It sucks that I have to learn the finicky vagaries of this in Javascript, but once I do, I'm fairly good going forward. However, no amount of learning on my side is going to help me when I need to add new pieces of information to some people data -- your ADT has decided for and _requires_ me to jam my knowledge and facts into an unnecessary rigid categorization in order to evolve your ADT-ridden data processing system. This post's refactoring of class hasn't changed that game for me. You've just moved this to each function's first parameter and called it "person" -- so while you've saved me momentarily from having to learn about this semantics[1], you haven't gotten rid of the truly offensive bit: the whole notion of the "person" classification itself and the rigid, upfront, unnecessary, and likely-to-be-wrong-in-the-future assumption that only its members can be given these things called names. [1] Which I should have learnt anyway being a Javascript programmer.

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.

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.