4 ms·
>> satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits I tend to rail quite hard against the “type everything”
by CraigJPerry 6y ago
>> satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits
I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.
Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.
In typescript you could actually type concat in a meaningful way but i digress.
I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.
There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.
All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.
- acemarke 6y agoYep, I'm a firm believer in using TS pragmatically. Type the obvious code (React component props, API responses, function arguments), and start by aiming for an "80% sweet spot" of type coverage. Don't get into arguments with the compiler, and avoid writing really complex types unless you've got a key spot in your code where adding that type now makes it a lot easier to infer types in other places: https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-using-typescript/#pragmatism-is-vital https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...