3 ms·

I'm a bit torn on whether an advanced type system like TS produces better api designs for libraries or whether it promotes bad designs that need advanced typing

by aszen 6y ago

I'm a bit torn on whether an advanced type system like TS produces better api designs for libraries or whether it promotes bad designs that need advanced typings to be safe and sound. I feel typescript is in many ways closely tied to JS because many of the advanced typing features don't make sense outside of existing javascript patterns. We all talk about simplicity so what makes type systems different that we get excited about their advanced and complicated features.

throwanem 6y ago
My experience has been that complex APIs will be complex whether they're statically typed or not. It's always possible to add accidental complexity to a design, but an essentially complex problem domain necessitates an essentially complex solution. If that solution includes a static type system, then the type system needs to be at least as complex as the domain. I'd be interested to hear more about the TS features that you find to be JS-bound. My experience with TypeScript gets deeper every day, but I haven't yet run into anything that was obviously only necessary because TypeScript is a layer over Javascript. I'd appreciate the benefit of some additional perspective there.
- aszen 6y ago
  Sure, let me start with a disclaimer, I have used TS briefly and found it great but I personally prefer Elm's type system. My understanding is TS was designed specifically to statically type existing JS patterns in popular libraries and frameworks and while that's great, newer libraries rarely need such flexibility if they aim for type safe designs from the start. When I use typescript I often get the feeling there are multiple ways of typing the same function, which is reasonable given that one of TS goals was to embrace the JS ecosystem and that meant covering multiple overlapping use cases. Consider Enums and Union types in TS, at a higer level both express the same thing (this value can be one of these sets of values) but in practice there is lots of discussion on when to use which. I have not seen sum types (as they are usually called) being implemented in two different ways in other languages. I think one of the ways to think about TS is that it was designed to help programmers better understand their JavaScript code by adding types while reinforcing their designs in a safe manner so if TS didn't have to interface with existing JS code many of the cool tricks it's picked up would not be useful I think. Finally on the point of expressivity, I'm interested to know how TS helps in modelling application logic to make invalid state impossible.
mattgreenrocks 6y ago
> I'm a bit torn on whether an advanced type system like TS produces better api designs for libraries or whether it promotes bad designs that need advanced typings to be safe and sound. Well, I'd argue the type system surfaces the pain faster than the untyped variant. In the untyped version, you have to read the code to see that, "it's either the number 4, or a function which may produce the number 4." Once you see you need a weird type signature to represent 4 OR a function which produces a number, then your spidey-sense kicks in and says, "this is getting gross, maybe I should either always return just the number, or always return a function which produces the number." This avoids a branch in the code that consumes the result where you check the type and do something based on that. At a meta-level, this is the type system telling you something about your program that you might otherwise miss if you were so focused on getting something working.
- aszen 6y ago
  I agree on type systems being helpful, my point was about immensely flexible type systems like TS which don't force any usual constraints of designing with sound types. I do appreciate a good sound type system that constraints the behavior of my code in well expected ways.

by aszen 6y ago

throwanem 6y ago

My experience has been that complex APIs will be complex whether they're statically typed or not. It's always possible to add accidental complexity to a design, but an essentially complex problem domain necessitates an essentially complex solution. If that solution includes a static type system, then the type system needs to be at least as complex as the domain. I'd be interested to hear more about the TS features that you find to be JS-bound. My experience with TypeScript gets deeper every day, but I haven't yet run into anything that was obviously only necessary because TypeScript is a layer over Javascript. I'd appreciate the benefit of some additional perspective there.

aszen 6y ago
Sure, let me start with a disclaimer, I have used TS briefly and found it great but I personally prefer Elm's type system. My understanding is TS was designed specifically to statically type existing JS patterns in popular libraries and frameworks and while that's great, newer libraries rarely need such flexibility if they aim for type safe designs from the start. When I use typescript I often get the feeling there are multiple ways of typing the same function, which is reasonable given that one of TS goals was to embrace the JS ecosystem and that meant covering multiple overlapping use cases. Consider Enums and Union types in TS, at a higer level both express the same thing (this value can be one of these sets of values) but in practice there is lots of discussion on when to use which. I have not seen sum types (as they are usually called) being implemented in two different ways in other languages. I think one of the ways to think about TS is that it was designed to help programmers better understand their JavaScript code by adding types while reinforcing their designs in a safe manner so if TS didn't have to interface with existing JS code many of the cool tricks it's picked up would not be useful I think. Finally on the point of expressivity, I'm interested to know how TS helps in modelling application logic to make invalid state impossible.

mattgreenrocks 6y ago

> I'm a bit torn on whether an advanced type system like TS produces better api designs for libraries or whether it promotes bad designs that need advanced typings to be safe and sound. Well, I'd argue the type system surfaces the pain faster than the untyped variant. In the untyped version, you have to read the code to see that, "it's either the number 4, or a function which may produce the number 4." Once you see you need a weird type signature to represent 4 OR a function which produces a number, then your spidey-sense kicks in and says, "this is getting gross, maybe I should either always return just the number, or always return a function which produces the number." This avoids a branch in the code that consumes the result where you check the type and do something based on that. At a meta-level, this is the type system telling you something about your program that you might otherwise miss if you were so focused on getting something working.

aszen 6y ago
I agree on type systems being helpful, my point was about immensely flexible type systems like TS which don't force any usual constraints of designing with sound types. I do appreciate a good sound type system that constraints the behavior of my code in well expected ways.