Good stuff from Dart

Google's Dart language and SDK appear to be approaching a 1.0 release some time this year. Having spent the last few years mostly in C# and .NET land (still using it every day - I work on Stack Overflow Careers 2.0 which is built on ASP.NET MVC), I have to admit that I'm intrigued by Dart's bold core premise: let's not fix, but make a clean cut with JavaScript, the web's lingua franca and its flaws. Instead, behold - we're introducing Dart, a new class-based and (optionally) typed language. We'll get all the OOP goodness back (real, not prototype-based inheritance, interfaces, generics...), and it'll run both in the browser and on the server! Plus, an async programming model and no shared-state concurrency via isolates. Sounds good in theory!

Well, it won't be that easy. Firstly, Google is pulling a VBScript by creating their own standard and incorporating it into their own browser. Other browsers aren't likely to include a Dart VM any time soon and will therefore require compiled versions of all client-side scripting code. I bet at least minor inconsistencies between the the native and compiled versions will occasionally appear. And they will be hard to troubleshoot - as a developer, let me put on my sceptical face for a second here :/.

Also, there's the ecosystem. It'll take a while to catch up with the gazillions of JS libraries out there. Granted, it comes with more batteries included (no need for jQuery for instance), but still.

So, it's hard to say at this time whether Dart will get widespread adoption or just disappear again within a couple of years. Nevertheless, I'm having a lot of fun studying the language and experimenting with it (oh yeah, that was your idea, Demis- thanks mate!). So occasionally, I'm going to blog about concepts and features in Dart which I like in particular. Who knows, maybe some of them will get ported to C# and other languages.

For today, let's start by talking about something simple yet very useful:

Named constructors

Method names should be self-explanatory and not require additional documentation. In fact, often times adding a comment can and should be avoided by refactoring code segments into well-named helper methods. Unfortunately, constructors in C# can't have names. In Dart, they can:

class Customer
{
  Customer.fromName(String name) { /* ... */ }
  Customer.fromJson(String json) { /* ... */ }
  Customer.fromXml(String xml) { /* ... */ }
}

To be fair: unlike Dart, C# supports method overloading and therefore constructors can typically be distinguished by their signatures. However, you'll have to become creative if the signatures end up identical, like in the example above. Static creator methods (stuff like DateTime.FromFileTimeUtc) can be used to work around this problem, but named constructors are nicer and I think they would make sense in C# and the CLR as well.



Written on September 18, 2013.