1.8 already? Wow. Yet enums are only now being added (the proposal was from 2013)
This puts me off Dart - for now - for two reasons.
Firstly, the language appears to have been rushed. Yes, great tooling, but was the language rushed out the door by corporate Google? Will they ditch Dart just as quickly if it doesn't gain traction? Lots of risk in learning Dart.
Second, if it wasn't rushed out the door, then the language designers made a mistake. It's nice they can admit that but it also shows a lack of conviction and belief in the language they have created. So what makes Dart unique? If I want Java, I use Java. Contrast with Golang and the reasons the team give for not having generics.
From what I see Dart was definitely not rushed. On the contrary. The team puts a lot of thought into what goes into the language and what doesn't (from a language, implementation and tooling pov).
With languages it is easy to add stuff but hard (often impossible) to remove it so it is important to understand the change and make sure it fits well with what is in the language and what might be added later.
It obviously helps to have a great team that has done exactly that many times over for many many other languages used in production.
Dart is a very clean language and I guess it made sense to postpone non-essential stuff like Enums & Async/Await. This doesn't mean those aren't awesome and great to have, it just means those things like other things better aren't rushed into the language but well thought through.
Dart only looks like java (this was a deliberate design choice to increase familiarity and ease learning/adoption), but it works a lot more like ruby and go.
Out of the myriad new languages the crop out almost daily, Dart stands out as clean, modern, fast and ready to roll with a large standard library. The team is strong and stacked with experts in the field.
On the flip side, algebraic data types have been invented in the 70es and are fundamental to the logic of programming. I don't understand the process through which an otherwise informed team ships half-baked sum types in 2014 in the guise of enums.
Sum types and subclasses cover much of the same problem space just with different trade-offs. Sum types give you exhaustiveness checking, while subclasses give you open-ended extensibility.
Given that Dart already has subclasses and they're the natural way for people to solve most problems where you'd reach for a sum type in other languages, I don't think there's as much need for enums to be larger and feature-rich. Instead, the language team focused them on the narrow use cases of wanting just an exhaustively checked numeric subrange, similar to enums in C#.
I do personally wish you could add methods and fields to them (á la Java but without case-specific methods and fields), but I think the language team wanted something easier to compile to a bare number in JS. Maybe they'll get added later.
Unless I'm missing something, enums are closed, thus overlap with sum types for the use-cases. Subclasses are an implementation detail in this context. Here is an example that uses subclasses to implement generalized enums, aka sum types:
enum List {
Cons(head, tail) {...}
Nil {...}
int length() {
switch (this) {
case Cons(head, tail): return 1 + length(tail)
case Nil: return 0
}
}
}
Mind you, this is syntactic sugar and you can do it by hand with enums + sublcasses. But the whole point of clean languages is to remove unnecessary boilerplate :)
Note that enums in Haxe are pure data types, and can't have member functions and/or values. However, since enums are public by nature, it's possible to achieve this easily with "using":
http://try.haxe.org/#87bF5
They're experts alright but it would appear that although you can take the person out of the Smalltalk, you can't quite take all the Smalltalk out of the person (not a bad thing in my opinion).
I'm from C# background and I can't imagine doing large client apps in JS anymore - maybe I'm too old but Dart IDE and integrated debugger is something I can't live without.
I left MS stack (not a big fan of Windows), so having really cross platform IDE is a big win for me.
Can't say anything on TS - but AFAIK it's mostly syntactic sugar on JS, no first class IDE on non-Windows, no pub (dedicated Dart package manager), no native VM (I'm also doing server side on Dart recently) and still it's possible shot your foot just like in JS - saying all that - I will have to really try it out.
Pretty much an identical background for me, and I recently had to write a fairly non-trivial client side application (some drag-and-drop, quartz-composer like interface) and I chose Dart. It worked really well.
I find that sometimes it's hard for people to reconcile their idealistic vs. pragmatic sensibilities when it comes to new programming languages. Dart makes it incredibly easy to get up and running ... it's pragmatic.
14 comments
[ 0.22 ms ] story [ 42.7 ms ] threadThis puts me off Dart - for now - for two reasons.
Firstly, the language appears to have been rushed. Yes, great tooling, but was the language rushed out the door by corporate Google? Will they ditch Dart just as quickly if it doesn't gain traction? Lots of risk in learning Dart.
Second, if it wasn't rushed out the door, then the language designers made a mistake. It's nice they can admit that but it also shows a lack of conviction and belief in the language they have created. So what makes Dart unique? If I want Java, I use Java. Contrast with Golang and the reasons the team give for not having generics.
With languages it is easy to add stuff but hard (often impossible) to remove it so it is important to understand the change and make sure it fits well with what is in the language and what might be added later.
It obviously helps to have a great team that has done exactly that many times over for many many other languages used in production.
Dart is a very clean language and I guess it made sense to postpone non-essential stuff like Enums & Async/Await. This doesn't mean those aren't awesome and great to have, it just means those things like other things better aren't rushed into the language but well thought through.
On the flip side, algebraic data types have been invented in the 70es and are fundamental to the logic of programming. I don't understand the process through which an otherwise informed team ships half-baked sum types in 2014 in the guise of enums.
Given that Dart already has subclasses and they're the natural way for people to solve most problems where you'd reach for a sum type in other languages, I don't think there's as much need for enums to be larger and feature-rich. Instead, the language team focused them on the narrow use cases of wanting just an exhaustively checked numeric subrange, similar to enums in C#.
I do personally wish you could add methods and fields to them (á la Java but without case-specific methods and fields), but I think the language team wanted something easier to compile to a bare number in JS. Maybe they'll get added later.
Note that enums in Haxe are pure data types, and can't have member functions and/or values. However, since enums are public by nature, it's possible to achieve this easily with "using": http://try.haxe.org/#87bF5
Dart is single best client side tech for me.
If yes how does it compare to Dart ?
Can't say anything on TS - but AFAIK it's mostly syntactic sugar on JS, no first class IDE on non-Windows, no pub (dedicated Dart package manager), no native VM (I'm also doing server side on Dart recently) and still it's possible shot your foot just like in JS - saying all that - I will have to really try it out.