4 ms·

> Your unit test suite should also be able to catch all these things with the right assertions. A type system lets you precisely define the structure of your o

> Your unit test suite should also be able to catch all these things with the right assertions. A type system lets you precisely define the structure of your objects in the same language. It's a kind of documentation of implicit information that forces you to keep it up to date and write the annotations in a standardised way. It doesn't replace tests, but it is more precise, compact and you get near instant feedback after every modification of the code. The additional transpiling step might seem like a delay, but only if you don't consider the time saved by the type checker. When working with other developers it's also useful and gives me the structure of all their objects at a glance. And for me writing unit tests is pretty much one of the most boring and cumbersome part of development, second only to things like reading documentation in an attempt to figure out why that one DB installation is now malfunctioning since I pushed a commit in a different project during full moon. The fewer tests I have to write the better.

spmurrayzzz 6y ago
> A type system lets you precisely define the structure of your objects in the same language This is much more persuasive than anything written in the article I am commenting on. I personally still don't think this is worth all the tradeoffs for myself or team, but its a good argument for TS. > When working with other developers it's also useful and gives me the structure of all their objects at a glance Doc blocks also do this. A good argument could be made such that "if you're cool with writing doc blocks, why not write types while you're there?" - totally agree with that in principle. But again, in the aggregate cost/benefit analysis this is a minor win. >And for me writing unit tests is pretty much one of the most boring and cumbersome part of development I retreat back to comment I made about ergonomics preferences. You really dislike writing unit tests, I do not. TDD has been an incredibly impactful (and enjoyable) part of my 15+ year software journey. I started my career using strictly typed languages, and found my way out of them. Unit tests are one of the ways I maintain application integrity, which does actually (perhaps strangely for some) bring me joy. A buttoned up test suite is a very "feels good" moment for me as an engineer. Knowing I, or anyone else for that matter, can come back to the code later and both safely and confidently make changes. Something also worth noting, that didn't occur to me previously, is that my implicit heuristic analysis here is mostly centered around production node.js apps, not front-end apps. I haven't worked with the latter on a day to day basis in many years. Theres a significant difference in the cost/benefit calculus between the two. And a side point since we're talking in heuristics analysis... In my experience, especially my recent experience being a director of engineering & cofounder of a large technology company, runtime type errors are just not prevalent in the class of failure modes we see in our applications in production. I can't remember the last time a ReferenceError or TypeError appeared in any of our APM logs. So then the question becomes, how much time is "lost" in development when you hit type bugs (either with new code or fixing old code). This is much harder to quantify admittedly, but also seems minimal in my own experience.

spmurrayzzz 6y ago

> A type system lets you precisely define the structure of your objects in the same language This is much more persuasive than anything written in the article I am commenting on. I personally still don't think this is worth all the tradeoffs for myself or team, but its a good argument for TS. > When working with other developers it's also useful and gives me the structure of all their objects at a glance Doc blocks also do this. A good argument could be made such that "if you're cool with writing doc blocks, why not write types while you're there?" - totally agree with that in principle. But again, in the aggregate cost/benefit analysis this is a minor win. >And for me writing unit tests is pretty much one of the most boring and cumbersome part of development I retreat back to comment I made about ergonomics preferences. You really dislike writing unit tests, I do not. TDD has been an incredibly impactful (and enjoyable) part of my 15+ year software journey. I started my career using strictly typed languages, and found my way out of them. Unit tests are one of the ways I maintain application integrity, which does actually (perhaps strangely for some) bring me joy. A buttoned up test suite is a very "feels good" moment for me as an engineer. Knowing I, or anyone else for that matter, can come back to the code later and both safely and confidently make changes. Something also worth noting, that didn't occur to me previously, is that my implicit heuristic analysis here is mostly centered around production node.js apps, not front-end apps. I haven't worked with the latter on a day to day basis in many years. Theres a significant difference in the cost/benefit calculus between the two. And a side point since we're talking in heuristics analysis... In my experience, especially my recent experience being a director of engineering & cofounder of a large technology company, runtime type errors are just not prevalent in the class of failure modes we see in our applications in production. I can't remember the last time a ReferenceError or TypeError appeared in any of our APM logs. So then the question becomes, how much time is "lost" in development when you hit type bugs (either with new code or fixing old code). This is much harder to quantify admittedly, but also seems minimal in my own experience.