Hacker News Reader

Comment by bob1029 | Hacker News Reader

I've been around the block a few times on modeling complex domains, and have found that generics do not help in a fundamental way.

If you back all the way out to the theoretical/academic realm and view the problem domain through the lens of normalization, you would probably find that any opportunity for use of generics to be a sign that you have not achieved 3NF.

Our core domain models are extremely simple types. They have no other complex types as properties and could be mapped 1:1 to SQL tables without any complication.

We could have certainly leveraged generics if it made sense (we use C#). But, for these core domain model types it causes more harm than good.

View on HN

Generics are about algorithms, not modeling. Not having generics becomes especially tedious in Go when you start trying to handle channels properly (e.g. proper prioritization and cleanup).

Generics isn't about the modeling of data, though.

I agree - its more about how you draw relations between types and work with them. If you are finding that a whole class of types can be processed or related in exactly the same way, then these are probably the same type.

The motivation for using generics falls away when every domain type is fundamentally different in its shape and requires ad-hoc relations to be made on a contextual basis.

> If you are finding that a whole class of types can be processed or related in exactly the same way, then these are probably the same type.

This is like saying "if a lot of different fruits can be processed the same way, then these are probably the same fruit"

An example that makes it very clear is stringifying (e.g. for logging). You can stringify a user, you can stringify a database connection and you can stringify a boolean. But these three things are obviously not the same type at all.

Therefore...

> The motivation for using generics falls away when every domain type is fundamentally different in its shape and requires ad-hoc relations to be made on a contextual basis

is wrong. However, bringing up the term "ad-hoc" is great! Because this is precisely what many languages are missing and where generics are absolutely needed. The languages that have the feature that you describe usually call it "type classes". Look up type classes in Haskell or Scala (if you are a JVM guy) or Rust where they call/implement it with traits (if you are a low-level guy).

I think there's a distinction between the kind of "processing" you refer to and the kind generics are a good tool to solve.

I'm interpreting what you describe as something like the methods on an object (in OO land), e.g., the "ToString()" method in Java. Generics aren't good for all such use cases (though they are for more than many might believe). The more specific the operation, the less applicable (obviously?) generics are.

Generics are useful for abstract operations regardless of the type. As an example consider insertions, deletions, and access of members of a container such as a list or map. As such the underlying type/data model isn't really relevant to their utility.

It is related in some way.

Since Go has no generics, it does not have datatypes like Sets, Maps (go has maps, but only supports a few types as keys), or Graphs. It also does not have immutable collections.

This complects data modeling.

Reply on news.ycombinator.com