This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make. The author also complains about some javascript projects being split up into enough files, which is hardly a side-effect of using javascript. The author inherited what sounds like a pretty di…
I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not…
Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't.
Don't mistake utility (what can be done) for usability (what is easy to do). Usability always matters.
> First of all, put a comment at the top of your function that says what to expect about the return value.
I want a language that gives me a nice pleasant syntax for doing that.
> Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do.
As a programmer, you should be trained that when you see "every time", you think "automate this". If you and everyone on your team and everyone who has ever been on your team has to remember to do something every single time, your code will accumulate a pile of instances of forgetting.
Fixing that is exactly what tools and languages are for. It's a hell of a lot easier to make a disciplined tool than a more disciplined programmer. (And when you have made a more disciplined programmer, they typically evidence that by asking for more disciplined tools.)