5 ms·

Can you give a clear example on “thinking in types” approach ?

by atmosx 7y ago

CodeWriter23 7y ago
I can’t speak for the parent, but my take on it is a skilled programmer would define structs or classes, for example: parent, student, address While the unskilled would: parentfirstname, parentlastname, parentaddress1, .... studentpostcode
- userbinator 7y ago
  Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types". Incidentally, that's another thing about the difference between actually-skilled programmers and "pretenders": the former will always explain something in very simple terms, while the latter will try to use as much abstract and vague technical-sounding terms as possible.
  - dodobirdlord 7y ago
    I think that your response is overly accusatory, especially given that I think "grouping related data (and functions, if you're using OOP) together" is only one aspect of thinking in a type-oriented way, and not always necessary. A perhaps simpler, perhaps better example: Floats are lossy, but transactions in currency cannot be. An inexperienced developer might make the mistake of representing currency values as floats, while a more experienced developer would know to use some sort of BigDecimal. But the more experienced developer is still making a fatal error. Currencies have units, but BigDecimals do not. While BigDecimals can be added together, it is not meaningful to add Dollars to Euros. A developer who is "thinking in types" will define a numeric type for Dollars and a numeric type for Euros that cannot be added together.
    - orwin 7y ago
      I'm sorry, for me it still more of a "how to define data" that "thinking in type". Full disclosure, i would create a struct like this: typedef struct Transactions { int value; char currency; } Transaction; (sorry for the naming and the poor c code, i've not done any c since 2016). If the transaction value can be superior to 21 thousands (or if the code is deployed on a 32bit system, or if i want my floating point value high), maybe i would use a long, and probably an enum to keep track of the different currencies the second time i pass over the module. Maybe even a field (or a macro outside the struct) with the floating point value (4 to 6 seems good enough tbh). I'm an "int, char, loop" guy, at least at first, especially if i have to write something from scratch. Thinking in "object" or "type" makes me uncomfortable except when it is for interfaces (but GUI makes me uncomfortable too, so...). I feel this is inefficient, and that well-defined/organized data should not need such complex handlers in most cases.
  - CodeWriter23 7y ago
    > (via @ararwhatever) The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. > (via @userbinator) Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types". There's some nuance between what you two are saying. IMO the "related" vector (depending on the definition) is a potential driver of what I refer to as the "Single Class Application". Back to the OP example, the Shipment and Notification are related to an Order. The simple "related" question says it's ok to implement all of those in one class instead of three. The real questions to ask are about the specific relationship of possession. Does this attribute BELONG to this object or another? Does this object DO this action? These go a little beyond the typical OOP mantra of abstraction and encapsulation.
aastronaut 7y ago
Not GP, but the book 'Domain Modeling Made Functional' does explain advantages in modeling with types quite well.
kyberias 7y ago
It's the anti-pattern "Primitive obsession" https://refactoring.guru/smells/primitive-obsession https://refactoring.guru/smells/primitive-obsession Let's say, for example, that we need to handle distances in on our code with different units (meters and inches, for example). I've seen code bases that use integers or floating points for this and it's always confusing and error-prone what is the unit. In fact, you could accidentally use some other values (money) as distances. Instead, if your programming language allows this, you could define a type Distance and make sure that all the code that handles distances only use this Distance type. Everyone is forced to think about distances when maintaining the code, conversions routines are implemented and instantiated in one place etc.
- Insanity 7y ago
  This is why I like type defs in a language.

Can you give a clear example on “thinking in types” approach ?

by atmosx 7y ago

Can you give a clear example on “thinking in types” approach ?

I can’t speak for the parent, but my take on it is a skilled programmer would define structs or classes, for example: parent, student, address While the unskilled would: parentfirstname, parentlastname, parentaddress1, .... studentpostcode

userbinator 7y ago
Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types". Incidentally, that's another thing about the difference between actually-skilled programmers and "pretenders": the former will always explain something in very simple terms, while the latter will try to use as much abstract and vague technical-sounding terms as possible.
- dodobirdlord 7y ago
  I think that your response is overly accusatory, especially given that I think "grouping related data (and functions, if you're using OOP) together" is only one aspect of thinking in a type-oriented way, and not always necessary. A perhaps simpler, perhaps better example: Floats are lossy, but transactions in currency cannot be. An inexperienced developer might make the mistake of representing currency values as floats, while a more experienced developer would know to use some sort of BigDecimal. But the more experienced developer is still making a fatal error. Currencies have units, but BigDecimals do not. While BigDecimals can be added together, it is not meaningful to add Dollars to Euros. A developer who is "thinking in types" will define a numeric type for Dollars and a numeric type for Euros that cannot be added together.
  - orwin 7y ago
    I'm sorry, for me it still more of a "how to define data" that "thinking in type". Full disclosure, i would create a struct like this: typedef struct Transactions { int value; char currency; } Transaction; (sorry for the naming and the poor c code, i've not done any c since 2016). If the transaction value can be superior to 21 thousands (or if the code is deployed on a 32bit system, or if i want my floating point value high), maybe i would use a long, and probably an enum to keep track of the different currencies the second time i pass over the module. Maybe even a field (or a macro outside the struct) with the floating point value (4 to 6 seems good enough tbh). I'm an "int, char, loop" guy, at least at first, especially if i have to write something from scratch. Thinking in "object" or "type" makes me uncomfortable except when it is for interfaces (but GUI makes me uncomfortable too, so...). I feel this is inefficient, and that well-defined/organized data should not need such complex handlers in most cases.
- CodeWriter23 7y ago
  > (via @ararwhatever) The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. > (via @userbinator) Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types". There's some nuance between what you two are saying. IMO the "related" vector (depending on the definition) is a potential driver of what I refer to as the "Single Class Application". Back to the OP example, the Shipment and Notification are related to an Order. The simple "related" question says it's ok to implement all of those in one class instead of three. The real questions to ask are about the specific relationship of possession. Does this attribute BELONG to this object or another? Does this object DO this action? These go a little beyond the typical OOP mantra of abstraction and encapsulation.

aastronaut 7y ago

Not GP, but the book 'Domain Modeling Made Functional' does explain advantages in modeling with types quite well.

kyberias 7y ago

It's the anti-pattern "Primitive obsession" https://refactoring.guru/smells/primitive-obsession https://refactoring.guru/smells/primitive-obsession Let's say, for example, that we need to handle distances in on our code with different units (meters and inches, for example). I've seen code bases that use integers or floating points for this and it's always confusing and error-prone what is the unit. In fact, you could accidentally use some other values (money) as distances. Instead, if your programming language allows this, you could define a type Distance and make sure that all the code that handles distances only use this Distance type. Everyone is forced to think about distances when maintaining the code, conversions routines are implemented and instantiated in one place etc.

Insanity 7y ago
This is why I like type defs in a language.