Google Dart Roundup: Dart to JS Compiler Frog, Pre-Built Editor/IDE Binaries, Type System Proposals
Google Dart has become easier to try with binary builds of the Dart editor. The SWT/Eclipse-based tool includes the DartC compiler, project management, application wizards, etc. and allows to run Dart applications compiled with DartC.
The editor runs the type checker on all code and annotates code that contains problems; providing type annotations helps the type checker be more useful.
The Frog project was started by none other than Jim Hugunin, the creator of Jython and IronPython who now works at Google. Jim explains his experience with Dart (from the linked mail):
I've spent most of my career trying to end the battles between the dynamic and static worlds and instead bring them together so that each side can enjoy the benefits of the other. Writing this compiler in dart is the first time that I've really felt the effortless blend of these worlds that I've been seeking.
Dart is the first time that I have been able to start off writing code in a very dynamic fashion and incrementally add static checks as designs become solid or complexity warrants the effort.
Google announced Dart as "technology preview" to get feedback and comments from the community. The language is far from finished; important details such as reflection are being worked on right now. The community has started providing feedback on the Dart mailing list and on the web.
One example is Bob Nystrom (who is on the Google Dart team) who has provided a proposal to add nullable types to Dart. The basic idea is that all types are non-nullable, but adding a
? to a type annotations allows that type to also accept
null as a value.
For details see the proposal text, but here's one of the reasons for nullable types (from the proposal):
Gilad describes Dart as having a "documentary" type system. With nullable and non-nullable types, we can now use type annotations to tell users of our APIs which things accept null and which don't. In other languages you have no choice but to spell that out in the documentation. With this, it's right in the type signature for a method. If you call method(Foo a, Foo? b), it's clear that it can handle a null for the second argument but not the first.
Nullable types and similar ideas are of course not new and are present in other languages, either as part of the type system or, for instance, in the form of Java annotations like
@NotNull. Considering the trouble
null has been causing, it can be a useful feature to have.
Gilad Bracha, who is on the Dart language team, recently gave a talk on Dart and explained some of the ideas behind the optional type system, citing documentation as the most important contribution. Just like Java's annotations or C# attributes, Dart's type annotations are optional and have no direct impact on the runtime behavior of the system. A video and transcript of Gilad's talk is available. An interview with Gilad about Dart is available at Channel9.
Another resource for Dart news is the DartWatch blog which provides news and also explores various areas of Dart.