Hacker News Reader

Comment by arwhatever | Hacker News Reader

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.

View on HN

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

It's the anti-pattern "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.

This is why I like type defs in a language.

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

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

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.

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.

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.

> (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.

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

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

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.

That sounds like a type that holds a string, which is just what the article suggested to use.

Which, prior to TypeScript, wouldn't have been an option. The ever-evolving front end ecosystem!

Reply on news.ycombinator.com