Response to Coffeescript and Dart article on nettuts

Some slight clarifications, if I may, following a recent article on nettuts.com:

Jeremy said: ” In addition, Dart retreats from the dynamism of JavaScript, and instead exists as a somewhat static language, where types can be checked at compile time, but are erased at runtime. ”

While there are many ways to interpret “dynamism”, it’s true that Dart doesn’t have extremely dynamic features like “eval” or the ability to arbitrarily change object structure.

However, it’s important to point out that Dart is an optionally typed language, allowing a developer to write as much or as little static type information in the code as they wish. This was a pragmatic decision (as there are plenty of web developers that have been writing great untyped code, and who probably don’t want to see a type), however we also think optional typing allows a program to grow over time (as complexity increases, types can help with documentation and tools.)

Types aren’t erased at runtime, values still have their types. A string is a string, a number is a num. In fact, collections have reified types, so you can ask if a List of Strings is really a List of Strings. I think the misconception is that a few presentations out there (mine included) have said, “types don’t affect the runtime semantics of your code.” Admittedly this is something best left for language designers to debate, as real life developers want to know if types help them or just get in the way.

Dart programs can run in something called “checked mode”, which I find quite useful. It can use the types to catch errors earlier in the program, something always helpful.

James said: “Dart doesn’t seem to bring anything to the table other than a more Java-esque syntax, which many developers aren’t too fond of, myself included.”

This is a fair assessment from the early samples and demos we released. However, Dart code can be written to look nothing like Java. Remember, Dart is just a technology preview, and we are still figuring out how to write idiomatic Dart code. The community will probably evolve into something that doesn’t quite look like Java, and something that doesn’t quite look like JavaScript. It will be Dart code, and that’s good. :)

Remember that Dart code doesn’t even have to use classes, and doesn’t have to look anything like Java. For example:

hello(msg, to, wrapper) {
  return '${wrapper(msg)} to ${to}';
}

importantify(msg) => '!!! ${msg} !!!';

main() => print(hello('world', 'Seth', importantify));

Granted that’s a contrived example, but we’re doing some non-Java things in there like string interpolation, untyped code, and passing functions as first class objects. Not to mention the syntax sugar for a one line function.

Nathan said: “the end-game for Dart is to get developers writing an entirely different language altogether (preferably interpreted in a browser’s VM, instead of being precompiled to JS).” and Ryan said “Dart aims to replace JavaScript”

The end game of Dart, and CoffeeScript, and modern JavaScript, is to help developers write more complex, full featured, high fidelity, larger modern web apps. These languages are a means to an end: a better modern web. Dart isn’t out to replace anything, any more than CoffeeScript is out to replace JavaScript. Dart is out there to help show developers on other platforms that the web is a compelling and amazing place to build apps.

Finally, Alex said: “Google took rather a walled garden approach to Dart, and I get the impression they didn’t really look outside the confines of their company for inspiration.”

It’s true, Dart was launched into Technology Preview with some ideas written down. Having some code written is better than just abstract ideas, in my opinion, because shipping code wins. But Dart is not done, and it’s open source, and there’s a lot more to do. It’s incredibly open, in fact, with all the code in the open, along with the bug tracker and mailing list. I do not believe Dart is a walled garden. The real test is how the team will accept and integrate outside patches, but I don’t sense this will be an issue.

As for inspiration, there has been plenty of outside and historical influence. Lars Bak, the lead of the project, has been working on virtual machines for many years. His team was responsible for V8, so they must have learned a lot there. Gilad Bracha, leading the spec, worked on the Java language spec and generics, and definitely learned a lot of good and bad lessons there. Many on the team are former Smalltalkers, like Peter Ahe. Bob Nystrom even built his own language. Josh Bloch, of Effective Java fame, knows a thing or two about designing libraries. I’m sure I’m missing people, and I apologize. And we’d be remiss if we didn’t mention CoffeeScript as part of the inspiration, for it is clear evidence that developers are hungry for options and alternatives.


(update: this is a repost of my original comment on the article. if you'd like to respond, we should probably carry on the conversation over at the original article)