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)
Post a Comment

Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
    Keep reading
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
    Keep reading
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som
    Keep reading