Here are my notes I jotted down while going over the language spec.
Bad grammer, cursing, and opinions abound: you have been warned!
Notes:
Why the => syntax?
Production vs checked mode seems like a bad idea.
Libraries are a good thing, but a dependancy system is !@#!@#~@!# REQURIED. The ecosystem of libraries is everything. syntax is cheap :)
Underscore as private/public: Simple, elegant: I like
Single Threaded: I like
Warnings/Errors/Exceptions: Pick a name and stick with it (Personally I'm partial to Exception). In reality the difference between the three will be so subtle that the difference will serve no-one.
Static variables: make them all final. There is never a 'good' reason to have global (non-instance) variables. Global variables are evil. Very few exceptions like Singletons…and I can't think of any others. Should be handled by a special kind of Class that has only one instance.
Function Declarations section of the spec: WTF? How about explaining what the hell the variables mean in T0 id(T1 a1, . . . , Tn an, [Tn+1 xn+1, . . . , Tn+k xn+k]){s} ???? An example would not go amiss…
Operator methods! woohoo! :)
get/set methods: ewwww…. just do foo and foo=. It is WAY easier to read and WAY easier to write dynamic code with. JUST DO IT!!!!
Constructor Parameter Lists: bad idea. This confuses the method(arumentGoesHere), or method(argumentNameGoesHere) paradigm for the sake of very,very few keystrokes (Many Constructors take zero arguments, or rely on their parent)
Redirecting Constructors…WTF? Not sure I understand this
Factory Classes: Seems like a cool idea, but not sure what the point of detailing it in the language spec is. Shouldn't this just be an idiom?
Generics: I guess something is better than nothing, but I'd really like to see those restrictions dropped.
Constants/final : use case to determine. If it is ALL_UPPER_CASE then it is constant/final. Makes variable names more meaningful and kills a keyword.
The static type of null is ⊥ WTF is '⊥' ?!?!?!? Unicode will be the death of us all, just wait….
Floats: IEEE754: Lets just end the madness, stop pretending, and just use fractions. Let 3.14 be = 314/100 and be done with it. Lossy floating point is just plain evil. We can even have 314/100.toString() = "3.14". If you REALLY want a lossy float then type 3.14f and may the god(s) of your choice have mercy on your…
Strings: "A string is a sequence of valid unicode code points." I suppose there is no point fighting it, but I personally have never found unicode anything but a PITA that makes my life more complicated and solves no problems I've ever run into. Some day it may save my bacon, but not yet.
I find it interesting/informative that the section on Multiline Strings is actually packed with useful examples (relatively speaking), while the section of function definition (the heart and soul of any programming language) was thrown together garbage.
Love the String Interpolation! Wish it mandated ${foo} and didn't allow $foo…I sense trouble with escaping and runtime generated strings if $foo is left in.
===: I really think I would like to see an actual english word here since this is a subtle concept. Maybe something like 'isSameObject'. Not as cute as === but since this is a rarely used operator I think it deserves the extra characters.
if / else does't require braces! Braces for all blocks should be MANDATORY.
do…while: super-rarely used. Not worth the headache of the extra syntax, should most likely be removed.
switch/case: It is soooo damn easy to get messed up on these that I ALWAYS use if/else. It is one of those things that would be cool if somebody could come up with a better syntax that didn't let you shoot yourself in the foot so easily, but the C syntax is just broken here.
return null by default: Going out on a limb but I think 'this' should be returned by default in all cases. Method chaining is just such a powerful technique that I think its use should be encouraged by default. In fact I would even go so far as to say that voids should be abandoned as a return type, with the default return type being the type of the Class the method is defined in.
Labels: OMG!!! This is just so evil I am flabbergasted (what an awesome word!)! Like I'm not really sure I'm seeing what my eyes are telling me I'm seeing. If you use labels in your code then you, my friend, are an idiot and you should just stop programming now while you still have a few good years left. Here is a hint: most methods should be less than 5 (FIVE) lines long. If you have the space to put in a label then you are already doing something wrong. I love the little note in the spec concerning why they STUPIDLY and WRONGLY and EVILY decided they wanted to include this REALLY BAD IDEA: "Labels should be avoided by programmers at all costs. The motivation for including labels in the language is primarily making Dart a better target for code generation." In other words they knew it was a bad idea at the time and did it anyway, because at some point there might be a machine that might maybe possibly at some day in the far future maybe decide it wants to generate some really truly horribly nasty machine generated code. Wow. Like I said I'm just stunned by this.
assert: I like the idea. I like the keyword. I don't like that they aren't evaluated in 'production mode'. Pre and post conditions to a function are an awesome concept. For the 0.001% of the code that is actually performance critical then comment these guys out in PD or surround them with isDebug() or something like that.
imports and includes? eck! Just have one and create a convention.
Other things I like:
semi-colons are mandatory!
Functions appear to be first-class citizens
main() method!
yummy closures
can create functions without a 'function' keyword.
Other things I don't like:
Code repository is subversion ? Any modern open source project has to be in git, or I'm already kind of wary of it.
The whole include/import thing and the lack of namespaces. Java did this right with the domain thing, really that is the thing to copy here. I'd love to see something like:
require (com.acme.Widget >= 1.5, 'http://optional.place.to.load.widget') {
// I don't like to type
var Widget = com.acme.Widget;
}
Then have a nice default place to load widgets from like /script/${full.package.name}-${version}.dart
That really isn't that hard now was it?
Things lacking:
Library ecosystem. This is THE problem of all languages right now IMHO, and there is no reason why the library dependency resolution/discovery mechanism can't be 'baked' into the language. Syntax is cool, but code is king.
Again just a few simple conventions, or a bit of thought could make all the difference. A central repository would be the obvious thing (like CPAN/RubyGems for instance). However that is kind of old-school (but still a billion times better than nothing).
My dream system would probably resemble something closer to github, but with some mechanism for voting (maybe a cross between github and stackoverflow?)
Final Thoughts:
Damn it I really didn't want to like this language! Javascript is the obvious web language, and although it isn't perfect, it is like 95% perfect (tackle the namespace issue, and get rid of the weird way 'this' is handled and it would be more like 99% perfect).
But Dart is very, very sexy. Such a wonderful blend of the best of javascript and Java. After spending a couple of hours going over it I have to say I'm fairly impressed. The only obvious 'missed the boat' thing is the lack of namespaces for libraries.
I could definitely see myself getting attached to Dart if I'm not careful. It will come down to the VM implementations and how widely available they become.
No comments:
Post a Comment