4 ms·
I got around to watching the entire talk. It's not convincing to me. The presentation tacitly assumes that the only benefit to type systems is catching type err
by nickm12 5y ago
I got around to watching the entire talk. It's not convincing to me. The presentation tacitly assumes that the only benefit to type systems is catching type errors and ignores the benefits to code readability and tooling. It also assumes that time spend developing and time spend debugging are fungible and I find that a bit simplistic; I would gladly trade debugging time for development time, even if the ratio is uneven. Finally, it doesn't even talk about the runtime performance penalty that dynamic languages typically incur.
Aside:
It's worth commenting more on "code readability" because it cuts both ways. It can absolutely be the case that a complex, manifest type system can be a hindrance to understandably and productivity due to the "noise" of all the types that need to be written. I think struggling with C++ and (to a lesser extent) Java typing is part of the reason the industry really embraced dynamic languages in the 2000s. Python and Ruby were like a breath of fresh air. But eventually we built large systems with these languages and discovered the pain that comes from having no type-safety.
The trend I've seen in the last decade is to embrace type inference, with explicit type declarations on function signatures and otherwise only when needed for disambiguation. To me, this is the sweet spot, giving the benefits of static typing with much of the cleanliness and concision of dynamic languages.