var a = someValue...
Here's another tiny data point. The new UX for our API documentation puts return types of methods after the method name. In the original dartdoc, I got a lot of feedback that it was hard to find member names when scanning a list of members if the return type was on the left. Pushing them to the right does help readability in this case.
I think it might also help with syntax for function types?
On Fri, Sep 4, 2015 at 10:01 AM, 'John Messerly' via Dart Misc <mi...@dartlang.org> wrote:On Fri, Sep 4, 2015 at 9:51 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:[...]Here's another tiny data point. The new UX for our API documentation puts return types of methods after the method name. In the original dartdoc, I got a lot of feedback that it was hard to find member names when scanning a list of members if the return type was on the left. Pushing them to the right does help readability in this case.This almost seems like the best reason to do it. Easier to read the method names. (Confession time: I sometimes leave off the return types of methods/functions for readability.)+1. In my C/C++ code, I sometimes do this style for the same reason:Return<Type, Here>someFunction() {...}For me, I think the fact that Flow, Hack, Python's type hints, and Mirah all do this is the really compelling point. It seems like everyone who does optional types for a dynamic language uses this syntax
(except for Typed Scheme, but, you know, they're (a lisp (so they have (their own syntax (space))))).I think it might also help with syntax for function types?And metadata annotations. Or, at least, I thought so at first. But Lasse and others brought up points that those may be tractable even with the current annotation style.Cheers!- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
The biggest problem (aside from migration, which we would absolutely provide automated tooling for) is unfamiliarity. That is a real issue.
Personally and from a completely idealistic point of view I would prefer the postfix syntax. I coded professionally in a language like that (ActionsScript) for a few years and found it very natural, even coming from more of a C/Java background.
However:The biggest problem (aside from migration, which we would absolutely provide automated tooling for) is unfamiliarity. That is a real issue.Now I'm not meaning to say that you diminish the question of migration however I believe this is by far the most important question to consider. It's one thing to convert your own codebase given good tools but will all your dependencies be converted? And if so, will all pub packages have to exist in a 1.x and 2.x version while everybody upgrades? I think Python 3 demonstrates very clearly that even a few libraries hanging on to an older language version can really cause fragmentation because you just don't want to waste time reimplementing library functionality yourself just to get on the 'new' version when the old one works just fine.More generally, are there any examples of languages that are not completely academic or niche making such radical changes post 1.0 without it generally being a disaster?
var improvement = valueOfNewBehavior - valueOfOldBehavior;var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;var worthDoing = improvement - totalMigrationCost;
The same question could of course be raised for any breaking feature in 2.0, this one just seems like the most radical.
Go is a good example of a language that made breaking changes after becoming popular and having it go smoothly. Being judicious is part of that, but gofix is a huge component too.
I totally agree any breaking change is very hard to do well. Here's why I think breaking changes like this are worth doing for Dart:
- Compared to other existing languages, our ecosystem is tiny. The set of things broken by a breaking is quite small. This is one of the rare cases where not being very popular is a real asset. :-/
- Our largest customers today are internal to Google's monolithic repo structure makes it possible to land sweeping changes atomically.
- The math is sort of like this:
var improvement = valueOfNewBehavior - valueOfOldBehavior;var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;var worthDoing = improvement - totalMigrationCost;Compared to other languages, valueOfOldBehavior is likely lower. numberOfLibraries is certainly much lower. toolability is higher in most cases. Given that, worthDoing skews a lot higher for us than it would in other language ecosystems.
On Fri, Sep 4, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:Go is a good example of a language that made breaking changes after becoming popular and having it go smoothly. Being judicious is part of that, but gofix is a huge component too.I think most of Go's popularity came after 1.0, after they stopped making core language changes. They have a nice tool with "go fix" but the community was pretty tiny at the time; I think Dart is already bigger.
They aren't using "go fix" much anymore.
I totally agree any breaking change is very hard to do well. Here's why I think breaking changes like this are worth doing for Dart:
- Compared to other existing languages, our ecosystem is tiny. The set of things broken by a breaking is quite small. This is one of the rare cases where not being very popular is a real asset. :-/
- Our largest customers today are internal to Google's monolithic repo structure makes it possible to land sweeping changes atomically.
You're assuming more magic than we actually have. We can make big changes in google3 but you never want to try to do it as a single commit if you value your sanity. What if that commit needs to be rolled forward and back multiple times? Best practice is a series of carefully planned migration steps done using small CL's in parallel with opt-in and opt-out phases. Dart is already at the point where making a major change would be fairly painful, and we still have cleanup to do from previous changes.If we had to do it, my recommendation would be a "use dart2" (or equivalent) declaration at the top of each file to enable the new syntax along with complete interoperability with existing code for a few months (realistically) so the community can migrate. (This includes upgrading all the code generators which can't be migrated automatically.)
var improvement = valueOfNewBehavior - valueOfOldBehavior;var totalMigrationCost = (migrationCost - toolability) * numberOfLibraries;var worthDoing = improvement - totalMigrationCost;Compared to other languages, valueOfOldBehavior is likely lower. numberOfLibraries is certainly much lower. toolability is higher in most cases. Given that, worthDoing skews a lot higher for us than it would in other language ecosystems.I analyze this a different way. How bad is Dart's syntax compared to its ideal syntax? If the gap is large then "improvement" can be large. But I don't think we have a situation like Erlang->Elixir or Java->Dart. Dart's syntax is already quite good and easy to pick up, so it's hard for further improvements to move the needle much.
Moving types on the right isn't going to do it. It's certainly a big change, but it's not a big improvement. People aren't going to say "hey, they fixed Dart's syntax so it's much more interesting to me now."
On the cost side, you're leaving out the *perception* of instability. It doesn't matter how much code people have written in Dart. What people are trying to figure out is if they jump in, how much work will they need to do to "keep up" with the language? So a period of stability can be useful.
It seems like we should start out with important features for mobile and see if they can be done without a compatibility break, rather than assuming we need a Dart 2.0?
I expect that extending the language (as with async/await) would be both easier and more useful than redoing core language stuff.My own pet feature is having a good syntax for inline templates for UI component trees. Removing "new" would be a small step in that direction, but I don't think the outsider would recognize Dart as a good language to write UI templates in if we removed "new". Something like JSX seems more promising, since it's more recognizable as a template language and closer to what people expect from a template language.But we don't need a big compatibility break to add that. It's a smaller change than async/await.
Sure, I wouldn't want to scare people off with churn. At the same time, we have been stable for a good while, and it hasn't gotten us masses of users yet. I'm not saying we would have more if we had been less stable, but I do think there's an opportunity to make real changes for the better.
This works both ways. If you can omit type, what difference does it make whether you omitted it on the right or on the left? :-)
int i = 123;
I too would like better notation for building up declarative, structured data. We aren't very DSL friendly.
// Current design
enableFlags({bool bold: false, bool hidden: false}) { // ...}
// 'var x bool' syntax would work
enableFlagsTypesOnRight({bold bool: false, hidden bool: false}) { // ...}
// 'var x : bool' syntax might require some more changes to the language syntax
enableFlagsTypesOnRightFail({bold : bool : false, hidden : bool : false}) { // ...}
enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) { // ...}
enableFlagsTypesOnRight2([bold bool: false, hidden bool: false]) { // ...}
// I would much prefer this
enableFlagsTypesOnRight1({bold bool: false, hidden bool: false}) { // ...}
// Over this..
enableFlagsTypesOnRight1({bold : bool = false, hidden : bool = false}) { // ...}
It enforces the optionally-typed/inferenced nature of a language. With LHS types, we can't exactly add/remove types without making adjustments.
It was mentioned elsewhere that Dart could become a fully-annotated bytecode language (or binary AST, like WASM). I'm all for it and should probably shorten startup times and app sizes. In which case, inference could be made a lot more complex since it would be done AoT. Types could be finally omitted, which isn't exactly the case today. It would't really matter then which side the types are.
With all that said, I could live with "var x : int", my primary concern is that it adds more unfamiliarity than needed for new devs
At the same time, we have been stable for a good while, and it hasn't gotten us masses of users yet
What is wrong with types on the left?Don't we already have a way to explicitly define types if the type is unknown?Type a = someValue;instead ofvar a : Type = someValue;With all that said, I could live with "var x : int", my primary concern is that it adds more unfamiliarity than needed for new devsvar x: int = ... is certainly much more unfamiliar than int x = ...The last time I've seen that kind of syntax was in Pascal / Delphi over 15 years ago, I certainly prefer the C / C++ / Java way of placing the type on the left.Something that it was useful for in the Delphi days was defining large blocks of variables in such a way:vars1, s2, s3, s4, s5: String;k1, k2, k3: int;q: int = 3;With types on the left, you get rid of the var keyword:String s1, s2, s3, s4, s5;int k1, k2, k3=2, q=3;At the same time, we have been stable for a good while, and it hasn't gotten us masses of users yetAt Devoxx Belgium last year, I spoke to many engineers from large companies including several Oracle engineers, a couple of Google engineers, one Amazon engineer, somebody from Microsoft and several software architects. The general concern with many things Google, is how Google make and break stuff and then drop it when they've lost interest in it. Two of the engineers mentioned GWT as an example, Google was pushing GWT heavily, then all of a sudden they handed it over to Vaadin. When I asked about Polymer, the answers were similar, we like the idea, but are skeptical that it will still be around next year.I asked a Google engineer about Polymer and his advice was to be careful where I'm using it as he himself wasn't sure what direction Polymer was going. Amazon, I mentioned Dart, the engineer said they won't touch it due to it being an immature language with immature package base.So in short, it's more a publicity / perception issue than adding a ton of new language features.Keeping things stable and backwards compatible seems to be high on the list of requirements when choosing a language for a new project for many of the companies I've done work for.
function myfunc(i:number, s:string):Point {
var x = i + 2;
let y = s.length;
return new Point(x, y);
}
fun myfunc(i:num, s:string):Point {
var x = i + 2; // mutable binding
let y = s.length; // immutable binding
return Point(x, y); // no new
}
I argued for rhs as part of a broader take pre-1.0. Here's the theory of the case:
Dart initially started with a JS syntax but then switch to a more C# inspired syntax ('dynamic', lambda) and some Java ('final', uppercase String) with lhs types. Combined with Checked Mode an inexpressive type system was locked into the language. Brendan Eich commented early on (if I remember correctly) that there was over annotation on locals - a bugbear of mine.
--
// The greeter service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
// A simple service used to exemplify application testing within mojo_shell.
interface ExampleService {
Ping(uint16 ping_value) => (uint16 pong_value);
};
// nonsense example
myfunc(int a) -> Point {
let lst = [2,4,6];
for (let i in lst) {
let i = i * a;
print(i);
}
return Point(3,3);
}
Removing new, +1 (as long as it's backwards compatible with libraries still using new, in other words, just make it optional)Adding function / fun keyword, make it optional so that stuff remains backwards compatible;Types on the right for functions, looks nice, make it available on left or right to not break existing code. (eg myfunction():Point or Point myfunction())Types on the right for variables, looks nice, once again, make it available on left and right and everyone's happy.
--
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.
--
--
Quote: "If the maintainer doesn't do it, you can create a fork and do the update yourself as a last resort."
Is the source code for all the packages on pub available to be able to do this?
If yes, then that covers my biggest concern which is bricking a brand new project simply because the packages are not being migrated.
--
When evaluating (and eventually choosing) Dart as our primary server-side language, the biggest pushback I got was Dart is still evolving too much to adopt right now. According to this admittedly small data point, stability in the language is going to sell more people than where the type annotation drops.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
I myself prefer the 'type on left' syntax over this hacklangish/TS-ish, type on right. It's only a preference, but a damn strong one.
An even better approach would be to use typedefs. Or add a ZoneSpecificationConfiguration class where each of these closures are properties and pass that. This is an outlying case where the problem is that this is just a bad interface.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
Try this....
Try this....And where in your version do you achieve horizontal alignment of parameter names? They are still jumping left and right because the types vary in length.
--
What is wrong with types on the left?Don't we already have a way to explicitly define types if the type is unknown?Type a = someValue;instead ofvar a : Type = someValue;With all that said, I could live with "var x : int", my primary concern is that it adds more unfamiliarity than needed for new devsvar x: int = ... is certainly much more unfamiliar than int x = ...The last time I've seen that kind of syntax was in Pascal / Delphi over 15 years ago, I certainly prefer the C / C++ / Java way of placing the type on the left.
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for a living) and 0 people working in other functional languages. Java, C#, C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people, placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same syntax rules I know about Java and eased into it very easy, a day later I churned probably about twice the amount of business value than I would have in Java.
My wife coming from a C# background also picked up Dart and started churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart Evangelists knock on people's doors and ask if they have time to talk about Dart.
--
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.
I too would like better notation for building up declarative, structured data. We aren't very DSL friendly.
Cheers!- bob
"but from the static functional languages ML, OCaml, Scala and F# "
I personally know 2 people developing in Scala (only 1 of them does it for a living) and 0 people working in other functional languages. Java, C#, C++, C, probably way over a 100 people.
If the idea was to build something that's familiar to C/Java people, placing the types where they are now was the right decision.
I managed to start writing my first dart app simply by using the same syntax rules I know about Java and eased into it very easy, a day later I churned probably about twice the amount of business value than I would have in Java.
My wife coming from a C# background also picked up Dart and started churning before she even read the docs.
So IMO that's a big win, just give it more time and let the Dart Evangelists knock on people's doors and ask if they have time to talk about Dart.
That thread about the language meeting notes is huge, so I'm going to split my responses into separate threads. If we could move discussions to these, that would be swell.Here's my personal thoughts about putting types on the right:It is strictly more verbose than the current syntax... when you use it. In practice, I think Dart 2.0 should come with a much better promise of type inference and let users reliably omit type annotations on locals. When you do that, most of your variable declarations will just be:var a = someValue...No type on the right or left. :)When you do want a type annotation, for things like top-level variables, fields, and parameters, I personally like it on the right and also like ":" even though it's a bit more verbose. Maybe it's just me, but it helps me separate out the variable name from the type. I'd also be fine with Go's approach and eliminating the ":".The biggest problem (aside from migration, which we would absolutely provide automated tooling for) is unfamiliarity. That is a real issue. I'd like to be believe it isn't insurmountable, though. TypeScript, Scala, Haskell, Kotlin, and Swift all use "name : Type" syntax.Optional type annotation systems for Python, Ruby, JavaScript, PHP all use this syntax. As far as I can tell, it is the standard way to add optional type annotations to a language.
Any myfunction(String s, int i, Any obj) {
// Explicit annotion
Point p = Point(1,1);
// mutable
var pm = Point(1,1);
// immutable
let pi = Point(1,1);
return "Something";
}
Here's another tiny data point. The new UX for our API documentation puts return types of methods after the method name. In the original dartdoc, I got a lot of feedback that it was hard to find member names when scanning a list of members if the return type was on the left. Pushing them to the right does help readability in this case.So, personally, I feel doing this would lead to a simpler, easier to extend grammar. And it would follow in the footsteps of almost every dynamically-typed with optional annotations language that also use "name : Type" syntax.Cheers!- bob
That thread about the language meeting notes is huge, so I'm going to split my responses into separate threads. If we could move discussions to these, that would be swell.Here's my personal thoughts about putting types on the right:It is strictly more verbose than the current syntax... when you use it. In practice, I think Dart 2.0 should come with a much better promise of type inference and let users reliably omit type annotations on locals. When you do that, most of your variable declarations will just be:var a = someValue...No type on the right or left. :)When you do want a type annotation, for things like top-level variables, fields, and parameters, I personally like it on the right and also like ":" even though it's a bit more verbose. Maybe it's just me, but it helps me separate out the variable name from the type. I'd also be fine with Go's approach and eliminating the ":".The biggest problem (aside from migration, which we would absolutely provide automated tooling for) is unfamiliarity. That is a real issue. I'd like to be believe it isn't insurmountable, though. TypeScript, Scala, Haskell, Kotlin, and Swift all use "name : Type" syntax.Optional type annotation systems for Python, Ruby, JavaScript, PHP all use this syntax. As far as I can tell, it is the standard way to add optional type annotations to a language.