3 ms·

Wrapping My Head Around Optional Typing (in Dart)

36 points by jashkenas 15y ago

jashkenas 15y ago
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.
chintan 15y ago
Great article! Thanks for writing this up. If there are no runtime performance benefits, then I wonder how is it different from the Type Expressions in Google Closure [1]? 1. http://code.google.com/closure/compiler/docs/js-for-compiler.html#types http://code.google.com/closure/compiler/docs/js-for-compiler...)
- munificent 15y ago
  Thanks! Dart's type annotations in a lot of ways are inspired by Closure. The big difference is that Closure Compiler style JS is... well... hideous. You get some of the maintainability and modularity of a statically typed language (I can't count the number of times the Closure Compiler found errors for me), but the way you have to write JavaScript to get that makes it incredibly ugly.

36 points by jashkenas 15y ago

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.

chintan 15y ago

Great article! Thanks for writing this up. If there are no runtime performance benefits, then I wonder how is it different from the Type Expressions in Google Closure [1]? 1. http://code.google.com/closure/compiler/docs/js-for-compiler.html#types http://code.google.com/closure/compiler/docs/js-for-compiler...)

munificent 15y ago
Thanks! Dart's type annotations in a lot of ways are inspired by Closure. The big difference is that Closure Compiler style JS is... well... hideous. You get some of the maintainability and modularity of a statically typed language (I can't count the number of times the Closure Compiler found errors for me), but the way you have to write JavaScript to get that makes it incredibly ugly.