3 ms·

A lot of the conversation about how Dart is going to run faster than JavaScript (or might someday) focuses on Dart's static types. This essay is a great explana

A lot of the conversation about how Dart is going to run faster than JavaScript (or might someday) focuses on Dart's static types. This essay is a great explanation of how Dart's types are a complete red herring when it comes to performance -- they're used for optionally enabling runtime assertions, or optionally running compile-time checks, but nothing more. They have no influence on the semantics of your program, or how the Dart VM will optimize it. This is interesting, because it seems to mean that any of the performance advantages Dart might have over JavaScript in the future ... could also just as easily be added to JavaScript, by: * Restricting changes to the shape of an object after it has first been created. Perhaps via a keyword. * Adding a true integer type. And for the curious, there's already a decent discussion happening over on Proggit: http://www.reddit.com/r/programming/comments/lkpil/wrapping_my_head_around_optional_typing/ http://www.reddit.com/r/programming/comments/lkpil/wrapping_...

pwpwp 15y ago
I find "production mode" and the motivation for it in this article highly irritating. If I declare a variable to hold only numbers, I'd expect that to hold, no matter what (or get a runtime error immediately). I wouldn't want my program to "stay the course" when my declared type assertions are wrong.
- cwp 15y ago
  Then just run in checked mode.
- ajanuary 15y ago
  I think the arguments about staying on course are poor. It seems to me the thinking is "Given we've got optional typing, it's faster to not check the types. The majority of type errors should be found during development."
colin_jack 15y ago
I think the documentation advantages of typing can be massive. Dynamic languages are great but they do place additional importance on documentation/comments, for example to tell the caller of an API what to pass in and why. In a static language, if the author has carefully thought about the naming of any abstractions, you get a lot of that documentation for free. Add in useful advantages like better tooling support and I do think a feature like optional typing could be very useful.

pwpwp 15y ago

I find "production mode" and the motivation for it in this article highly irritating. If I declare a variable to hold only numbers, I'd expect that to hold, no matter what (or get a runtime error immediately). I wouldn't want my program to "stay the course" when my declared type assertions are wrong.

cwp 15y ago
Then just run in checked mode.
ajanuary 15y ago
I think the arguments about staying on course are poor. It seems to me the thinking is "Given we've got optional typing, it's faster to not check the types. The majority of type errors should be found during development."

colin_jack 15y ago

I think the documentation advantages of typing can be massive. Dynamic languages are great but they do place additional importance on documentation/comments, for example to tell the caller of an API what to pass in and why. In a static language, if the author has carefully thought about the naming of any abstractions, you get a lot of that documentation for free. Add in useful advantages like better tooling support and I do think a feature like optional typing could be very useful.