5 ms·

The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. Too many software developers never progress bey

The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. Too many software developers never progress beyond primitives and basic control structures - I call them Int, String, and For Loop Developers. Second biggest issue I see is failing to incorporate our cognitive shortcomings into code design, assuming that you'll remember these dozens of little details from today forever, and failing to enforce or make explicit one's "today knowledge" in the code.

atmosx 7y ago
Can you give a clear example on “thinking in types” approach ?
- 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.
JMTQp8lwXL 7y ago
Could you explain the consequences of not progressing beyond "Int, String, and For Loop" development? Are you suggesting that these engineers don't understand or apply Design Patterns [0]? [0]: https://en.wikipedia.org/wiki/Design_Patterns https://en.wikipedia.org/wiki/Design_Patterns
- dodobirdlord 7y ago
  That would be part of it, but since was talking about inability to think in types I suspect they were taking aim more at things like excessively stringly-typed[0] code. [0] https://devcards.io/stringly-typed https://devcards.io/stringly-typed
  - JMTQp8lwXL 7y ago
    I do a lot of TypeScript these days. It's possible to define a type which equates to one or more literal string values. The TypeScript compiler will complain if you try and supply an invalid string parameter. So --at least for TypeScript-- I think this is less of a concern than in the past (and TypeScript is growing in popularity within the JS community). In a more general sense, I agree with the author that the 2nd code sample offers additional clarity.
    - nemetroid 7y ago
      That sounds like a type that holds a string, which is just what the article suggested to use.
      - JMTQp8lwXL 7y ago
        Which, prior to TypeScript, wouldn't have been an option. The ever-evolving front end ecosystem!

atmosx 7y ago

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

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.

JMTQp8lwXL 7y ago

Could you explain the consequences of not progressing beyond "Int, String, and For Loop" development? Are you suggesting that these engineers don't understand or apply Design Patterns [0]? [0]: https://en.wikipedia.org/wiki/Design_Patterns https://en.wikipedia.org/wiki/Design_Patterns

dodobirdlord 7y ago
That would be part of it, but since was talking about inability to think in types I suspect they were taking aim more at things like excessively stringly-typed[0] code. [0] https://devcards.io/stringly-typed https://devcards.io/stringly-typed
- JMTQp8lwXL 7y ago
  I do a lot of TypeScript these days. It's possible to define a type which equates to one or more literal string values. The TypeScript compiler will complain if you try and supply an invalid string parameter. So --at least for TypeScript-- I think this is less of a concern than in the past (and TypeScript is growing in popularity within the JS community). In a more general sense, I agree with the author that the 2nd code sample offers additional clarity.
  - nemetroid 7y ago
    That sounds like a type that holds a string, which is just what the article suggested to use.
    - JMTQp8lwXL 7y ago
      Which, prior to TypeScript, wouldn't have been an option. The ever-evolving front end ecosystem!