Types on the right

[Bob Nystrom]

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, Ruby, JavaScript, PHP 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 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]

On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

[...]

Here's another tiny data point. The new UX for our API documentation 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]

+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))))).

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]

On Fri, Sep 4, 2015 at 10:15 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <mi...@dartlang.org> wrote:

On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

[...]

Here's another tiny data point. The new UX for our API documentation 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

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.

 

(except for Typed Scheme, but, you know, they're (a lisp (so they have (their own syntax (space))))).

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 email to misc+uns...@dartlang.org.

[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 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?

[tatumizer-v0.2]

> 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]

On Fri, Sep 4, 2015 at 11:07 AM, Lasse Knud Damgaard <lasse.d...@gmail.com> wrote:

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.

 

However:

The biggest problem (aside from migration, which we would absolutely 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.

 

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.

[Brian Slesinsky]

On Fri, Sep 4, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

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 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.

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.)

• 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.

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]

On Fri, Sep 4, 2015 at 1:31 PM, 'Brian Slesinsky' via Dart Misc <mi...@dartlang.org> wrote:

On Fri, Sep 4, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

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.

 

They aren't using "go fix" much anymore.

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

 

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.

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;

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.

 

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.

 

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.

 

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 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.

[Brian Slesinsky]

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

[Bob Nystrom]

On Fri, Sep 4, 2015 at 2:09 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

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

[Benjamin Strauß]

Am Freitag, 4. September 2015 23:04:10 UTC+2 schrieb Bob:

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.

[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.

[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}) {

  // ...

}

[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.

--

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.

[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).

[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 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;

   

   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

[Günter Zöchbauer]

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

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 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;

   

   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.

[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 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.

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.

[Benjamin Strauß]

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

[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.

On Mon, 7 Sep 2015 at 15:59 kc <kevin...@gmail.com> wrote:

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.

--

[kc]

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

gRPC and mojo idl have both kept lhs 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 without 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.

[Lex Berezhny]

On Mon, Sep 7, 2015 at 10:21 AM, Jan Mostert <jan.m...@gmail.com> wrote:

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]

Yeah, making things optional sounds nightmarish :(

--

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 email to misc+uns...@dartlang.org.

--

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.

--

[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.

[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.

--

[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.

[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.

 

[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.

[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.

[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)

--

[James Ots]

On 8 September 2015 at 00:12, Joe Conway <joe.c...@stablekernel.com> wrote:

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.

--

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 email to misc+uns...@dartlang.org.

--

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.

[Paul Brauner]

Wadler's law at work :)

[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.

[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]

On Tuesday, September 8, 2015 at 1:38:09 PM UTC+1, Dániel Varga wrote:

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. 

[tatumizer-v0.2]

> - 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.

[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

[Yegor Jbanov]

Another example where type-on-the-right would help a lot: the readability of the ZoneSpecification factory. 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;

[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.

On Thu, Sep 10, 2015 at 11:09 PM, Joe Conway <joe.c...@stablekernel.com> wrote:

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 email to misc+uns...@dartlang.org.

--

Kasper

[Yegor Jbanov]

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 <mi...@dartlang.org> wrote:

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.

--

[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.

[kc]

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

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 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.

[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.

[Eduardo Teixeira Dias]

Dart was sold that way...

https://www.youtube.com/watch?v=-IavVtOE_Fg

https://www.youtube.com/watch?v=UZOIAz-eR34

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..

--

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 email to misc+uns...@dartlang.org.

--

Saudações,

Eduardo Teixeira Dias

------------------------------------------

Tendencies Consultoria Ltda.

Tel: 11 3828-1281

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 ?

[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. 

[Benjamin Strauß]

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

[Eduardo Teixeira Dias]

I hope it's just FUD

[Daniel Davidson]

On Friday, September 4, 2015 at 4:04:10 PM UTC-5, Bob wrote:

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, but I still love that you can do so much declaratively with cascades.

Thanks

Dan

 

Cheers!

- bob

[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. At present,Golang's sell point is simplicity and concurrency,what about Dart? Although Dart is four years old, it fails to achieve its initial goal(replacing javascript).Many people around me feels javascript(ES6/TS) is enough and decline to use dart when i recommend dart to them.What's worse,after angular team announce angular2 will be written in typescript they think dart is dead.So how to eliminate such negative and wrong impression towards dart? IMHO,It's time for Dart to innovate even if it becomes somewhat "unfamiliar" and break backward compatibility.I do not worry about so-called "py3k" problem.Because python 2.x was already a mainstream language compared to Dart 1.x.

[kc]

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

"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).

 

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. 

[kc]

On Friday, September 4, 2015 at 5:51:52 PM UTC+1, Bob wrote:

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, Ruby, JavaScript, PHP 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.

Here's another tiny data point. The new UX for our API documentation 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

[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.

On Friday, September 4, 2015 at 11:51:52 AM UTC-5, Bob wrote:

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, Ruby, JavaScript, PHP all use this syntax. As far as I can tell, it is the standard way to add optional type annotations to a language.