Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

First look: Google Dart vs. JavaScript

Dart nails some of Web programming's worst pet peeves, but is it good enough to beat JavaScript?

  • Print
  • Feedback

Page 2 of 4

Given that, you can imagine how overjoyed I was to read Gilad Brancha, one of the Dart developers, write in the Dart documentation, "Your program will have exactly the same semantics no matter what type annotations you add." Wow. Thanks for nothing -- literally. In response, some jokers suggest that Google just wanted to save you the hassle of putting comment marks around the type annotations.

It turns out that Dart doesn't throw the type information into the bit recycling bin. You can ask it to run more slowly and check to see if the types of the data actually agree with what you suggested. There's even a static checker that preprocesses the file to flag some of the problems. The Dart authors also suggest the compiler might do a better job if the type information is there, but that awaits a future spec.

Some people will see this as ideal. I've known many smart and capable programmers who hate type systems. What I see as a helpful exoskeleton of logic, they see as a rigid pain in the neck invented by programmers who want to get paid by the keystroke. Dart offers them most of the power of type checking if and when they want to deploy it. If they're just having fun and writing something simple, there's no need to be too verbose and specify the type. People like me, on the other hand, can add types to everything, and it might help catch some bugs. This kind of flexibility is ideal for the lone coder because the lone coder can choose their favorite path.

A deeper question is whether Dart and this new freedom will really make it easier to get teams together to write big programs. There's no doubt that the careful namespaces and class structure add nice firewalls that prevent collisions. That discipline is something that's bound to help most people.

But can all of the other new features and flexibility help larger teams? In some cases, the syntactical shorthand may sow confusion. In others, the devil-may-care attitude toward typing will leave team members at odds with each other because flexibility isn't always a good idea for keeping people on the same path.

Google Dart: Structure and freedom
I've worked on several teams where the leader was a real whip cracker who drafted long lists of annoying rules. Each statement had to be on its own line. Each constant had to start with a certain letter. There could be no chaining of method calls because it made stepping through the code difficult during debugging. Everyone hated the rules and the rule maker, but the code was much more consistent and readable.

Dart seems to be taking the opposite approach. There are often several ways to say exactly the same thing. Functions are first-class objects and they're tossed everywhere. Constructors take various forms. Of course you can also get your own whip cracker to come up with tough rules and jam them down the throats of the coders, but we can already do that with the existing languages. If anything, Dart is offering more ways for programmers to develop their own secret idioms, then get cheesed off when the other coders can't grok their infinite coolness.


  • Print
  • Feedback

Resources