3 ms·
The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster. The issue is working on projects once they've reached a
by RhodesianHunter 3y ago
The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster.
The issue is working on projects once they've reached a certain size where you have no idea what the intent of the original author was and you maybe need to refactor, add-in major pieces, or change anything with the expectation that it continues to work.
- fiddlerwoaroof 3y agoI’m including maintenance costs in “productivity”. I’ve worked on large dynamically typed codebases and never experienced what you’re talking about. I think it’s a question of understanding how to work and think without explicit types rather than something that makes statically typed codebases easier to maintain.
- ReflectedImage 3y agoUntyped code bases with microservices are the best code bases out there by far. They are exceptionally easy to refactor, add-in new parts, etc. The keyword is microservices, you need to know how to do proper microservices if you are using untyped code.
- bcrosby95 3y agoI dunno. Something like spec, dialyzer, or "assertive" typing (in the case of Elixir) on the boundary works just fine for me.
- kaba0 3y agoMicroservices just push the problem out of sight — now you need interoperable types between them, there are race conditions, IDEs don’t see inside the black box of other services so refactoring is harder, etc. They can be the correct solution sometimes, but blindly applying them everywhere is just dumb.