I've felt the same, but I blame error messages and language ergonomics rather than the practice itself. Basically, everything you said, but with optimism that future languages and language implementations make 'hyper typing' a good practice. Recent languages have shown that there's a lot of room for improvement on error messages in complex programs. Hopefully that extends to complex types before too long.
Fully agree. TS shouldn't throw internal types into the user's face. The errors UX is abyssymal.
The fact that the most popular editor - VSC - doesn't preserve line breaks makes reading TS errors even worse. I highly recommend the pretty TS errors extension, otherwise you're only hurting yourself working with TS.
I don't use typing for correctness. I use it for documentation. That's why I prefer JSDoc these days. I only type top-level variables/functions to get hints from my editor. Everything inside a function body remains untyped unless necessary. It’s the benefit of using Typescript without being forced to write dumb code just to satisfy the compiler.
I've been frustrated about this for a while, but I haven't had a good term to describe it, so thanks for that! The biggest annoyance I find from the increasingly complex types is the impact on tooling. My IDE slows to a crawl trying to process recursive types. tsc takes 4 minutes because of some needlessly complicated library types. Just pump the brakes on the types and write some damn unit tests.
I started using swift with a lot of enthusiasm for the type system, but at times it was a huge time suck. There were lots of obscure interface types that read like BipartisanPoliticallyCorrectSequence<T> that made writing my own generic utilities challenging. Documentation for that stuff was very poor and the source code was often totally inscrutable due to the implementation of core types in c++ and the overall complexity of the compiler.
I recently saw Chris Lattner talk about Mojo and he made passing reference to Swift trying to do too much with the type system. It’s telling that a guy with his experience is trying something more like zig’s comptime approach to types after two decades of generics.
Having worked on large codebases with many developers of varying levels of experience I have noticed that bugs that can be written very often will be written - a sort of programming specific version of Murphy's law. So I try to make the ones that seem the most likely impossible. Sometimes I go too far.
> So I try to make the ones that seem the most likely impossible.
Yeah this is a very key point to reflect on. Is this stricter type actually catching a bug that's easy to make? Or is it just giving you more satisfaction of more precise typing? It takes time and practice to make that distinction.
Similar things can also be said about automated tests. I've written too many of them that end up being written for a mistake that never gets made.
Really nice write-up, thanks. The issues you raise with complex typing are really nicely set out. It's such a trade-off, and you're absolutely write to claim that sometimes, simplicity trumps perfection.
