3 ms·

I have years of experience with typed ECMAScript (3 years of ActionScript 3, 2 years of Java and 1 year of TypeScript). What you're saying here and in your pre

I have years of experience with typed ECMAScript (3 years of ActionScript 3, 2 years of Java and 1 year of TypeScript). What you're saying here and in your previous comment makes sense. From my experience, engineers who have a LOT of diverse experiences with different paradigms tend to agree that types don't reduce bug density in the code. Types are a learning tool like training wheels on a bike; with comparable costs in terms of efficiency. Don't get me wrong, training wheels are great but you won't find them at the Olympics.

dunefox 8y ago
> Types are a learning tool like training wheels on a bike; with comparable costs in terms of efficiency. Don't get me wrong, training wheels are great but you won't find them at the Olympics. That is such an idiotic comparison, I don't really know what to say here. 1.) Proper type inference means you don't have to explicitly write out most/any types, so there is no "cost in terms of efficiency". Some annotations might be required from time to time. If the type checker throws an error that means that your types don't align and that you further reason about your program - which is something you need to do in dynamic languages as well, just without any assurance in the first place. 2.) Types allow performance optimisations not available in dynamically typed languages, so again - no "cost in efficiency". 3.) In dynamic languages you don't get as much help from your tools as in static languages, so you can't exclude whole classes of bugs that your compiler finds for you. So, where does this "cost in efficiency" occur? How is static code analysis a "training wheel"?