This magic pony exists. That's what the author is trying to say. You can write magic pony code, and it can be run as JavaScript. Magic Pony -> JS Conversion!
Also, the OP doesn't have an issue dynamic languages as much as weak typed languages. It just happens that JS is weak and dynamic, while AS is strong and static.
Having switched between Java, ActionScript and JavaScript for the last four years, I can assure you that bugs happen all the time in weakly typed languages that wouldn't compile in strongly typed languages. Sure, it doesn't make it past refreshing the browser, but it's not uncommon for a coworker to check in changes to a JavaScript class that completely breaks a part of the application that the dev wasn't thinking about.
For instance, I've seen return objects switch from strings to ints because of how the strings were concatenated (return "Item " + x/returns string/; -> return x/returns int/;). Somewhere else in the function it returns early with "". Now you have other functions in other classes that check someFunction().length... error... sometimes...
The point is, you now have to write unit tests to check the TYPE of each value, and in many cases, it's not easy to tell. To check if an item is an array in JS, you have to do: Object.prototype.toString.call(obj) === '[object Array]'...
Since this checking needs to be done anyways, I'd rather it be done by the compiler rather than by a dev remembering to write a test for each possibility.
> but it's not uncommon for a coworker to check in changes to a JavaScript class that completely breaks a part of the application that the dev wasn't thinking about
You don't need to write unit tests to check the type of each value, you just need to have a decent set of integration tests to make sure you aren't breaking other parts of the app. If errors in the browser after a refresh don't help you catch it, failing integration tests will. This is how we do things on my large scale javascript project and it works out just fine; we have development challenges, for sure, but weak/dynamic typing issues is not one of them.
The point still stays. Why having to write even integration test for something that can be easily checked by compiler. Better focus on writing tests that cover functionality instead of making sure return types are correct.
That's unreliable for client-side work because each frame has its own Array.prototype object which disavows instances that were created by code from different frames. It's a lot like Java classloaders, where if you aren't careful you can end up with several distinct and incompatible classes with identical names and (often) bytecode.
This magic pony exists. That's what the author is trying to say. You can write magic pony code, and it can be run as JavaScript. Magic Pony -> JS Conversion!
Also, the OP doesn't have an issue dynamic languages as much as weak typed languages. It just happens that JS is weak and dynamic, while AS is strong and static.
Having switched between Java, ActionScript and JavaScript for the last four years, I can assure you that bugs happen all the time in weakly typed languages that wouldn't compile in strongly typed languages. Sure, it doesn't make it past refreshing the browser, but it's not uncommon for a coworker to check in changes to a JavaScript class that completely breaks a part of the application that the dev wasn't thinking about.
For instance, I've seen return objects switch from strings to ints because of how the strings were concatenated (return "Item " + x/returns string/; -> return x/returns int/;). Somewhere else in the function it returns early with "". Now you have other functions in other classes that check someFunction().length... error... sometimes...
The point is, you now have to write unit tests to check the TYPE of each value, and in many cases, it's not easy to tell. To check if an item is an array in JS, you have to do: Object.prototype.toString.call(obj) === '[object Array]'...
Since this checking needs to be done anyways, I'd rather it be done by the compiler rather than by a dev remembering to write a test for each possibility.