Dart & Swift

[kc]

// Declare an immutable binding to a new Point object:

// Dart
final Point p = new Point(0,0);

// Swift
let p = Point(0,0)

One of these looks succinct and modern. The other 1995.

K.

[Matt f]

I like it. Simpler, more to the point. Hehe puns.

[Matt f]

[Joao Pedrosa]

Hi,

Apple needed to revamp their language of choice. :-)

I like the name too, Swift. I hope it's as good as it sounds. :-)

I also like more succinct languages. Although given the literate programming that Apple has always tried to adopt with descriptive and long names and so on, that short sample was a nice surprise. I hope they got more of it right too.

Cheers,

Joao

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

[Matt f]

I like that it can be used alongside Obj-C.

[Justin Fagnani]

Of course you can leave the type annotation out of the Dart example, making the comparison come down to "final" vs "let" and the "new" keyword. I might or might not agree with you on which is better, but I don't think this example is particularly meaningful.

Some of the more significant differences would be structs, blocks, static typing and extension methods.

[luu hoo]

And semicolon is optional.

在 2014年6月3日星期二UTC+8上午9时05分23秒，kc写道：

[kc]

On Tuesday, June 3, 2014 3:03:44 AM UTC+1, Justin Fagnani wrote:

Of course you can leave the type annotation out of the Dart example, making the comparison come down to "final" vs "let" and the "new" keyword. I might or might not agree with you on which is better, but I don't think this example is particularly meaningful.

'C' style type annotations encourage over-annotation on locals. Especially by Java programmers.

Some of the more significant differences would be structs, blocks, static typing and extension methods.

Also patterns, tuples and a useful switch statement. With a live programming/REPL environment.

K.

[Joao Pedrosa]

Hi,

It's good to think that in a time when iPads and phones rule the computers, making the programmers to write long lines doesn't even fit on the screens of some of those computers, if say the programmers were trying to program using one of them.

I don't think Dart's idea of it's OK to write long names so long as the Editor is helping you along the way fits into that picture. For example, ever since Future usage became an issue in Dart, I lost all hope for shorter lines. Since I can imagine that the difference between a normal function and a Future function is big enough to warrant a perhaps complete type declaration.

Can we imagine a programmer using his phone to write programs in the future? Who knows.

Cheers,

Joao

[Lasse R.H. Nielsen]

Go wins:

  p := Point{0, 0}

Some of us do want Dart to be brief as well: 

http://dartbug.com/18241

/L ''and I would also gladly accept the := declaration style"

--
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 R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Bluenuance]

to be fair: 

// Dart
final p = new Point(0,0);

is enough, which looks quite the same imho

[George Moschovitis]

My thoughts exactly. It's disheartening to see in Swift the language that Dart could be.

Btw, Swift looks at least as 'familiar' to me as Dart.

-g.

[Filipe Morgado]

On Tuesday, 3 June 2014 09:49:04 UTC+1, George Moschovitis wrote:

My thoughts exactly. It's disheartening to see in Swift the language that Dart could be.

Btw, Swift looks at least as 'familiar' to me as Dart.

-g.

+1

Enums, structs, extension methods, true generics, tuples, leniency, etc

It's missing a few details but it seems a lot more polished.

And being a native language (allegedly faster than Objective-C) should make it 2x-4x faster than Dart.

Well, some say that perf matters.

[Ladislav Thon]

Dne úterý, 3. června 2014 3:05:23 UTC+2 kc napsal(a):

This is really cheap. This is how javascript kiddies compare their languages. We, grownups, at least look at language features. For example, here are some things that Swift has:

• extensions
• nullable/non-nullable types with null-safe calls
• pattern matching
• tuples
• enums (though they look a bit strange, serving 2 or 3 different purposes at once)
• ability to create a new instance of generic type
• structures ... I mean, value types (yea, sure, scalar replacement...)
• understandable function parameters (optional params, named params, variadic params, passing by reference)
• arbitrary parameters for [] and []=

On the other hand, Dart has:

• arbitrary-precision ints
• mixins
• isolates (OK, this one will be an advantage once they start to make sense, which is barely starting to happen)
• library-based privacy (heck, I don't remember seeing anything about privacy in Swift language guide, am I blind?)
• implicitly defined interfaces
• no operator overloading (yes, I consider the inability to define operator +<+>+ an advantage!)
• automatic memory handling via GC (ARC gives you deterministic finalization, which is nice, but the way they solve the cycle problem looks really subpar)
• consistent handling of method parameters (in Swift, by default, no parameter is named for functions, all but the 1st are named for methods and all are named for initializers; it makes sense given historical context, but is still fairly arbitrary and can easily be very confusing to people)

Note that this is based on a pretty quick glance over the Swift language guide, zero experience in actually using the language, so I might have easily missed or misunderstood a lot of stuff. (Not that you didn't.)

LT

[Günter Zöchbauer]

Does it run in the browser?

[Filipe Morgado]

On Tuesday, 3 June 2014 12:12:30 UTC+1, Günter Zöchbauer wrote:

Does it run in the browser?

Nope. Native compilation only, alongside objective-C.

I don't think it would be easy to transpile it to JS, but a Swift VM would certainly work very well. 

[kc]

On Tuesday, June 3, 2014 9:49:04 AM UTC+1, George Moschovitis wrote:

My thoughts exactly. It's disheartening to see in Swift the language that Dart could be.

Btw, Swift looks at least as 'familiar' to me as Dart.

-g.

Totally agree.

This idée fixe "be familiar with Java" has been an albatross around Dart's neck. Early adopters are looking for something both richer and simpler while jobbing Java dev's follow early adopters. Catch 22.

K.

[Günter Zöchbauer]

I didn't expect it ;-)
I guess Swift is more comparable to Go then.

[Filipe Morgado]

On Tuesday, 3 June 2014 15:15:02 UTC+1, Günter Zöchbauer wrote:

I didn't expect it ;-)
I guess Swift is more comparable to Go then.

I guess, but ...

Swift will be primarily used for mobile/desktop apps, which is pretty much the same (long-term) niche as Dart.

Swift will be well ahead for being more performant and having an efficient UI instead of the DOM.

Despite a few semantic differences, I find the two languages very similar.

With a few tweaks (structs, nullable types, native arithmetic, optional GC, etc), Dart could make for an awesome systems programming language as well.

[Günter Zöchbauer]

I guess Swift is Apply only or will apps built with it run on Windows, Linux, Android, Ardoino, ...?

For me only Swift is in a niche.

[Graham Wheeler]

Ladislav forgot to add too:

• Dart is open-source. 
  

--

[Matthew Butler]

On Tuesday, June 3, 2014 1:31:57 PM UTC-3, Graham Wheeler wrote:

Ladislav forgot to add too:

• Dart is open-source. 
  

And going through a standards body on top of it.

[kc]

On Tuesday, June 3, 2014 11:31:36 AM UTC+1, Ladislav Thon wrote:

 

This is really cheap. This is how javascript kiddies compare their languages. We, grownups, at least look at language features. 

The point re 'final/new' is that Swift made the right syntax call. Whereas Dart stuck with a core Java-ism, which turns away potential developers. Especially scripters - kiddy or otherwise. 

In the Swift WWDC presentation the 'regular and composable' syntax of Swift was emphasized more than once. Gilad Bracha when asked what the most important feature of a programming languages was, replied 'composability'. Dart's Java-isms detract from it's composability, make growing the language more complex and hide it's good clean core semantics.

K.

[Charles Forsyth]

On 3 June 2014 11:31, Ladislav Thon <lad...@gmail.com> wrote:

For example, here are some things that Swift has:

I didn't see anything about concurrency, but I might have missed it.

[Filipe Morgado]

Supposedly the same as Objective-C.

[Daniel Morilha]

One  is intend to replace java and run everywhere (including browser) the other resembles javascript and locks you down into a specific platform.

On Mon, Jun 2, 2014 at 6:05 PM, kc <kevin...@gmail.com> wrote:

// Declare an immutable binding to a new Point object:

// Dart
final Point p = new Point(0,0);

// Swift
let p = Point(0,0)

One of these looks succinct and modern. The other 1995.

K.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Daniel Morilha (dmor...@gmail.com)

[Graham Wheeler]

I see no connection between that Swift and Apple's.

On Tue, Jun 3, 2014 at 10:43 AM, Gen <gp78...@gmail.com> wrote:

Swift seems to have roots in the natural science field.
http://swift-lang.org/ 
I do not know how or why Apple chose that language for its future.

--

[Gen]

I got the message wrong ;)
There was a link at the bottom of the page https://developer.apple.com/swift/

[Clovis Lemes Ferreira Junior]

I found this article

http://glaforge.appspot.com/article/apple-s-swift-programming-language-inspired-by-groovy

--

Clóvis Lemes Ferreira Júnior

[Gen]

Thanks.

As far as I can see, Swift is a modern Objective C without C.
And Swift remains limited to Apple and their OS.
So I am not excited about that language.

[Monty Rasmussen]

An Apple-only language? Pass.

[Jacob Goodson]

It does have interactivity(playground), which Dart is supposed to have some day... 

On Tuesday, June 3, 2014 9:37:56 PM UTC-4, Monty Rasmussen wrote:

An Apple-only language? Pass.

[Ladislav Thon]

Dne úterý, 3. června 2014 18:41:33 UTC+2 Matthew Butler napsal(a):

Both correct. Omitting those was a mistake I made, having too narrow focus. Also, calling a language Swift when there is another language called Swift that has a swiftlang.org domain is just irresponsible.

LT

[Peter Ahé]

Eventually, I'd like Dart to have something like http://worrydream.com/#!/InventingOnPrinciple

You can follow my progress on Google+, for example: https://plus.google.com/104729279175870053531/posts/eGdSfRjMM26

Cheers,
Peter

--

[Ladislav Thon]

Dne úterý, 3. června 2014 18:48:52 UTC+2 kc napsal(a):

On Tuesday, June 3, 2014 11:31:36 AM UTC+1, Ladislav Thon wrote:

 

This is really cheap. This is how javascript kiddies compare their languages. We, grownups, at least look at language features. 

The point re 'final/new' is that Swift made the right syntax call. Whereas Dart stuck with a core Java-ism, which turns away potential developers. Especially scripters - kiddy or otherwise.

Oh come on, this gets really old. This is a language designed for large applications and teams -- a little bit of discomfort in scripting situations is a good price to pay (note that the focus is on little here). Also, please compare

public class Main {

    public static void main(String[] args) {

        System.out.println("Hello, world!");

    }

}

with

main() {

  print("Hello, world!");

}

and then tell me about Java-isms. Dart is in fact not bad for scripting, though I will agree that the discomfort is there.

 

In the Swift WWDC presentation the 'regular and composable' syntax of Swift was emphasized more than once. Gilad Bracha when asked what the most important feature of a programming languages was, replied 'composability'. Dart's Java-isms detract from it's composability, make growing the language more complex and hide it's good clean core semantics.

What I think of composable syntax is nothing like mainstream languages syntax have (see e.g. JetBrains Nitra or JetBrains MPS for industry-ready examples of composable syntax). Swift, like Dart, doesn't really care about composable syntax (no matter what they say on a conference) -- if they did, they'd at least unify expressions and statements. Which, AFAIK, they didn't.

LT

[曹忠]

Google and dart to win the future, we must recruit more , quickly take dart and development framework to the mature and open up the dart can develop desktop, web and mobile applications, because not much time left to google.  Obviously, apple swift more mature, better development tools, performance and dynamic language features combine more rods, the only drawback is not cross-platform.

在 2014年6月3日星期二UTC+8上午9时05分23秒，kc写道：

[Günter Zöchbauer]

Most of the complexity lies in supporting different environments. Apple makes it easy for themselves by just ignoring the outside World.

(many areas where Apply seems superior are based on just that)

For this reason alone the language is limited to people who are satisfied when their solutions run on Apple hardware alone.

That Google supports so many environments makes their task much harder but the solutions can run everywhere.

There is no need for panic, just because Apple made a nice presentation the other day.

[George Moschovitis]

There is no need for panic, just because Apple made a nice presentation the other day.

No panic, but maybe we could consider 'borrowing' some nice features, e.g.

- enums/switch (their design looks interesting)

- typealias

- tupples / destructuring

- repl

to name just a few.

-g.

[kc]

On Wednesday, June 4, 2014 9:23:06 AM UTC+1, Ladislav Thon wrote:

Oh come on, this gets really old. This is a language designed for large applications and teams -- a little bit of discomfort in scripting situations is a good price to pay (note that the focus is on little here).

Dart's language designer seems to prefer:

- function return types on the rhs with '->'

- no 'new'. Maybe 'const' as a modifier for immutability.

- val/let instead of 'final' for immutable bindings (if not immutable by default)

- elements of Scala syntax (if not Newspeak)

  Possibly Scala/C# 6.0 primary constructors

This gives something both parsable/toolable and easy on the eye:

class Point(int x, int y);

myfunction(int a, int b)-> Point {
 
 var x = a;
 let y = b;

 return Point(x,y);

}

// n.b this is apart from whether type annotations should be rhs (with or without a colon).

The interesting aspect of Dart is the core semantics with a new runtime to compete against the JS, Java and Dotnet VM's that dominate the landscape. The syntax is almost incidental - but why obscure the semantics under Java-isms? The Swift syntax was a reminder of a missed opportunity. 

K.

[kc]

On Wednesday, June 4, 2014 10:42:32 AM UTC+1, George Moschovitis wrote:

There is no need for panic, just because Apple made a nice presentation the other day.

No panic, but maybe we could consider 'borrowing' some nice features, e.g.

- enums/switch (their design looks interesting)

- typealias

- tupples / destructuring

- repl

to name just a few.

-g.

Agree - the core semantics of Dart are good. But comparing Swift switch/tuples/patterns with Dart's 'C'/Java heritage switch, I honesty think the Swift version will be of more use in 'industry', 'enterprize' and script kiddy-land.

K.

 

[Matthew Butler]

On Wednesday, June 4, 2014 6:42:32 AM UTC-3, George Moschovitis wrote:

There is no need for panic, just because Apple made a nice presentation the other day.

No panic, but maybe we could consider 'borrowing' some nice features, e.g.

- enums/switch (their design looks interesting)

http://dartbug.com/88 

- typealias

http://dartbug.com/2626 

- tupples / destructuring

http://dartbug.com/10310 

- repl

http://dartbug.com/4409 

[kc]

On Wednesday, June 4, 2014 1:33:41 PM UTC+1, Matthew Butler wrote:

http://dartbug.com/88 

- typealias

http://dartbug.com/2626 

- tupples / destructuring

http://dartbug.com/10310 

- repl

http://dartbug.com/4409 

to name just a few.

The are lots of language requests in the issue tracker. How do developers get an insight into how they are prioritized/bundled for releases - as part of TC52. (And EcmaTime can slow things down as Lars Bak is well aware).

Who is on TC52? Anyone from MS, Mozilla, Apple, Opera or Adobe? Outside Google? Any contributors to the Dart Google groups?

http://news.dartlang.org/2014/02/standardizing-dart-1st-ecma-tc52.html

K. 

[Gen]

I guess the best way is to complain in the forum and the issue tracker with good reasons.

Who cares about TC52 anyway ?
Apple, Facebook, Mozilla, Microsoft and the Java world have made their decision and Dart is not part of any one's future.
Unless Google supports Mozilla even more.

Dart is and will depend on Google.
Like you I hope that TC52 will not become a problem for Dart.
It is time that Google shows that Dart is a serious project; unlike their "secret weapon" Go.
Their secret customer stories, the absence from Android (AFAIK) and the Isolate and Mirror API struggle do not convince regular programmers.

[Jesse Warden]

Whats the Isolate struggle?

--

[Matthew Butler]

On Wednesday, June 4, 2014 11:34:49 AM UTC-3, Gen wrote:

I guess the best way is to complain in the forum and the issue tracker with good reasons.

Who cares about TC52 anyway ?
Apple, Facebook, Mozilla, Microsoft and the Java world have made their decision and Dart is not part of any one's future.

Actually, important people care about TC52. In fact the initial complaints from Webkit (eg Safari) and Mozilla was not a new language in itself, but that it was a 'non-standardized' language. With the standards committee closing that issue, these companies will need to seriously look at Dart again, particularly as it is integrated into Chrome and starts giving a boost to applications.

Matt

[Gen]

I have not followed Dart very closely in the last months.
It took a long time for the Isolate API to be finished. I do not know if the Isolate API is considered stable by now.

The Mirror API lacks features for dynamic code generation. I do not know about any work on that front.
Probably the Dart team would refuse to give any kind of schedule anyway.

[Joao Pedrosa]

Hi,

I think by now most of us have been able to take a look at the Swift documentation. I can say that I am glad that Dart took as many chances as possible to streamline the syntax early on. By having Dart I don't really envy Swift.

Many folks seem to be mostly interested in how the different languages handle types. And the bug tracker of Dart and a lot of discussion in Dart has always had types as a core concern.

Thanks to neat syntax, Dart got away without so many abbreviations. Swift uses "func" and "init" and perhaps "in", a lot.

I confess that I found the string interpolation syntax with "abc\(name)def" kind of neat. :-)

I think we are fortunate that Apple has come up with an easier to understand language, since Objective-C was kind of a mess. But Dart is higher level than Swift and thus is much more fun to work with. Swift may be fun insofar as it's plenty fast for what it does. We may envy Swift's great performance though. Programmers also like it fast.

Cheers,

Joao

[Gen]

It was one of the initial complaints.
I know no one that would use or dismiss Dart because there is some Ecma specification or not.

AFAIR, Brendan Eich said once that Ecma sounds like a skin disease
and I had not the impression that he attributed any importance to that association.

[Matthew Butler]

On Wednesday, June 4, 2014 12:37:09 PM UTC-3, Gen wrote:

It was one of the initial complaints.
I know no one that would use or dismiss Dart because there is some Ecma specification or not.

AFAIR, Brendan Eich said once that Ecma sounds like a skin disease

Actually it was specifically about JavaScript being renamed "EcmaScript"[1]

 

and I had not the impression that he attributed any importance to that association.

It was Brendan that criticized Google for Dart being a non-standard language and saying those resources should be added to the existing ones already contributing to TC39 (EcmaScript) and the goals they're trying to reach.  

[1]: https://mail.mozilla.org/pipermail/es-discuss/2006-October/000133.html 

[Alex Tatumizer]

In Europe, there's a standard for everything. They once standardized cucumbers:
http://www.spiegel.de/international/europe/european-bureaucracy-should-the-eu-sell-bent-cucumbers-a-562064.html
Not sure whether it was an ECMA standard or not, and whether Apple was on committee, but it could be. Apples these days often taste like cucumbers, and vice versa.

 

[Gen]

You fight with what you have.
And I guess this is the main point:

"those resources should be added to the existing ones already contributing to TC39 (EcmaScript)"

I still believe that Brendan or any one involved with Ecmascript would rather see Dart fail sooner than later in order to keep Javascript/Ecmascript in the spotlight.
Dart competes with Javascript, like any other web and now server language (nodejs), despite a different marketing speech from the Dart team.

PS
From an old discussion: https://news.ycombinator.com/item?id=2982949
Brendan is interested in an open and universal web language and not specifically about design by committee or JS. 

[kc]

On Wednesday, June 4, 2014 4:26:16 PM UTC+1, Matthew Butler wrote:

Actually, important people care about TC52.

Who? Are they represented on TC52?

 

In fact the initial complaints from Webkit (eg Safari) and Mozilla was not a new language in itself, but that it was a 'non-standardized' language. With the standards committee closing that issue, these companies will need to seriously look at Dart again, particularly as it is integrated into Chrome and starts giving a boost to applications.

The imprimatur of ECMA will likely have no effect.

A commitment by Google that the Dart VM is going into the heart of it's own platforms - Chrome, ChromeOS and Android - so that it flies on touch with modern web technologies - will make people pay attention. Because of Google's market share.

Apple are totally committed with Swift. They laid out what they doing. It's going to be core to their platforms, no questions asked. (Whether Swift v1.0 will be released with a MIT licence as part of  Clang/llvm I don't know.)

K.

[Günter Zöchbauer]

As far as I know standardization is to make it more likely other browser vendors implement it too

not to make it more compelling to developers.

I don't think that it makes much difference for developers, they rather have new features fast.

[Matthew Butler]

On Wednesday, June 4, 2014 1:31:50 PM UTC-3, kc wrote:

On Wednesday, June 4, 2014 4:26:16 PM UTC+1, Matthew Butler wrote:

Actually, important people care about TC52.

Who? Are they represented on TC52?

I honestly couldn't say if they're represented on TC52 or not. But they don't have to be. Who? Brendan Eich is one who said that Mozilla wouldn't adopt Dart because it was not an open standard. And Apple Engineer Oliver Hunt also voiced similar concerns about Dart not being a standard. However they don't need to be a member of the committee to implement, or even pay attention to the language now that it's being standardized. Do they make the final decisions at either Mozilla or Apple/Safari (or webkit in general for that matter). No probably not (anymore), however when the customers start looking for Dart support that's one less leg that either browser has to stand on to refuse to implement it.   

 

In fact the initial complaints from Webkit (eg Safari) and Mozilla was not a new language in itself, but that it was a 'non-standardized' language. With the standards committee closing that issue, these companies will need to seriously look at Dart again, particularly as it is integrated into Chrome and starts giving a boost to applications.

The imprimatur of ECMA will likely have no effect.

A commitment by Google that the Dart VM is going into the heart of it's own platforms - Chrome, ChromeOS and Android - so that it flies on touch with modern web technologies - will make people pay attention. Because of Google's market share.

Which is being done. But if it was shipped when Dart was not a standard then immediately we see what we had when Dart was first announced, that Google is trying to fracture the web and implementing non-standard features that others cannot/will not implement not being a standard. 

Apple are totally committed with Swift. They laid out what they doing. It's going to be core to their platforms, no questions asked. (Whether Swift v1.0 will be released with a MIT licence as part of  Clang/llvm I don't know.)

Sure, but being as I do not have apple products I'll never run a line of code of it. Dart's platform however it the web which runs on Apple, Android, Windows Phone, Linux, Windows etc. etc etc. Google's platform is the web. It's where gmail resides, it's where AdWords resides. They didn't ship a 'chrome only' AdWords, just as the didn't ship an Android Only Gmail. But that's exactly what Apple is doing. 

K.

[Gen]

From an a old discusson:

https://news.ycombinator.com/item?id=2982949
Brendan is interested in an open and universal web language and not specifically about design by committee or JS. 

He thinks the specificatipon is important because it creates a common standard for all browser vendors.
But even with TC52, the situation is completely different because only Google wants and offers Dart.

I do not know how the other Javascript users and implementors think about Dart.
Ecma or not, Dart competes in every regard with Javascript as only universal web language.
Ecma or not, no other browser vendor but Google and maybe Firefox because of Google, will offer the DartVM.
Ecma or not, implementation and support for a VM is not simple or cheap.

[Alex Tatumizer]

I think Swift outswifted dart in one respect: it can be used as web programming language regardless of standartization or formal support by browser vendors - much in the way how objective C could be used: via emscripten -e.g.

https://sites.google.com/site/virtualcide/home/using-emscripten

Not sure how easy or difficult this route could be, but it's possible (may be just a matter of using appropriate libraries).

Strange that no one mentioned this option yet.

[Günter Zöchbauer]

I don't think emscripten will become mainstream. This is nice if you have a big codebase that you want migrate to the web.

There is no garbage collection and I don't know if it even can access the DOM (at least NaCl code can't)

[kc]

On Wednesday, June 4, 2014 5:55:37 PM UTC+1, Matthew Butler wrote:

I honestly couldn't say if they're represented on TC52 or not.

OK. Who *is* on TC52. Is there a list somewhere?

 

Which is being done. But if it was shipped when Dart was not a standard then immediately we see what we had when Dart was first announced, that Google is trying to fracture the web and implementing non-standard features that others cannot/will not implement not being a standard. 

If standardization is a box Google feels it has to tick before putting the Dart VM into it's platforms then OK. But ticking that box will have no effect on the other browser vendors. The only thing that will is massive and rapid takeup of Dart. Which requires at least the announcement from Google that the Dart VM is going into it's platforms. Google is asking developers to make a platform bet. 

 

Apple are totally committed with Swift. They laid out what they doing. It's going to be core to their platforms, no questions asked. (Whether Swift v1.0 will be released with a MIT licence as part of  Clang/llvm I don't know.)

Sure, but being as I do not have apple products I'll never run a line of code of it. Dart's platform however it the web which runs on Apple, Android, Windows Phone, Linux, Windows etc. etc etc. Google's platform is the web. It's where gmail resides, it's where AdWords resides. They didn't ship a 'chrome only' AdWords, just as the didn't ship an Android Only Gmail. But that's exactly what Apple is doing. 

I admire Apple's focus not their lock-in strategy. And that Swift had the good taste not to look like Java.

K.

[Matthew Butler]

On Wednesday, June 4, 2014 2:37:39 PM UTC-3, kc wrote:

On Wednesday, June 4, 2014 5:55:37 PM UTC+1, Matthew Butler wrote:

I honestly couldn't say if they're represented on TC52 or not.

OK. Who *is* on TC52. Is there a list somewhere?

Apart from Chaiman and Secretary I'm not able to tell. I believe the members list is restricted to members only access (but being as I'm not part of Ecma Group or this TC in particular i couldn't say for sure). 

[kc]

On Wednesday, June 4, 2014 6:54:51 PM UTC+1, Matthew Butler wrote:

OK. Who *is* on TC52. Is there a list somewhere?

Apart from Chaiman and Secretary I'm not able to tell. I believe the members list is restricted to members only access (but being as I'm not part of Ecma Group or this TC in particular i couldn't say for sure). 

Does anyone know? Are the meetings of TC52 minuted?

K.

[George Moschovitis]

I confess that I found the string interpolation syntax with "abc\(name)def" kind of neat. :-)

+10

[Filipe Morgado]

Swift is not a "web programming language". It is a iOS/OSX-only programming language and it will probably never run "on the web".

[Alex Tatumizer]

> I don't think emscripten will become mainstream

If Apple says it's mainstream, it's mainstream by definition. They can change the name from emscripten to "cucumber", who cares, it's just LLVM-js compiler.
For DOM, they can define LLVM extension (LLVM is designed by the same guy anyway).
Whether they choose to activate this option, it's hard to tell, but the option certainly exists.

> Swift is not a "web programming language"

They can start calling it web programming language at any time. What is there to stop them?

[Gen]

Probably it possible to port or translate Cocoa and Swift code to Javascript or even asm.js using LLVM.
Will Apple do that ? I doubt it.

[Matthew Butler]

I did some digging and found this document:
http://www.ecma-international.org/publications/files/ECMA-MEMENTOS/Ecma%20memento%202014%20public.pdf

Page 47 lists TC52 including members (3 from Google, One from Aarhus University and one from Broadcom)

I know the meeting minutes are supposed to be posted on the site as well, however they are relatively slow to post up-to-date information and I've not been able to discover them yet.

Matt 

K.

[Günter Zöchbauer]

Apple can an will call it everything that helps to sell it, no question.

There are always some use cases where this is great approach (the same for Go on LLVM and NaCl) 

but I wouldn't expect broad adoption for such solutions.

[Anders Holmgren]

thanks for the link. I think this is a great vision for what can be done. Excited to see where this goes

On Wednesday, 4 June 2014 18:18:12 UTC+10, Peter von der Ahé wrote:

Eventually, I'd like Dart to have something like http://worrydream.com/#!/InventingOnPrinciple

You can follow my progress on Google+, for example: https://plus.google.com/104729279175870053531/posts/eGdSfRjMM26

Cheers,
Peter

On ons. 4. jun. 2014 at 4.44 AM, Jacob Goodson <submissio...@gmx.com> wrote:

It does have interactivity(playground), which Dart is supposed to have some day... 

On Tuesday, June 3, 2014 9:37:56 PM UTC-4, Monty Rasmussen wrote:

An Apple-only language? Pass.

[David Kopec]

I think a lot of you are looking at this wrong - there is no competition between Dart and Swift. They serve completely different markets.  Nobody will be choosing between Dart and Swift for a project for the foreseeable future.  

If we zoom out a bit, and don't get caught in the weeds looking at very specific features or syntax, it's actually interesting how much the two have in common.  Both are elegant object-oriented languages with clear influence from the functional realm.  Both actually improve on performance over their predecessors (Dart over JavaScript and Swift over Objective-C).  Both were developed by world class engineers at large corporations with cutting edge previous language implementation experience (V8 guys at Google, LLVM guys at Apple).

Personally I'm very excited about both of them - no need to pit them against each other.  They represent best-of-what's-out-there for their respective silos.  And yes, open-source or not, they are effectively silos.  I can't develop a native iOS app in Dart for now, and I can't develop a web app in Swift for now, and I can't develop a native Windows app in either easily.  Silos.  But damn good silos and we should be excited that a new generation of excellent industry supported languages has come about.

[Siddhartha Gadgil]

Good to hear that Dart language designers like scala syntax. I do miss a few scala features in Dart:

(1) Case classes - especially overriding of equality and toString()

(2) flatMap and flatten

(3) The for statement sugar for combinations of map, flatMap and filter.

On Wednesday, June 4, 2014 3:45:45 PM UTC+5:30, kc wrote:

On Wednesday, June 4, 2014 9:23:06 AM UTC+1, Ladislav Thon wrote:

Oh come on, this gets really old. This is a language designed for large applications and teams -- a little bit of discomfort in scripting situations is a good price to pay (note that the focus is on little here).

Dart's language designer seems to prefer:

- function return types on the rhs with '->'

- no 'new'. Maybe 'const' as a modifier for immutability.

- val/let instead of 'final' for immutable bindings (if not immutable by default)

- elements of Scala syntax (if not Newspeak)

  Possibly Scala/C# 6.0 primary constructors

This gives something both parsable/toolable and easy on the eye:

class Point(int x, int y);

myfunction(int a, int b)-> Point {
 
 var x = a;
 let y = b;

 return Point(x,y);

}

// n.b this is apart from whether type annotations should be rhs (with or without a colon).

The interesting aspect of Dart is the core semantics with a new runtime to compete against the JS, Java and Dotnet VM's that dominate the landscape. The syntax is almost incidental - but why obscure the semantics under Java-isms? The Swift syntax was a reminder of a missed opportunity. 

K.

[Greg Lowe]

2) I believe iterable.expand() is the equivalent of flatMap().

https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-core.Iterable#id_expand

[Siddhartha Gadgil]

Thanks. I will start using it.

--

[kc]

On Thursday, June 5, 2014 5:13:21 AM UTC+1, David Kopec wrote:

I think a lot of you are looking at this wrong - there is no competition between Dart and Swift. They serve completely different markets.  Nobody will be choosing between Dart and Swift for a project for the foreseeable future.  

I get that.

Swift is AOT/native initially aimed at iOS/OS X. (Though maybe Apple will eventually release the compiler, core libs and runtime under an MIT licence).

Dart is a JIT/dynamic OO language aimed at the web. Goes from source to execution at runtime. Snapshots for fast startup. Open licence.

Different markets.

But one language made the right call re Java-isms and the other didn't.

And what is poor is that the Java-isms hide what Dart is about. 

Who wants a switch like Java/C. No one. 

Who wants tuples. Everyone. 

Who wants a succinct syntax for immutable bindings. Thinking dev's.

And despite the magical thinking that TC52 will cause Mozilla and Apple to have an epiphany and adopt a competitors technology, all TC52 does is lock-in the Java-isms and slow down the adoption of features like tuples/multiple return values. The only benefit to TC52 is if Google think having a ECMA standard is a figleaf before putting the VM into Chrome. But overall, given that TC52 membership is 3 Googler's, someone from Dart's local uni and a dude from Broadcom it doesn't mean much.

K. 

[peteroc]

Someone made the following comment on the HN thread about Swift

"Worth noting that one of the greatest problems in software development is concurrency support and its ease of use/robustness. It is a critical and growing issue.

In contrast, having or not having generics, optionals (in C# these are nullable types), algebraic data types (which in Go is interface, albiet minus the type set checking) make a marginal, vanishingly small difference in programmer productivity or application performance/stability. 99% of the articles about the profound importance of generics are people building nothing of interest for anyone, and it is exactly that vaguery of design that makes generics seem so important."

Even though the quote references something that seems as fundamental as generics its probably correct. They make a marginal difference. Even in dart they make a marginal difference relative to its main features which are a toolable fast consistent OO language with flexible typing that runs in all web browsers. Certainly I think that the features you listed (pattern matching, tuples, succinct consts) would make very little difference indeed to my daily productivity. They are clever but not really useful and in the case of the first two will actually add cognitive overhead to learning and using the language (e.g. when should I use an ADT instead of an object?). You start to sweat things that make little difference when you should be concentrating on getting your product finished. Leave the sweating to the language connoisseurs on reddit - they seem to have little else to do. 

[kc]

On Thursday, June 5, 2014 6:19:11 PM UTC+1, peteroc wrote:

Someone made the following comment on the HN thread about Swift

"Worth noting that one of the greatest problems in software development is concurrency support and its ease of use/robustness. It is a critical and growing issue.

True. Eight core Arm64 soon enough.

 

 You start to sweat things that make little difference when you should be concentrating on getting your product finished. Leave the sweating to the language connoisseurs on reddit - they seem to have little else to do. 

The dev's who are using Dart are maybe self-selecting - they don't mind some familiar boilerplate in exchange for not dealing with JS crazyness. But there's another set - the connoisseurs - who won't give the language a go because of it.

K.

 

[peteroc]

OK. However I'm trying to interest some people in work in using dart for a project. They like their languages but I know that these kinds of relatively minor features will be the last thing they look at when deciding whether to use it. Instead it will be darts major features as a language along with performance, portability, and long term support and usage base. I imagine that its the same for most people who are going to build something reasonably large and reasonably long lived. If they are going to reject dart it won't be because of e.g. pattern matching, tuples, succinct consts. In other words if you are going to use dart for a primary project you are going to use it anyway. These features will make no difference.

[Jacob Goodson]

That is a nice quote.  You are true when you say that most of the sugary syntactic things we do are of little use for day to day programming. I too, have gotten caught up the "superiority" of print "hello world" in the past.  The next big language will prob not be a language at all but a run-time; one that makes concurrency as naive as garbage collection is now.

[Greg Lowe]

I'm all for new features - but It's easy to get things wrong if you try and add everything at once - and it's hard/impossible to undo mistakes once they're baked into the language.

Dart seems to be progressing pretty quickly - consider as a comparison that it's taken Java two decades to get closures - despite a big team and a hefty budget.

I hope that Dart will get multiple returns, destructing and pattern matching in the not to distant future (or maybe someone will do that in Dart's "CoffeeScript").

Bug for pattern matching:

  https://code.google.com/p/dart/issues/detail?id=2949

[Greg Lowe]

destructing => destructuring

--

[Gen]

It took Java that long because:
- Managers decided what the masses want by listening to some of their customers about what they thought they needed.
Most people think they do not need something because they have never put it to good use.
I wonder how much Gilad is in the driver seat this time with Dart.
 
- The could not decide on good syntax.
Something that appears not important to some when I read this discussion.
IMO, Java is out of favor because of cumbersome syntax and not because of technical efficiency and static types.
I watched a talk from Bjarne Stroustrup: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote
And AFAIR he said at some point that customers and committee want cumbersome syntax for new things until next year when they have learned the concept.

Besides, Sun they tried ISO and Ecma but withdraw both times and kept the defacto standard model.
Since 1998 Java has the community process.

[Sebastien Deleuze]

Linked topic : please vote (star) this issue if you are interested in building Android native apps with Dart : http://dartbug.com/19266

Le vendredi 6 juin 2014 06:19:29 UTC+2, Gen a écrit :

It took Java that long because:
- Managers decided what the masses want by listening to some of their customers about what they thought they needed.
Most people think they do not need something because they have never put it to good use.
I wonder how much Gilad is in the driver seat this time with Dart.
 
- The could not decide on good syntax.
Something that appears not important to some when I read this discussion.
IMO, Java is out of favor because of cumbersome syntax and not because of technical efficiency and static types.
I watched a talk from Bjarne Stroustrup: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote
And AFAIR he said at some point that customers and committee want cumbersome syntax for new things until next year when they have learned the concept.

Besides, Sun they tried ISO and Ecma but withdraw both times and kept the defacto standard model.
Since 1998 Java has the community process.

Am Freitag, 6. Juni 2014 02:35:34 UTC+2 schrieb Greg Lowe:

[kc]

On Thursday, June 5, 2014 11:40:26 PM UTC+1, Jacob Goodson wrote:

I have gotten caught up the "superiority" of print "hello world" in the past.  The next big language will prob not be a language at all but a run-time; one that makes concurrency as naive as garbage collection is now.

Yes. A runtime with async and immutability at it's core designed for modern multi-core cpu/gpu's. Though recently the Dart VM does seem to emphasise these feature with streams, zones etc. Maybe the Dart VM should focus on the 64-bit platforms - especially ARM64 - given dart2js for 32-bit platforms. First on the server, and when Oilpan/Web Components/Animations is done, on the client.

But I don't see what's particularly 'enterprise' or 'industry' about Java syntax. The reason it became established was accidental. People like me in the 90's were looking for a serverside language/runtime and went with servlets. (Avoided J2EE - recognize insane boilerplate when I see it). JS, despite it's weird corners, always had the richer semantics. But it took node/V8 for JS to flourish on the server.

But newer languages - including those that run on the JVM - are choosing other syntaxes with good reason. Easier to parse, annotate, read and write. Dart looks like it's in a no man's land between Java, C# and JS. 

K.

 

[Peter Ahé]

You are so far off the mark. The tale of closures in Java includes petty rivalry and Sun putting Java out to pasture while they focused on JavaFX.

We put out the proposal in 2007, it was sponsored by the language creator (James), specification lead (Gilad), compiler lead (me), and the former compiler lead (Neal). See http://www.javac.info/closures-v01.html. It crashed and burned in politics.

Cheers,
Peter

--

[Greg Lowe]

@Peter

Sorry for picking the Java closure example - not intentional - that sounds like a really frustrating experience. I hope this time around you've got more chance to innovate (although Dart's compile to js requirement must also feel limiting and frustrating at times - i.e. no non local returns). 

The dart2js incremental compilation work you're doing looks like it could be a huge win for cross browser development. I'm also curious to see how this pans out for live development workflows.

[kc]

On Wednesday, June 4, 2014 9:23:06 AM UTC+1, Ladislav Thon wrote:

Dne úterý, 3. června 2014 18:48:52 UTC+2 kc napsal(a):

On Tuesday, June 3, 2014 11:31:36 AM UTC+1, Ladislav Thon wrote:

 

This is really cheap. This is how javascript kiddies compare their languages. We, grownups, at least look at language features. 

The point re 'final/new' is that Swift made the right syntax call. Whereas Dart stuck with a core Java-ism, which turns away potential developers. Especially scripters - kiddy or otherwise.

Oh come on, this gets really old. This is a language designed for large applications and teams -- a little bit of discomfort in scripting situations is a good price to pay (note that the focus is on little here). Also, please compare

You used to be the biggest Dartisan around. Looks like your new love is Kotlin. Let's have a glance at Kotlin syntax:

class Point(x: Int, y: Int)

fun getPoint(x: Int): Point {
  var y: Int
  y = a * 2
  return Point(x,y)
}

val pt = getPoint(1)

Syntax features:

- succinct immutable binding syntax 'val'

- no 'new'

- class primary constructors (also in C# 6.0)

- type annotations on rhs

This syntax - *not* the full-on type system of Kotlin (or Scala) - also fits in with the underlying theory/semantics of Dart. Would help make the sale that type annotations are *just* annotations.

There's a reason Kotlin, Swift, Rust, Scala, TypeScript/ES6 are moving in a certain direction. How can Swift - an AOT native language - have, in some respects, a lighter, richer syntax than Dart.

K.

 

[Alex Tatumizer]

I think most of archaic features in dart stem from "familiarity" principle. Other languages moved on, Now declaration syntax, mandatory "breaks" in switch statement, mandatory "new" already look slightly outdated. 

But things don't stop here. Probably same principle of "familiarity" (the meaning of which is a subject of speculation) dictated the preference for declarative frameworks like angular - weird, amateurish attempt to enhance HTML by building a clumsy programming language on top of it. Is this a right way to showcase dart? If dart is not good enough to formulate API for UI programming, then what's the point of the language? Angular+javascript is not much different from angular+dart anyway, it's still the same cake, why would anyone want to switch?

Naturally, polymer follows in footsteps of angular, trying to define yet another language. And to those curious when to use which, the advice is to use BOTH (!). Plus dart, compiled to javascript.

This angular thing is something that disappoints me much more than slightly outdated syntax.

[Greg Lowe]

> mandatory "new"

There's a bug for optional new/const:

https://code.google.com/p/dart/issues/detail?id=18241

I've heard one complication for making new optional is it's required in the grammar so that you can add generic type parameters to constructor calls.

But if generic functions are added this problem would go away I guess.

https://code.google.com/p/dart/issues/detail?id=254

[Ladislav Thon]

Dne sobota, 7. června 2014 16:50:51 UTC+2 kc napsal(a):

On Wednesday, June 4, 2014 9:23:06 AM UTC+1, Ladislav Thon wrote:

Dne úterý, 3. června 2014 18:48:52 UTC+2 kc napsal(a):

On Tuesday, June 3, 2014 11:31:36 AM UTC+1, Ladislav Thon wrote:

 

This is really cheap. This is how javascript kiddies compare their languages. We, grownups, at least look at language features. 

The point re 'final/new' is that Swift made the right syntax call. Whereas Dart stuck with a core Java-ism, which turns away potential developers. Especially scripters - kiddy or otherwise.

Oh come on, this gets really old. This is a language designed for large applications and teams -- a little bit of discomfort in scripting situations is a good price to pay (note that the focus is on little here). Also, please compare

You used to be the biggest Dartisan around. Looks like your new love is Kotlin.

Ahem...

 

Let's have a glance at Kotlin syntax:

class Point(x: Int, y: Int)

fun getPoint(x: Int): Point {
  var y: Int
  y = a * 2
  return Point(x,y)
}

val pt = getPoint(1)

Syntax features:

- succinct immutable binding syntax 'val'

- no 'new'

- class primary constructors (also in C# 6.0)

- type annotations on rhs

This syntax - *not* the full-on type system of Kotlin (or Scala) - also fits in with the underlying theory/semantics of Dart. Would help make the sale that type annotations are *just* annotations.

There's a reason Kotlin, Swift, Rust, Scala, TypeScript/ES6 are moving in a certain direction. How can Swift - an AOT native language - have, in some respects, a lighter, richer syntax than Dart.

There's a whole lot of things I don't exactly like on Dart, on Kotlin, and on all languages I ever used. It would probably be even in a language that I would design :-) (No, I'm not working on anything like that. I don't have the skills.)

For example, I hate constructors in Kotlin and I strongly believe that the only language that got constructors right is Dart. (I still don't understand how can anyone consider class Point(var x, var y) readable, and even explain it like "you know, the class is like a function...", which is an explanation that works surpsingly well for generics, an entirely different topic.) I also hate the need of the fun keyword -- I shouldn't have to write that. Compare:

fun main(args: Array<String>) {

  println("Hello, world")

}

with

main() {

  print("Hello, world");

}

Who's succint now?

And in case you asked -- no, I don't think these are a fair comparison. I also don't think your purely syntax-based comparison is valid. I mean -- for me, the things you are so passionate about are nothing but fassion. I'm not interested in that, even though I strongly believe that syntax is very very important.

LT

P.S.: I also used to be very passionate about left-hand side vs. right-hand side type annotations, back in the days when I first moved from Pascal to C. I've grown a bit since then.

[Ladislav Thon]

Dne sobota, 7. června 2014 21:39:19 UTC+2 Alex Tatumizer napsal(a):

Huge +1.

Also, I've seen that you still work on Circuit. That's admirable. Never give up, never surrender!

LT

[kc]

On Monday, June 9, 2014 8:24:05 AM UTC+1, Ladislav Thon wrote:

 

For example, I hate constructors in Kotlin and I strongly believe that the only language that got constructors right is Dart. (I still don't understand how can anyone consider class Point(var x, var y) readable, and even explain it like "you know, the class is like a function...", which is an explanation that works surpsingly well for generics, an entirely different topic.) 

C# 6.0 thinks differently. Great syntax for immutable POD's.

 

I also hate the need of the fun keyword -- I shouldn't have to write that. Compare:

fun main(args: Array<String>) {

  println("Hello, world")

}

with

main() {

  print("Hello, world");

}

Who's succint now?

Not much bothered about 'fun' (though Kotlin, Rust, Go and Swift chose different). However, a fair comparison of Kotlin-ish syntax skinned on Dart semantics:

fun main() {

  print("Hello, world");

}

 Also 'fun':

- indicates a new binding

- can trigger a text expansion

- leaves syntax space for new keywords, trailing closure/block syntax or even macros

- is easy to eyeball

It's not succinct for it's own sake. It's the right combination of succinct, readable and parsable/toolable.

I also don't think your purely syntax-based comparison is valid.

Sure. It's what lies beneath the syntax that is important - semantics and runtime. The significant part of Dart is the Dart VM - and it's dart2js trojan horse. The editor and analyser could be done by the community and tool vendors. But the community and tool vendors can't create a new VM and get it into Googles client platforms. Syntax helps makes the sale.

 

I mean -- for me, the things you are so passionate about are nothing but fassion. I'm not interested in that,

 

Saw a video of a Dart presentation you gave. So on this we agree.

LT

P.S.: I also used to be very passionate about left-hand side vs. right-hand side type annotations, back in the days when I first moved from Pascal to C. I've grown a bit since then.

It's not so much lhs/rhs. It's that Dart's current Java/C type annotation syntax encourages over-annotation especially on locals. And given Dart's optional/pluggable approach to types and the fact that in Dart everything is an object which has intrinsic security properties it unnecessarily encourages developers to sweat the types.

K.

 

[Ladislav Thon]

P.S.: I also used to be very passionate about left-hand side vs. right-hand side type annotations, back in the days when I first moved from Pascal to C. I've grown a bit since then.

It's not so much lhs/rhs. It's that Dart's current Java/C type annotation syntax encourages over-annotation especially on locals. And given Dart's optional/pluggable approach to types and the fact that in Dart everything is an object which has intrinsic security properties it unnecessarily encourages developers to sweat the types.

Does it? Last time I checked, it was a convention in the Dart land to avoid annotations on locals, just like in languages with local inference (Scala, Kotlin, Swift?). This, IMHO, strikes the best balance -- types makes a lot of sense on API boundary, not that much inside the implementation.

LT

[Günter Zöchbauer]

I tried to follow this guideline but very frequently found bugs when not using concrete types on local variables.

Especially for something like

var x = y ? getR() : s;

Dart doesn't warn about anything you do with x afterwards;

This caused a lot of troubles when porting a large codebase from JavaScript to Dart (a lot of runtime exceptions).

Therefore I add types everywhere. String, int and SomeType are not longer than var most of the time. 

When I later change anything (the return type of getValue() for example) the analyzer immediately shows which parts of the code are affected.

There are feature requests to make the analyzer warn when it can't reliably infer the type of an expression.

• https://code.google.com/p/dart/issues/detail?id=17945
  
• https://code.google.com/p/dart/issues/detail?id=16157
  
• https://code.google.com/p/dart/issues/detail?id=14600
  
• https://code.google.com/p/dart/issues/detail?id=9401
  

 But a recent bug report showed that this wouldn't help much because the analyzer already infers a type from the above expression (the least common denominator - which doesn't help much either). So type annotation everywhere is the only answer to allow the analyzer to be helpful.

[kc]

On Monday, June 9, 2014 2:29:05 PM UTC+1, Ladislav Thon wrote:

Does it? Last time I checked, it was a convention in the Dart land to avoid annotations on locals, just like in languages with local inference (Scala, Kotlin, Swift?).

Well yes. Even the examples on the dartlang.org front page have annotations on locals. See 'Testing':

  Point a = new Point(2, 15);

  Point b = new Point(7, 3);

The jobbing Java dev will read this and add 'final' for the trifecta.

In the Java/C# world the developer has to get past the compiler in order to generate byte code. And static types can offer performance optimizations.

Whereas the Dart deal is - no byte code, everything is an object. Feel free to ignore warnings if needs be. Because type annotations are just annotations. Even roll your own analyser. Nice. (Though I like Swift syntax in some ways the move away from the dynamism of Objective C is a negative).

This, IMHO, strikes the best balance -- types makes a lot of sense on API boundary, not that much inside the implementation.

Totally agree. But convention needs to be backed up by syntax.

And a great convention is that bindings for function parameters and the for-loop index should be immutable. Swift get this succinctly right. Dart - use final.

K.

[Alex Tatumizer]

The problem of "final", other than the word is too long, is that it has some implicit exclamation mark attached to it (like someone saying: watch out, this thing is final!). It draws too much attention, which is not deserved because most of the things we declare are "final".

That's where syntax interferes with semantics. Syntax is never syntax only - it carries some (implicit or explicit) meaning.

Plus, the problem of style. I think Kotlin chose "fun" instead of "func" because now all 3 declarations (var, val and fun) are 3-letter keywords. They "rhyme" better.

>> Also, I've seen that you still work on Circuit. That's admirable. Never give up, never surrender!

Yeah, Circuit turned to be a hard sell. Maybe it's too unfamiliar. Or it's too circular for angular world.
Or perhaps I'm just not a good salesman.

Anyway, glad to see you back!

[Filipe Morgado]

On Monday, 9 June 2014 16:49:44 UTC+1, Alex Tatumizer wrote:

The problem of "final", other than the word is too long, is that it has some implicit exclamation mark attached to it (like someone saying: watch out, this thing is final!). It draws too much attention, which is not deserved because most of the things we declare are "final".

I like that "attention". When in Scala, I very often mistake "val" for "var" (or vice-versa). "Final" makes it more explicit.

Coming from AS3, I like the "var point:Point" syntax, rather than C-style.

There will always be diverging opinions on every detail.

I agree with a few comments upwards ... In the end, these details don't matter. I'm not less productive because of them.

[Sean Eagan]

On Sat, Jun 7, 2014 at 6:07 PM, Greg Lowe <gr...@vis.net.nz> wrote:

> mandatory "new"

There's a bug for optional new/const:

https://code.google.com/p/dart/issues/detail?id=18241

Note that terseness is one aspect of http://dartbug.com/18241, but the more important aspect is making "const" much more usable by:

* allowing for const methods, operators, and properties (other than those explitily defined in the language spec)

* determining constness at callsites instead of declaration sites, which for example would allow const constructors to call other const constructors, which is currently not possible.

I've heard one complication for making new optional is it's required in the grammar so that you can add generic type parameters to constructor calls.

Assume the call in question is `Foo<int>()`.  If `Foo` represents...

A constructor: Then clearly it's a constructor call, no need for new/const.

Something other than a constructor (e.g. a method): compile error.  

Invalid identifier: compile warning / runtime error.

And since the naming convention for classes (UpperCamelCase) differs from that of everything else (lowerCamelCase) in dart, it's generally easy for humans to discern that `Foo` is a class, and thus that `Foo()` is a constructor call without new/const as well, even without the aid of semantic highlighting in an editor.

But if generic functions are added this problem would go away I guess.

https://code.google.com/p/dart/issues/detail?id=254

http://dartbug.com/18241 should make generic functions *slightly* less necessary, since you no longer would want to create top-level generic methods which merely redirect to constructors just to avoid the tax of `new ` at call sites.

On Sun, Jun 8, 2014 at 7:39 AM, Alex Tatumizer <tatu...@gmail.com> wrote:

I think most of archaic features in dart stem from "familiarity" principle. Other languages moved on, Now declaration syntax, mandatory "breaks" in switch statement, mandatory "new" already look slightly outdated. 

But things don't stop here. Probably same principle of "familiarity" (the meaning of which is a subject of speculation) dictated the preference for declarative frameworks like angular - weird, amateurish attempt to enhance HTML by building a clumsy programming language on top of it. Is this a right way to showcase dart? If dart is not good enough to formulate API for UI programming, then what's the point of the language? Angular+javascript is not much different from angular+dart anyway, it's still the same cake, why would anyone want to switch?

Naturally, polymer follows in footsteps of angular, trying to define yet another language. And to those curious when to use which, the advice is to use BOTH (!). Plus dart, compiled to javascript.

This angular thing is something that disappoints me much more than slightly outdated syntax.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

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

[Alex Tatumizer]

My point was that "var" deserves implicit exclamation mark (and attention) much more.

[kc]

On Monday, June 9, 2014 5:04:21 PM UTC+1, Filipe Morgado wrote:

On Monday, 9 June 2014 16:49:44 UTC+1, Alex Tatumizer wrote:

The problem of "final", other than the word is too long, is that it has some implicit exclamation mark attached to it (like someone saying: watch out, this thing is final!). It draws too much attention, which is not deserved because most of the things we declare are "final".

I like that "attention". When in Scala, I very often mistake "val" for "var" (or vice-versa). "Final" makes it more explicit.

Coming from AS3, I like the "var point:Point" syntax, rather than C-style.

There will always be diverging opinions on every detail.

Swift seemed to get it right:

var x = 1; // mutable
let y = 2; // immutable
var x:int; // mutable with annotation because no initializer

 

I agree with a few comments upwards ... In the end, these details don't matter. I'm not less productive because of them.

Early adopters have made a platform bet. But the bet could be better if the syntax was more immediately appealing. To give Dart a wider audience and more adoption.

K.

 

[kc]

On Friday, June 6, 2014 8:09:58 AM UTC+1, Sebastien Deleuze wrote:

Linked topic : please vote (star) this issue if you are interested in building Android native apps with Dart : http://dartbug.com/19266

Imo the best Google strategy would be a 'new' language with a good async/immutable story which compiles down to both JS and ART/Dalvik (Google's take on Java). This would cover Chrome/OS and Android.

Ultimately this 'new' language would eventually have it's own runtime geared to modern multi-core cpu/gpu hardware. And the runtime could be used both within the browser with JIT and for native apps with a bit more static AOT.

Dart has a new runtime but the Android side of things seems unclear. 

K.