Learn Dart in 15 Minutes

http://learnxinyminutes.com/docs/dart/

by tosh • 12 years ago

54 41 12 years ago

learnxinyminutes.com

fnbr2• 12 years ago

I love Dart, I think it's a great language. I hope that Google will start supporting it natively in Chrome.

pjmlp2• 12 years ago

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.

skybrian• 12 years ago

I don't think you can infer any particular schedule from that page. Dart's been in development for a long time.

andreasvc3• 12 years ago

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?

spankalee4• 12 years ago

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.

sehr• 12 years ago

What's the status on other browsers implementing it? Is it even a possibility?

andreasvc3• 12 years ago

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.

Tloewald• 12 years ago

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:

http://www.w3.org/TR/html-markup/syntax.html#attribute

cygx• 12 years ago

Note that XML attribute values do need to be quoted, so this is only true for HTML and not XHTML.

phpnode• 12 years ago

This seems rather odd from example 14:

    // Boolean expressions need to resolve to either true or false, as no
    // implicit conversions are supported.

I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

sgk284• 12 years ago

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.

[1] https://www.destroyallsoftware.com/talks/wat

spankalee4• 12 years ago

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

It treats true and non-zero numbers as true, and everything else (including null) as false.

oblique63• 12 years ago

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) { ... }

The core libraries support a lot of useful properties like that.

[0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...

munificent2• 12 years ago

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.

berns• 12 years ago

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)

dragonwriter4• 12 years ago

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

spankalee4• 12 years ago

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

nickpresta• 12 years ago

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.

andreasvc3• 12 years ago

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.

chrionsr• 12 years ago

looks cool!

spankalee4• 12 years ago

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 = [];

Also, the example of looping over characters in a String using substring is very odd and expensive. Generally, if you want to iterate over a list of single-character Strings, you'd use String.split():

    for (var c in str.split('')) {}

split('') is necessary to be unicode safe. There's also String.codeUnits and String.runes (an iterable of code-points).

MisterBastahrd• 12 years ago

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?

lumpysnake• 12 years ago

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.

L8D• 12 years ago

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.

crazypyro• 12 years ago

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

adrianlmm• 12 years ago

I like Dart, but Polymer code converted to JavaScript doesn't work on IE11, just Chrome.

Learn Dart in 15 Minutes

Related Stories