I’ve recently seen this nice talk on the value of adding type parameters by DA’s own @StephenCompall.
As a developer who generally prefers to keep things fairly concrete, this talk made me think a lot about the value of abstraction using an expressive type system. In particular, I see a lot of value in abstracting over details that you don’t want to test for in a specific situation. It simplifies testing and allows you limit using unnecessary tools or possibly some brittle hack.
I usually like to not abstract in business logic data types because I tend to get lost with
Ts. I find it difficult to understand the meaning of something if I can’t anchor it to something I can clearly understand. To go back to the example in the talk, why is this
WebPage parameterized over something? What is this
A floating around? When working with values, it’s usually a recognized good practice to give bindings and variables a telling name (unless you’re using a widely-recognized shortening in a clear context), so why not adopting the same attitude towards type parameters? Is there a good reason to have a
WebPage[A] over a
WebPage[Content]? Probably ergonomics, as handling types in most languages is a second-class citizen. I’m seeing more and more of a push in a direction where there’s little difference between using types and values (e.g. I like how Scala 3 will have named type parameters and there’s a proposal to add them to TypeScript).
Have a look at the talk if you wish, I’d love to get your opinion on it.