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 As and 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.
If interested in another real life example, please have a look at the JSON API domain:
E.g. if we did not have LfV type parameter in CreateCommand, we would have ended up with 4 different classes representing CreateCommand with payload in different stages of processing, instead we can just do:
CreateCommand[String],
CreateCommand[JsValue],
CreateCommand[LfValue],
CreateCommand[ApiValue]
You can guess who insisted on introducing the type parameters in the JSON API domain .
I finally watched this talk and found it quite inspiring. It’s a great reminder that we can use the type system to constrain far beyond "this is an Integer".
I’m not sure I’d use this technique when there really is only one possible type to insert, as I think the drawbacks of the more complicated type signatures would probably outweigh the upsides of the extra proofs. However, when there’s a possibility of more than one type, especially when we have multiple stages of parsing/transforming as detailed in the video and by @Leonid_Shlyapnikov above, I think it’s an excellent idea.
Glad you all found it interesting. I wish that languages would make type abstraction “cheaper” lexically, so to speak, so the costs @SamirTalwar mentions would not be so painful in some of the interesting but complex cases.
If your choices are introducing a type parameter and introducing a mocking framework, surely you have only one choice, right?
.