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.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
It's all about knowing how to build an open source community -- plus experience running applications in...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Visual Studio 2017 is not only smaller and faster, but armed for many more use cases than previous...
The possibility: A knowledge network that can map both the relationships among individuals and with...
Gradle 3.4 eliminates classpath leakage and improves compilation
In search of a simple service, a techie is frustrated personally and professionally by bad web work