Re: Proposal: In "checked" mode compiler MUST compile all code paths and analyze code statically.

[Gen]

I think you refer to this https://groups.google.com/a/dartlang.org/d/msg/misc/Nhk-w9RCIhQ/34znBgtifO4J

This seems stupid to me as well.
But maybe I miss some Dart details.

Regarding your proposal, I trust the Dart team to chose the most efficient way:
- to offer performance
- to offer the benefits of static types
- to offer useful tools

 
Am Samstag, 18. Mai 2013 08:15:25 UTC schrieb mezoni:

If all this already done then I can say that current compiler is "stupid".

And I have nothing to add to this.

[Gen]

PS.
Every project has personal and financial constraints.
Even those supported by Google.

[Ladislav Thon]

> I think that dart analyzer is not redundant but it MUST be just an useful tool that may be used in some situations.

Why?

> But compilers MUST have a very well organized static analyzer implementation inside itself.

Why?

> Compiler MUST have ability run it as good code analyzer.

Why?

> Compiler MUST NOT require from programmers to have any external tool for code analyzing and writing errorless code.

Why?

If the distinction between the 'dart' executable and 'dartanalyzer' executable is so troubling for you, just write yourself a tiny wrapper.

LT

[Gen]

There is a misunderstanding.
I am on your side.
I agree with you.
I do not understand eithere why initializing a final variable in a constructor should be an error.

Am Samstag, 18. Mai 2013 09:51:53 UTC schrieb mezoni:

>> This seems stupid to me as well.

You may say a little more to prove your words.

In addition of just to praise Dart team.

There I wrote why I have an opinion and I substantiate my words.

You remind me a fanatic.

I may say that I rude but I'm telling the truth.

Need recognition of the weak force of the developers?

I could give links to posts but I do not want to do that for fanatics.

The weak force does not excuse the poor quality of development process.

But you do not understand them. You will pray.

And you shall cry, "Glory and praise to the development team".

"Glory and praise that was bad before but now it is better. And we believe that one day will be fine. Maybe even after a few generations.".

[Gen]

Good performance, static types and good tools is what you and most other Dart programmers want.
The Dart team wants to have it too.
I meant that if we do not have that stuff already, then because the Dart team has constraints which we do not know about.

Regarding static types:
There is no general opinion. Make your own.
I will not discuss the merits of static or dynamic typing.

Regarding tools:
Yes. A language should be useful without tools.
But whatever programming language, tools can help.

Am Samstag, 18. Mai 2013 10:04:16 UTC schrieb mezoni:

>> Regarding your proposal, I trust the Dart team to chose the most efficient way:
>> - to offer performance

This proposal does not affect performance. If you can read in English.

In Development (diagnostic) mode performance of how fastly VM execute first un-optimized line of your code is not critical.

>> - to offer the benefits of static types

It would be better and more help from your praises than to show your mind.

What you want to argue by this "benefits of static types"?

I don't understand.

Or may be you think my proposal cancels and degrades them?

Learn English or read carefully.

>>- to offer useful tools

Come and praise for everything.

Useful tools just useful tools.

It not improve language itself.

Implementation of the language can not rely on useful tools.

The language is totally dependent on the its implementator (compilator).

[kc]

On Saturday, May 18, 2013 8:51:22 AM UTC+1, mezoni wrote:

Proposal: In "checked" mode compiler MUST compile all code paths and analyze code statically.

Like static compiler C#.

I think the Dart designers - both VM and language - Lars B. and Gilad B. - come from a OO background - Smalltalk/Strongtalk.

Not so much a functional type flow/inference background. And for them typing is actually a tool time thing via pluggable types.

I think we will have to accept this.

But regarding 'pluggable types'. I think it would be clearer for the language to settle on one type system even if only for the analyser/editor. 

Most user's wont be plugging in types systems.

K.

[Gen]

I do not think that Dart will be at the front of progress.
Dart will have:
- what is created by enthusiastic programmers.
- what is already proven and mainstream. The stand regarding keywords and being like Java is telling enough.
The Eclipse editor, like a bare bone Java editor, is telling enough as well.
There is a reason why Gilad is still dreaming and working for Newspeak.

[Ladislav Thon]

> Why Dart VM always compile code only lazy?

It's not always, it's by default. You can switch it off.

LT

[Ladislav Thon]

>> It's not always, it's by default. You can switch it off.

I cannot find appropriate option

I'd swear that there used to be a flag, but you're right, you can't opt out. Sorry.

LT

[Bob Nystrom]

On Sat, May 18, 2013 at 12:51 PM, mezoni <andrew...@gmail.com> wrote:

"Proposal: In "checked" mode compiler MUST compile all code paths and analyze code statically."

In short words this is equal: "Proposal: Add compiler option "compile_all".

Or "early_compilation" or "static_compilation".

I think you are confusing two separate concepts:

In checked mode, the VM does dynamic type checks, at runtime.

The analyzer does static type analysis.

These two modes are separate in Dart. Each generates errors that the other does not. For example, this program has a dynamic error, but no static errors:

main() {

  var a = "not int";

  int b = a;

}

Conversely, this program has a static error but no dynamic errors:

class Foo {

  void bar(); // abstract method in non-abstract class

}

main() {

  var foo = new Foo();

}

The VM does not implement any static warnings. That's not its job. Even if the VM compiled all methods, it still would not give you the warnings you seek. If you want to see all of the static warnings for your program, use the analyzer. That's what it's for.

It would be possible to have a way to run a Dart program that would automatically run the analyzer on it first. I know some people on the team have talked about that, but I don't know if there's any plans in this direction. Personally, I'd love to be able to do:

  $ dart --analyze myapp.dart

And have it run the analyzer first and bail if there are warnings.

Cheers!

- bob

[Vyacheslav Egorov]

> Dart VM forked from V8.

Dart VM does not share any code with V8 (except bits of the disassembler for x64).

 

// Vyacheslav Egorov

On Mon, May 20, 2013 at 7:31 PM, mezoni <andrew...@gmail.com> wrote:

Microsoft® “Roslyn” CTP

Traditionally, compilers are black boxes – source code goes in one end and object files or assemblies come out the other end. The Roslyn project changes that model by opening up the Visual Basic and C# compilers as APIs.  These APIs allow tools and end-users to share in the wealth of information the compilers have about code. The Roslyn CTP previews the next generation of language object models for code generation, analysis, and refactoring, and the upcoming support for scripting and interactive use of VB and C#.

What innovations we have in Dart?

No, apart from the fact that this is a new Javascript.

Is there is Dart next generation of language object models for code generation, analysis, and refactoring?

Or may be be javascript is not good as web assembler?

I think that Microsoft does not think so.

Javascript can be adapted for almost anything.

Typescript not really cuts out the unused parts of the code as it does Dart2JS.

They have other trump cards in hand.

First of all, they work on the language.

Dart VM forked from V8.

Dart was anonced in 2011 but I don't know when it will be started in reality (in 2010?).

Dart VM is still not brought to mind. Echoes of Javascript VM?

New syntax and object orientation this is good but it does not pull on next generation of language.

Maybe Google do not have the strength?

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

[Vyacheslav Egorov]

> Or maybe I'm wrong and the Dart VM is superior than hydrogen + lithium?

This sentence has no meaning because you are comparing apple and oranges: one virtual machine to two intermediate representations. 

I think you are misunderstanding how VM's optimizing compiler operates: you seem to assume that it has a statical type checking / global type inference built in, but that is not the case. Optimizing compiler cares more about observed types of values then about their interface types that define type compatibility per specification. Precise global type inference is expensive and impractical for the JIT compiler. Additionally global type checking will not even provide information that optimizer needs to produce efficient code. 

Thus there is no reason to include something like that directly into the VM.

Dart Analyzer exists and is perfectly fine as an external entity, when it matures it should catch all "mistyping" issues.

This is all perfectly aligned with Dart philosophy and Dart semantics: it's a *dynamic* language with tooling driven via type annotations. You might disagree with this philosophy, but for better or worse Dart is sticking with it.

PS. Also, Andrew, when you send multiple emails to the same thread one after another you make it very hard to follow your thought. Consider waiting a little before sending and put all your thoughts that come into a single mail.

// Vyacheslav Egorov

On Mon, May 20, 2013 at 9:15 PM, mezoni <andrew...@gmail.com> wrote:

Dart2JS is really excellent work.

But Dart VM is not so good.

Or maybe I'm wrong and the Dart VM is superior than hydrogen + lithium?

[Justin Fagnani]

On Mon, May 20, 2013 at 2:03 PM, mezoni <andrew...@gmail.com> wrote:

>> I think you are misunderstanding how VM's optimizing compiler operates: you seem to assume that it has a statical type checking

I think as described here v8: a tale of two compilers

Here your name referred...

I know how JIT works.

But Dart Editor analyzer works bad...

And compiler cannot...

>> PS. Also, Andrew, when you send multiple emails to the same thread one after another you make it very hard to follow your thought. Consider waiting a little before sending and put all your thoughts that come into a single mail.

Thoughts come and go. It is impossible. I'm sorry.

You're the only one who continually responds to himself on this list, so I don't believe it's impossible to change that behavior.

[James Ots]

>> PS. Also, Andrew, when you send multiple emails to the same thread one after another you make it very hard to follow your thought. Consider waiting a little before sending and put all your thoughts that come into a single mail.

Thoughts come and go. It is impossible. I'm sorry.

Emailing your thoughts to everyone on this list probably isn't the best way to go about remembering things. You could try writing your thoughts down somewhere else, such as in a Google Doc, if you're worried about forgetting them. Or use something like Google Keep, or Evernote.

When you've thought things through properly, and have something the list might want to hear, then send the email.

James Ots

[kc]

On Monday, May 20, 2013 5:26:54 PM UTC+1, Bob Nystrom wrote:

In checked mode, the VM does dynamic type checks, at runtime.

The analyzer does static type analysis.

These two modes are separate in Dart. Each generates errors that the other does not. For example, this program has a dynamic error, but no static errors:

main() {

  var a = "not int";

  int b = a;

}

I fully get this - and have no complaints about static type analysis being done at tool time.

It's just that the C style type notation - int b = a; - encourages users to think otherwise.

The notation looks so incredibly static. And hides the true dynamic OO nature of Dart.

And will lead to over-annotation by the 'masses'.

var b:int // a more natural fit for Dart - looks more annotation-ish. But the language is baked.

K.

[Ladislav Thon]

var b:int

Could someone please explain why this is supposed to look more "dynamic"? There is a ton of statically-typed languages using this exact syntax, from Pascal or Ada to Scala or Kotlin.

LT

[Gen]

I prefer least typing and reading effort.
I do not see either how:

var b:int

is an improvement over:

var b;
int b;

And what is the deal with "var" and "int" ?
If some does not need anything else than "int" than I would advice to write "int" and not "var".
Besides, most programmers will use "var" soon enough if required.
I am not all too concerned about someone writing more restrictive and concrete code than less restrictive and more vague code.
Types are one of the main reasons why I consider Dart as a replacement for Ecmascript.

[kc]

On Tuesday, May 21, 2013 9:59:03 AM UTC+1, Ladislav Thon wrote:

var b:int

Could someone please explain why this is supposed to look more "dynamic"? There is a ton of statically-typed languages using this exact syntax, from Pascal or Ada to Scala or Kotlin.

Because this syntax encourages type notations on public api's and type inference for locals.

Stops over-annotation on locals. 

The C syntax encourages over annotation - especially by the Javatards.

myfunction(a = 0, b:int) { a typed to int via initalizer, b typed to int

     val x = 0; // immutable binding to int

     var x = 1; // mutable binding to int

     var x:int; // type annotation on a local - because no initialiser

}

But - the language is done. And so am I.

K.

[Ladislav Thon]

var b:int

Could someone please explain why this is supposed to look more "dynamic"? There is a ton of statically-typed languages using this exact syntax, from Pascal or Ada to Scala or Kotlin.

Because this syntax encourages type notations on public api's and type inference for locals.

Does it? How exactly?

The C syntax encourages over annotation

Does it? How exactly?

LT

[kc]

On Tuesday, May 21, 2013 11:07:36 AM UTC+1, Ladislav Thon wrote:

Does it? How exactly?

The type syntax looks so C like - like static allocations. 

Javatards will think 'var' is a duck type and they are getting some performance benefit from explicit type annotations:

var x = 1;

to:

int i = 1;

And even my favourite:

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

And I will have to read this rubbish - if the DartVM becomes a player on Chrome/Android.

Hey - I'm done.

K. 

[jim.trainor.kanata]

So this is your final point?

K.

[kc]

On Tuesday, May 21, 2013 11:48:01 AM UTC+1, Jim Trainor wrote:

So this is your final point?

Yes - haha!

And the point wasn't even new.

K.

[Peter Ahé]

dart2js has an option called --analyze-all. Is that what you're looking for?

Cheers,

Peter

On Saturday, May 18, 2013, mezoni wrote:

Proposal: In "checked" mode compiler MUST compile all code paths and analyze code statically.

Like static compiler C#.

[Zoran Tkavc]

I like dart. It's nice language with new non fragmented ecosystem.,
I believe that one of the most important thing is VM speed. Darts
speed will be close to Java and C#.
I wonder how many years will take ECMA to release ECMAScript 8(!) with
SIMD to be available in JavaScript or TypeScript?
So, if dart succeeds at least we will have another much speedier VM
soon as target for your favorite language with your favorite
syntax ;-)

Zoran

[Justin Fagnani]

On Tue, May 21, 2013 at 3:30 AM, kc <kevin...@gmail.com> wrote:

On Tuesday, May 21, 2013 11:07:36 AM UTC+1, Ladislav Thon wrote:

Does it? How exactly?

The type syntax looks so C like - like static allocations. 

Javatards

Please do not use this terminology on the list. We have members from all kinds of language backgrounds and there's absolutely no reason to be rude and insulting.

Thanks,

  Justin

 

will think 'var' is a duck type and they are getting some performance benefit from explicit type annotations:

var x = 1;

to:

int i = 1;

And even my favourite:

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

And I will have to read this rubbish - if the DartVM becomes a player on Chrome/Android.

Hey - I'm done.

K. 

--

[Gen]

I do not think that kc was aware of the insulting connotation of -tard.

[kc]

On Tuesday, May 21, 2013 5:51:04 PM UTC+1, Justin Fagnani wrote:

On Tue, May 21, 2013 at 3:30 AM, kc <kevin...@gmail.com> wrote:

On Tuesday, May 21, 2013 11:07:36 AM UTC+1, Ladislav Thon wrote:

Does it? How exactly?

The type syntax looks so C like - like static allocations. 

Javatards

Please do not use this terminology on the list. We have members from all kinds of language backgrounds and there's absolutely no reason to be rude and insulting.

Thanks,

  Justin

Apologies for that suffix - definitely did not mean to insult the learning disabled.

On the other hand Java programmers.  Are they such a limited bunch that they need familiar excessive Java boilerplate in order to adopt a new language. That's pretty insulting.

K.

[Ladislav Thon]

Does it? How exactly?

The type syntax looks so C like - like static allocations. 

Javatards

Please do not use this terminology on the list. We have members from all kinds of language backgrounds and there's absolutely no reason to be rude and insulting.

Apologies for that suffix - definitely did not mean to insult the learning disabled.

On the other hand Java programmers.  Are they such a limited bunch that they need familiar excessive Java boilerplate in order to adopt a new language. That's pretty insulting.

I have a really hard time restraining from writing a bunch of strong words here. Let me just say that there is a LOT of brilliant Java programmers and they don't really deserve your treatment. Can we just speak to the point?

(Which, by the way, is moot. C++, Java, C# and a bunch of other languages are using the same syntax [mostly] without even thinking of static allocations. And on the other hand, a lot of other languages, like Pascal or Ada, use your syntax together with static allocations. This argument makes very little sense to me.)

LT

[kc]

On Tuesday, May 21, 2013 7:33:37 PM UTC+1, Ladislav Thon wrote:

Does it? How exactly?

The type syntax looks so C like - like static allocations. 

Javatards

Please do not use this terminology on the list. We have members from all kinds of language backgrounds and there's absolutely no reason to be rude and insulting.

Apologies for that suffix - definitely did not mean to insult the learning disabled.

On the other hand Java programmers.  Are they such a limited bunch that they need familiar excessive Java boilerplate in order to adopt a new language. That's pretty insulting.

I have a really hard time restraining from writing a bunch of strong words here. Let me just say that there is a LOT of brilliant Java programmers and they don't really deserve your treatment. Can we just speak to the point?

Look I was once a Java programmer myself. Java Cert Dev 1997. Done *lots* of server side development. Grew to hate the language.

 

Now strong words for you. The world does not need another server side language that looks like Java. 

The focus has to be on mobile and touch. Getting the fast VM into the browser - the oilpan project looks interesting.

IMO The Java syntax will be a net negative. You and the Dart team obviously disagree. Fair enough.

K.

[Bob Nystrom]

On Tue, May 21, 2013 at 11:43 AM, kc <kevin...@gmail.com> wrote:

The focus has to be on mobile and touch. Getting the fast VM into the browser - the oilpan project looks interesting.

We are super excited about oilpan.

 

IMO The Java syntax will be a net negative. You and the Dart team obviously disagree. Fair enough.

No syntax will please all users, unfortunately. I do think it's important to discuss syntax issues because usability is a key facet of a language, and syntax is the user interface. But it's a better use of all of our time if we focus that attention on things that are open to change, or where we have new data that hasn't been considered, or where we have empirical data to back up our assertions.

For corners of the language that are baked and are in wide use, the barrier to change is very high. Even if it's clearly a change for the better, it doesn't have to just be better, it has to be so much better that it justifies the transition cost.

Cheers,

- bob

[Gen]

I agree with Mezoni that static analysis is very useful. I am confident that we will have better tools quite soon.

I agree with you that Dart looks like Java at first glance.
But at second sight, Dart programming is quite different.
I have read this morning this comment (http://lambda-the-ultimate.org/node/4612#comment-75356) where he refuses Dart because a different Timer object is used.
Dart has drifted quite a lot from the Java and Javascript/Typescript islands.
All the more surprising that the Dart team wants to keep "new" just for familiarity.

You would have to leave the C family for Haskell or projects like Elm to have something really different.
Dart is meant as part of the C family. Critisizing Dart for that is rather unfair.

[kc]

On Tuesday, May 21, 2013 8:42:45 PM UTC+1, Bob Nystrom wrote:

No syntax will please all users, unfortunately. I do think it's important to discuss syntax issues because usability is a key facet of a language, and syntax is the user interface. But it's a better use of all of our time if we focus that attention on things that are open to change, or where we have new data that hasn't been considered, or where we have empirical data to back up our assertions.

I wonder what empirical data was used re Java syntax.

OK - time to let it go!

But...

This is great - the OO operator overloading shines:

val v = Vector(1,2,3) + Vector(2,3,4);

This not so much:

final Vector v = (new Vector(1,2,3)) + (new Vector(2,3,4));

K.

 

[kc]

On Tuesday, May 21, 2013 8:44:27 PM UTC+1, Gen wrote:

Dart has drifted quite a lot from the Java and Javascript/Typescript islands.
All the more surprising that the Dart team wants to keep "new" just for familiarity.

You would have to leave the C family for Haskell or projects like Elm to have something really different.
Dart is meant as part of the C family. Critisizing Dart for that is rather unfair.

It's not the core C syntax I object to. This is fine:

if (expression) { doSomething(); }

I prefer parens around the 'expression' and semi-colon at then end of statements.

It's the Java boilerplate:

new / final / type notation

And that Dart - while within the core C syntax - could have been a little more adventurous syntax wise. Promise pipelines? Yes please.

K. 

[Bob Nystrom]

On Tue, May 21, 2013 at 1:34 PM, kc <kevin...@gmail.com> wrote:

This is great - the OO operator overloading shines:

val v = Vector(1,2,3) + Vector(2,3,4);

This not so much:

final Vector v = (new Vector(1,2,3)) + (new Vector(2,3,4));

You can just do what I do:

Vector vec(x, y, z) => new Vector(x, y, z);

I don't do this for all types, but for some it's worth it. Then you get:

var v = vec(1, 2, 3) + vec(2, 3, 4);

- bob

[Gen]

Of course we can.
And nobody would complain about not having to write "new" or "final" explicitly :-)

[Gen]

But it is not you we have to convince.

[Alex Tatumizer]

@Bob: that's exactly the point! In attempt to establish uniformity of object creation, language motivates programmer to introduce shortcuts.
Some will call it "vec", some - "vector", or "v", or "w"... And there was argument about grep? Grepping this would be difficult indeed :-)

[kc]

Bob - that's great! 

I should have realised this would work given the true dynamic OO nature of Dart.

Is this in the style guide?

For lightweight objects - without side effects - consider a function wrapper for ease of use. Sweet.

K.

 

[Gen]

Are you serious ?
All that post writing and you are happy with this ?

[kc]

On Tuesday, May 21, 2013 10:27:58 PM UTC+1, Gen wrote:

Are you serious ?
All that post writing and you are happy with this ?

Short and sweet. Declarative. Given that the language is not going to change I'll give credit where credits due.

Gen - what are you looking for? Seriously?

K. 

[kc]

On Tuesday, May 21, 2013 10:12:57 PM UTC+1, Alex Tatumizer wrote:

@Bob: that's exactly the point! In attempt to establish uniformity of object creation, language motivates programmer to introduce shortcuts.
Some will call it "vec", some - "vector", or "v", or "w"... And there was argument about grep? Grepping this would be difficult indeed :-)

It will be interesting to see if library authors in their public api's for lightweight objects with operators adopt the workaround. 

For instance an imperial measurement library could expose functions that enable:

var distance = miles(30) + yards(4) + feet(4);

as an alternative to:

var distance = new Miles(30) + new Yards(4) + new Feet(4);

The fact that this workaround gem was hidden was possibly due to my brain being addled by years of Java.

And Dart's superficial Java-esque nature. The typing misleads.

K.

[Gen]

Ok.
To quote you, I am done with it.

[kc]

On Tuesday, May 21, 2013 10:39:40 PM UTC+1, Gen wrote:

Ok.
To quote you, I am done with it.

Actually I think you should explain yourself. I have never truly understood where you are coming from - what you are after.

Me - I hate Java boilerplate - and feel that it distorts the true nature of the DartVM - it's pure dynamic OO vision.

You - I don't know.

K. 

[Alex Tatumizer]

Why the gem was hidden? I used it all along. That's what I was complaining about. It could be easily possible in java, too - introduce static method "vec".
All problems can be solved by the same template.
E.g. Elvis operator. You don't need it, just write
var a= _try(()=> a.b.c.d);
and define _try so that it catches null pointer. Sweet? :-)

Please tell me what other problems you have :-)

[kc]

Yeah - doh!  

But there's no operator overloading in Java. Or there wasn't last time I checked.

K.

[Gen]

I see that my efforts failed hard.
I want to get rid of writing (IMO) useless keywords.

What does it matter from where I come ?
I do not want to modify Dart just to be like or different from another language.

[Alex Tatumizer]

Let's leave it for language designers now. We made the argument. "new" is logically not necessary in dart, everybody understands this, but there can be factors beyond pure logic.

--

[kc]

On Tuesday, May 21, 2013 10:57:22 PM UTC+1, Gen wrote:

I see that my efforts failed hard.
I want to get rid of writing (IMO) useless keywords.

I sympathise. There's still going to be lots of 'new new etc' . But it seems the language is done core syntax wise. 

 

I do not want to modify Dart just to be like or different from another language.

I agree. Ideally Dart would have a syntax which matches it's semantics - succinctly and simply.

K.

[jim.trainor.kanata]

What's the "new new etc' pattern?

kc wrote:

[Alex Tatumizer]

> But there's no operator overloading in Java. Or there wasn't last time I checked.

Hm... interesting "theoretical" question :-)
I think it's possible to implement it monadic-style in java.
Your vec(a,b,c) can return int (for which everything is defined).
Suppose for simplicity, we are interested in supporting just two operations: + and * . So you add and multiply your vecs and then call compute(int) for int value representing entire expression.
The question is: how to define vec() so that it returns int, and then however it's added with other vec() values, it's possible to reconstruct what was added to what and what was multiplies by what. I think it's possible. (E.g., Godel used numbers to represent any set of integers as products of primes: e.g. if you have set (3, 4, 6), you can represent it as a single number p3*p4*p6 =  5*7*13 - where pN is N-th prime, and went on to represent more difficult things by similar method).

Probably, it's possible to find encoding that represents sum and product such that it can be decoded uniquely. (This has no practical use, just a fun question. I don't know whether there's a known solution, need to google). If somebody knows - please telegraph :-)

 

[kc]

On Tuesday, May 21, 2013 11:18:22 PM UTC+1, Jim Trainor wrote:

What's the "new new etc' pattern?

Just meant there is still going to be still going to be lots of 'new' boilerplate scattered throughout Dart code. And maybe the 'factory' keyword will encourage 'new' usage.

Will check out Dart again when hopefully the DartVM gets the go ahead for inclusion in Chrome.

K.

[Zdeslav Vojkovic]

On Tue, May 21, 2013 at 9:42 PM, Bob Nystrom <rnys...@google.com> wrote:

 

IMO The Java syntax will be a net negative. You and the Dart team obviously disagree. Fair enough.

No syntax will please all users, unfortunately. I do think it's important to discuss syntax issues because usability is a key facet of a language, and syntax is the user interface.

I am glad that you think so. After doing c++ and c# for years I have moved to Python. It felt so elegant that I wanted to do everything in Python, even the things which didn't make sense at all :)  This is exactly what Dart should provide to people who switch to Dart. Going from Python to Dart is painful - you need to type a lot of boilerplate for some common tasks. I don't advocate making Dart into Python, neither I care about details like new/val, but I don't see that kind of elegance or expressiveness. I see some other niceties which did attract me to Dart, but I also see too many of comments like 'we did it to make Dart more familiar to C#/Java devs' - C# and Java devs are in general smart people and they will easily switch to something better. after all, many of them switched from C++ or VB.

static checks in Dart are also very C#/Java-ish and sometimes too constraining  - one area where C++ beats both the languages is that templates (once you forget the syntax :) give you statically checked duck typing, with no need to declare a bunch interfaces - this is a killer feature rarely seen in mainstream languages.
 

For corners of the language that are baked and are in wide use, the barrier to change is very high.

I would argue that there are no corners of languages which are really in wide use. Dart is still in very early phase of adoption which can be witnessed by the number of questions on stackoverflow, which is < 5% of Node, or 1/3 of coffeescript. so now is the best time to change things, surely better than later.

for sure, many issues have workaround in form of helper functions and classes, but this will result in every developer having his own set of tools, instead of one common set, and this is bad - for the same reason that having each C++ shop defining their own set of safe features is bad - both for the devs and for language.

[jim.trainor.kanata]

About usability: the packaging system, analyzer, compilers, vm checked mode execution, etc (the "tooling") all have a bigger impact on usability than minor details of the syntax.  This is where Dart separates itself from the pack and where it will succeed or fail.  All of those items have a bigger impact on the success of a large project than do the minor details of the syntax.  Dart simply doesn't have to differentiate on syntax to accomplish its goals IMO.  Minor details of syntax don't have an impact on one's ability to engineer a large project with Dart. That ability to engineer a large project is Dart's mission IMO and where it has to push the boundaries to be different. Not language syntax!

[Gen]

Syntax and the related semantics are key facets of a language.

The packaging system, analyzer, compilers, vm checked mode execution are not a (required) part of a language definition.

Only static types are a link between language and tools to enable static source code analysis in contrast to runtime or live programming (debugging) and TDD.

[Zdeslav Vojkovic]

"Tooling has a bigger impact on usability than minor details of the syntax."

I agree with this 100% - that's why I didn't talk about minor details of the syntax - actually, quite opposite, I noted that I don't really care about details like 'new/final'.
E.g. I find CoffeeScript to be more expressive and readable than Dart, but I still prefer Dart, less due to tooling, more due to stuff like isolates, futures and streams.

If you come from Java and need to pick between JS and Dart, then it is clear - tooling is superior and coding is not more painful than in Java.

If you come from Python or a similar language, then it is quite different, and no amount of tooling will save you from frustration.
Fortunately, all the things I miss (tuples, list comprehensions, decorators, simple C#-like event declaration/consuming, ...) can be added later on, so I have high hopes.

nobody picks a language because he will be able to run an analyzer/compiler - if that was the case, C# in browser would make more sense. developers are typically not excited with having a chance to run a command line tool.
you pick a language because you can express a lot of stuff with as little code as possible while keeping it readable/obvious. Otherwise C++ and C would still rule as it is hard to beat their optimizing compilers, code checkers, etc.

I like Dart, but there are rough points (normal for pre 1.0 tech). I am only wondering how much of that stuff will remain there forever, because 'we can't break it now'

--

[jim.trainor.kanata]

That's my experience exactly with Python. And the reason why I've seen it rejected numerous times for large projects, and why I would reject it myself despite using it frequently for small projects. Javascript is similar - except that it couldn't be rejected so easily, until recently, for lack of alternatives.

p.s. Of course, I should have included "sdk" in my list of thing more important than minor syntax issues.

[Gen]

It might seem as if I was splitting hairs.

But we have C style tools and libraries because we have a C style language (syntax, semantics).

As intended by the Dart team.

Syntax and semantics is the foundation. Everything else adapts accordingly.

[kc]

On Wednesday, May 22, 2013 9:43:35 AM UTC+1, Zdeslav Vojkovic wrote:

On Tue, May 21, 2013 at 9:42 PM, Bob Nystrom <rnys...@google.com> wrote:

 

IMO The Java syntax will be a net negative. You and the Dart team obviously disagree. Fair enough.

No syntax will please all users, unfortunately. I do think it's important to discuss syntax issues because usability is a key facet of a language, and syntax is the user interface.

but I don't see that kind of elegance or expressiveness. I see some other niceties which did attract me to Dart, but I also see too many of comments like 'we did it to make Dart more familiar to C#/Java devs' - C# and Java devs are in general smart people and they will easily switch to something better. after all, many of them switched from C++ or VB.

Well said.

Some took my comments as expressing contempt for realworld Java programmers - no.

It's the strawman Java/C# developer that Dart imagine exists I take issue with.

Gen has made the point - when was the survey done re language features. Was a survey/research done validating this idea - fidelity with c#/Java is a core selling point?

Justin F. pointed out the issue with boilerplate - and 'new' here:

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

Gilad B, Bob N agree. So do Gen, LT, Yonggang L. and and many others.

They have taste. But there are lots of developers who lack this taste - I don't think so.

Assume that developers are smart people - who require *some* familiarity - but are really looking for a language with "productively and expressiveness" combined with structure and performance for modern web apps - which can exploit the great hardware that is becoming available.

For corners of the language that are baked and are in wide use, the barrier to change is very high.

I would argue that there are no corners of languages which are really in wide use. Dart is still in very early phase of adoption which can be witnessed by the number of questions on stackoverflow, which is < 5% of Node, or 1/3 of coffeescript. so now is the best time to change things, surely better than later.

Yes. And it must be nightmare keeping the DartVM and dart2js/analyser/editor in sync when the language is in flux.

K.

 

[kc]

On Wednesday, May 22, 2013 10:59:02 AM UTC+1, Jim Trainor wrote:

That's my experience exactly with Python. And the reason why I've seen it rejected numerous times for large projects, and why I would reject it myself despite using it frequently for small projects. Javascript is similar - except that it couldn't be rejected so easily, until recently, for lack of alternatives.

I thing the sweet spot is Python productivity and std libs but without the sheer dynamic runtime nature of Python. That is in Dart classes are - and should be - a declarative statement about the static shape of a program - which can thus be optimised - and give performance. With a succinct, simple regular non-magical syntax which can be tooled - and minified.

K. 

[jim.trainor.kanata]

Survey's take too long. Google set out to leapfrog ES6. To succeed they
needed to move quickly and decisively. Start factoring in too many
opinions, having too many consultations, and Dart would never be
finished. You'd also end up with a vanilla result where every strong
opinion is watered down and factored out in order to find consensus. Far
better to get it down quickly, warts, controversy, and all. A V2.0
release is an opportunity to fold in new thoughts.

[kc]

On Wednesday, May 22, 2013 10:22:14 AM UTC+1, Jim Trainor wrote:

About usability: the packaging system, analyzer, compilers, vm checked mode execution, etc (the "tooling") all have a bigger impact on usability than minor details of the syntax.  This is where Dart separates itself from the pack and where it will succeed or fail.  

But tooling can be like OO patterns - a bit of a crutch for defects in the core language.

K.

[kc]

On Wednesday, May 22, 2013 12:03:26 PM UTC+1, Jim Trainor wrote:

Start factoring in too many
opinions, having too many consultations, and Dart would never be
finished.  You'd also end up with a vanilla result where every strong
opinion is watered down and factored out in order to find consensus. Far
better to get it down quickly, warts, controversy, and all.  

But Dart is kind of vanilla at the moment - because it's trying to find consensus with Java/C#.

 

A V2.0
release is an opportunity to fold in new thoughts.

Fundamentally disagree. Get it right from 1.0. Hit the ground running.

For instance the 'match' feature should be in 1.0.

You get one chance to make a good impression.

K.

 

[Gen]

The fight might be lost but I just can not resist to answer ;-)

A V2.0 release is no opportunity to remove things.

Especially not with the current mindset to keep Dart pre 1.0 as it is; despite having no target users or large amount of 3rd party libraries.

I wish Dart all the best but I do not see how it will convince the conservative masses not to use ES6 or Typescript.

[Zdeslav Vojkovic]

I don't see any problem with not consulting the community.
Great languages/frameworks are not designed by committees, they are designed by one person or a very small number of individuals with good opinions and good taste.

[kc]

On Wednesday, May 22, 2013 12:59:06 PM UTC+1, Zdeslav Vojkovic wrote:

I don't see any problem with not consulting the community.
Great languages/frameworks are not designed by committees, they are designed by one person or a very small number of individuals with good opinions and good taste.

This is true. But it's almost as if Dart has turned off it's tastebuds in order to find an unnecessary 'consensus' with Java/C#.

K.

[Zdeslav Vojkovic]

well, that would be too harsh - it is a decent language, although there are quite a few nice things in C# that Dart doesn't have

as I wrote before, most of the things that I personally miss can be added later, without braking compatibility with older versions, I can live with Dart 1.0 not having them :)

[kc]

On Wednesday, May 22, 2013 1:20:32 PM UTC+1, Zdeslav Vojkovic wrote:

well, that would be too harsh - it is a decent language, although there are quite a few nice things in C# that Dart doesn't have

as I wrote before, most of the things that I personally miss can be added later, without braking compatibility with older versions, I can live with Dart 1.0 not having them :)

Ok - more that Dart thinks it needs a big dose of sugar to go down. But the sugar masks the underlying flavours. 

Adding features after 1.0 could be tricky. C# started off as a Java clone - but woke up to the fact the developers were using JS,Python, Lua, Ruby and also appreciating concepts from functional PL's and Smalltalk. The expected something better. C# then adopted more flexible typing afterwards - and other features - and the c# became a bit big and confused imo.

K.

[Zdeslav Vojkovic]

and there is a good reason why developers use Python or Lua or Ruby. Sure, C# got bigger, but I can't imagine a single competent C# dev which would like to return to time before generics, lambdas, anonymous classes, iterators/yield, Linq (not really a language feature, but it depends on iterators, lambdas, etc), automatic properties, type inference, extension methods and many other post C# 1.0 features.

All these features significantly reduce the amount of code which needs to be written to get the same results.

K.

--

[kc]

On Wednesday, May 22, 2013 1:46:02 PM UTC+1, Zdeslav Vojkovic wrote:

and there is a good reason why developers use Python or Lua or Ruby. Sure, C# got bigger, but I can't imagine a single competent C# dev which would like to return to time before generics, lambdas, anonymous classes, iterators/yield, Linq (not really a language feature, but it depends on iterators, lambdas, etc), automatic properties, type inference, extension methods and many other post C# 1.0 features.

All these features significantly reduce the amount of code which needs to be written to get the same results.

But they feel like bolt ons. Because they are.

Dart's opportunity is to say 'what have we learned from the past 20 years - since JS/Java. What is required for the next 20 years.'

A thoughtful synthesis. If done right Dart it could become the defacto programming language. The language that people learn as their first language.

K.

 

[jim.trainor.kanata]

If done right Dart it could become the defacto programming language. The language that people learn as their first language.

Except, that's not Dart's goal. They just want to be able to engineer bigger, more complex, web apps without the pain of javascript.

Some server side interest as well, I suppose to counter node.js.

[Ladislav Thon]

Dart's opportunity is to say 'what have we learned from the past 20 years - since JS/Java. What is required for the next 20 years.'

A thoughtful synthesis. If done right Dart it could become the defacto programming language. The language that people learn as their first language.

I believe that there is a direct contradiction between language for learning and language for industry. To me, Dart looks like it targets the industry -- which means that it can have larger surface (more features that aren't necessarily orthogonal), but it also needs to be appealing to the Average Joe Programmer. That's why Dart designers chose to use syntax very similar to Java, even though it doesn't carry a lot of Java semantics.

LT

[kc]

On Tuesday, May 21, 2013 8:42:45 PM UTC+1, Bob Nystrom wrote:

On Tue, May 21, 2013 at 11:43 AM, kc <kevin...@gmail.com> wrote:

The focus has to be on mobile and touch. Getting the fast VM into the browser - the oilpan project looks interesting.

We are super excited about oilpan.

Oilpan represents a real opportunity for Dart to become the perfect partner to Chrome and Chrome packaged apps with Web components.

The real selling point of Dart would be when Oilplan is in Chrome there is a demo app with the DartVM which shows outstanding touch and great graphics - on both desktop and mobile. The DartVM should almost 'serve' oilpan - while still compiling to efficient ES and being useful for general programming.

K.

[kc]

On Wednesday, May 22, 2013 2:03:21 PM UTC+1, Jim Trainor wrote:

If done right Dart it could become the defacto programming language. The language that people learn as their first language.

Except, that's not Dart's goal. They just want to be able to engineer bigger, more complex, web apps without the pain of javascript.

Some server side interest as well, I suppose to counter node.js.

Sure not the immediate goal. But Java started off as set top box language. And JS was concocted in two weeks for the mid-nineties web - and look at it now.

K.

[Gen]

I think there is no common agreement of what we have learned the past 20 or 50 years.
Lisp ? C ? Smalltalk ? C++ ? Haskell ? Go ? Newspeak ?
Not to mention many other unknown but interesting other languages.

There is even less concrete agreement what is required for the next 20 years.
Except that C style and shared memory is probably not the future.
In german we say: Totgesagte leben länger.
In english: Those said to be dead live longer ;-)
  
I guess that Dart started out as Javascript with types and less freedom for better performance.
But Dart is already a separate non-mainstream island with its own VM and incompatible library.   

[kc]

That's where we disagree. I don't think the average programer is that average. There's no such thing as the 'masses'.

When I look at a PL I always think - how can I help the user build a clear mental model of how it really works and how to use it. 

And the 'industry'. The languages widely used today weren't designed for industry. They were effectively 'revolutions from below'. Skunk work projects that escaped the lab.

K. 

[Gen]

<< Skunk work projects that escaped the lab.

Could you mention some ?
I think that every major software technology was pushed by large (US) companies while others were either killed or ignored and left to die.
Maybe Lua, Python and Ruby are the exceptions.