Dart fixes a number of problems with Web programming, but introduces new problems of its own
Google Dart: Art of the familiar
Before I give my opinion about the type system in Dart, I want to explain that I began this project after spending two solid days trying to chase down a crashing bug in an Objective-C program that appeared after I upgraded a library. My code didn't change, but it started crashing in one small, yet crucial corner. The new version of the library renamed one of the objects that my code used as a base class, but I never noticed. The Objective-C compiler probably noticed, but it didn't bother to tell me it couldn't find that base class anymore. Nope -- it built my code and gave me a high five, perhaps because someone thought that the word "objective" means not sticking your nose into others' conflicts or taking sides of any kind. After a few days of fiddling, I found the conflict and the code stopped crashing.
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.
This weekend's Windows 10 upgrade has users angry, and it's unclear if the ploy will continue
Here’s the best of the best for Windows 10. Sometimes good things come in free packages
Speaking at the O'Reilly Fluent conference, Eich also endorsed the Service Workers mobile app...
Four, rich, pretrained machine learning APIs bring the smarts behind Google to your apps
F# 4.1 will include struct tuples, improved error messages, and backing for .Net Core
The Apache project for container orchestration aims higher than merely managing Docker or being a...
Whether their cloud is powered by Amazon, Google, Microsoft, or IBM, developers need security tools....