Dart -- disappointment of the year

[paulmillr]

Hey Dart guys.

Just wanted to clarify some things I didn't saw in the spec / sandbox.

- Why keep syntactic noise aka semicolons?
- Where's "rest" / "spread" parameters? (func(params...))
- Where's traits / mixins / multiple inheritance?
- Where's tail recursion optimization?
- Where's currying?
- Where's operator overloading? Can we say "goodbye" to great DSLs?
- Where's metaprogramming? Even ES6 supports proxies.
- Where's pythonic / es6 generators?
- Where's pattern matching / algebraic data types?

Is ANYTHING from these features even planned?

[Quildreen Motta]

There is operator overloading. Operators are messages send from RHS to LHS:

1 + 2

Is actually

1['+'](2) or 1.+(2) or 1.__add__(2)

Traits would indeed be nice, and I think another thread said they're considering it. Well, it's an work in progress, so let's wait and see how it evolves. Bear in mind though that Dart has many more possibilities of evolving than ES.next has, since ECMAScript has to be backwards compatible semantically-wise, and stuff.

2011/10/10 paulmillr <paulp...@gmail.com>

[Eric Ayers]

Hopefully, your disappointment is premature. We released early to get
feedback like this. In fact, we removed support for some features
before the Technology Preview to make sure that we had a subset of
features that work well together (e.g. splay arguments were a victim
of named optional parameters).

-Eric.

--
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

[xavm]

Hi Eric,

As said in a previous post, I would enjoy to find many Go features and
syntax in Dart ; you are from the same company, and Go has made nice
things like variable declaration, multiple returns, goroutines, mix
obej and functional orientation, ..., and everything in a efficient
way... Dart could be a subset of Go with specific GUI oriented
features like seaside continuation pattern for instance...

best regards
Xavier

On Oct 10, 2:32 pm, Eric Ayers <zun...@google.com> wrote:
> Hopefully, your disappointment is premature.  We released early to get
> feedback like this.  In fact, we removed support for some features
> before the Technology Preview to make sure that we had a subset of
> features that work well together (e.g. splay arguments were a victim
> of named optional parameters).
>
> -Eric.
>
>
>
>
>
>
>
>
>
> On Mon, Oct 10, 2011 at 8:27 AM, Quildreen Motta <quildr...@gmail.com> wrote:
> > There is operator overloading. Operators are messages send from RHS to LHS:
>
> > 1 + 2
>
> > Is actually
>
> > 1['+'](2) or 1.+(2) or 1.__add__(2)
>
> > Traits would indeed be nice, and I think another thread said they're
> > considering it. Well, it's an work in progress, so let's wait and see how it
> > evolves. Bear in mind though that Dart has many more possibilities of
> > evolving than ES.next has, since ECMAScript has to be backwards compatible
> > semantically-wise, and stuff.
>

> > 2011/10/10 paulmillr <paulpmi...@gmail.com>

[Hanno Braun]

I don't think Dart is a disappointment, but tail call optimization and
currying would be nice!
And as I already said in another thread, mandatory semi-colons are a
horrible idea, in my opinion.

On Oct 10, 2:32 pm, Eric Ayers <zun...@google.com> wrote:

> Hopefully, your disappointment is premature.  We released early to get
> feedback like this.  In fact, we removed support for some features
> before the Technology Preview to make sure that we had a subset of
> features that work well together (e.g. splay arguments were a victim
> of named optional parameters).
>
> -Eric.
>
>
>
>
>
>
>
>
>
> On Mon, Oct 10, 2011 at 8:27 AM, Quildreen Motta <quildr...@gmail.com> wrote:
> > There is operator overloading. Operators are messages send from RHS to LHS:
>
> > 1 + 2
>
> > Is actually
>
> > 1['+'](2) or 1.+(2) or 1.__add__(2)
>
> > Traits would indeed be nice, and I think another thread said they're
> > considering it. Well, it's an work in progress, so let's wait and see how it
> > evolves. Bear in mind though that Dart has many more possibilities of
> > evolving than ES.next has, since ECMAScript has to be backwards compatible
> > semantically-wise, and stuff.
>

> > 2011/10/10 paulmillr <paulpmi...@gmail.com>

[alexey.petrushin]

I would like to thanks Google team for effort to make Web better.

About syntax - agreed. I hoped it would be something like Ruby /
Python / Lua / ...
I personally don't want to switch back to Java / C++, even if it's
more stable and has better performance.

[Bob Nystrom]

On Mon, Oct 10, 2011 at 5:21 AM, paulmillr <paulp...@gmail.com> wrote:

- Why keep syntactic noise aka semicolons?

This has come up repeatedly. Dart started from a known simple grammar: semicolons and ignored whitespace, and we can always take it from there. Go made semicolons optional later in the development of the language without too much difficulty.

 

- Where's "rest" / "spread" parameters? (func(params...))

It was in for a while, but we took it out temporarily. We're still working on named and optional arguments and getting all of those to play well together is a little tricky. Actually removing rest/spread was a surprisingly small change to the codebase, so I don't think it adds as much value as I initially thought it did.

 

- Where's traits / mixins / multiple inheritance?

It's an open question. The language isn't done yet. We want to get a solid single inheritance story implemented first, I believe. It's easy to say "where's traits/mixins/MI" and just kind of hand-wave the distinction, but all of those have very complex semantics, which is why current languages still seem to be experimenting with them. It's not the kind of thing you'd want to just rush into.

 

- Where's tail recursion optimization?
- Where's currying?

Put in feature requests for these if it's something you'd like the language to support.

 

- Where's operator overloading? Can we say "goodbye" to great DSLs?

Operator overloading is implemented, used in several examples and described in this article here: http://www.dartlang.org/articles/idiomatic-dart/.

 

- Where's metaprogramming? Even ES6 supports proxies.

We haven't gotten there yet. ES6 hasn't shipped proxies either, you know, and they've been at it much longer than we have! :)

 

- Where's pythonic / es6 generators?

If this is something you'd like, put in a feature request for it. I know some other people on the team like them too.

 

- Where's pattern matching / algebraic data types?

There's a proposal floating around for pattern matching. Dart already has subtyping so I don't think sum types will add that much, especially if we do get pattern matching.

 

Is ANYTHING from these features even planned?

Are you mad at us for giving you the opportunity to get involved in helping designing this stuff before the language locked down?

- bob

[paulmillr]

Thanks for the replies. Sorry guys, I've thought that Dart is locked
down already.

That's great news then! Where can I make a feature request?

On Oct 10, 10:53 pm, Bob Nystrom <rnyst...@google.com> wrote:

[Lee]

On Oct 10, 3:53 pm, Bob Nystrom <rnyst...@google.com> wrote:

> On Mon, Oct 10, 2011 at 5:21 AM, paulmillr <paulpmi...@gmail.com> wrote:
> > - Where's "rest" / "spread" parameters? (func(params...))
>
> It was in for a while, but we took it out temporarily. We're still working
> on named and optional arguments and getting all of those to play well
> together is a little tricky. Actually removing rest/spread was a
> surprisingly small change to the codebase, so I don't think it adds as much
> value as I initially thought it did.

@Bob, speaking from a Coffeescript POV, I agree it is isn't used
frequently (at least by me). But I would argue that on the times it
is used, it is a very valuable addition to the language. It certainly
makes the code more concise, readable and maintainable.

I hope the team reconsiders putting this feature back into Dart.

[poltomb]

I think that var-args parameters (as they are called in Java, my
primary language) are a cheap and easy way to make a method accept any
number of parameters. The problem is that it is not always easy to
understand, especially for new programmers. Also, when methods are
overloaded, var-args can cause a lot of confusion, especially in
dynamically typed languages. I think that the named optional
parameters are the best way to go.

someFunc(a, b, c...) {
for (d in c) {
// do something with the elements
}
}

someFunc(a, b, c, d, e, f) {
// do stuff
}

someOtherFunc(a, b, [List c = new List() ]) {
// c is a List, either use comments to convey this or a type in the
parameter

for (d in c) {
// do something with the elements
}
}

someOtherFunc(a, b, c, d, e, f) {
// do stuff
}

doStuff() {
// var-args
// which someFunc is being called?
someFunc('apples', 'bananas', 'cherries', 'blueberries',
'raspberries', 'blackberries');

// named optional parameters
// very clear which method is being called, also the List type in
the definition makes it
// easier for prgrammers understand what is to be done with it
someOtherFunc('apples', 'bananas', c: ['cherries', 'blueberries',
'raspberries', 'blackberries']);
}

Using named optional parameters only adds a few extra keystrokes,
depending on the length of the variable name, and it is MUCH clearer
what is going on.

[poltomb]

Easier to read code example: http://pastebin.com/21VkqF2f

[John Tamplin]

On Wed, Oct 12, 2011 at 10:54 AM, poltomb <paul.bjo...@gmail.com> wrote:

Also, when methods are overloaded, var-args can cause a lot of confusion, especially in
dynamically typed languages.

In Dart, you can't overload the method (as types are optional) so you can't have both a varags and non-varargs method of the same name.

--
John A. Tamplin
Software Engineer (GWT), Google

[poltomb]

I see. Even so, named optional params gives a better description of
what they are used for. It took me a few days to figure out how to
use a var-args param in Java. That was years ago, and before I knew
what an IDE was.

On Oct 12, 10:07 am, John Tamplin <j...@google.com> wrote:

[poltomb]

Updated my example to follow what John said about overloading:

http://pastebin.com/hWQQyp6z