Notes from last week's DEP meeting

[Bob Nystrom]

Here's my notes from the last meeting.

The exciting bit is that the pkgspec proposal has been accepted. This means we can now—finally!—get rid of those accursed "packages" symlinks. Huzzah!

- bob

[Don Olmstead]

With the optional and named parameters why not just do like C#? https://msdn.microsoft.com/en-us/library/dd264739.aspx

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

[Günter Zöchbauer]

Where is the champagne \o/

[George Moschovitis]

With the optional and named parameters why not just do like C#? https://msdn.microsoft.com/en-us/library/dd264739.aspx

Just checked you link, indeed it looks great: simple, elegant, consistent, readable. 

Makes you wonder what's the benefit of Dart's more complex syntax.

-g.

 

[Paul Brauner]

That's how Python works also as far as I understand C#'s semantics. The problem with that is that the name of parameters becomes part of the function's signature, you can't change them without breaking clients. Today in dart, this is only true for positional optional arguments. Changing this would break this assumption. I'm presonally fine with it, but this is a breaking change.

--

[Don Olmstead]

I've personally found the optional parameters syntax a bit convoluted. If the idea is to be able to have optional and named I personally think following Python/C#'s example makes for much clearer code.

Originally opened this bug https://code.google.com/p/dart/issues/detail?id=6496 years ago but it got put as WONTFIX. Maybe with this DEP its time to reopen the discussion?

[Sean Eagan]

Dart used to have pretty much the same exact syntax.

The problem with "positional AND named" optional parameters (as in C# and formerly in Dart) is that you have to commit to both a name and position up front for every optional parameter.  Also it means there is "two ways to do the same thing" at call sites.  Dart's "positional OR named" optional parameters have neither of these problems.

-g.

 

[Don Olmstead]

@Sean I don't really buy the argument that committing to a name and position is a problem. Packages have semantic versioning for a reason and the analyzer is more than happy to yell at you if you do something wrong.

[Günter Zöchbauer]

You can indicate that the update contains breaking changes using the version number. So your users know they should *NOT* update because it breaks their app. I don't see how this is an advantage.

[Sean Eagan]

On Wed, May 20, 2015 at 2:01 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

@Sean I don't really buy the argument that committing to a name and position is a problem. Packages have semantic versioning for a reason and the analyzer is more than happy to yell at you if you do something wrong.

Every breaking change in my package means users of my package need to:

* discover the new version I've published (which won't happen via pub get/upgrade assuming their using appropriate version constraints)

* learn about the breaking changes

* update their version constraint to allow the new version

* test against it (the analyzer *can* help here, but not always)

* make changes to their package if they are affected by the breaking change

* release a new version of their package

* pass the buck to their users if they needed to make a breaking change to accomedate mine

Any way I can avoid putting my users through that is a big win to me.

Also, often I want to require the name to appear at the call site so that the call-site is self documenting, and readers don't have to click through to read the full documentation.  This is even encoded in the style guide for `bool` parameters:

https://www.dartlang.org/articles/style-guide/#avoid-boolean-arguments-unless-their-meaning-is-completely-obvious

[Bob Nystrom]

On Wed, May 20, 2015 at 11:46 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Originally opened this bug https://code.google.com/p/dart/issues/detail?id=6496 years ago but it got put as WONTFIX. Maybe with this DEP its time to reopen the discussion?

Unfortunately, probably not.

Like most languages, we are trying to avoid breaking changes. This DEP relaxes a limitation but all existing code keeps working. Any more substantial change to the optional parameter syntax would probably be a breaking one.

For what it's worth, I like Dart's semantics around optional/named parameters, especially if this DEP gets accepted. I do like having control over which parameter names are part of my API and which aren't. (Actually, I prefer Smalltalk's approach which distinguishes the name that appears in the method invocation from the name of the parameter variable.)

The actual syntax Dart has for declaring optional and named parameters is pretty unfortunate in my opinion, but it's too late to do anything about that.

Cheers,

- bob

[Sean Eagan]

On Wed, May 20, 2015 at 2:32 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Wed, May 20, 2015 at 11:46 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Originally opened this bug https://code.google.com/p/dart/issues/detail?id=6496 years ago but it got put as WONTFIX. Maybe with this DEP its time to reopen the discussion?

Unfortunately, probably not.

Like most languages, we are trying to avoid breaking changes. This DEP relaxes a limitation but all existing code keeps working. Any more substantial change to the optional parameter syntax would probably be a breaking one.

We could probably have positional AND named optional parameters (like C#) by allowing to overlap the "[]" and "{}", but I wouldn't want it.

[Don Olmstead]

@Sean That's the package author's problem communicating what changed. I don't even want to know how many migrations I've had to do over time with Polymer. They communicate any breaking changes bump the minor version and I deal with it if I want the latest version. How is that not the price of admission for using a library?

@Bob I get that having breaking changes is bad in a language but what are you supposed to do when you go down the wrong path?

[Günter Zöchbauer]

Sure if you have to break, break, but don't break if you can avoid it. When a package is 9.0 you still might want to add something but your users won't be so comfortable with breaking changes like users of the 0.16.4 version.

[Bob Nystrom]

On Wed, May 20, 2015 at 12:42 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

@Bob I get that having breaking changes is bad in a language but what are you supposed to do when you go down the wrong path?

In theory, we can make breaking changes in 2.0. Even then, though, we want to minimize them. Breaking existing code has a very very high cost.

I think the strategy is basically:

1. Don't go down the wrong path.
   
2. See step one.
   
3. If those steps didn't work... live with it.
   

My purist sensibilities would love to make lots of breaking changes to fix previous errors. But the usability side of my brain understands that engineering is about making the most useful thing for the most people. Breaking stuff on them—even to get to something better—is often not the best way to do that.

- bob

[Don Olmstead]

Is there anything that might be a breaking change in 2.0? On a meta level I'm curious what the criteria would be for doing a language breaking change. To me the optional/named parameters is the ugliest part of the language and something like C#/Python would greatly simplify things.

I get that not getting in a bad state is a goal to strive for, but if you never break anything then you just end up piling more stuff on ala C++.

[Thomas Schranz]

I almost spilled my coffee. *joy* \o/

[Jacob Goodson]

Why not break the living crap out of Dart since the goal is no longer to be the lingua franca of the web.  How about small talk 2.0 or some derivative thereof?

[Gilad Bracha]

Wouldn't that be nice.  Alas, we have customers, and breaking changes are not very popular with them. More broadly, the pressure to remain familiar remains. But I remain hopeful.

Matilda Briggs was not the name of a young woman, Watson, ... It was a ship which is associated with the giant rat of Sumatra, a story for which the world is not yet prepared.

[Bob Nystrom]

On Wed, May 20, 2015 at 1:45 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Is there anything that might be a breaking change in 2.0? On a meta level I'm curious what the criteria would be for doing a language breaking change.

I'm not sure. I know the bar is very high, which means the utility of the change must be quite high or the chance of it impacting users must be quite low.

For example, we have some folks working on a generic method proposal. I believe the current syntax has a corner case that would change how some existing Dart code could be interpreted. Today, this:

a(b<c,d>(e))

Is interpreted to mean:

a(b < c, d > (e))

In other words, call a() with two arguments, the result of b < c, and the result of d > (e). With the proposed generic method syntax, that would be interpreted as:

a(b<c, d>(e))

So, call a() with one argument, the result of applying type parameters c and d to generic method b, then invoking that with argument e.

Would changing this be a breaking change? Technically yes. Is it likely to impact users? No.

 

To me the optional/named parameters is the ugliest part of the language

I'd put them after cascades and the type annotation syntax. :-/

 

I get that not getting in a bad state is a goal to strive for, but if you never break anything then you just end up piling more stuff on ala C++.

You could do worse in life than to have as many users as C++. I agree whole-heartedly that no one wants an ugly language. I think the only solution is to not add ugly features to begin with. Once your language is in the wild, it's very hard to undo mistakes.

If there are corners of the language that are mistakes, the best thing we can probably do is to add other unrelated features that are so compelling that they overshadow the warts.

Cheers,

- bob

[Jos Hirth]

On Wednesday, May 20, 2015 at 8:46:43 PM UTC+2, Don Olmstead wrote:

I've personally found the optional parameters syntax a bit convoluted.

Sounds like you haven't seen ES6's version yet:

function foo({one = 1, two = 2} = {}) {
  console.log(one, two);
}

It's actually even worse than it initially looks. That's a destructuring assignment. You can put whatever you want on the right-hand side of every '='. Anything goes.

Dart's syntax is super fabulous compared to this mess.

[Don Olmstead]

@Jos I don't even know how to respond to that. Just. Ugh.

--

[Alex Tatumizer]

>function foo({one = 1, two = 2} = {}) {
>  console.log(one, two);
>}

Ugliness is the new beauty. But there's stiff competition. Look at the this Angular2 exhibit:

<div>My name is {{name}}</div>

<div>

<input #newname type="text">

<button (click)="changeName(newname.value)"

[disabled]="newname.value === 'David' "> Change Name

</button>

</div>

There are several dimensions of new beauty here - ES6 looks like an amateur in comparison.

[Don Olmstead]

[George Moschovitis]

I do like having control over which parameter names are part of my API and which aren't. 

Indeed, that's a benefit. 

[George Moschovitis]

the pressure to remain familiar remains.

That might be one of the ...pressing problems with Dart.

 

[Jim Trainor]

I can think of few examples of web application code (the top level interface stuff - the html, js glue, and css combo) that I doesn't look like a mess. Here's hoping for web components and polymer.

One case I can think of where the code didn't look like a disaster is GWT using the vanilla built in components.  But that's a very limited use case.

The current hype about react-js certainly isn't because the code is elegant. It's a dog-awful mess.

[Alex Tatumizer]

> Here's hoping for web components and polymer.

Don't bet on it - you might be disappointed. It's like adding a number of exotic ingredients to the otherwise yucky soup and expect it to improve.
Better pray for sky_sdk. Since no one knows what it is, there's still hope. At least until we find out.

[Don Olmstead]

@Alex nobody would say that the web is made of the best technologies out there. As Dart showed even if you make a better thing its not going to be able to replace something so entrenched. If Sky is just another framework to build apps in then honestly its of no use to me. I'd rather write something once rather than targeting a ton of different devices. So +1 if I can take a web app written in Dart and run it on Sky. Otherwise I think they're going down the wrong path.

--

[Alex Tatumizer]

> Otherwise I think they're going down the wrong path.

Unless web apps go out of fashion. Which is quite possible. You know, fashions are changing. Objectively, native apps look better. If their code also could look better and more consistent across a range of devices...

[Benjamin Strauß]

In a perfect world (in my view at least), every browser would have a native newspeak virtual machine and html/css/js would be gone. ;)

Just look at this quote.

ECMAScript is the official name for the JavaScript language we all know and love.

http://blogs.windows.com/msedgedev/2015/05/12/javascript-moves-forward-in-microsoft-edge-with-ecmascript-6-and-beyond/

I made myself sad.

[Gilad Bracha]

+1000

On Thu, May 21, 2015 at 1:52 PM Benjamin Strauß <benm...@gmail.com> wrote:

In a perfect world (in my view at least), every browser would have a native newspeak virtual machine and html/css/js would be gone. ;)

Am Donnerstag, 21. Mai 2015 00:01:09 UTC+2 schrieb Jacob Goodson:

Why not break the living crap out of Dart since the goal is no longer to be the lingua franca of the web.  How about small talk 2.0 or some derivative thereof?

On Wednesday, May 20, 2015 at 4:34:29 PM UTC-4, Bob wrote:

On Wed, May 20, 2015 at 12:42 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

@Bob I get that having breaking changes is bad in a language but what are you supposed to do when you go down the wrong path?

In theory, we can make breaking changes in 2.0. Even then, though, we want to minimize them. Breaking existing code has a very very high cost.

I think the strategy is basically:

1. Don't go down the wrong path.
   
2. See step one.
   
3. If those steps didn't work... live with it.
   

My purist sensibilities would love to make lots of breaking changes to fix previous errors. But the usability side of my brain understands that engineering is about making the most useful thing for the most people. Breaking stuff on them—even to get to something better—is often not the best way to do that.

- bob

[Mark H]

So +1 if I can take a web app written in Dart and run it on Sky. Otherwise I think they're going down the wrong path.

 

100% agree! There won't be much gain if you still have to have two completely different codebases for web and mobile.

[Filipe Morgado]

Or it should be the other way around.

You take a Sky app and run it on the web.

It should only take a Sky_sdk written in JS and a dart2js aware of it.

The web sucks. We all know that or we wouldn't be here.

Dart is an alternative to JS which can run as JS.

Now comes Sky as an alternative to DOM/CSS, which may run as DOM/CSS.

[kc]

On Wednesday, May 20, 2015 at 11:01:09 PM UTC+1, Jacob Goodson wrote:

Why not break the living crap out of Dart since the goal is no longer to be the lingua franca of the web.  How about small talk 2.0 or some derivative thereof?

At the Dart Summit Lars Bak specifically mentioned no breaking changes for 2.0 (unlike Python 2.x to 3.x). 

He also did a Steve Jobs impression and asked the Dart team to stand up - half the room stood up. And what's worse they seemed surprised to see one another!

So, is the existing user base that big?

If the current syntax is doing a first class job of disguising the core dynamic object semantics as well as turning off dev's who dislike boilerplate - shouldn't it (judiciously) be considered. 

Dart has another bite at the cherry with Sky and Fletch. Dev's will have another look and the more attractive the language the more likely dev's will bite.

K.

 

[Jim Trainor]

Was Dart ever supposed to be the new lingua franca of the web?  It not how I read the original "leaked" memo.

--

[Alex Tatumizer]

> He also did a Steve Jobs impression and asked the Dart team to stand up - half the room stood up. And what's worse they seemed surprised to see one another!

Haha. Good observation! BTW, any idea what was the other half?

[Jacob Goodson]

From the leaked memo... "The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform."  How else could you read that?

[Jim Trainor]

Yes, indeed it does use the words linga franca in one sentence.  The rest, and bulk, of it, however (and it's pretty long), is very reasonable and realistic in tone regarding the goals and the risk/complexity of introducing a new language vis-a-vis improving javascript. The tone of the "leaked' email was not nearly as strident as, for example, many of the reactions to it.

[Thomas Schranz]

I don't see anything wrong with having ambitious goals.

I also don't find it very useful to declare that someone failed at reaching an ambitious goal (especially if the goal does not have a deadline and/or is obviously a long-term goal).

It's like declaring someone failed to go to university while they are still in school.

Technology adoption takes time.

[Günter Zöchbauer]

+1 

or declaring it's an ugly duckling ;-)

[Metronome]

For the people with the skills to design a language it doesn't take much to design a language that is better than Javascript.  Javascript is nothing more than that nightmare corporate code base that many of us have either written (Unintentionally.) ourselves, or have had the extreme displeasure of having to maintain extended over an entire ecosystem.  The only other major difference is that there are lots of highly competent people who have convinced themselves that Javascript is actually good at what we are trying to use it for.  However even with this dire state of affairs it strikes me as truly amazing that the major platform that is targeted by Javascript basically does nothing to actually help the people that create applications for it.

1. We still have browsers that cannot easily run multiple distinct profiles. We pretty much have to mix our use of the target platform with our development for it at the same time.

2. All we have for debugging javascript and the dom are these pathetic builtin consoles.  We could and should have standard protocols to facilitate integration with our development tools.  We do have this for straight up browser automation in the form of Selenium. We probably have a scattering of various hacks for the bits and pieces of a proper debugger for everything else.

3. We don't seem to have an easy way to just visualize the dom tree in terms of the positional boxes that we have to deal with.  All we usually get is highlighting of an individual element without context of every other element in the document!  Yes, that is so helpful...

There are of course other things but I don't really want to write a book.  At the end of the day creating something better than Javascript is easy (For language designers.) however the bar is low; pretty much anything with actual logic and you know, planning is better than the sea of chaos we call Javascript.  We make a serious mistake if we only focus on imposing some order on Javascript.  We need to also focus on getting our target platform to actually work for and with us. 

 

[kc]

On Saturday, May 23, 2015 at 10:37:48 AM UTC+1, Thomas Schranz wrote:

I don't see anything wrong with having ambitious goals.

Nothing wrong at all. But execution counts. 

 

I also don't find it very useful to declare that someone failed at reaching an ambitious goal (especially if the goal does not have a deadline and/or is obviously a long-term goal).

Dart did fail in its initial goal - because it had the wrong goal - it didn't focus enough on mobile.

I argued that this project should have been more ambitious - the means to join up Android and Chrome OS - join up mobile and the web - preferably with a unified design language (like Metro/Web OS/iOS 7) - which eventually happened with Material Design.

 

It's like declaring someone failed to go to university while they are still in school.

Technology adoption takes time.

I've heard this argument from Dart team leaders. The thing that's different from even 10 years ago is ubiquitous, cheap and connected computing power from IoT to mobile to desktop to servers. It's a dynamic competitive environment imo made for some of Dart's core ideas.

But to use some buzzwords - the project leadership must be agile and reactive. Not maybe-maybe-not we-have-all-the-time-in-the-world if-ever.

Dart has an opportunity with Mojo/Sky to get into Google's client side platforms.

Personally, I think on the Dart VM side all resources should be used to work closely with the Mojo/Sky team so that the runtime is tightly integrated and also works well with gRPC. Also,the Fletch concurrency ideas - make Async disappear - would have more value here. 

Once established on Android and Chrome OS then look at IoT and the server - especially with concurrency.

Also Win10 looks good - coding once for Android, Chrome OS and Win10 would be a massive win - more so than iOS imo. There's much similarity between Material Design and the emerging Win10 design language and Win10 is a more open platform and easier to get onto.

What's striking is that Google's competitors are now really focused - MS, FB and Apple - whereas Google seem all over the shop - almost Balmer-esque. And the competitors are going after Google's core business - search. (Mozilla tried to join up web and mobile but as a recent announcement showed they failed).

K. 

[Jim Trainor]

This line of reasoning is a logical fallacy commonly referred to as "moving the goal post".

On Sun, May 24, 2015 at 9:07 AM, kc <kevin...@gmail.com> wrote:

On Saturday, May 23, 2015 at 10:37:48 AM UTC+1, Thomas Schranz wrote:

I don't see anything wrong with having ambitious goals.

Nothing wrong at all. But execution counts. 

 

I also don't find it very useful to declare that someone failed at reaching an ambitious goal (especially if the goal does not have a deadline and/or is obviously a long-term goal).

Dart did fail in its initial goal - because it had the wrong goal - it didn't focus enough on mobile.

I argued that this project should have been more ambitious - the means to join up Android and Chrome OS - join up mobile and the web - preferably with a unified design language (like Metro/Web OS/iOS 7) - which eventually happened with Material Design.

 

It's like declaring someone failed to go to university while they are still in school.

Technology adoption takes time.

I've heard this argument from Dart team leaders. The thing that's different from even 10 years ago is ubiquitous, cheap and connected computing power from IoT to mobile to desktop to servers. It's a dynamic competitive environment imo made for some of Dart's core ideas.

But to use some buzzwords - the project leadership must be agile and reactive. Not maybe-maybe-not we-have-all-the-time-in-the-world if-ever.

Dart has an opportunity with Mojo/Sky to get into Google's client side platforms.

Personally I think on the Dart VM side all resources should be used to work closely with Mojo/Sky teams so that the runtime is tightly integrated and also works well with gRPC. Also,the Fletch concurrency ideas - make Async disappear - would have more value here. 

[kc]

On Sunday, May 24, 2015 at 2:15:10 PM UTC+1, Jim Trainor wrote:

This line of reasoning is a logical fallacy commonly referred to as "moving the goal post".

Projects often start out with initial goals different from their eventual success.

Mojo/Sky looks like a good opportunity - ball is in front of the posts - put the ball in the back of the net ('soccer' style).

K.

[kc]

Some parts of ES6/TS are very attractive - the type annotation syntax makes function and union types very easy.

But there is the vibe of a hotel built over an old Native American burial ground. 

Dart did select solid ground, but took too much design inspiration from the mid-90's.

K.

[kc]

On Saturday, May 23, 2015 at 12:14:28 PM UTC+1, Günter Zöchbauer wrote:

+1 

or declaring it's an ugly duckling ;-)

const/new - messes up  DSL's  - see Sky.

final Point p = new Point(4,4); // anyone for type inference 

type annotations - union and function types - how?

tricky to eyeball anon functions passed as arguments

verbose Java boilerplate for immutable objects - all 'final'

Why does Swift and even Rust look more scripting language like than Dart?

K.

[Günter Zöchbauer]

You shouldn't need the "Point" after "final" and lrn is interested in getting rid of "new" AFAIK. It doesn't seem there is are many opponents.

On Sunday, May 24, 2015 at 3:58:43 PM UTC+2, kc wrote:

On Saturday, May 23, 2015 at 12:14:28 PM UTC+1, Günter Zöchbauer wrote:

+1 

or declaring it's an ugly duckling ;-)

const/new - messes up  DSL's  - see Sky.

final Point p = new Point(4,4); // anyone for type inference 

type annotations - union and function types - how?

tricky to eyeball anon functions passed as arguments

verbose Java boilerplate for immutable objects - all 'final'

Why does Swift and even Rust look more like scripting languages than Dart?

[Lex Berezhny]

On May 24, 2015 10:04 AM, "Günter Zöchbauer" <gzo...@gmail.com> wrote:
>
> You shouldn't need the "Point" after "final" and lrn is interested in getting rid of "new" AFAIK. It doesn't seem there is are many opponents.
>
>

Any date set for this? I would like to mark my calendar for a going away party.

[kc]

On Sunday, May 24, 2015 at 3:04:53 PM UTC+1, Günter Zöchbauer wrote:

You shouldn't need the "Point" after "final" and lrn is interested in getting rid of "new" AFAIK. It doesn't seem there is are many opponents.

Of course. But Java dev's will type annotate with final.

imo it would be useful to encourage dev's to use an immutable/single assignment binding as it makes the type inference story much clearer.

As expressed in this thread:

https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/It2sBgpdIG8

'let' seems a natural choice given it's reserved word status in ES6 and the similar semantics in Swift. Also aesthetically pleasing and easy on the eye.

The dev's who may give Dart another chance re Sky/Fletch won't be Java dev's which 'final' might appeal to. Java dev's are conservative - it's the early adopters who Dart once again needs to pick up.

They will not want to see:

final Point p = new Point(1,1); // no taste.

K.

[George Moschovitis]

Also aesthetically pleasing and easy on the eye.

yes! 

[Randal L. Schwartz]

>>>>> "kc" == kc <kevin...@gmail.com> writes:

kc> Projects often start out with initial goals different from their eventual
kc> success.

Java: programming your toaster vs. programming a huge amount of today's
code

Perl: text wrangling vs. running most of the interactive web in the 90s

Javascript: a few nice pop-ups vs. modern single-page applications

TCL: A simple embedded language vs. a huge bracket hell monstrosity only
recognizable because of TK and expect

PHP: A "home page maker" vs "the modern source of most website takeovers"

The list goes on and on...

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[Bob Nystrom]

On Mon, May 25, 2015 at 7:06 AM, kc <kevin...@gmail.com> wrote:

Of course. But Java dev's will type annotate with final.

Sure, but like you note we need early adopters first, and those generally aren't Java devs.

 

imo it would be useful to encourage dev's to use an immutable/single assignment binding as it makes the type inference story much clearer.

As expressed in this thread:

https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/It2sBgpdIG8

Personally, I don't think explicit single-assignment declarations are needed to help inference. C#, TypeScript, Go, Flow, Hack, and C++ seem to handle inference with mutable variables.

 

'let' seems a natural choice given it's reserved word status in ES6 and the similar semantics in Swift. Also aesthetically pleasing and easy on the eye.

Given that we already have a keyword for a single-assignment binding ("final"), I think it's really unlikely the language team would add another one. That's a bummer because they one they chose seems to turn off a lot of users. I wish we'd done "let" or "val" instead.

 

The dev's who may give Dart another chance re Sky/Fletch won't be Java dev's who 'final' might appeal to. Java dev's are conservative - it's the early adopters who Dart once again needs to pick up.

They will not want to see:

final Point p = new Point(1,1); // no taste.

That's why the style guide says:

var p = new Point(1, 1);

But, of course, you know that already. :)

- bob

[kc]

On Tuesday, May 26, 2015 at 6:17:57 PM UTC+1, Bob wrote:

On Mon, May 25, 2015 at 7:06 AM, kc <kevin...@gmail.com> wrote:

Of course. But Java dev's will type annotate with final. 

Sure, but like you note we need early adopters first, and those generally aren't Java devs.

But the early adopters do tend to dislike Java and Java-isms. Often they are Java absconders.

 

 

imo it would be useful to encourage dev's to use an immutable/single assignment binding as it makes the type inference story much clearer.

As expressed in this thread:

https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/It2sBgpdIG8

Personally, I don't think explicit single-assignment declarations are needed to help inference. C#, TypeScript, Go, Flow, Hack, and C++ seem to handle inference with mutable variables.

If Dart dials up static types too much then in some ways the dynamic object message passing story of Dart becomes obscured. SoundScript is dialling up static types in an ML-ish way - and it has a type syntax which works. Dev's who want a strict type story will likely go in this direction.

 

 

'let' seems a natural choice given it's reserved word status in ES6 and the similar semantics in Swift. Also aesthetically pleasing and easy on the eye.

Given that we already have a keyword for a single-assignment binding ("final"), I think it's really unlikely the language team would add another one. That's a bummer because they one they chose seems to turn off a lot of users. I wish we'd done "let" or "val" instead.

True about turning off users. C# is considering something in the let/val space and here are a couple of comments from users:

As somebody who also programs in Java which has final for readonly parameters and locals as well as fields, I always use it (when applicable) for fields but I often omit it from parameters and locals. I think let would be a good choice, and I would definitely use it.

Look at the final keyword in Java. People should really use it (for reasons I think we all agree with) but the extra keyword makes a surprisingly large negative impact on readability and thus very few people use it. That's why I think it's so important that we have the keyword let in C# for locals at least, because it's nice and short (val would be my second choice).

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

The dev's who may give Dart another chance re Sky/Fletch won't be Java dev's who 'final' might appeal to. Java dev's are conservative - it's the early adopters who Dart once again needs to pick up.

They will not want to see:

final Point p = new Point(1,1); // no taste.

That's why the style guide says:

var p = new Point(1, 1);

But, of course, you know that already. :)

Of course - this is well trodden ground! But if people keep ignoring it maybe some reflection is needed. Especially given that the audience for Sky and Fletch maybe different and potentially (much) larger than the existing Dart2js user-base.

K.

 

- bob