5 ms·

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

by sidlls 5y ago

bob1029 5y ago
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.
- valenterry 5y ago
  > 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).
- sidlls 5y ago
  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.
peq 5y ago
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.

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

by sidlls 5y ago

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.

valenterry 5y ago
> 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).
sidlls 5y ago
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.

peq 5y ago

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.