▲ 54 points
back
41 comments
This has got to be the worst learn x in y minutes that I've ever read. Whitespaces, anyone? Every example is compacted and very hard to read. Comments should document each line instead of a huge wall of text before the function.
Naming everything ExampleX is very difficult to see what is being talked about in this particular function.
I'm lucky to know enough about Dart already, because this is a very bad representation of it, IMO.
Perhaps you could contribute to the file via a PR instead of ranting at a post on a news aggregator? If people like you did then the open source community would be a better place.
"Make a pull request" is not a proper way to respond to valid criticism of open source projects. Is it not obvious how fallacious that argument is?
There's an error in the section on literals. Literals used outside of classes do not have to be const. Not sure where that notion came from, but this is totally valid:
var l = [];
for (var c in str.split('')) {}
I love Dart, I think it's a great language. I hope that Google will start supporting it natively in Chrome.
They are. Check "In Development" section.
http://www.chromestatus.com/features/6682831673622528
So in a few months we will have Google's VbScript available in Chrome.
The VBScript comparison dig is as old as it is wrong.
VBScript was IE only, because VBScript didn't compile to JavaScript. Dart compiles to JavaScript and runs on IE, Safari, Chrome, Firefox and Opera. VBScript didn't have a specification accepted by any standards organizations, Dart is ratified as ECMA 408. VBScript is not open source, Dart is.
The fact that Dart has been used in production years before any VM in a browser should show how different they are.
> Dart compiles to JavaScript
Not all language features can be represented in JavaScript.
Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaScript.
And I bet there is a VbScript to JavaScript somewhere out there.
> Dart is ratified as ECMA 408. VBScript is not open source, Dart is.
Standards by themselves don't foster adoption.
Eiffel, Ada, Modula-2, Extended Pascal, Common Lisp, Smalltalk, ... have ISO/ANSI standards.
In the 60 - 90's being open source wasn't a requirement for multiple implementations for programming languages.
Context: I'm using Dart for app development for two years now.
> Not all language features can be represented in JavaScript.
I could not name one (except the dart:io stuff, which is not supported in the JS world). Could you please elaborate?
> Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaScript.
I've found the same, but Dart is a surprising exception. If you are not using any fancy framework (e.g. Angular.Dart), you will be just fine with the close-to-the-browser approach of the language and APIs.
The main example is that Dart's basic numeric types can't be represented in JavaScript. Dart VM integers are bignums, while dart2js numbers are IEEE754 doubles.
That's for performance because I guess the majority of users would probably not notice the difference.
They can be represented in JS, but not natively.
>Besides, all the languages that compile to JavaScript just add complexity layers to the already complex model of HTML/CSS/JavaS
Does it? Because HTML/CSS/JS development is a bit of mess to begin with (and complexity rises when you start adding micro-frameworks into the mix - and you kinda have to if your codebase gets to be a decent size). I've done some Dart web-development, and it's cleaner and nicer.
I don't get why people make this VbScript comparison (sneer, actually). Yes, it is a language introduced by a single company, but then again many languages have started that way, and in this particular case there are big differences between VbScript and Dart. I think Dart is a better language. Do you disagree?
> Yes, it is a language introduced by a single company, but then again many languages have started that way
Including JavaScript.
Acceptance as a standard usually happens after someone implements it, makes it widely available, and proves its merit, not the other way around (and standards that happen the other way around tend to be dead on the vine.)
It's true that many current standards became accepted by force, after a powerful entity pushed them on the development world. However, that doesn't mean it's a good model.
We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced. The process isn't perfect of course, but nothing is.
It seems quite insulting to that process for Google to go completely around it and ship major new features that have no interest from other parties, like PNaCl and Dart.
With that said, I do agree with Google about its recent choice to go back to prefixed features, but only ship them to 50% of users; that avoids websites relying on them, but does allow testing "in the wild". I think that would be a far better model than Google has taken with PNaCl (shipping it to 100% of users). If Google took that approach with PNaCl and Dart (instead of what it has been doing with PNaCl), much of my objections would go away.
> We do have a well-functioning standards process in the web space now - which we did not have back when JavaScript was introduced.
The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation. And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged.
> The "well-functioning" process, to the extent it exists,includes the same features -- things are introduced by a vendor and proposed for standardization, but generally do not become standardized until there is uptake in the wild of the implementation.
True, but also one vendor does not ship the feature in a unilateral way, in opposition to all the others.
> And, to the extent processes exist that didn't when JavaScript emerged and are even arguably "well-functioning", they apply largely to modifications to existing core web technologies (particularly HTML and JS), and not to new alternative or supplemental technologies, where, to the extent that processes exist, they are largely similar to (or exactly the same) processes that were available when JavaScript emerged.
True to some extent (most standards work is incremental), but also entirely new web technologies have arisen through the standards process, such as WebGL and WebRTC. New web technologies can be added without unilateral and controversial action.
I don't think you can infer any particular schedule from that page. Dart's been in development for a long time.
What's the status on other browsers implementing it? Is it even a possibility?
It doesn't look good. It's very well possible, but the other parties just do not seem interested. Maybe because they are currently investing in Javascript related technologies.
That's the real issue, IMO. It doesn't matter if Chrome has Dart as long as 2/3rd the market is using different browsers.
It's important to distinguish adopting a Dart VM from supporting Dart the language. Dart works fine in all modern browsers now by being compiled to JS. Doing that gives you the developer-time productivity boost of using Dart (which to me is the most compelling aspect of the language) while letting you ship your app to the entire web.
The VM is neat too, but from the user's perspective, it's an implementation detail. It's a really nice development tool, because it lets you run and debug your Dart code straight from source instead of trying to deal with generated code.
But I think it's relatively less important that the VM be shipped to end users. I think Dart can be a great, successful product without that happening.
It's not an issue. I've noticed dart2js performance is as good as hand-written js.
At least with dart2js I have just one "VM" to target - Google have sorted the x-browser issues for me. Imagine the peculiarities you'd find in Microsoft's implementation, for example.
One of the examples reminded me of some xml/html trivia I picked up a few years back -- attributes do not need to have double-quotes. (Yes, in practice you can leave out quotes altogether if the attribute has no spaces because browsers are tolerant, but the spec allows for single or double quotes, so if you're going to parse markup you need to allow for both.)
It occurred to me that HTML5 might have tightened up this rule, but it remains as before:
Note that XML attribute values do need to be quoted, so this is only true for HTML and not XHTML.
It seems to me that the majority of the time learning any new language is not the syntax itself, but memorizing function names and parameter order. Has there ever been an effort to design a family of languages which use the same function names and order of parameters for the same operation so that switching between them would be a matter of learning basic syntax?
This seems rather odd from example 14:
// Boolean expressions need to resolve to either true or false, as no
// implicit conversions are supported.
> I think I'd miss patterns like `if (arr.length) { ... }`
At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this:
if (arr.isNotEmpty) { ... }
[0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...
It's actually important to prefer .isNotEmpty over .length here. In some iterables (think generators, or sequences transformed by higher-order functions), calculating the length requires traversing the entire sequence where .isNotEmpty can stop after finding a single item.
Implicit coercion is often a source of bugs. Some languages simply mandate that you be explicit about your intent. It can be slightly more verbose, but you gain clarity and reduce ambiguity.
With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit.
If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS.
Being explicit is great, but it doesn't prevent a library from defining it's own boolean coercion rules.
The Angular team, for instance, has defined toBool() (which they use in directives like ng-if) like this:
bool toBool(x) {
if (x is bool) return x;
if (x is num) return x != 0;
return false;
}
I think this is wrong or at least misleading. According to the Ecma standard:
Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application
(bool v){
assert(v != null);
return identical(v, true);
}(o)Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time not generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it does provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart has implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you mean it to be a wordy way to create unreachable code) is never something you want to do.
[1] http://blog.sethladd.com/2012/02/booleans-in-dart.html "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."
It's subtle. The conversion rule states that only `true` is true, `null` is an error, and everything else is false. However, the type annotation of `bool` means that in checked mode any non-bool value will cause a type error to be thrown.
The reason it's defined this way is for efficient compilation to JavaScript. Control-flow constructs don't have to perform a type-check, just a null check (which can be left out in cases due to null propagation).
This is true in Go as well http://play.golang.org/p/Mk6i0Ll8uW
I rather like that you're forced to be explicit. Often, the (hidden) conversion is a source of bugs or confusion.
Are you really worried about having to type 2 characters ('>0') more? I think people are too worried about syntax when it comes to programming languages. I guess it makes sense because that is what is most obvious when you look at a language for the first time.
I like Dart, but Polymer code converted to JavaScript doesn't work on IE11, just Chrome.
looks cool!