Sharing my experiences

[Ruudjah]

I'd like to share my (small) experience working with the dart platform
so far. This is meant to be constructive, to share things hoping
someday they will be improved :). I'm trying to ignore stuff I know is
being worked on at the dart team.

-Dart editor can be really slow at times, with unworkable delays for
autcompletion/file switching/saving. Turning off auto-build helps here
sometimes to speed up.
-Sometimes dart editor seems to be running an old build, failing to
refresh
-No integrated test environment in the darteditor. A simple testing
framework solves this, but is inherently slower (testing small
snippets of code require firing up the complete app, dartium, etc),
violating the principle that tests should be fast.
-dart2js in darteditor failed without any sensible error message

-Why does object not implement Hashable?
-Reflection kind of works for object class names when using
String temp = obj.toString().substring(13);
return temp.substring(0,temp.length - 1);
Does this work at all in javascript compiled dart? Also, don't
override toString() ;)
-Terse, clear, simple, nice looking code! Compared to Java/C# horror
of 50 imports, 10+ lined javadocs, 2 loc for curley braces, mandatory
newline for "return" (as opposed to =>, which can be on the same
line), Dart code is a breeze for my brain to build a mental model of
the code. "One page", lets say 32 loc, can amount for twice, three
times or even four times as terse code compared to java/c#. Awesome!
-Initialization code of variables can however reverse this terseness a
bit: you need 1 loc for declaration, 1 loc for initialization, as
opposed to c#/java needing only 1 loc of declaration+initialization.
-Traits (concrete interfaces) can remove duplicate code for Hashable
implementors & custom collections. Currently, you need duplicate code
to implement them.
-What class to subclass an implementation of List<T>? I didn't get
this to work.
-Renaming classes requires renaming all constructors (minor annoyance,
prolly solved with better refactoring tools)
-Missing event support in dart (my take:
https://github.com/generateui/Dartan/blob/master/Observable.dart) -->
I will clarify & submit in the issuetracker)
-new Element.html("<div></div>") or new Element.tag("div") is weakly
typed, fell a few times in this trap. Why not just new Element.div(),
or new Div()? Seems more intuitive to me.


So far, very positive, few rough edges, very workable. Keep up the
good work :)

Ruud

[Bob Nystrom]

On Sun, Apr 29, 2012 at 7:37 AM, Ruudjah <rti...@gmail.com> wrote:

I'd like to share my (small) experience working with the dart platform
so far. This is meant to be constructive, to share things hoping
someday they will be improved :).

Thanks! This is very helpful. The experience of new users to Dart is especially important because it's easy for us to forget what it's like to come to Dart with fresh eyes.

-Dart editor can be really slow at times, with unworkable delays for
autcompletion/file switching/saving. Turning off auto-build helps here
sometimes to speed up.
-Sometimes dart editor seems to be running an old build, failing to
refresh

The editor folks may have some more details here, but I know autocomplete performance is something they're aware of and care a lot about.

 

-No integrated test environment in the darteditor. A simple testing
framework solves this, but is inherently slower (testing small
snippets of code require firing up the complete app, dartium, etc),
violating the principle that tests should be fast.

I've had a few discussions with the editor team about this. Integrated unit testing is definitely on their todo list, but it's a long list so we aren't sure when we'll get to it. When/if they do, it will most likely build on top of the existing unittest library that's in the Dart repo.

 

-dart2js in darteditor failed without any sensible error message

:(

Can you post the (insensible) error message to this list? Maybe someone on dart2js or the editor can help.

 

-Why does object not implement Hashable?

This has come up very frequently (Hmm, maybe we should have a FAQ entry on it). Having all objects be hashable would definitely be a big usability win, especially when working with maps. However, it comes at a cost.

I believe most other languages that allow any object to be hashed do so be using an internal per-object ID. For example, I believe on the JVM every object needs a unique lock ID so the object can be synchronized on, so they reuse that value as the default hash code. I think .NET does something similar.

This means every object requires an extra word to store that ID even for the many many objects that you never synchronize on or store in a map. With Dart, I think the VM team is trying to avoid that overhead unless they know they really need it.

 

-Reflection kind of works for object class names when using
     String temp = obj.toString().substring(13);
     return temp.substring(0,temp.length - 1);
Does this work at all in javascript compiled dart? Also, don't
override toString() ;)

Ha, clever, but definitely a hack. :)

Full-feature reflection support that should let you do this without hacks is definitely on its way. It's just not done yet.

 

-Terse, clear, simple, nice looking code!

Awesome!

 

Compared to Java/C# horror of 50 imports, 10+ lined javadocs, 2 loc for curley braces, mandatory
newline for "return" (as opposed to =>, which can be on the same
line), Dart code is a breeze for my brain to build a mental model of
the code. "One page", lets say 32 loc, can amount for twice, three

times or even four times as terse code compared to java/c#. Awesome!

That's been my experience too, though with C# most of the savings come from more terse doc comments and a style guide that puts opening "{" on their own line.

 

-Initialization code of variables can however reverse this terseness a
bit: you need 1 loc for declaration, 1 loc for initialization, as
opposed to c#/java needing only 1 loc of declaration+initialization.

There's two kinds of "initializations" you can be referring to here:

1. Fields that are always initialized by some value or expression when you create the object.

2. Fields that are initialized from constructor arguments.

For example:

class Foo {

  var a;

  var b;

  Foo(a_)

    : a = a_,

      b = 123;

  }

}

Dart has a couple of things to make those cases easier. If you're initializing a field directly from a constructor argument, you can just do this:

class Foo {

  var a;

  Foo(this.a); // "this.a" here initializes "a" from the first constructor arg.

}

If you're initializing a field to some constant expression, you can do so at the declaration:

class Foo {

  var b = 123;

}

What you can't do right now is use a non-constant initializer at the declaration. So this doesn't work:

class Foo {

  var a = new Set(); // not a const expr

}

Gilad can correct me if I'm wrong, but I believe there is a plan to support this in the language at some point.

So right now, for the common cases of initializing to constants or constructor args, Dart is OK here. In the future we may also be as good for initializing to non-const expressions like Java and C# are now.

 

-Traits (concrete interfaces) can remove duplicate code for Hashable
implementors & custom collections. Currently, you need duplicate code
to implement them.

Traits, mixins, and extension methods come up very frequently for discussion. I don't think we have consensus or a plan here yet, though we certainly all feel the pain that not having anything along these lines causes.

Dart is quite conservative in most aspects of its language design and this is an area where it isn't clear what the best practice is yet. Mixins, trains, and extension methods all have their problems and limitations.

 

-What class to subclass an implementation of List<T>? I didn't get
this to work.

Our core collection libraries will be getting a significant revamp Any Day Now (TM), and this use case should be addressed by that. Right now, you can #import('dart:coreimpl') which, despite the "impl" in the name is an intended use case, and subclass the concrete types in there. One of the problems with this is that those concrete types are implementation-specific (i.e. VM versus frog/dart2js) right now.

It's a problem. I hope we'll have a better solution when the new collections are in place.

 

-Renaming classes requires renaming all constructors (minor annoyance,
prolly solved with better refactoring tools)

Yup. This bugs me too, but in return for this, we get a constructor syntax that's more familiar to users coming to Dart from Java, C#, and C++.

 

-Missing event support in dart

Our dart:html library does have event support for DOM events (of course), but you're right that we don't have something more generic and usable outside of a web context. We're starting to work on a UI framework now, and my hope is that this is one thing it will expose in a way that you can use in general.

 

(my take:
https://github.com/generateui/Dartan/blob/master/Observable.dart) -->
I will clarify & submit in the issuetracker)

Thanks, we'll take a look at this. :)

 

-new Element.html("<div></div>") or new Element.tag("div") is weakly
typed, fell a few times in this trap.

I'm not sure what you mean by "weakly typed" here. It is true that those constructors may return a different concrete type than what appears after the "new". In all cases, though, they should be returning a subtype, so that shouldn't be a trap for you to fall into. What problems did you run into here?

 

Why not just new Element.div(),

I think it would make more sense to go with your second suggestion:

or new Div()? Seems more intuitive to me.

I think we're planning to support this, but we just haven't gotten around to creating those constructor methods yet. If you'd like, don't hesitate to file a bug so we don't forget.

So far, very positive, few rough edges, very workable. Keep up the
good work :)

Awesome, thanks for trying it out!

- bob

[Ruudjah]

Thanks. These replies show you guys really care :).

The thing I mean with new Element.tag("ul"); being weakly typed, is
that when you decide a <div> is a better fit. There is no failsafe in
the compiler telling you that an <li> element does not make sense
within a <div>. A new Div() would enable a type checker to tell me
that I'm being nonsensical adding a <li> to it.

Ruud

> If you're initializing a field to some *constant* expression, you can do so

> at the declaration:
>
> class Foo {
>   var b = 123;
>
> }
>

> What you *can't* do right now is use a *non-constant* initializer at the

> declaration. So this doesn't work:
>
> class Foo {
>   var a = new Set(); // not a const expr
>
> }
>
> Gilad can correct me if I'm wrong, but I believe there is a plan to support
> this in the language at some point.
>
> So right now, for the common cases of initializing to constants or
> constructor args, Dart is OK here. In the future we may also be as good for
> initializing to non-const expressions like Java and C# are now.
>
> > -Traits (concrete interfaces) can remove duplicate code for Hashable
> > implementors & custom collections. Currently, you need duplicate code
> > to implement them.
>
> Traits, mixins, and extension methods come up very frequently for
> discussion. I don't think we have consensus or a plan here yet, though we
> certainly all feel the pain that not having anything along these lines
> causes.
>
> Dart is quite conservative in most aspects of its language design and this
> is an area where it isn't clear what the best practice is yet. Mixins,
> trains, and extension methods all have their problems and limitations.
>
> > -What class to subclass an implementation of List<T>? I didn't get
> > this to work.
>
> Our core collection libraries will be getting a significant revamp Any Day

> Now (TM), and this use case should be addressed by that. Right now, you *can
> * #import('dart:coreimpl') which, despite the "impl" in the name is an

[Sam McCall]

On Mon, Apr 30, 2012 at 8:11 PM, Bob Nystrom <rnys...@google.com> wrote:
>> -new Element.html("<div></div>") or new Element.tag("div") is weakly
>> typed, fell a few times in this trap.
>
> I'm not sure what you mean by "weakly typed" here. It is true that those
> constructors may return a different concrete type than what appears after
> the "new".

I think 'dynamically typed' is more accurate than 'weakly typed' here:
Element.tag returns an Element, which is appropriate when you don't
know the type at compile-time.
The problem is that when you *do* know that you want a <button>, the
only way to get one is new Element.tag('button') and know from the
docs that it will return a ButtonElement.
You won't get any assistance from the type-checker or editor, because
they can't read the docs.

> In all cases, though, they should be returning a subtype, so that
> shouldn't be a trap for you to fall into.

It'd be equally correct if all API methods were declared to return
Object. I spent enough time with Ruby to know it can be a trap :-)

> What problems did you run into here?

No completion in the editor (for chained expressions, cascades, or
Dynamic-typed locals with type inference): e.g.
doc.body.add(new Element.tag('a')..href='/foo'..text='Foo')

No warnings when you assign to the wrong subtype, likely when
modifying a statement:
InputElement addButton() {
return new Element.tag('input')..type='submit'; // old
return new Element.tag('button'); // new
}

[Peter Ahé]

Hi Ruud,

Any examples of the dart2js error you mentioned below?

We are aware of a whole bunch of places where we don't use the right methods for reporting internal errors. I knew this would be a problem when we turned dart2js on in the editor, but unfortunately it slipped my mind to do something about it before turning it on.

I'll try to make a catch-all fix that should at least tell you what method could not be compiled.

Please don't hesitate to report bad error messages directly to me, or at http://dartbug.com/new. I'm very interested in improving the basic user experience of error messages, and I think it is a bug in the compiler if you don't immediately understand an error message (even if you later learn more about Dart and the error becomes easier to understand).

Cheers,

Peter

[Peter Ahé]

I filed this bug to track the issue of missing diagnostics:

http://code.google.com/p/dart/issues/detail?id=3062

Cheers,
Peter