[dart-misc] Types on the right

['Bob Nystrom' via Dart Misc]

That thread about the language meeting notes is huge, so I'm going to split
my responses into separate threads. If we could move discussions to these,
that would be swell.

Here's my personal thoughts about putting types on the right:

It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
do that, most of your variable declarations will just be:

var a = someValue...


No type on the right *or* left. :)

When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".

The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.

Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use this
syntax. As far as I can tell, it is the standard way to add optional type
annotations to a language.

Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts return
types of methods after the method name. In the original dartdoc, I got a
lot of feedback that it was hard to find member names when scanning a list
of members if the return type was on the left. Pushing them to the right
does help readability in this case.

So, personally, I feel doing this would lead to a simpler, easier to extend
grammar. And it would follow in the footsteps of almost every
dynamically-typed with optional annotations language that also use "name :
Type" syntax.

Cheers!

- bob

['John Messerly' via Dart Misc]

On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the method
names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

I think it might also help with syntax for function types?

['Bob Nystrom' via Dart Misc]

On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the method
names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

+1. In my C/C++ code, I sometimes do this style for the same reason:

Return<Type, Here>
someFunction() {
...
}

For me, I think the fact that Flow, Hack, Python's type hints, and Mirah
all do this is the really compelling point. It seems like *everyone* who
does optional types for a dynamic language uses this syntax (except for
Typed Scheme, but, you know, they're (a lisp (so they have (their own
syntax (space))))).

Post by 'John Messerly' via Dart Misc
I think it might also help with syntax for function types?

And metadata annotations. Or, at least, I thought so at first. But Lasse
and others brought up points that those may be tractable even with the
current annotation style.

Cheers!

- bob

['Justin Fagnani' via Dart Misc]

On Fri, Sep 4, 2015 at 10:15 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the
method names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

Return<Type, Here>
someFunction() {
...
}
For me, I think the fact that Flow, Hack, Python's type hints, and Mirah
all do this is the really compelling point. It seems like *everyone* who
does optional types for a dynamic language uses this syntax

There could easily be some correlation vs causation confusion going on
here. All these languages had no type annotations at all first, and it's
quite possible that adding them after the fact was much easier this way.
Certainly with Python where annotation position wasn't even explicitly for
types, but for arbitrary metadata.

Post by 'Bob Nystrom' via Dart Misc
(except for Typed Scheme, but, you know, they're (a lisp (so they have
(their own syntax (space))))).

Post by 'John Messerly' via Dart Misc
I think it might also help with syntax for function types?

And metadata annotations. Or, at least, I thought so at first. But Lasse
and others brought up points that those may be tractable even with the
current annotation style.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Robert Åkerblom-Andersson]

I think Justin makes a good point here. I'm not sure the comparison is
completely "fair" (or maybe not that simple) considering that all these
languages have very different backgrounds and evolutions (for example when
types was added, how the overall support for types is the said language,
what kind of backing resources existed; 1 developer that does everything vs
a bigger team etc..).

While it is true that the other languages listed in the thread uses the
"var x : int" syntax I'm not sure they use it because it is the best syntax
for developers, I think they use it because it is an easier syntax to
parse... Maybe it's better if types have been nonexistent for a long time
in many codebases and then all of a sudden types arrives, then I could see
how the extra verbosity could be more beneficial, but that's not Dart, we
already have types... I think the Dart team has some great parsing
infrastructure in place already, the language is designed to be good for
tools etc, if Dart can pull it off without the ":", and I think it can, I
just find that much better. I think Go is a better language to look at for
this particular syntax detail (not overall, overall Go is different in many
way). As I see it they had the resources and time to choose the "best
syntax", I think it's valid to ask why did they not use "var x : int" if
it's so great? Maybe it's worth reaching out internally (at Google) to see
if they had a similar discussion back then or not. I think the answer
simply is that they did not do that since they did not need to, some other
languages might have had to do it for various reasons, if Dart does not
need to I don't think it should add it just because some other languages
does...

As I said in the "main thread" I'm not against types on the right, I'm
mostly against the extra ":". As long as there is not a considerable
difference in the effort required to implement this I think the best would
be to skip the ":". For devs that are used to "var x : int", I find the
syntax "var x int" quite familiar. For devs coming from "int x", going to
"var x int" is an easier mental switch than "var x : int", sure the
difference might not look huge but I think adding that new previously
unused character, simply put, looks plain weird for someone who has not
seen it before...

With all that said, I could live with "var x : int", my primary concern is
that it adds more unfamiliarity than needed for new devs. Existing devs
like myself with adapt either way I think.

Post by 'Justin Fagnani' via Dart Misc
On Fri, Sep 4, 2015 at 10:15 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the
method names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

Return<Type, Here>
someFunction() {
...
}
For me, I think the fact that Flow, Hack, Python's type hints, and Mirah
all do this is the really compelling point. It seems like *everyone* who
does optional types for a dynamic language uses this syntax

There could easily be some correlation vs causation confusion going on
here. All these languages had no type annotations at all first, and it's
quite possible that adding them after the fact was much easier this way.
Certainly with Python where annotation position wasn't even explicitly for
types, but for arbitrary metadata.

Post by 'Bob Nystrom' via Dart Misc
(except for Typed Scheme, but, you know, they're (a lisp (so they have
(their own syntax (space))))).

Post by 'John Messerly' via Dart Misc
I think it might also help with syntax for function types?

And metadata annotations. Or, at least, I thought so at first. But Lasse
and others brought up points that those may be tractable even with the
current annotation style.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Robert Åkerblom-Andersson]

Just one more thing...

I don't know if you have noted this, but the suggested change would collide
with the current named optional parameter syntax I think:

// Current design
enableFlags({bool bold: false, bool hidden: false}) {
// ...
}

// 'var x bool' syntax would work
enableFlagsTypesOnRight({bold bool: false, hidden bool: false}) {
// ...
}

// 'var x : bool' syntax might require some more changes to the language
syntax
enableFlagsTypesOnRightFail({bold : bool : false, hidden : bool : false}) {
// ...
}

While we are on this topic, I find it somewhat odd that positional
parameters differ here and uses "=" instead of ":", maybe there is a good
reason for that? I would rather see that ":" was added to positional
parameters instead of "=".

enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) {
// ...
}

enableFlagsTypesOnRight2([bold bool: false, hidden bool: false]) {
// ...
}

I guess of course one could make the opposite argument as well that
changing both to using "=" would solve my proposed issue above. But even if
you would do that, I don't find it a great solution:

// I would much prefer this
enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) {
// ...
}

// Over this..
enableFlagsTypesOnRight1({bold : bool = false, hidden : bool = false}) {
// ...
}





On Saturday, September 5, 2015 at 1:31:57 PM UTC+2, Robert

Post by Robert Åkerblom-Andersson
I think Justin makes a good point here. I'm not sure the comparison is
completely "fair" (or maybe not that simple) considering that all these
languages have very different backgrounds and evolutions (for example when
types was added, how the overall support for types is the said language,
what kind of backing resources existed; 1 developer that does everything vs
a bigger team etc..).
While it is true that the other languages listed in the thread uses the
"var x : int" syntax I'm not sure they use it because it is the best syntax
for developers, I think they use it because it is an easier syntax to
parse... Maybe it's better if types have been nonexistent for a long time
in many codebases and then all of a sudden types arrives, then I could see
how the extra verbosity could be more beneficial, but that's not Dart, we
already have types... I think the Dart team has some great parsing
infrastructure in place already, the language is designed to be good for
tools etc, if Dart can pull it off without the ":", and I think it can, I
just find that much better. I think Go is a better language to look at for
this particular syntax detail (not overall, overall Go is different in many
way). As I see it they had the resources and time to choose the "best
syntax", I think it's valid to ask why did they not use "var x : int" if
it's so great? Maybe it's worth reaching out internally (at Google) to see
if they had a similar discussion back then or not. I think the answer
simply is that they did not do that since they did not need to, some other
languages might have had to do it for various reasons, if Dart does not
need to I don't think it should add it just because some other languages
does...
As I said in the "main thread" I'm not against types on the right, I'm
mostly against the extra ":". As long as there is not a considerable
difference in the effort required to implement this I think the best would
be to skip the ":". For devs that are used to "var x : int", I find the
syntax "var x int" quite familiar. For devs coming from "int x", going to
"var x int" is an easier mental switch than "var x : int", sure the
difference might not look huge but I think adding that new previously
unused character, simply put, looks plain weird for someone who has not
seen it before...
With all that said, I could live with "var x : int", my primary concern is
that it adds more unfamiliarity than needed for new devs. Existing devs
like myself with adapt either way I think.

Post by 'Justin Fagnani' via Dart Misc
On Fri, Sep 4, 2015 at 10:15 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the
method names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

Return<Type, Here>
someFunction() {
...
}
For me, I think the fact that Flow, Hack, Python's type hints, and Mirah
all do this is the really compelling point. It seems like *everyone*
who does optional types for a dynamic language uses this syntax

There could easily be some correlation vs causation confusion going on
here. All these languages had no type annotations at all first, and it's
quite possible that adding them after the fact was much easier this way.
Certainly with Python where annotation position wasn't even explicitly for
types, but for arbitrary metadata.

Post by 'Bob Nystrom' via Dart Misc
(except for Typed Scheme, but, you know, they're (a lisp (so they have
(their own syntax (space))))).

Post by 'John Messerly' via Dart Misc
I think it might also help with syntax for function types?

And metadata annotations. Or, at least, I thought so at first. But Lasse
and others brought up points that those may be tractable even with the
current annotation style.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

[Kasper Peulen]

"While it is true that the other languages listed in the thread uses the
"var x : int" syntax I'm not sure they use it because it is the best syntax
for developers, I think they use it because it is an easier syntax to
parse... "

Swift is one language that also has types on the right, but I don't think
it is because of easier parsing.

On Sat, Sep 5, 2015 at 2:07 PM, Robert Åkerblom-Andersson <

Post by Robert Åkerblom-Andersson
Just one more thing...
I don't know if you have noted this, but the suggested change would
// Current design
enableFlags({bool bold: false, bool hidden: false}) {
// ...
}
// 'var x bool' syntax would work
enableFlagsTypesOnRight({bold bool: false, hidden bool: false}) {
// ...
}
// 'var x : bool' syntax might require some more changes to the language
syntax
enableFlagsTypesOnRightFail({bold : bool : false, hidden : bool : false}) {
// ...
}
While we are on this topic, I find it somewhat odd that positional
parameters differ here and uses "=" instead of ":", maybe there is a good
reason for that? I would rather see that ":" was added to positional
parameters instead of "=".
enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) {
// ...
}
enableFlagsTypesOnRight2([bold bool: false, hidden bool: false]) {
// ...
}
I guess of course one could make the opposite argument as well that
changing both to using "=" would solve my proposed issue above. But even if
// I would much prefer this
enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) {
// ...
}
// Over this..
enableFlagsTypesOnRight1({bold : bool = false, hidden : bool = false}) {
// ...
}
On Saturday, September 5, 2015 at 1:31:57 PM UTC+2, Robert

Post by Robert Åkerblom-Andersson
I think Justin makes a good point here. I'm not sure the comparison is
completely "fair" (or maybe not that simple) considering that all these
languages have very different backgrounds and evolutions (for example when
types was added, how the overall support for types is the said language,
what kind of backing resources existed; 1 developer that does everything vs
a bigger team etc..).
While it is true that the other languages listed in the thread uses the
"var x : int" syntax I'm not sure they use it because it is the best syntax
for developers, I think they use it because it is an easier syntax to
parse... Maybe it's better if types have been nonexistent for a long time
in many codebases and then all of a sudden types arrives, then I could see
how the extra verbosity could be more beneficial, but that's not Dart, we
already have types... I think the Dart team has some great parsing
infrastructure in place already, the language is designed to be good for
tools etc, if Dart can pull it off without the ":", and I think it can, I
just find that much better. I think Go is a better language to look at for
this particular syntax detail (not overall, overall Go is different in many
way). As I see it they had the resources and time to choose the "best
syntax", I think it's valid to ask why did they not use "var x : int" if
it's so great? Maybe it's worth reaching out internally (at Google) to see
if they had a similar discussion back then or not. I think the answer
simply is that they did not do that since they did not need to, some other
languages might have had to do it for various reasons, if Dart does not
need to I don't think it should add it just because some other languages
does...
As I said in the "main thread" I'm not against types on the right, I'm
mostly against the extra ":". As long as there is not a considerable
difference in the effort required to implement this I think the best would
be to skip the ":". For devs that are used to "var x : int", I find the
syntax "var x int" quite familiar. For devs coming from "int x", going to
"var x int" is an easier mental switch than "var x : int", sure the
difference might not look huge but I think adding that new previously
unused character, simply put, looks plain weird for someone who has not
seen it before...
With all that said, I could live with "var x : int", my primary concern
is that it adds more unfamiliarity than needed for new devs. Existing devs
like myself with adapt either way I think.

Post by 'Justin Fagnani' via Dart Misc
On Fri, Sep 4, 2015 at 10:15 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
[...]
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.

This almost seems like the best reason to do it. Easier to read the
method names. (Confession time: I sometimes leave off the return types of
methods/functions for readability.)

Return<Type, Here>
someFunction() {
...
}
For me, I think the fact that Flow, Hack, Python's type hints, and
Mirah all do this is the really compelling point. It seems like
*everyone* who does optional types for a dynamic language uses this
syntax

There could easily be some correlation vs causation confusion going on
here. All these languages had no type annotations at all first, and it's
quite possible that adding them after the fact was much easier this way.
Certainly with Python where annotation position wasn't even explicitly for
types, but for arbitrary metadata.

Post by 'Bob Nystrom' via Dart Misc
(except for Typed Scheme, but, you know, they're (a lisp (so they have
(their own syntax (space))))).

Post by 'John Messerly' via Dart Misc
I think it might also help with syntax for function types?

And metadata annotations. Or, at least, I thought so at first. But
Lasse and others brought up points that those may be tractable even with
the current annotation style.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

[Filipe Morgado]

Personally, coming from years of AS3 (and still writing it), I like RHS types.

It enforces the optionally-typed/inferenced nature of a language. With LHS types, we can't exactly add/remove types without making adjustments.

It was mentioned elsewhere that Dart could become a fully-annotated bytecode language (or binary AST, like WASM). I'm all for it and should probably shorten startup times and app sizes. In which case, inference could be made a lot more complex since it would be done AoT. Types could be finally omitted, which isn't exactly the case today. It would't really matter then which side the types are.

[Lasse Knud Damgaard]

Personally and from a completely idealistic point of view I would prefer
the postfix syntax. I coded professionally in a language like that
(ActionsScript) for a few years and found it very natural, even coming from
more of a C/Java background. One of the main benefits in a language like
ActionScript (which is in many ways similar to Dart) and which I think was
also mentioned in the DEP notes is that the postfix syntax makes the
var/final declaration non-optional which means that it's not any more
verbose to declare stuff final and you consequently just do it more (as
opposed to how a lot of people don't use final in Java for instance). I
also agree that is seems a more natural fit when types are optional.

However:

The biggest problem (aside from migration, which we would *absolutely*

Post by 'Bob Nystrom' via Dart Misc
provide automated tooling for) is unfamiliarity. That is a real issue.

Now I'm not meaning to say that you diminish the question of migration
however I believe this is by far the most important question to consider.
It's one thing to convert your own codebase given good tools but will all
your dependencies be converted? And if so, will all pub packages have to
exist in a 1.x and 2.x version while everybody upgrades? I think Python 3
demonstrates very clearly that even a few libraries hanging on to an older
language version can really cause fragmentation because you just don't want
to waste time reimplementing library functionality yourself just to get on
the 'new' version when the old one works just fine.

More generally, are there any examples of languages that are not completely
academic or niche making such radical changes post 1.0 without it generally
being a disaster?
That is not a retorical question by the way :-)

The same question could of course be raised for any breaking feature in
2.0, this one just seems like the most radical.

Lasse

[Arron Washington]

I think Python 3 demonstrates very clearly that even a few libraries

hanging on to an older language version can really cause fragmentation
because you just don't want to waste time reimplementing library
functionality yourself just to get on the 'new' version when the old one
works just fine.

Python 3's changes couldn't be automated away: they all required manual
work to upgrade libraries. A significant investment all around.

Kotlin (also has types on the right), through its maturation as a language,
has deprecated and removed many things. JetBrains (Kotlin's creator) has
always shipped a set of "quick fixes" that will migrate defunct code to its
equivalent in the new version. I imagine that Dart, as tool-able as it is,
would be able to do the same, so a migrating a codebase should only take a
few seconds?

Personally and from a completely idealistic point of view I would prefer
the postfix syntax. I coded professionally in a language like that
(ActionsScript) for a few years and found it very natural, even coming from
more of a C/Java background. One of the main benefits in a language like
ActionScript (which is in many ways similar to Dart) and which I think was
also mentioned in the DEP notes is that the postfix syntax makes the
var/final declaration non-optional which means that it's not any more
verbose to declare stuff final and you consequently just do it more (as
opposed to how a lot of people don't use final in Java for instance). I
also agree that is seems a more natural fit when types are optional.
The biggest problem (aside from migration, which we would *absolutely*

Post by 'Bob Nystrom' via Dart Misc
provide automated tooling for) is unfamiliarity. That is a real issue.

Now I'm not meaning to say that you diminish the question of migration
however I believe this is by far the most important question to consider.
It's one thing to convert your own codebase given good tools but will all
your dependencies be converted? And if so, will all pub packages have to
exist in a 1.x and 2.x version while everybody upgrades? I think Python 3
demonstrates very clearly that even a few libraries hanging on to an older
language version can really cause fragmentation because you just don't want
to waste time reimplementing library functionality yourself just to get on
the 'new' version when the old one works just fine.
More generally, are there any examples of languages that are not
completely academic or niche making such radical changes post 1.0 without
it generally being a disaster?
That is not a retorical question by the way :-)
The same question could of course be raised for any breaking feature in
2.0, this one just seems like the most radical.
Lasse

[tatumizer-v0.2]

Post by Lasse Knud Damgaard
More generally, are there any examples of languages that are not

completely academic or niche making such radical changes post 1.0 without
it generally being a disaster?
My understanding is that 99+% of all code written in dart for production is
written at google. (E.g., I tried to find dart jobs in Canada - there's
none. In US, on monster.com, there are 50 jobs but most of them in fact
refer not to dart, but to DART, which can mean one of the following 50
things: http://acronyms.thefreedictionary.com/DART).

The change won't make the language less popular elsewhere, that's for sure.
It may make the syntax less convenient in common case, that's a bigger
concern. If you look at TIOBE, it's obvious that absolute majority of
programmers currently are "type-leftists". For them (us?) it's a foreign
notation, takes time to get used to, and the benefits of undergoing this
mental shift are unclear.

['Bob Nystrom' via Dart Misc]

On Fri, Sep 4, 2015 at 11:07 AM, Lasse Knud Damgaard <

Post by Lasse Knud Damgaard
Personally and from a completely idealistic point of view I would prefer
the postfix syntax. I coded professionally in a language like that
(ActionsScript) for a few years and found it very natural, even coming from
more of a C/Java background.

Ah, yes. I forgot ActionScript, but that's another example of "popular
language with optional type annotations". I wrote a lot of AS back when I
was a game developer at EA.

Post by Lasse Knud Damgaard
The biggest problem (aside from migration, which we would *absolutely*

Post by 'Bob Nystrom' via Dart Misc
provide automated tooling for) is unfamiliarity. That is a real issue.

Now I'm not meaning to say that you diminish the question of migration
however I believe this is by far the most important question to consider.
It's one thing to convert your own codebase given good tools but will all
your dependencies be converted? And if so, will all pub packages have to
exist in a 1.x and 2.x version while everybody upgrades? I think Python 3
demonstrates very clearly that even a few libraries hanging on to an older
language version can really cause fragmentation because you just don't want
to waste time reimplementing library functionality yourself just to get on
the 'new' version when the old one works just fine.
More generally, are there any examples of languages that are not
completely academic or niche making such radical changes post 1.0 without
it generally being a disaster?

I think the interesting question is whether or not Dart should be
considered "niche" today. The last time I checked, we had less than 2,000
packages on pub and many of those are unmaintained or come from Google.

Go is a good example of a language that made breaking changes after
becoming popular and having it go smoothly. Being judicious is part of
that, but gofix is a huge component too.

I totally agree any breaking change is very hard to do well. Here's why I
think breaking changes like this are worth doing for Dart:

- Compared to other existing languages, our ecosystem is tiny. The set
of things broken by a breaking is quite small. This is one of the rare
cases where not being very popular is a real asset. :-/

- Our largest customers today are internal to Google's monolithic repo
structure makes it possible to land sweeping changes atomically.

- Unlike, say Python, Dart is much more amenable to static analysis,
which makes automated fixups more tractable. We also have already
implemented most of the analysis infrastructure required for this.

- Dart's package ecosystem, unlike Ruby and Python's, was designed
around versioning from day one. In particular, packages also can control
which versions of *Dart *they are compatible with. If we ship Dart 2.0,
pub will automatically help ensure you only get packages that work on 2.0.
In fact, you rely on this functionality every day. It's why you won't pick
up a version of a package that uses async/await until you upgrade your SDK
to one that supports it.

- For this particular change, it's syntactic, not semantic. That makes
it much easier for an automated tool to detect and fix. It's just parser
work. Contrast that with Python's change to strings, which affects the
actual *runtime* behavior of objects that can get passed from one module
to another.

- The cost benefit analysis is very different for us. Python 2.x is
already quite good and successful, so the increase in value from that to
Python 3.0 is relatively less. There's less relative benefit to motivate
the change. Dart 1.x, is frankly not successful in the marketplace. In the
eyes of the world, there clearly is a lot of room to improve. It's possible
for us to design a Dart 2.0 that is miles better than Dart 1.0 just because
the relative starting point is lower.

The math is sort of like this:

var improvement = valueOfNewBehavior - valueOfOldBehavior;
var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;
var worthDoing = improvement - totalMigrationCost;


Compared to other languages, valueOfOldBehavior is likely lower.
numberOfLibraries is certainly much lower. toolability is higher in most
cases. Given that, worthDoing skews a lot higher for us than it would in
other language ecosystems.

Post by Lasse Knud Damgaard
The same question could of course be raised for any breaking feature in
2.0, this one just seems like the most radical.

In many ways, this is not that radical. Since it's easier to automate than
many other changes, it would be annoying, but relatively straightforward to
just fix all the code. Compare that to, say, making strings UTF-8
internally, which would require deep human introspection and lots of
testing to ensure old code is upgrade.

Cheers!

- bob

[Cogman]

@Bob

You missed rust in the type on the right languages. Rust does modifiers on
the left, type on the right and then does a crap-load of type inference so
you almost never do any type typing.

So with rust it is usually something like this

let bob = true;
let bob : bool = true;
let mut bob : bool = true;

With really good type inference, type on the right modifiers on the left
makes things pretty succinct. Further you could still have something like

var bob = jim;
var bob : Person = jimbo;
const bob = jim;

Which would minimize a lot of the impact of types really being on the right
while providing a lot of the usability benefits that right types bring to
the table.

On Fri, Sep 4, 2015 at 1:36 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Fri, Sep 4, 2015 at 11:07 AM, Lasse Knud Damgaard <

Post by Lasse Knud Damgaard
Personally and from a completely idealistic point of view I would prefer
the postfix syntax. I coded professionally in a language like that
(ActionsScript) for a few years and found it very natural, even coming from
more of a C/Java background.

Ah, yes. I forgot ActionScript, but that's another example of "popular
language with optional type annotations". I wrote a lot of AS back when I
was a game developer at EA.

Post by Lasse Knud Damgaard
The biggest problem (aside from migration, which we would *absolutely*

Post by 'Bob Nystrom' via Dart Misc
provide automated tooling for) is unfamiliarity. That is a real issue.

Now I'm not meaning to say that you diminish the question of migration
however I believe this is by far the most important question to consider.
It's one thing to convert your own codebase given good tools but will all
your dependencies be converted? And if so, will all pub packages have to
exist in a 1.x and 2.x version while everybody upgrades? I think Python 3
demonstrates very clearly that even a few libraries hanging on to an older
language version can really cause fragmentation because you just don't want
to waste time reimplementing library functionality yourself just to get on
the 'new' version when the old one works just fine.
More generally, are there any examples of languages that are not
completely academic or niche making such radical changes post 1.0 without
it generally being a disaster?

I think the interesting question is whether or not Dart should be
considered "niche" today. The last time I checked, we had less than 2,000
packages on pub and many of those are unmaintained or come from Google.
Go is a good example of a language that made breaking changes after
becoming popular and having it go smoothly. Being judicious is part of
that, but gofix is a huge component too.
I totally agree any breaking change is very hard to do well. Here's why I
- Compared to other existing languages, our ecosystem is tiny. The set
of things broken by a breaking is quite small. This is one of the rare
cases where not being very popular is a real asset. :-/
- Our largest customers today are internal to Google's monolithic repo
structure makes it possible to land sweeping changes atomically.
- Unlike, say Python, Dart is much more amenable to static analysis,
which makes automated fixups more tractable. We also have already
implemented most of the analysis infrastructure required for this.
- Dart's package ecosystem, unlike Ruby and Python's, was designed
around versioning from day one. In particular, packages also can control
which versions of *Dart *they are compatible with. If we ship Dart
2.0, pub will automatically help ensure you only get packages that work on
2.0. In fact, you rely on this functionality every day. It's why you won't
pick up a version of a package that uses async/await until you upgrade your
SDK to one that supports it.
- For this particular change, it's syntactic, not semantic. That makes
it much easier for an automated tool to detect and fix. It's just parser
work. Contrast that with Python's change to strings, which affects the
actual *runtime* behavior of objects that can get passed from one
module to another.
- The cost benefit analysis is very different for us. Python 2.x is
already quite good and successful, so the increase in value from that to
Python 3.0 is relatively less. There's less relative benefit to motivate
the change. Dart 1.x, is frankly not successful in the marketplace. In the
eyes of the world, there clearly is a lot of room to improve. It's possible
for us to design a Dart 2.0 that is miles better than Dart 1.0 just because
the relative starting point is lower.
var improvement = valueOfNewBehavior - valueOfOldBehavior;
var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;
var worthDoing = improvement - totalMigrationCost;
Compared to other languages, valueOfOldBehavior is likely lower.
numberOfLibraries is certainly much lower. toolability is higher in most
cases. Given that, worthDoing skews a lot higher for us than it would in
other language ecosystems.

Post by Lasse Knud Damgaard
The same question could of course be raised for any breaking feature in
2.0, this one just seems like the most radical.

In many ways, this is not that radical. Since it's easier to automate than
many other changes, it would be annoying, but relatively straightforward to
just fix all the code. Compare that to, say, making strings UTF-8
internally, which would require deep human introspection and lots of
testing to ensure old code is upgrade.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Brian Slesinsky' via Dart Misc]

On Fri, Sep 4, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
Go is a good example of a language that made breaking changes after
becoming popular and having it go smoothly. Being judicious is part of
that, but gofix is a huge component too.

I think most of Go's popularity came after 1.0, after they stopped making
core language changes. They have a nice tool with "go fix" but the
community was pretty tiny at the time; I think Dart is already bigger. They
aren't using "go fix" much anymore.

I totally agree any breaking change is very hard to do well. Here's why I

Post by 'Bob Nystrom' via Dart Misc
- Compared to other existing languages, our ecosystem is tiny. The set
of things broken by a breaking is quite small. This is one of the rare
cases where not being very popular is a real asset. :-/
- Our largest customers today are internal to Google's monolithic repo
structure makes it possible to land sweeping changes atomically.
You're assuming more magic than we actually have. We can make big changes

in google3 but you never want to try to do it as a single commit if you
value your sanity. What if that commit needs to be rolled forward and back
multiple times? Best practice is a series of carefully planned migration
steps done using small CL's in parallel with opt-in and opt-out phases.
Dart is already at the point where making a major change would be fairly
painful, and we still have cleanup to do from previous changes.

If we had to do it, my recommendation would be a "use dart2" (or
equivalent) declaration at the top of each file to enable the new syntax
along with complete interoperability with existing code for a few months
(realistically) so the community can migrate. (This includes upgrading all
the code generators which can't be migrated automatically.)

Post by 'Bob Nystrom' via Dart Misc
var improvement = valueOfNewBehavior - valueOfOldBehavior;
var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;
var worthDoing = improvement - totalMigrationCost;
Compared to other languages, valueOfOldBehavior is likely lower.
numberOfLibraries is certainly much lower. toolability is higher in most
cases. Given that, worthDoing skews a lot higher for us than it would in
other language ecosystems.

I analyze this a different way. How bad is Dart's syntax compared to its
ideal syntax? If the gap is large then "improvement" can be large. But I
don't think we have a situation like Erlang->Elixir or Java->Dart. Dart's
syntax is already quite good and easy to pick up, so it's hard for further
improvements to move the needle much.

Moving types on the right isn't going to do it. It's certainly a big
change, but it's not a big improvement. People aren't going to say "hey,
they fixed Dart's syntax so it's much more interesting to me now."

On the cost side, you're leaving out the *perception* of instability. It
doesn't matter how much code people have written in Dart. What people are
trying to figure out is if they jump in, how much work will they need to do
to "keep up" with the language? So a period of stability can be useful.

It seems like we should start out with important features for mobile and
see if they can be done without a compatibility break, rather than assuming
we need a Dart 2.0? I expect that extending the language (as with
async/await) would be both easier and more useful than redoing core
language stuff.

My own pet feature is having a good syntax for inline templates for UI
component trees. Removing "new" would be a small step in that direction,
but I don't think the outsider would recognize Dart as a good language to
write UI templates in if we removed "new". Something like JSX seems more
promising, since it's more recognizable as a template language and closer
to what people expect from a template language.

But we don't need a big compatibility break to add that. It's a smaller
change than async/await.

- Brian

['Bob Nystrom' via Dart Misc]

On Fri, Sep 4, 2015 at 1:31 PM, 'Brian Slesinsky' via Dart Misc <

Post by 'Brian Slesinsky' via Dart Misc
On Fri, Sep 4, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
Go is a good example of a language that made breaking changes after
becoming popular and having it go smoothly. Being judicious is part of
that, but gofix is a huge component too.

I think most of Go's popularity came after 1.0, after they stopped making
core language changes. They have a nice tool with "go fix" but the
community was pretty tiny at the time; I think Dart is already bigger.

You really think so? These kind of metrics are hard to gather, but my
impression is that they had more users then than we do now. Maybe just a
differene of perception.

Post by 'Brian Slesinsky' via Dart Misc
They aren't using "go fix" much anymore.

True, because they aren't talking about Go 2 any time soon.

Post by 'Brian Slesinsky' via Dart Misc
I totally agree any breaking change is very hard to do well. Here's why I

Post by 'Bob Nystrom' via Dart Misc
- Compared to other existing languages, our ecosystem is tiny. The
set of things broken by a breaking is quite small. This is one of the rare
cases where not being very popular is a real asset. :-/
- Our largest customers today are internal to Google's monolithic
repo structure makes it possible to land sweeping changes atomically.
You're assuming more magic than we actually have. We can make big changes

in google3 but you never want to try to do it as a single commit if you
value your sanity. What if that commit needs to be rolled forward and back
multiple times? Best practice is a series of carefully planned migration
steps done using small CL's in parallel with opt-in and opt-out phases.
Dart is already at the point where making a major change would be fairly
painful, and we still have cleanup to do from previous changes.
If we had to do it, my recommendation would be a "use dart2" (or
equivalent) declaration at the top of each file to enable the new syntax
along with complete interoperability with existing code for a few months
(realistically) so the community can migrate. (This includes upgrading all
the code generators which can't be migrated automatically.)

Yeah, or, when possible, supporting both syntaxes simultaneously. There's
lot of cats and lots of ways to skin them for stuff like this.

var improvement = valueOfNewBehavior - valueOfOldBehavior;

Post by 'Brian Slesinsky' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
var totalMigrationCost = (migrationCost - toolability) *
numberOfLibraries;
var worthDoing = improvement - totalMigrationCost;
Compared to other languages, valueOfOldBehavior is likely lower.
numberOfLibraries is certainly much lower. toolability is higher in most
cases. Given that, worthDoing skews a lot higher for us than it would in
other language ecosystems.

I analyze this a different way. How bad is Dart's syntax compared to its
ideal syntax? If the gap is large then "improvement" can be large. But I
don't think we have a situation like Erlang->Elixir or Java->Dart. Dart's
syntax is already quite good and easy to pick up, so it's hard for further
improvements to move the needle much.

Good point. I definitely wouldn't suggest moving types on the right as an
isolated change. But, in the context of other syntax changes, it may be
worth doing if it gets us to something holistically simpler and better.

Post by 'Brian Slesinsky' via Dart Misc
Moving types on the right isn't going to do it. It's certainly a big
change, but it's not a big improvement. People aren't going to say "hey,
they fixed Dart's syntax so it's much more interesting to me now."

True.

Post by 'Brian Slesinsky' via Dart Misc
On the cost side, you're leaving out the *perception* of instability. It
doesn't matter how much code people have written in Dart. What people are
trying to figure out is if they jump in, how much work will they need to do
to "keep up" with the language? So a period of stability can be useful.

Sure, I wouldn't want to scare people off with churn. At the same time, we
*have* been stable for a good while, and it hasn't gotten us masses of
users yet. I'm not saying we would have *more* if we had been less stable,
but I do think there's an opportunity to make real changes for the better.

Post by 'Brian Slesinsky' via Dart Misc
It seems like we should start out with important features for mobile and
see if they can be done without a compatibility break, rather than assuming
we need a Dart 2.0?

I think "if we do Dart 2.0" is implicit in these discussions, but it's good
to call this out. Certainly, if we see a path to paradise that doesn't
involve trekking through the Valley of Breaking Changes, we will definitely
do that.

I expect that extending the language (as with async/await) would be both

Post by 'Brian Slesinsky' via Dart Misc
easier and more useful than redoing core language stuff.
My own pet feature is having a good syntax for inline templates for UI
component trees. Removing "new" would be a small step in that direction,
but I don't think the outsider would recognize Dart as a good language to
write UI templates in if we removed "new". Something like JSX seems more
promising, since it's more recognizable as a template language and closer
to what people expect from a template language.
But we don't need a big compatibility break to add that. It's a smaller
change than async/await.

I too would like better notation for building up declarative, structured
data. We aren't very DSL friendly.

Cheers!

- bob

[tatumizer-v0.2]

I think Dart 2.0 should come with a much better promise of type inference

and let users reliably omit type annotations on locals.
...

With really good type inference, type on the right modifiers on the left

makes things pretty succinct

This works both ways. If you can omit type, what difference does it make
whether you omitted it on the right or on the left? :-)

+1 for JSX. I unexpectedly found myself liking JSX syntax much more than
dart's unwieldy literals, with "new" or without.

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
This works both ways. If you can omit type, what difference does it make
whether you omitted it on the right or on the left? :-)

You can't *omit* the type here:

int i = 123;


:)

- bob

['Brian Slesinsky' via Dart Misc]

Post by 'Bob Nystrom' via Dart Misc
Sure, I wouldn't want to scare people off with churn. At the same time, we
*have* been stable for a good while, and it hasn't gotten us masses of
users yet. I'm not saying we would have *more* if we had been less
stable, but I do think there's an opportunity to make real changes for the
better.

I'm not sure we've actually tried stability yet. Dart hasn't really been
there for web developers due to not having an easy to use, stable UI
framework. It seems like our first chance will be after the Angular 2
release. It would be a shame if, once the IDE and web framework transitions
are behind us, we give people something new to worry about with Dart 2.0.

- Brian

[Benjamin Strauß]

Post by 'Bob Nystrom' via Dart Misc
I too would like better notation for building up declarative, structured
data. We aren't very DSL friendly.

Doesn't Scala have implicit member selection with spaces similiar to
smalltalk? That would certainly be a solution. My guess is the sky folks
would also like this for their UI building.

[Daniel Davidson]

Post by 'Bob Nystrom' via Dart Misc
I too would like better notation for building up declarative, structured
data. We aren't very DSL friendly.

Bob,

Could you elaborate on what you mean here? Maybe by describing what you
would like to see that is more declarative and DSL friendly?

Maybe I'm totally abusing Dart by making a 100 plus-line statement
<https://github.com/patefacio/cpp_ebisu/blob/master/codegen/bin/libs/utils.dart#L6-L170>,
but I still love that you can do so much declaratively with cascades.

Thanks
Dan

Post by 'Bob Nystrom' via Dart Misc
Cheers!
- bob

[Daniel Davidson]

Post by 'Bob Nystrom' via Dart Misc
I too would like better notation for building up declarative, structured
data. We aren't very DSL friendly.

Bob,

Could you elaborate on what you mean here? Maybe by describing what you
would like to see that is more declarative and DSL friendly?

Maybe I'm totally abusing Dart by making a 100 plus-line statement
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fpatefacio%2Fcpp_ebisu%2Fblob%2Fmaster%2Fcodegen%2Fbin%2Flibs%2Futils.dart%23L6-L170&sa=D&sntz=1&usg=AFQjCNGF-0CQ49gBqoV_LHq-6Yz6EE4j2A>,
but I still love that you can do so much declaratively with cascades.

Thanks
Dan

Post by 'Bob Nystrom' via Dart Misc
Cheers!
- bob

[Man Hoang]

I always prefer types on the right despite having been programming in C# in
the last four years. It's easier to read and parse in my opinion.

We should notice that, 90% of the time, we don't need type annotations when
declaring variables (assuming that type inference is good enough).

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[tatumizer-v0.2]

@Bob: I assumed type inference will be used to implicitly declare type
(Quote: " I think Dart 2.0 should come with a much better promise of type
inference ").
Then, using old declaration syntax, we have:
var x = 42; // automatically declares x as int
And with new syntax:
var x = 42; // automatically declares x as int

I fail to see much of a difference between the two, but maybe it's only me.

Regardless of this - I looked into some of the languages cited as
inspiration. Apparently, all of them follow a meta-pattern: every
declaration is introduced by keyword.
When keyword is mandatory, the rest of the syntax follows. "var x" - where
to add type annotation here? On the right is the only choice. So the
language takes "type on the right" simply as a consequence of another
language decision.

However, this in turn affects also other decisions: e.g. functions are
introduced by keyword, too (variants: "function", "fun", "func", "def",
etc). Examples:
fn add_one(x: i32) -> i32 // rust
func add_one(x int) int // go
func add_one(x: Int) -> Int // swift

// etc...

Is dart going to copy this pattern as well? How about "lambda" for
anonymous function? What "get" declaration will look like?
And, more broadly, *what is exactly the problem that we are trying to
solve?*

As an aside, right-typing is not a recent invention. E.g. in PL/1:
DCL FOO FIXED BINARY(31);
Here, the keyword is a verb ("declare"), so the sentence at least makes
some sense.

[Jan Mostert]

What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?

Type a = someValue;

instead of

var a : Type = someValue;

With all that said, I could live with "var x : int", my primary concern is

Post by Robert Åkerblom-Andersson
that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*

The last time I've seen that kind of syntax was in Pascal / Delphi over 15
years ago, I certainly prefer the C / C++ / Java way of placing the type on
the left.

Something that it was useful for in the Delphi days was defining large
blocks of variables in such a way:

var
s1, s2, s3, s4, s5: String;
k1, k2, k3: int;
q: int = 3;

With types on the left, you get rid of the var keyword:

String s1, s2, s3, s4, s5;
int k1, k2, k3=2, q=3;

Post by Robert Åkerblom-Andersson
At the same time, we have been stable for a good while, and it hasn't
gotten us masses of users yet

At Devoxx Belgium last year, I spoke to many engineers from large companies
including several Oracle engineers, a couple of Google engineers, one
Amazon engineer, somebody from Microsoft and several software architects.
The general concern with many things Google, is how Google make and break
stuff and then drop it when they've lost interest in it. Two of the
engineers mentioned GWT as an example, Google was pushing GWT heavily, then
all of a sudden they handed it over to Vaadin. When I asked about Polymer,
the answers were similar, we like the idea, but are skeptical that it will
still be around next year.
I asked a Google engineer about Polymer and his advice was to be careful
where I'm using it as he himself wasn't sure what direction Polymer was
going. Amazon, I mentioned Dart, the engineer said they won't touch it due
to it being an immature language with immature package base.
So in short, it's more a publicity / perception issue than adding a ton of
new language features.

Keeping things stable and backwards compatible seems to be high on the list
of requirements when choosing a language for a new project for many of the
companies I've done work for.














--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Robert Åkerblom-Andersson
@Bob: I assumed type inference will be used to implicitly declare type
(Quote: " I think Dart 2.0 should come with a much better promise of type
inference ").
var x = 42; // automatically declares x as int
var x = 42; // automatically declares x as int
I fail to see much of a difference between the two, but maybe it's only me.
Regardless of this - I looked into some of the languages cited as
inspiration. Apparently, all of them follow a meta-pattern: every
declaration is introduced by keyword.
When keyword is mandatory, the rest of the syntax follows. "var x" - where
to add type annotation here? On the right is the only choice. So the
language takes "type on the right" simply as a consequence of another
language decision.
However, this in turn affects also other decisions: e.g. functions are
introduced by keyword, too (variants: "function", "fun", "func", "def",
fn add_one(x: i32) -> i32 // rust
func add_one(x int) int // go
func add_one(x: Int) -> Int // swift
// etc...
Is dart going to copy this pattern as well? How about "lambda" for
anonymous function? What "get" declaration will look like?
And, more broadly, *what is exactly the problem that we are trying to
solve?*
DCL FOO FIXED BINARY(31);
Here, the keyword is a verb ("declare"), so the sentence at least makes
some sense.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

On Sunday, September 6, 2015 at 8:37:49 PM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern is

Post by Robert Åkerblom-Andersson
that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over 15
years ago, I certainly prefer the C / C++ / Java way of placing the type on
the left.
Something that it was useful for in the Delphi days was defining large
var
s1, s2, s3, s4, s5: String;
k1, k2, k3: int;
q: int = 3;
String s1, s2, s3, s4, s5;
int k1, k2, k3=2, q=3;

Post by Robert Åkerblom-Andersson
At the same time, we have been stable for a good while, and it hasn't
gotten us masses of users yet

At Devoxx Belgium last year, I spoke to many engineers from large
companies including several Oracle engineers, a couple of Google engineers,
one Amazon engineer, somebody from Microsoft and several software
architects. The general concern with many things Google, is how Google make
and break stuff and then drop it when they've lost interest in it. Two of
the engineers mentioned GWT as an example, Google was pushing GWT heavily,
then all of a sudden they handed it over to Vaadin. When I asked about
Polymer, the answers were similar, we like the idea, but are skeptical that
it will still be around next year.
I asked a Google engineer about Polymer and his advice was to be careful
where I'm using it as he himself wasn't sure what direction Polymer was
going. Amazon, I mentioned Dart, the engineer said they won't touch it
due to it being an immature language with immature package base.
So in short, it's more a publicity / perception issue than adding a ton of
new language features.
Keeping things stable and backwards compatible seems to be high on the
list of requirements when choosing a language for a new project for many of
the companies I've done work for.

I like this open discussions about Darts future and I'll start worrying
about Dart when the Dart team doesn't discuss possible future directions
anymore.
I invested heavily in MS technologies in the past and they didn't fix the
simplest limitations for years, if ever. I found this worse than killing a
project. When a project gets killed, you at least don't expect anything
anymore that won't happen anyway. Makes it much easier to move on.
Googles approach is much more honest than keeping mostly unmaintained
products around just to keep the license fees flowing.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Robert Åkerblom-Andersson
@Bob: I assumed type inference will be used to implicitly declare type
(Quote: " I think Dart 2.0 should come with a much better promise of type
inference ").
var x = 42; // automatically declares x as int
var x = 42; // automatically declares x as int
I fail to see much of a difference between the two, but maybe it's only me.
Regardless of this - I looked into some of the languages cited as
inspiration. Apparently, all of them follow a meta-pattern: every
declaration is introduced by keyword.
When keyword is mandatory, the rest of the syntax follows. "var x" -
where to add type annotation here? On the right is the only choice. So the
language takes "type on the right" simply as a consequence of another
language decision.
However, this in turn affects also other decisions: e.g. functions are
introduced by keyword, too (variants: "function", "fun", "func", "def",
fn add_one(x: i32) -> i32 // rust
func add_one(x int) int // go
func add_one(x: Int) -> Int // swift
// etc...
Is dart going to copy this pattern as well? How about "lambda" for
anonymous function? What "get" declaration will look like?
And, more broadly, *what is exactly the problem that we are trying to
solve?*
DCL FOO FIXED BINARY(31);
Here, the keyword is a verb ("declare"), so the sentence at least makes
some sense.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[kc]

On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern is

Post by Robert Åkerblom-Andersson
that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over 15
years ago, I certainly prefer the C / C++ / Java way of placing the type on
the left.

The rhs ':' notation isn't coming so much from Delphi (Anders Hejlsberg )
but from the static functional languages ML, OCaml, Scala and F# (Luke
Hoban). These languages have opened dev's minds to more expressive type
systems then Java/C#. And this syntax makes complex annotations easier.

So TS & Flow - without the limitation of a Checked Mode - were able to go
to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.

This got developers mind-share vs Dart.

But, the time to make a switch was maybe pre-1.0 - not so much now.

K.

[Jan Mostert]

"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for
a living) and 0 people working in other functional languages. Java, C#,
C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people,
placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same
syntax rules I know about Java and eased into it very easy, a day later I
churned probably about twice the amount of business value than I would have
in Java.
My wife coming from a C# background also picked up Dart and started
churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart
Evangelists knock on people's doors and ask if they have time to talk about
Dart.

Post by kc
On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern

Post by Robert Åkerblom-Andersson
is that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over
15 years ago, I certainly prefer the C / C++ / Java way of placing the type
on the left.

The rhs ':' notation isn't coming so much from Delphi (Anders Hejlsberg )
but from the static functional languages ML, OCaml, Scala and F# (Luke
Hoban). These languages have opened dev's minds to more expressive type
systems then Java/C#. And this syntax makes complex annotations easier.
So TS & Flow - without the limitation of a Checked Mode - were able to go
to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.
This got developers mind-share vs Dart.
But, the time to make a switch was maybe pre-1.0 - not so much now.
K.

[Gen]

I will never understand that standpoint of considering curly braces, "new"
and "left side type declarations" as a big win because of familiarity.
There is a whole new language with
- a different syntax
- different access modifiers
- a different module system
- a different type system
- a different culture (types, closures, mixins,...)
- a different approach to concurrency (e.g. cooperative, non-preemptive
multi tasking)
- streams, futures, promises, sinks and async/await
- a different standard library
- different tools

Right side type declarations with a colon have become a defacto standard
for dynamically types languages. Even Python 3.5 uses them in PEP 484
(https://www.python.org/downloads/release/python-350/)
Personally I do not care much about the side of type declarations though.

Post by Jan Mostert
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for
a living) and 0 people working in other functional languages. Java, C#,
C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people,
placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same
syntax rules I know about Java and eased into it very easy, a day later I
churned probably about twice the amount of business value than I would have
in Java.
My wife coming from a C# background also picked up Dart and started
churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart
Evangelists knock on people's doors and ask if they have time to talk about
Dart.

Post by kc
On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern

Post by Robert Åkerblom-Andersson
is that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over
15 years ago, I certainly prefer the C / C++ / Java way of placing the type
on the left.

The rhs ':' notation isn't coming so much from Delphi (Anders Hejlsberg )
but from the static functional languages ML, OCaml, Scala and F# (Luke
Hoban). These languages have opened dev's minds to more expressive type
systems then Java/C#. And this syntax makes complex annotations easier.
So TS & Flow - without the limitation of a Checked Mode - were able to go
to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.
This got developers mind-share vs Dart.
But, the time to make a switch was maybe pre-1.0 - not so much now.
K.

[Eduardo Teixeira Dias]

Dart was sold that way...

Easier to understend the argument now?

I do not care what side the type is. Now it is on the left. Why to pay the
cost of this change..

Post by Gen
I will never understand that standpoint of considering curly braces, "new"
and "left side type declarations" as a big win because of familiarity.
There is a whole new language with
- a different syntax
- different access modifiers
- a different module system
- a different type system
- a different culture (types, closures, mixins,...)
- a different approach to concurrency (e.g. cooperative, non-preemptive
multi tasking)
- streams, futures, promises, sinks and async/await
- a different standard library
- different tools
Right side type declarations with a colon have become a defacto standard
for dynamically types languages. Even Python 3.5 uses them in PEP 484 (
https://www.python.org/downloads/release/python-350/)
Personally I do not care much about the side of type declarations though.

Post by Jan Mostert
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it
for a living) and 0 people working in other functional languages. Java, C#,
C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people,
placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same
syntax rules I know about Java and eased into it very easy, a day later I
churned probably about twice the amount of business value than I would have
in Java.
My wife coming from a C# background also picked up Dart and started
churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart
Evangelists knock on people's doors and ask if they have time to talk about
Dart.

Post by kc
On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern

Post by Robert Åkerblom-Andersson
is that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over
15 years ago, I certainly prefer the C / C++ / Java way of placing the type
on the left.

The rhs ':' notation isn't coming so much from Delphi (Anders
Hejlsberg ) but from the static functional languages ML, OCaml, Scala and
F# (Luke Hoban). These languages have opened dev's minds to more expressive
type systems then Java/C#. And this syntax makes complex annotations easier.
So TS & Flow - without the limitation of a Checked Mode - were able to
go to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.
This got developers mind-share vs Dart.
But, the time to make a switch was maybe pre-1.0 - not so much now.
K.

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Saudações,

Eduardo Teixeira Dias

------------------------------------------
Tendencies Consultoria Ltda.
Tel: [phone]
Cel: 11 9 9246-4192

[Alex Tatumizer]

I think it's not so much about familiarity as it is about convenience.
After all, what is the point of syntax sugar if not making things shorter?
(I'm re-phrasing what Gilad said in one of the threads)

Suppose every language in existence used type-on-the-right:
var x : int;

and somebody comes up with idea: why so much ceremony? Just write
int x;
I think it would be perceived as great improvement by many.

Whenever something is used very often, it's just natural to shorten
notation - this is true for any notation, including natural language.

For the same reason I think that
"for (int i<n)" would be better than "for (int i=0; i<n; i++)" - it targets
major use case and makes it shorter and cleaner.

Right vs left debate is very old though. Fortran and Algol use left typing;
Cobol and PL/1 - right typing. Not sure this makes any of them more
"civilized" than the other. Right typing looks more "formal" to me, left
typing - more "colloquial". I'm afraid dart can lose its "cuteness" if it
starts drifting towards more "formal" syntax.

[Gen]

I agree with most of what you wrote.
AFAIU, there are people (creators and users of Dart) that defend some
decisions with familiarity as in "like in other languages for better or
worse".
I like familiarity with similar languages.
But what developers are the target for the Dart team ?
Familiarity would dictate "right side type declarations" WRT to similar
languages: Python, Typescript, Swift. But not Hack from Facebook.
OTOH, I see the future of Dart as replacement for Java 8 and higher for
Android developers and as language with a standard library that runs in the
browser and maybe on iOS.
But even with Android developers as target, there are much more important
concerns with regard to familiarity than keyword "new" or the side of the
type declaration.
Besides, is there any need to write "var x : int = ..." instead of "x :
int = ..." ?

IMO, the most important reason to decide the type declaration question
might be political:
How many Dart users are there and what do they want ?
How many Dart users are the target in the future ?
How does it look like if the Dart team changes the type declaration syntax
and for what reason ?

Post by Alex Tatumizer
I think it's not so much about familiarity as it is about convenience.
After all, what is the point of syntax sugar if not making things shorter?
(I'm re-phrasing what Gilad said in one of the threads)
var x : int;
and somebody comes up with idea: why so much ceremony? Just write
int x;
I think it would be perceived as great improvement by many.
Whenever something is used very often, it's just natural to shorten
notation - this is true for any notation, including natural language.
For the same reason I think that
"for (int i<n)" would be better than "for (int i=0; i<n; i++)" - it
targets major use case and makes it shorter and cleaner.
Right vs left debate is very old though. Fortran and Algol use left
typing; Cobol and PL/1 - right typing. Not sure this makes any of them more
"civilized" than the other. Right typing looks more "formal" to me, left
typing - more "colloquial". I'm afraid dart can lose its "cuteness" if it
starts drifting towards more "formal" syntax.

[Jim Trainor]

Is this whole discussion just FUD?

Dart is four years old and has been approved as an ECMA standard.. They're
not going to change the declaration syntax at this point. That would be a
different language, not a change.

Post by Gen
I agree with most of what you wrote.
AFAIU, there are people (creators and users of Dart) that defend some
decisions with familiarity as in "like in other languages for better or
worse".
I like familiarity with similar languages.
But what developers are the target for the Dart team ?
Familiarity would dictate "right side type declarations" WRT to similar
languages: Python, Typescript, Swift. But not Hack from Facebook.
OTOH, I see the future of Dart as replacement for Java 8 and higher for
Android developers and as language with a standard library that runs in the
browser and maybe on iOS.
But even with Android developers as target, there are much more important
concerns with regard to familiarity than keyword "new" or the side of the
type declaration.
int = ..." ?
IMO, the most important reason to decide the type declaration question
How many Dart users are there and what do they want ?
How many Dart users are the target in the future ?
How does it look like if the Dart team changes the type declaration syntax
and for what reason ?

Post by Alex Tatumizer
I think it's not so much about familiarity as it is about convenience.
After all, what is the point of syntax sugar if not making things
shorter? (I'm re-phrasing what Gilad said in one of the threads)
var x : int;
and somebody comes up with idea: why so much ceremony? Just write
int x;
I think it would be perceived as great improvement by many.
Whenever something is used very often, it's just natural to shorten
notation - this is true for any notation, including natural language.
For the same reason I think that
"for (int i<n)" would be better than "for (int i=0; i<n; i++)" - it
targets major use case and makes it shorter and cleaner.
Right vs left debate is very old though. Fortran and Algol use left
typing; Cobol and PL/1 - right typing. Not sure this makes any of them more
"civilized" than the other. Right typing looks more "formal" to me, left
typing - more "colloquial". I'm afraid dart can lose its "cuteness" if it
starts drifting towards more "formal" syntax.
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Benjamin Strauß]

This came up in one of their own meetings, so i guess it's not completely
off the table.

Post by Jim Trainor
Is this whole discussion just FUD?
Dart is four years old and has been approved as an ECMA standard.. They're
not going to change the declaration syntax at this point. That would be a
different language, not a change.

Post by Gen
I agree with most of what you wrote.
AFAIU, there are people (creators and users of Dart) that defend some
decisions with familiarity as in "like in other languages for better or
worse".
I like familiarity with similar languages.
But what developers are the target for the Dart team ?
Familiarity would dictate "right side type declarations" WRT to similar
languages: Python, Typescript, Swift. But not Hack from Facebook.
OTOH, I see the future of Dart as replacement for Java 8 and higher for
Android developers and as language with a standard library that runs in the
browser and maybe on iOS.
But even with Android developers as target, there are much more important
concerns with regard to familiarity than keyword "new" or the side of the
type declaration.
int = ..." ?
IMO, the most important reason to decide the type declaration question
How many Dart users are there and what do they want ?
How many Dart users are the target in the future ?
How does it look like if the Dart team changes the type declaration
syntax and for what reason ?

Post by Alex Tatumizer
I think it's not so much about familiarity as it is about convenience.
After all, what is the point of syntax sugar if not making things
shorter? (I'm re-phrasing what Gilad said in one of the threads)
var x : int;
and somebody comes up with idea: why so much ceremony? Just write
int x;
I think it would be perceived as great improvement by many.
Whenever something is used very often, it's just natural to shorten
notation - this is true for any notation, including natural language.
For the same reason I think that
"for (int i<n)" would be better than "for (int i=0; i<n; i++)" - it
targets major use case and makes it shorter and cleaner.
Right vs left debate is very old though. Fortran and Algol use left
typing; Cobol and PL/1 - right typing. Not sure this makes any of them more
"civilized" than the other. Right typing looks more "formal" to me, left
typing - more "colloquial". I'm afraid dart can lose its "cuteness" if it
starts drifting towards more "formal" syntax.
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Eduardo Teixeira Dias]

I hope it's just FUD

[Hoo Luu]

Considering google will not integrate Dart into chrome, "familiarity"
becomes less important than before.Now dart's target is becoming a general
programming language for mobile/web/server/Iot instead of just a javascript
replacement.As a new programming language, I wish dart's syntax is clean
and consistent without cruft in it (such as some old
languages,java,c++,javascript,etc.) At present,Golang's sell point is
simplicity and concurrency,what about Dart? Many people around me feels
javascript(ES6/TS) is enough and decline to use dart when i recommend dart
to them. IMO,It's time for Dart to innovate even if it becomes somewhat
"unfamiliar" and break backward compatibility.

圚 2015幎9月13日星期日 UTC+8䞋午3:03:24Jan Vladimir Mostert写道

Post by Jan Mostert
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for
a living) and 0 people working in other functional languages. Java, C#,
C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people,
placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same
syntax rules I know about Java and eased into it very easy, a day later I
churned probably about twice the amount of business value than I would have
in Java.
My wife coming from a C# background also picked up Dart and started
churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart
Evangelists knock on people's doors and ask if they have time to talk about
Dart.

Post by kc
On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern

Post by Robert Åkerblom-Andersson
is that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over
15 years ago, I certainly prefer the C / C++ / Java way of placing the type
on the left.

The rhs ':' notation isn't coming so much from Delphi (Anders Hejlsberg )
but from the static functional languages ML, OCaml, Scala and F# (Luke
Hoban). These languages have opened dev's minds to more expressive type
systems then Java/C#. And this syntax makes complex annotations easier.
So TS & Flow - without the limitation of a Checked Mode - were able to go
to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.
This got developers mind-share vs Dart.
But, the time to make a switch was maybe pre-1.0 - not so much now.
K.

[kc]

On Sunday, September 13, 2015 at 8:03:24 AM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for
a living) and 0 people working in other functional languages. Java, C#,
C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people,
placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same
syntax rules I know about Java and eased into it very easy, a day later I
churned probably about twice the amount of business value than I would have
in Java.
My wife coming from a C# background also picked up Dart and started
churning before she even read the docs.

Right. But look at where C# 7 is going - a lot of ideas from the functional
world.

https://github.com/dotnet/roslyn/issues/2136

(This Work List approach looks like a good pragmatic approach for Dart 2.0.
I don't think dev's should be lobbing DEP's at the lang team. Maybe mails
here prefixed with 'Proposal:' which the lang team can consider).

Post by Jan Mostert
So IMO that's a big win, just give it more time and let the Dart
Evangelists knock on people's doors and ask if they have time to talk about
Dart.

Honestly no. It's getting the runtime into mobile with decent
syntax/semantics and performance.

However I think it's possible to for Dart to both not annoy existing users
and evolve in an interesting direction.

Ideally things like concurrency, patterns etc. could be introduced in such
a way that you and your wife would wonder how your ever lived without them
(which is what most dev's feel who tried these things). Also a lot of code
vanishes - but in a good non-magical sense.

So I would vote no to rhs. However there are good reasons for rhs. See E
lang (Mark Miller) and Virgil lang (Ben Titzer). Both of these guys work
for Google. (Always amazes me how Google has smart people working at cross
purposes).

K.

Post by Jan Mostert

Post by kc
On Sunday, September 6, 2015 at 7:37:49 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
What is wrong with types on the left?
Don't we already have a way to explicitly define types if the type is
unknown?
Type a = someValue;
instead of
var a : Type = someValue;
With all that said, I could live with "var x : int", my primary concern

Post by Robert Åkerblom-Andersson
is that it adds more unfamiliarity than needed for new devs

*var x: int = ...* is certainly much more unfamiliar than *int x = ...*
The last time I've seen that kind of syntax was in Pascal / Delphi over
15 years ago, I certainly prefer the C / C++ / Java way of placing the type
on the left.

The rhs ':' notation isn't coming so much from Delphi (Anders Hejlsberg )
but from the static functional languages ML, OCaml, Scala and F# (Luke
Hoban). These languages have opened dev's minds to more expressive type
systems then Java/C#. And this syntax makes complex annotations easier.
So TS & Flow - without the limitation of a Checked Mode - were able to go
to town re types and sold this syntax to TC39. And SoundScript (V8) is
thinking along using the type info re perf.
This got developers mind-share vs Dart.
But, the time to make a switch was maybe pre-1.0 - not so much now.
K.

[kc]

I argued for rhs as part of a broader take pre-1.0. Here's the theory of
the case:

Dart initially started with a JS syntax but then switch to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.

Meanwhile JS got a move on with ES6 and then TypeScript - which sold rhs
types to TC39.

So given that dart2js/dev_compiler/Angular 2 has to compile down to ES why
not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.

Furthermore take the opportunity to fix some irritations in syntax and also
explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.

Syntax annoyances which TC39 member have mentioned:
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const' available
for genuine const's. 'var' mutable non-hoisted.
- no 'new'

So (nonsense example):

// ES6/TS

function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}


// ES6-ish syntax over Dart object model

fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}

Easy on the eye. Also makes the language an easier sell to ES6 users - 'hey
similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say for
non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.

Track/troll TC39.

K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[Benjamin Strauß]

But why the function keyword? I like it that Dart has no function keyword.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory of
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold rhs
types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES why
not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const' available
for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say for
non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[Jan Mostert]

Removing new, +1 (as long as it's backwards compatible with libraries still
using new, in other words, just make it optional)
Adding function / fun keyword, make it optional so that stuff remains
backwards compatible;
Types on the right for functions, looks nice, make it available on left or
right to not break existing code. (eg myfunction():Point or Point
myfunction())
Types on the right for variables, looks nice, once again, make it available
on left and right and everyone's happy.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory of
Dart initially started with a JS syntax but then switch to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold rhs
types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES why
not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const' available
for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say for
non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Lex Berezhny]

Post by Jan Mostert
Removing new, +1 (as long as it's backwards compatible with libraries
still using new, in other words, just make it optional)
Adding function / fun keyword, make it optional so that stuff remains
backwards compatible;
Types on the right for functions, looks nice, make it available on left or
right to not break existing code. (eg myfunction():Point or Point
myfunction())
Types on the right for variables, looks nice, once again, make it
available on left and right and everyone's happy.

Having a million ways to do things is a sure way to create a pedagogical
nightmare and keep Dart as purely niche language.

I hope that no matter which way it's done there is a single right and
obvious way to do something.

['Andreas Kirsch' via Dart Misc]

Yeah, making things optional sounds nightmarish :(

Post by Lex Berezhny

Post by Jan Mostert
Removing new, +1 (as long as it's backwards compatible with libraries
still using new, in other words, just make it optional)
Adding function / fun keyword, make it optional so that stuff remains
backwards compatible;
Types on the right for functions, looks nice, make it available on left
or right to not break existing code. (eg myfunction():Point or Point
myfunction())
Types on the right for variables, looks nice, once again, make it
available on left and right and everyone's happy.

Having a million ways to do things is a sure way to create a pedagogical
nightmare and keep Dart as purely niche language.
I hope that no matter which way it's done there is a single right and
obvious way to do something.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Why is this e-mail so short? Answer: five.sentenc.es.

[Jan Mostert]

And breaking every existing library / piece of dart software out there to
make a nice-to-have change would be exactly the type of thing that scares
away potential adopters - at least business clients who pay developers to
write software. Not every company out there has Google's budget to just
throw dev resources at keeping code maintained.
If both were adopted, and the IDE puts a light-bulb next to the old style
of doing things saying the new recommended way of doing this is so and so,
would you like to convert to the new style, then that would be superb, the
old style still compiles, but with some suggestions.
The new style gets adopted without breaking existing code.

Take Java generics as an example, if you have List containing only Strings,
then IntelliJ recommends rather using List<String>
If you do List<String> s = new ArrayList<String>(), the IDE suggests rather
doing List<String> s = new ArrayList<>()
They both compile, but the IDE suggests what the new way of doing things
should be, Java still compiles both without issues.

Post by Lex Berezhny

Post by Jan Mostert
Removing new, +1 (as long as it's backwards compatible with libraries
still using new, in other words, just make it optional)
Adding function / fun keyword, make it optional so that stuff remains
backwards compatible;
Types on the right for functions, looks nice, make it available on left
or right to not break existing code. (eg myfunction():Point or Point
myfunction())
Types on the right for variables, looks nice, once again, make it
available on left and right and everyone's happy.

Having a million ways to do things is a sure way to create a pedagogical
nightmare and keep Dart as purely niche language.
I hope that no matter which way it's done there is a single right and
obvious way to do something.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

I very much hope `fun` / `function` would not necessary, this would make me
an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not, if not
then it should not be allowed at all.

The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory of
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold rhs
types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES why
not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const' available
for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say for
non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[Jan Mostert]

If libraries in pub are also automatically made dart 2.0+ compatible
(alongside the conversion tool), then kill the new keyword and bring on the
breaking changes.
As long as pub is not split into two - dart1 compliant, dart2 compliant
packages, if it was written in Dart1, it should be migrated to Dart2
without having to wait for package maintainers to upgrade their packages.
Python fragmented their userbase when they made breaking changes like that
moving from Python 2 to Python 3, certain projects I maintained are now
stuck in Python2 since some of the Python 2 libraries doesn't work in
Python3 and the new Python 3 libraries I'd like to use doesn't work in
Python 2, so that project will eventually be migrated away from Python.

Post by Günter Zöchbauer
I very much hope `fun` / `function` would not necessary, this would make
me an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not, if
not then it should not be allowed at all.
The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory of
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold rhs
types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES
why not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const'
available for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say for
non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use
it.* In practice, I think Dart 2.0 should come with a much better
promise of type inference and let users reliably omit type annotations on
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby
<http://www.mirah.org/>, JavaScript <http://flowtype.org/>, PHP
<http://hacklang.org/> all use this syntax. As far as I can tell, it is
the standard way to add optional type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Benjamin Strauß]

You are already able to specify a certain dart version constraint on your
packages in your pubspec. So there shouldn't be any problems. You can't
just edit code of pub libraries, they could be hosted anywhere.

Post by Jan Mostert
If libraries in pub are also automatically made dart 2.0+ compatible
(alongside the conversion tool), then kill the new keyword and bring on the
breaking changes.
As long as pub is not split into two - dart1 compliant, dart2 compliant
packages, if it was written in Dart1, it should be migrated to Dart2
without having to wait for package maintainers to upgrade their packages.
Python fragmented their userbase when they made breaking changes like that
moving from Python 2 to Python 3, certain projects I maintained are now
stuck in Python2 since some of the Python 2 libraries doesn't work in
Python3 and the new Python 3 libraries I'd like to use doesn't work in
Python 2, so that project will eventually be migrated away from Python.

Post by Günter Zöchbauer
I very much hope `fun` / `function` would not necessary, this would make
me an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not, if
not then it should not be allowed at all.
The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory of
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold
rhs types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES
why not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const'
available for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say
for non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use
it.* In practice, I think Dart 2.0 should come with a much better
promise of type inference and let users reliably omit type annotations on
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level
variables, fields, and parameters, I personally like it on the right and
also like ":" even though it's a bit more verbose. Maybe it's just me, but
it helps me separate out the variable name from the type. I'd also be fine
with Go's approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby
<http://www.mirah.org/>, JavaScript <http://flowtype.org/>, PHP
<http://hacklang.org/> all use this syntax. As far as I can tell, it
is the standard way to add optional type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

What about a conversion flag in your pubspec which then converts the Dart1
libraries and keeps a copy of the converted library on your file system?
Libraries are already copied to your filesystem when you include them in
pubspec, conversion on the fly seems like the logical thing to do if Dart2
contains breaking changes.

If you can't convert libraries, you have the same fragmentation problem
Python is having (eg, being stuck in Python 2 because the libraries doesn't
get updated to Python 3 and not being able to use Python 3 libraries in
Python 2).
Java for the most part, Java4 works in Java5, Java5 works in Java6, Java6
works in Java7, Java7 works in Java8 due to code getting compiled to
bytecode.

I'm assuming Dart libraries contains the raw Dart code and doesn't get
compiled to some intermediate bytecode-like format?
If that's the case, library conversion on the fly seems like a logical
option, just include the conversion tool as part of the SDK.

Post by Benjamin Strauß
You are already able to specify a certain dart version constraint on your
packages in your pubspec. So there shouldn't be any problems. You can't
just edit code of pub libraries, they could be hosted anywhere.

Post by Jan Mostert
If libraries in pub are also automatically made dart 2.0+ compatible
(alongside the conversion tool), then kill the new keyword and bring on the
breaking changes.
As long as pub is not split into two - dart1 compliant, dart2 compliant
packages, if it was written in Dart1, it should be migrated to Dart2
without having to wait for package maintainers to upgrade their packages.
Python fragmented their userbase when they made breaking changes like
that moving from Python 2 to Python 3, certain projects I maintained are
now stuck in Python2 since some of the Python 2 libraries doesn't work in
Python3 and the new Python 3 libraries I'd like to use doesn't work in
Python 2, so that project will eventually be migrated away from Python.

I very much hope `fun` / `function` would not necessary, this would make

Post by Jan Mostert

Post by Günter Zöchbauer
me an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not, if
not then it should not be allowed at all.
The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold
rhs types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES
why not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const'
available for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say
for non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use
it.* In practice, I think Dart 2.0 should come with a much better
promise of type inference and let users reliably omit type annotations on
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level
variables, fields, and parameters, I personally like it on the right and
also like ":" even though it's a bit more verbose. Maybe it's just me, but
it helps me separate out the variable name from the type. I'd also be fine
with Go's approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby
<http://www.mirah.org/>, JavaScript <http://flowtype.org/>, PHP
<http://hacklang.org/> all use this syntax. As far as I can tell, it
is the standard way to add optional type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

I don't expect this to work, this would also need to change dependencies to
newer versions. What if a maintainers manually updated a dependency and
also changed the API during?
It's the work of the package maintainers to update the package and publish
a new version, but the tools should make it easy for them to do that.
If the maintainer doesn't do it, you can create a fork and do the update
yourself as a last resort.

A lot of compatibility to previous versions mostly ensure that no
innovation will take place anymore.
Dart is at version 1 and I think it's time to rethink the direction and
adjust. Better now than later.
I don't expect big breaking changes anymore at version 6 but from 1.0 to
2.0 some are to be expected.

On Monday, September 7, 2015 at 6:05:23 PM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
What about a conversion flag in your pubspec which then converts the Dart1
libraries and keeps a copy of the converted library on your file system?
Libraries are already copied to your filesystem when you include them in
pubspec, conversion on the fly seems like the logical thing to do if Dart2
contains breaking changes.
If you can't convert libraries, you have the same fragmentation problem
Python is having (eg, being stuck in Python 2 because the libraries doesn't
get updated to Python 3 and not being able to use Python 3 libraries in
Python 2).
Java for the most part, Java4 works in Java5, Java5 works in Java6, Java6
works in Java7, Java7 works in Java8 due to code getting compiled to
bytecode.
I'm assuming Dart libraries contains the raw Dart code and doesn't get
compiled to some intermediate bytecode-like format?
If that's the case, library conversion on the fly seems like a logical
option, just include the conversion tool as part of the SDK.

Post by Benjamin Strauß
You are already able to specify a certain dart version constraint on your
packages in your pubspec. So there shouldn't be any problems. You can't
just edit code of pub libraries, they could be hosted anywhere.

Post by Jan Mostert
If libraries in pub are also automatically made dart 2.0+ compatible
(alongside the conversion tool), then kill the new keyword and bring on the
breaking changes.
As long as pub is not split into two - dart1 compliant, dart2 compliant
packages, if it was written in Dart1, it should be migrated to Dart2
without having to wait for package maintainers to upgrade their packages.
Python fragmented their userbase when they made breaking changes like
that moving from Python 2 to Python 3, certain projects I maintained are
now stuck in Python2 since some of the Python 2 libraries doesn't work in
Python3 and the new Python 3 libraries I'd like to use doesn't work in
Python 2, so that project will eventually be migrated away from Python.

I very much hope `fun` / `function` would not necessary, this would make

Post by Jan Mostert

Post by Günter Zöchbauer
me an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not, if
not then it should not be allowed at all.
The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory
Dart initially started with a JS syntax but then switched to a more C#
inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold
rhs types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to ES
why not go with a ES6-ish syntax - but skinned over the sane and structured
Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax and
also explore semantic enhancements that TC39 feel they can't do because of
backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const'
available for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users -
'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say
for non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use
it.* In practice, I think Dart 2.0 should come with a much better
promise of type inference and let users reliably omit type annotations on
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level
variables, fields, and parameters, I personally like it on the right and
also like ":" even though it's a bit more verbose. Maybe it's just me, but
it helps me separate out the variable name from the type. I'd also be fine
with Go's approach and eliminating the ":".
The biggest problem (aside from migration, which we would
*absolutely* provide automated tooling for) is unfamiliarity. That
is a real issue. I'd like to be believe it isn't insurmountable, though.
TypeScript, Scala, Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby
<http://www.mirah.org/>, JavaScript <http://flowtype.org/>, PHP
<http://hacklang.org/> all use this syntax. As far as I can tell, it
is the standard way to add optional type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

Quote: "If the maintainer doesn't do it, you can create a fork and do the
update yourself as a last resort."

Is the source code for all the packages on pub available to be able to do
this?
If yes, then that covers my biggest concern which is bricking a brand new
project simply because the packages are not being migrated.

Post by Günter Zöchbauer
I don't expect this to work, this would also need to change dependencies
to newer versions. What if a maintainers manually updated a dependency and
also changed the API during?
It's the work of the package maintainers to update the package and publish
a new version, but the tools should make it easy for them to do that.
If the maintainer doesn't do it, you can create a fork and do the update
yourself as a last resort.
A lot of compatibility to previous versions mostly ensure that no
innovation will take place anymore.
Dart is at version 1 and I think it's time to rethink the direction and
adjust. Better now than later.
I don't expect big breaking changes anymore at version 6 but from 1.0 to
2.0 some are to be expected.
On Monday, September 7, 2015 at 6:05:23 PM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
What about a conversion flag in your pubspec which then converts the
Dart1 libraries and keeps a copy of the converted library on your file
system?
Libraries are already copied to your filesystem when you include them in
pubspec, conversion on the fly seems like the logical thing to do if Dart2
contains breaking changes.
If you can't convert libraries, you have the same fragmentation problem
Python is having (eg, being stuck in Python 2 because the libraries doesn't
get updated to Python 3 and not being able to use Python 3 libraries in
Python 2).
Java for the most part, Java4 works in Java5, Java5 works in Java6, Java6
works in Java7, Java7 works in Java8 due to code getting compiled to
bytecode.
I'm assuming Dart libraries contains the raw Dart code and doesn't get
compiled to some intermediate bytecode-like format?
If that's the case, library conversion on the fly seems like a logical
option, just include the conversion tool as part of the SDK.

Post by Benjamin Strauß
You are already able to specify a certain dart version constraint on
your packages in your pubspec. So there shouldn't be any problems. You
can't just edit code of pub libraries, they could be hosted anywhere.

Post by Jan Mostert
If libraries in pub are also automatically made dart 2.0+ compatible
(alongside the conversion tool), then kill the new keyword and bring on the
breaking changes.
As long as pub is not split into two - dart1 compliant, dart2 compliant
packages, if it was written in Dart1, it should be migrated to Dart2
without having to wait for package maintainers to upgrade their packages.
Python fragmented their userbase when they made breaking changes like
that moving from Python 2 to Python 3, certain projects I maintained are
now stuck in Python2 since some of the Python 2 libraries doesn't work in
Python3 and the new Python 3 libraries I'd like to use doesn't work in
Python 2, so that project will eventually be migrated away from Python.

I very much hope `fun` / `function` would not necessary, this would make

Post by Jan Mostert

Post by Günter Zöchbauer
me an opponent to types on the right.
No for optional `new` or `fun`. Either it is necessary or it is not,
if not then it should not be allowed at all.
The Dart team mentioned a few times that they want to provide tools to
convert from old syntax to new syntax, this should be enough.

Post by kc
I argued for rhs as part of a broader take pre-1.0. Here's the theory
Dart initially started with a JS syntax but then switched to a more
C# inspired syntax ('dynamic', lambda) and some Java ('final', uppercase
String) with lhs types. Combined with Checked Mode an inexpressive type
system was locked into the language. Brendan Eich commented early on (if I
remember correctly) that there was over annotation on locals - a bugbear
of mine.
Meanwhile JS got a move on with ES6 and then TypeScript - which sold
rhs types to TC39.
So given that dart2js/dev_compiler/Angular 2 has to compile down to
ES why not go with a ES6-ish syntax - but skinned over the sane and
structured Smalltalk-ish object model of Dart.
Furthermore take the opportunity to fix some irritations in syntax
and also explore semantic enhancements that TC39 feel they can't do because
of backward compatibility.
- BE feels 'function' too long - 'fun'
- 'let' would be better for immutable/single assignment. 'const'
available for genuine const's. 'var' mutable non-hoisted.
- no 'new'
// ES6/TS
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
// ES6-ish syntax over Dart object model
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
Easy on the eye. Also makes the language an easier sell to ES6 users
- 'hey similar syntax but much less gotchas/weirdness - unsurprising object
model'.
Re semantics - there *has *been creative thinking over at TC39 - say
for non-local returns - but stymied because of backward compat and group
agreement. Dart could explore this area.
Track/troll TC39.
K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going
to split my responses into separate threads. If we could move discussions
to these, that would be swell.
It is strictly more verbose than the current syntax... *when you
use it.* In practice, I think Dart 2.0 should come with a much
better promise of type inference and let users reliably omit type
annotations on locals. When you do that, most of your variable declarations
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level
variables, fields, and parameters, I personally like it on the right and
also like ":" even though it's a bit more verbose. Maybe it's just me, but
it helps me separate out the variable name from the type. I'd also be fine
with Go's approach and eliminating the ":".
The biggest problem (aside from migration, which we would
*absolutely* provide automated tooling for) is unfamiliarity. That
is a real issue. I'd like to be believe it isn't insurmountable, though.
TypeScript, Scala, Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby
<http://www.mirah.org/>, JavaScript <http://flowtype.org/>, PHP
<http://hacklang.org/> all use this syntax. As far as I can tell,
it is the standard way to add optional type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[kc]

Here's some thoughts on keeping lhs with some tweaks/evolution:

gRPC and mojo idl have both kept lsh type annotations - except for
functions/methods.

gRPC:

// The greeter service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}

Mojo idl:

// A simple service used to exemplify application testing within mojo_shell.
interface ExampleService {
Ping(uint16 ping_value) => (uint16 pong_value);
};



Maybe the same approach for Dart (with new/const and let/val) tweaks:

// nonsense example

myfunc(int a) -> Point {
let lst = [2,4,6];
for (let i in lst) {
let i = i * a;
print(i);
}
return Point(3,3);
}


Originally suggested here:
https://groups.google.com/a/dartlang.org/d/msg/misc/8Uchi3bW1YQ/fdFwfsp8zLgJ

Also the language could be evolved with upsetting (hopefully) existing
users:
- allow both return syntaxes initially
- new is optional
- introduce let

Eyeballs quite well and could give Dart it's own flavour.

K.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[Joe Conway]

The reason Swift has types on the right is due to the difference in var/let
- one couldn't replace 'var' or 'let' keywords with a type annotation and
still be able to specify mutability. This isn't true in Dart, you don't
lose anything by declaring a type via replacing the var keyword.

That said, along with having written ObjC for a very long time and now
using Swift, where the annotation falls is a subjective preference. I think
changes like this should be driven by metrics, not by subjective
preference. Are people staying away from Dart because where the type
annotation falls? Are people going to flock to Dart when the type
annotation moves to the right?

When evaluating (and eventually choosing) Dart as our primary server-side
language, the biggest pushback I got was Dart is still evolving too much to
adopt right now. According to this admittedly small data point, stability
in the language is going to sell more people than where the type annotation
drops.

[Jan Mostert]

"According to this admittedly small data point, stability in the language
is going to sell more people than where the type annotation drops."
+3 new projects here in the last 6 months which are now in Java instead of
Dart for exactly the same reasons - stability over features (one project
was migrated from Python2 which we couldn't upgrade to Python3 due to
legacy libraries that weren't being updated - so instead management decided
to dump Python for Java)

Post by Joe Conway
The reason Swift has types on the right is due to the difference in
var/let - one couldn't replace 'var' or 'let' keywords with a type
annotation and still be able to specify mutability. This isn't true in
Dart, you don't lose anything by declaring a type via replacing the var
keyword.
That said, along with having written ObjC for a very long time and now
using Swift, where the annotation falls is a subjective preference. I think
changes like this should be driven by metrics, not by subjective
preference. Are people staying away from Dart because where the type
annotation falls? Are people going to flock to Dart when the type
annotation moves to the right?
When evaluating (and eventually choosing) Dart as our primary server-side
language, the biggest pushback I got was Dart is still evolving too much to
adopt right now. According to this admittedly small data point, stability
in the language is going to sell more people than where the type annotation
drops.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[James Ots]

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary server-side
language, the biggest pushback I got was Dart is still evolving too much to
adopt right now. According to this admittedly small data point, stability
in the language is going to sell more people than where the type annotation
drops.
We're evaluating what language to use for our front end development, and

while I'm generally favouring Dart, I think it'll be quite a hard sell if
people know that after learning Dart then it's all going to change.

James Ots

[Kasper Peulen]

Come on, learning how to write this new syntax is a matter of minutes.
Getting used to it will probably not take much more than a couple of days.

Post by James Ots

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary server-side
language, the biggest pushback I got was Dart is still evolving too much to
adopt right now. According to this admittedly small data point, stability
in the language is going to sell more people than where the type annotation
drops.
We're evaluating what language to use for our front end development, and

while I'm generally favouring Dart, I think it'll be quite a hard sell if
people know that after learning Dart then it's all going to change.
James Ots
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

[Benjamin Strauß]

People have strong opinions about syntax. You see that by the fact that
this thread seems the get the most attention out of the discussed subjects
being talked about for 2.0. ;)

I would place syntax at the bottom of the issue list.

Post by Kasper Peulen
Come on, learning how to write this new syntax is a matter of minutes.
Getting used to it will probably not take much more than a couple of days.

Post by James Ots

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary
server-side language, the biggest pushback I got was Dart is still evolving
too much to adopt right now. According to this admittedly small data point,
stability in the language is going to sell more people than where the type
annotation drops.
We're evaluating what language to use for our front end development, and

while I'm generally favouring Dart, I think it'll be quite a hard sell if
people know that after learning Dart then it's all going to change.
James Ots
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

['Paul Brauner' via Dart Misc]

Wadler's law at work :)

Post by Benjamin Strauß
People have strong opinions about syntax. You see that by the fact that
this thread seems the get the most attention out of the discussed subjects
being talked about for 2.0. ;)
I would place syntax at the bottom of the issue list.

Post by Kasper Peulen
Come on, learning how to write this new syntax is a matter of minutes.

Getting used to it will probably not take much more than a couple of days.

Post by Kasper Peulen

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary
server-side language, the biggest pushback I got was Dart is still evolving
too much to adopt right now. According to this admittedly small data point,
stability in the language is going to sell more people than where the type
annotation drops.
We're evaluating what language to use for our front end development,

and while I'm generally favouring Dart, I think it'll be quite a hard sell
if people know that after learning Dart then it's all going to change.
James Ots

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Varga, Dániel]

I myself prefer the 'type on left' syntax over this hacklangish/TS-ish,
type on right. It's only a preference, but a damn *strong *one.

On Tue, Sep 8, 2015 at 2:19 PM, 'Paul Brauner' via Dart Misc <

Post by 'Paul Brauner' via Dart Misc
Wadler's law at work :)

Post by Benjamin Strauß
People have strong opinions about syntax. You see that by the fact that
this thread seems the get the most attention out of the discussed subjects
being talked about for 2.0. ;)
I would place syntax at the bottom of the issue list.

Post by Kasper Peulen
Come on, learning how to write this new syntax is a matter of minutes.

Getting used to it will probably not take much more than a couple of days.

Post by Kasper Peulen

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary
server-side language, the biggest pushback I got was Dart is still evolving
too much to adopt right now. According to this admittedly small data point,
stability in the language is going to sell more people than where the type
annotation drops.
We're evaluating what language to use for our front end development,

and while I'm generally favouring Dart, I think it'll be quite a hard sell
if people know that after learning Dart then it's all going to change.
James Ots

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Eduardo Teixeira Dias]

What about not changing what is working rule...

This change will involve:
- Dart team changing the compiler / Transpiler
- Upgrade current dart code
- Pub packages upgrade and hell on earth during the process /
fragmentation
- IDE developers time to create helpers for upgrade

People that are entering will start doing packages only for Dart 2.0. Then,
more fragmentation..

For what concrete gain?

Pleasure for someone's eyes?

What if, instead of Dart 2.0 just do a Dart 1.50, no breaking changes..

A Hint, no more new stuff, until the last year's stuff is no longer
alphaware vapourware amazing promise.

We can't yet easily develop in Dart Mobile First Material Design Web
Applications. Does it make any sense for a "batteries-included developer
platform for building structured HTML5 web apps"?

[kc]

Post by Varga, Dániel
I myself prefer the 'type on left' syntax over this hacklangish/TS-ish,
type on right. It's only a preference, but a damn *strong *one.

I argued for rhs pre-1.0 - but can see how it could be rocking the boat too
much now.

But the reason for rhs is that it makes complex type annotations easy to
parse/tool. So worth investigating how lhs can accommodate function types
etc.

Hacklangish:
- 'dynamic' from C#
- 'final' from Java
- list/map literals from JS (not C#/Java)
- 'var' from either JS or C# - which has led to confusion
- lambda from C#
- optional/named param syntax from who knows where
- cascade syntax which uses the 'familiar' range operator

I have a feeling that the Dart syntax fell between stools and potential
dev's weren't getting the simplicity of the object model.

Hopefully Dart with a *few *syntax tweaks could satisfy both it's current
users (Google and external) as well as provide a cleaner foundation for 2.0
with a clearer view of the underlying semantics.

K.

Post by Varga, Dániel
On Tue, Sep 8, 2015 at 2:19 PM, 'Paul Brauner' via Dart Misc <

Post by 'Paul Brauner' via Dart Misc
Wadler's law at work :)

Post by Benjamin Strauß
People have strong opinions about syntax. You see that by the fact that
this thread seems the get the most attention out of the discussed subjects
being talked about for 2.0. ;)
I would place syntax at the bottom of the issue list.

Post by Kasper Peulen
Come on, learning how to write this new syntax is a matter of minutes.

Getting used to it will probably not take much more than a couple of

Post by Kasper Peulen
days.

Post by Joe Conway
When evaluating (and eventually choosing) Dart as our primary
server-side language, the biggest pushback I got was Dart is still evolving
too much to adopt right now. According to this admittedly small data point,
stability in the language is going to sell more people than where the type
annotation drops.
We're evaluating what language to use for our front end development,

and while I'm generally favouring Dart, I think it'll be quite a hard sell
if people know that after learning Dart then it's all going to change.
James Ots

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

Post by kc
- list/map literals from JS (not C#/Java)

There are also "typed" literals like <String,int>{ "foo": 1, "bar": 2 } and
<int>[1,2,3]. Not sure from what language those were borrowed, but they are
not bad. If you look closely, you will see left typing here :)

[Benjamin Strauß]

These are generics. I don't think they are part of the type system.

Post by tatumizer-v0.2

Post by kc
- list/map literals from JS (not C#/Java)

There are also "typed" literals like <String,int>{ "foo": 1, "bar": 2 }
and <int>[1,2,3]. Not sure from what language those were borrowed, but they
are not bad. If you look closely, you will see left typing here :)

[Don Olmstead]

@kc "- optional/named param syntax from who knows where"

Oh man I laughed so hard when I saw that. I really truly hate the
optional/named syntax and argued that it was ugly in November of 2012,
https://github.com/dart-lang/sdk/issues/6496

Post by Benjamin Strauß
These are generics. I don't think they are part of the type system.

Post by tatumizer-v0.2

Post by kc
- list/map literals from JS (not C#/Java)

There are also "typed" literals like <String,int>{ "foo": 1, "bar": 2 }
and <int>[1,2,3]. Not sure from what language those were borrowed, but they
are not bad. If you look closely, you will see left typing here :)
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Yegor Jbanov]

Another example where type-on-the-right would help a lot: the readability
of the ZoneSpecification factory
<https://api.dartlang.org/1.12.1/dart-async/ZoneSpecification/ZoneSpecification.html>.
It is very hard to find the names of the parameters because the types on
the left prevent them from being horizontally aligned.

Today:

const factory ZoneSpecification({
dynamic handleUncaughtError(Zone self, ZoneDelegate parent, Zone zone,
error, StackTrace stackTrace),
dynamic run(Zone self, ZoneDelegate parent, Zone zone, f()),
dynamic runUnary(
Zone self, ZoneDelegate parent, Zone zone, f(arg), arg),
dynamic runBinary(Zone self, ZoneDelegate parent, Zone zone,
f(arg1, arg2), arg1, arg2),
ZoneCallback registerCallback(
Zone self, ZoneDelegate parent, Zone zone, f()),
ZoneUnaryCallback registerUnaryCallback(
Zone self, ZoneDelegate parent, Zone zone, f(arg)),
ZoneBinaryCallback registerBinaryCallback(
Zone self, ZoneDelegate parent, Zone zone, f(arg1, arg2)),
AsyncError errorCallback(Zone self, ZoneDelegate parent, Zone zone,
Object error, StackTrace stackTrace),
void scheduleMicrotask(
Zone self, ZoneDelegate parent, Zone zone, f()),
Timer createTimer(Zone self, ZoneDelegate parent, Zone zone,
Duration duration, void f()),
Timer createPeriodicTimer(Zone self, ZoneDelegate parent, Zone zone,
Duration period, void f(Timer timer)),
void print(Zone self, ZoneDelegate parent, Zone zone, String line),
Zone fork(Zone self, ZoneDelegate parent, Zone zone,
ZoneSpecification specification, Map zoneValues)
}) = _ZoneSpecification;

With types on the right you get a very clear *visual hierarchy*:

const factory ZoneSpecification({
handleUncaughtError:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
zone: dynamic,
stackTrace: StackTrace) -> dynamic,
run:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> dynamic,
runUnary:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg: dynamic) -> dynamic,
arg: dynamic) -> dynamic,
runBinary:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg1: dynamic, arg2: dynamic) -> dynamic,
arg1: dynamic,
arg2: dynamic) -> dynamic,
registerCallback:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> ZoneCallback,
registerUnaryCallback:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg) -> dynamic) -> ZoneUnaryCallback,
registerBinaryCallback:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg1, arg2) -> dynamic) -> ZoneBinaryCallback,
errorCallback:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
error: Object,
stackTrace: StackTrace) -> AsyncError,
scheduleMicrotask:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> void,
createTimer:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
duration: Duration,
f: () -> void) -> Timer,
createPeriodicTimer:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
period: Duration,
void f(timer: Timer)) -> Timer,
print:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
line: String) -> void,
fork:
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
specification: ZoneSpecification,
zoneValues: Map) -> Zone
}) = _ZoneSpecification;

[Eduardo Teixeira Dias]

Try this....

const factory ZoneSpecification({
dynamic handleUncaughtError(
Zone self,
ZoneDelegate parent,
Zone zone,
error,
StackTrace stackTrace
),
dynamic run(
Zone self,
ZoneDelegate parent,
Zone zone,
f()
),
dynamic runUnary(
Zone self,
ZoneDelegate parent,
Zone zone,
f(arg),
arg
),
dynamic runBinary(
Zone self,
ZoneDelegate parent,
Zone zone,
f(arg1, arg2),
arg1,
arg2
),
ZoneCallback registerCallback(
Zone self,
ZoneDelegate parent,
Zone zone,
f()
),
ZoneUnaryCallback registerUnaryCallback(
Zone self,
ZoneDelegate parent,
Zone zone,
f(arg)
),
ZoneBinaryCallback registerBinaryCallback(
Zone self,
ZoneDelegate parent,
Zone zone,
f(arg1, arg2)
),
AsyncError errorCallback(
Zone self,
ZoneDelegate parent,
Zone zone,
Object error,
StackTrace stackTrace
),
void scheduleMicrotask(
Zone self,
ZoneDelegate parent,
Zone zone,
f()
),
Timer createTimer(
Zone self,
ZoneDelegate parent,
Zone zone,
Duration duration,
void f()
),
Timer createPeriodicTimer(
Zone self,
ZoneDelegate parent,
Zone zone,
Duration period, void f(Timer timer)),
void print(
Zone self,
ZoneDelegate parent,
Zone zone,
String line
),
Zone fork(
Zone self,
ZoneDelegate parent,
Zone zone,
ZoneSpecification specification,
Map zoneValues
)
}) = _ZoneSpecification;

Post by Yegor Jbanov
Another example where type-on-the-right would help a lot: the readability
of the ZoneSpecification factory
<https://api.dartlang.org/1.12.1/dart-async/ZoneSpecification/ZoneSpecification.html>.
It is very hard to find the names of the parameters because the types on
the left prevent them from being horizontally aligned.
const factory ZoneSpecification({
dynamic handleUncaughtError(Zone self, ZoneDelegate parent, Zone zone,
error, StackTrace stackTrace),
dynamic run(Zone self, ZoneDelegate parent, Zone zone, f()),
dynamic runUnary(
Zone self, ZoneDelegate parent, Zone zone, f(arg), arg),
dynamic runBinary(Zone self, ZoneDelegate parent, Zone zone,
f(arg1, arg2), arg1, arg2),
ZoneCallback registerCallback(
Zone self, ZoneDelegate parent, Zone zone, f()),
ZoneUnaryCallback registerUnaryCallback(
Zone self, ZoneDelegate parent, Zone zone, f(arg)),
ZoneBinaryCallback registerBinaryCallback(
Zone self, ZoneDelegate parent, Zone zone, f(arg1, arg2)),
AsyncError errorCallback(Zone self, ZoneDelegate parent, Zone zone,
Object error, StackTrace stackTrace),
void scheduleMicrotask(
Zone self, ZoneDelegate parent, Zone zone, f()),
Timer createTimer(Zone self, ZoneDelegate parent, Zone zone,
Duration duration, void f()),
Timer createPeriodicTimer(Zone self, ZoneDelegate parent, Zone zone,
Duration period, void f(Timer timer)),
void print(Zone self, ZoneDelegate parent, Zone zone, String line),
Zone fork(Zone self, ZoneDelegate parent, Zone zone,
ZoneSpecification specification, Map zoneValues)
}) = _ZoneSpecification;
const factory ZoneSpecification({
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
zone: dynamic,
stackTrace: StackTrace) -> dynamic,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> dynamic,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg: dynamic) -> dynamic,
arg: dynamic) -> dynamic,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg1: dynamic, arg2: dynamic) -> dynamic,
arg1: dynamic,
arg2: dynamic) -> dynamic,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> ZoneCallback,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg) -> dynamic) -> ZoneUnaryCallback,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: (arg1, arg2) -> dynamic) -> ZoneBinaryCallback,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
error: Object,
stackTrace: StackTrace) -> AsyncError,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
f: () -> dynamic) -> void,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
duration: Duration,
f: () -> void) -> Timer,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
period: Duration,
void f(timer: Timer)) -> Timer,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
line: String) -> void,
(self: Zone,
parent: ZoneDelegate,
zone: Zone,
specification: ZoneSpecification,
zoneValues: Map) -> Zone
}) = _ZoneSpecification;
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Yegor Jbanov' via Dart Misc]

Post by Eduardo Teixeira Dias
Try this....

And where in your version do you achieve horizontal alignment of parameter
names? They are still jumping left and right because the types vary in
length.

[Don Olmstead]

I think the point was that it was poorly formatted in terms of parsing it
visually. The types on the right don't really help without the vertical
breaks its still hard to parse.

On Thu, Sep 10, 2015 at 2:21 PM, 'Yegor Jbanov' via Dart Misc <

Post by Eduardo Teixeira Dias
Try this....
And where in your version do you achieve horizontal alignment of parameter
names? They are still jumping left and right because the types vary in
length.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

Alignment (no matter left or right) is the least of the problems with those
classes. There's a fair amount of redundancy and awkwardness and mystery
here.
First reaction when I saw it was: WTF? Second and all subsequent reactions
were: WTF??...?
Maybe it indicates the problem with the concept. Or the language is not
expressive enough. Or I'm just not smart enough - go figure. Alignment is
not much help with any of the above.

[Joe Conway]

An even better approach would be to use typedefs. Or add a
ZoneSpecificationConfiguration class where each of these closures are
properties and pass that. This is an outlying case where the problem is
that this is just a bad interface.

[Kasper Peulen]

I think one of the advantages of types on the right would be to not having
to use typedefs anymore!
At least that is what I understood from the DEP meeting notes.

Post by Joe Conway
An even better approach would be to use typedefs. Or add a
ZoneSpecificationConfiguration class where each of these closures are
properties and pass that. This is an outlying case where the problem is
that this is just a bad interface.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

[kc]

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.

I think this is the crux. Optional types play badly with lhs type
annotations. Whereas rhs read like a natural addition to a binding given
left to right english code.

One possibility is making types on interfaces - class props/methods and
functions - but not locals - mandatory. Typically you do want to annotate
these things. Also going with say 'Any' instead of a rather clumsy
'dynamic' and with some tweaks re let/new:

Any myfunction(String s, int i, Any obj) {

// Explicit annotion
Point p = Point(1,1);

// mutable
var pm = Point(1,1);

// immutable
let pi = Point(1,1);

return "Something";
}





Reads quite well.

Also:
Ceylon went with lhs but has a function prefix.
Groovy is most like Dart - but uses 'def' instead of 'var' and uses to
start a function defintion.

K.

Post by 'Bob Nystrom' via Dart Misc
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob

[George Moschovitis]

FWIW I also don't have any problem with moving types to the right.
It looks just as familiar as the left-hand-side types, these days (and I
don't mind backwards incompatible changes in general)

-g.

[Weiping Chen]

Now ES6, ES7 is catching up with Dart feature wise, and TS is having a
upper hand in Web space for now, maybe now is good time for Dart to be bold
for some great things, like Dependee Injection at language level, given the
main users are internal to Google. When a language is widely used by many,
it will be much harder to add breaking features. Just my humble opinion.

Post by 'Bob Nystrom' via Dart Misc
That thread about the language meeting notes is huge, so I'm going to
split my responses into separate threads. If we could move discussions to
these, that would be swell.
It is strictly more verbose than the current syntax... *when you use it.* In
practice, I think Dart 2.0 should come with a much better promise of type
inference and let users reliably omit type annotations on locals. When you
var a = someValue...
No type on the right *or* left. :)
When you do want a type annotation, for things like top-level variables,
fields, and parameters, I personally like it on the right and also like ":"
even though it's a bit more verbose. Maybe it's just me, but it helps me
separate out the variable name from the type. I'd also be fine with Go's
approach and eliminating the ":".
The biggest problem (aside from migration, which we would *absolutely*
provide automated tooling for) is unfamiliarity. That is a real issue. I'd
like to be believe it isn't insurmountable, though. TypeScript, Scala,
Haskell, Kotlin, and Swift all use "name : Type" syntax.
Optional type annotation systems for Python
<https://www.python.org/dev/peps/pep-0484/>, Ruby <http://www.mirah.org/>,
JavaScript <http://flowtype.org/>, PHP <http://hacklang.org/> all use
this syntax. As far as I can tell, it is the standard way to add optional
type annotations to a language.
Here's another tiny data point. The new UX for our API documentation
<https://api.dartlang.org/1.12.0/dart-async/Future-class.html> puts
return types of methods after the method name. In the original dartdoc, I
got a lot of feedback that it was hard to find member names when scanning a
list of members if the return type was on the left. Pushing them to the
right does help readability in this case.
So, personally, I feel doing this would lead to a simpler, easier to
extend grammar. And it would follow in the footsteps of almost every
Type" syntax.
Cheers!
- bob