3 ms·
Refactoring. Say you want to make a 1:1 relation into a 1:* relation. You change your core data type from e.g. `type person{address:string}` to `type person{a
by daxfohl 10y ago
Refactoring. Say you want to make a 1:1 relation into a 1:* relation. You change your core data type from e.g. `type person{address:string}` to `type person{addresses:string[]}`, follow/fix all the red squiggly lines until it compiles, and generally you're done.
OTOH with unit tests, you've got to find/fix not only your app code but the test code as well. You may forget some things because you overlook a function and its tests. And of course your test coverage is likely not 100% so things may slip through.
So in addition to "refactoring", I'd add "guarantees": literally one line of code gives you 100% coverage.
PLUS autocomplete. JS editors have gotten better, but TS blows them out of the water. Importa new library, and stuff almost codes itself.
Mutability is somewhat orthogonal to the discussion. You can write things immutably or immutably in typed or untyped languages. I prefer mostly immutable too. But, going with it, I'd been a Clojure fan for a couple years, where immutability and dynamic types are both forefront. After rewriting an app in F#, and then performing a major refactor, this is what I had to say about it. https://disqus.com/home/discussion/owenrh/the_beauty_of_clojure/#comment-2218264287 https://disqus.com/home/discussion/owenrh/the_beauty_of_cloj... tldr: refactoring is much easier with types backing you up.
n.b. There's no reason you have to choose. You can have all three. Immutability, tests, and types. I do. Though if I had to choose, I'd pick types first. I'm a disciplined enough coder that immutability guarantees aren't that necessary, and if I've got types and discipline, then tests usually are unnecessary.
- nojvek 10y agoThe way I think about this is types is like writing tests for your code. Typescript will fail if the contracts don't match.