3 ms·

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 unski

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.

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.