Dart language

If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock.

As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY.

Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.

It seems pretty obvious to me that unless Google fucks up the VM implementation, it'll always be much faster than compiling to JS, which doesn't even implement the same concepts - let alone semantics - of Dart. In fact, if VM is not much faster, why would they have it at all?

Being faster than handwritten JS is irrelevant, because the VM will be faster still, and that's the difference he's talking about.

Obj-C and Java are not browser-supported. Sure, there's a native apps vs. web apps contest. Native is winning? Not according to Fred Wilson (AVC) and other observers.

Who knows, really. We're speculating, but let's find out by doing. Mozilla is working on both Open Web Apps that run in modern browsers, and Boot To Gecko.

You make this sound like its a bad thing, but that's open-source always and forever. Scratch your own itch.

You now even have options!

[1] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

I don't know what the timeline is for Dart but I will say this:

1. If anyone is capable of the long sort of time frame that something like this can benefit from--event requires--it's Google;

2. If there is anyone who's qualified as a domain expert in Javascript generation it is, by virtue of GWT, Google; and

3. If there is anyone who's qualified to speak to the limits of what you can do with Javascript it is, by virtue of Chrome and V8, Google.

If anything, I believe the error here (if you can call it that) is failing to properly set expectations and communicate the goals of the language (as witnessed by all the comments on this thread from people who were expecting something more and/or different).

The engineer that wrote the memo needed people for his team. To get people to join a team from any of the others at Google, you need to convince them that your team is awesome to work with. At Google, you can't offer more money/benefits, so it has to be a "join us and you'll change the world!" message. That's going to lead to a lot of overblown statements that may or may not end up being true, and may or may not even be believed by the author.

Google is not in the business of doing things that are bad for the web (and when they have done, there's been an about-face, see: Google Video shutdown), even if internal machinations might make it seem that way.

Also, going back to 2006 or so when I invited pre-Google Alex Russell and other JS hackers to Ecma TC39 meetings, Mozillans including yours truly have tried to open up the standards process. Mozilla, Opera, and Apple co-founded the WHATWG and set up an open membership structure for it in 2004, to create HTML5. W3C finally relented and internalized much of that structure.

So alleging that "Mozilla" is trying to keep the old boy's club closed is simply false.

I've cited hard, in some cases physical (as in physics) reasons for why there won't be a lower-level bytecode standard for browser-based VMs any time soon. I'm not blowing smoke.

http://www.aminutewithbrendan.com/pages/20101122

A high level bytecode sounds a lot like minified JS source, with a relatively-few extensions to the standard language. Extending is easier than replacing or setting up a new, parallel cross-browser standard.

Your inflamed sense of grievance at "Mozilla" is misplaced. Mozilla has no control other than what users of our software delegate to us by trusting us enough to download and run our stuff. We do not have hundreds of millions in our browser advertising budgets. We do not have billions of revenue with which to influence people or pay for attention and distribution.

If we are really in the way of Web standards, I'll personally pull the plug.

Really? I thought that was the _mission_ of Mozilla. Except for the "stable" part perhaps, because that's quite at odds with innovation.

The track record easily shows that pretty much every single thing you have said is wrong.

Mozilla "conspires" to do almost exactly the opposite of what you suggest. Having lots of decent browsers available was our old success condition. Now the mobile world is starting to look locked up, so breaking that open to competition and free choice is our new success condition.

Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs.

But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics.

Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best.

You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects.

Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.

> Although you might expect int and double to be primitive types, they're actually interfaces that extend the num interface. This means that int and double variables are also nums.

But from a new language standpoint, it's not worth dropping them. The ridiculous arguments that come out of it, the programmers who refuse to use the language because of it, they're things that can and should be avoided by using semicolons like most languages.

I'll never understand why programmers care so much about this, but hey, that's life.

- no braces where avoidable, no semicolons where avoidable

- release early a free, open source reference development environment that really helps in developing with Dart. The biggest pain with Javascript, imho, is in the lack of development tools really thought out for it, and not just an adaptation of Java/C/whatever other editors

  - if you develop said IDE as a web-IDE, even better (why not writte in dart itself?)

  - give as many inobtrusive visual cues as possible to easily see tab alignment, syntax coloring, etc.

  - integrate unit testing facilities in the IDE

Seeing how Go, which "wasn't done yet" either, handled external feedback... I don't see why anyone would have hopes for dart.

I'm fine with the semicolons, but I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.

For those people who come from "ugly" languages like Java you could have a feature in the IDE which auto-inserted (and of course auto-removed) the braces/semicolons so that they felt at home too.

For example value types would be excellent. Even better would be explicit regions, but I'm sure that's not going to happen.

Also, please fix this:

The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is easy for tools to provide a sound type analysis if they choose, which may be useful for tasks like refactoring.

And add proper generics. If sound type rules fly in the face of programmer intuition, that means that the programmer's intuition is wrong. The proper response is to inform the programmer of his mistake at compile time, and not to silently ignore it and add dynamic type checks on every contravariant use of generics including array access! That is worse on both programmer productivity because the programmer expects that his program is type safe when he is using static types and on runtime speed because the dynamic checks slow down all programs needlessly. Dart already has dynamic typing; use that when you want it, not something that looks like static typing but really is dynamic typing.

Another thing that would be awesome is if you provide a compact binary format for code.

- Requiring a redundant mechanism to mark blocks

- Possible introducing situations where code looks differently than how it executes

is all very mid-90s. python was the first to fix this, but yaml and coffescript do to. In particular, Dart will have to compete with mindshare from .coffee, so at least should be better than that.

I shouldn't need to write 'Point p = new Point(2, 3);'

var p = new Point(2,3); should be inferred as a Point

http://golang.org/doc/go_spec.html#Semicolons

I like Clojure and have dabbled with clojurescript but the workflow feels pretty hacky and it is clear that this is not what javascript was made for.

This would indeed be nice but it seems that google wants to push the language more than the VM. I quite get this because saying "you can now run your favorite language for the browser" seems much much more attractive than saying "look we made programming language 1001 and this is what you people should be using now!".

> In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.

I have no knowledge of how one would do this but a lot of dynamically typed languages exist for the (I am assuming) statically typed platforms such as the JVM and CLR now.

    var greeter = Greeter()

Alternatively,

    var greeter = Greeter.new()

    var greeter = greeter new

> it's more Smalltalk under the hood.

The speed and wide-spread use of Smalltalk with the regularity, flexibility and terseness of Java's syntax? That sounds like a recipe for success.

Ok, fine, but why have both forms?

- JQuery examples like to abuse 'this'.

- I should always, explictly provide the event as a parameter in the callback.

So '@' is always the object, and 'event' is whatever started the method.

I never use inheritance.

Since I started to do this, my code has become much simpler and cleaner.

P.S. Don't ever use the term "klocks" unless you want to sound like a enterprise middle manager who hasn't touched code in 20 years. Just a friendly tip. :)

Of course Javascript has problems, every language has problems associated with it. They all have strengths and they all have weaknesses.

From what I've seen, projects like GWT, Dart, and Coffeescript come out of communities of developers other then the web development community. GWT and comes from Java engineers as an attempt to not have to write javascript, Coffeescript comes from Ruby developers attempting to accomplish the same thing. Now Dart is another attempt by the Java community to not write Javascript.

The thing is, I never hear from the web development community that Javascript is broken, missing major features, and needs to be replaced. These are the people using Javascript every day. The people that say Javascript needs these features are people who don't use it that much.

    document.query("#menu").nodes.add(sliderMenu.node);

Oh. :-(

But mathematically it doesn't make sense to have an int type which does not represent integers consistently. Clearly Javascript can represent 2^31 as a positive integer. In fact it can represent 2^53 as a positive integer (of course in reality it uses a double precision float) as can be verified by typing (1<<20)x(1<<20)x(1<<13) into a Javascript console.

So why is (1<<31) not positive? This is surely something which needs to be fixed in Dart. If they want to make (1<<31) negative, then (1<<30) + (1<<30) should equal (1<<31) and so it should also be negative. Otherwise doing arithmetic is difficult and error prone, which makes it unsuitable as a target for other languages which want to compile down to Dart.

In fact, not having at least 32 bit unsigned integers would be a major drawback. For efficiency reasons you want these to be handled directly by your VM using integer assembly instructions. This is the only way that you'll ever implement efficient bignum libraries for example which require FFT's which necessarily use integers that are an exact multiple of 32 bits in length (Z/pZ for p = 2^(2^L) + 1 usually, where 2^L is a multiple of 64 at least, usually).

"Integers are not restricted to a fixed range. Dart integers are true integers, not 32 bit or 64 bit or any other fixed range representation. Their size is limited only by the memory available to the implementation"

So they obviously haven't got this right. Not only does their implementation not implement this, but it is completely broken anyway because you certainly won't be more efficient than Javascript if your integers are implemented as bignums instead of floats.

Not yet.

> No destructuring either.

There's a proposal floating around for pattern-matching that would address that too.

This is still early days for the language, so there's a lot left to be done.

A delightfully blank page :-) Yes it mentions classes, interfaces, optional types, libraries, tools, structured yet flexible language. But all of these are a given. Is there nothing else?

What about Generics, Covariance/Contravariance ? Type inference? Odersky thinks type inference in the presence of subtyping is untenable. Is it the same here? Are interfaces linearized as in Scala? What about immutability? It might be too much to ask for rank-2 polymorphism and Haskellish Type Classes but what about support for delimited continuations? Let me guess, these aren't "design goals". All I am saying is this isn't 1990 either.

> Types can help you write and maintain your code, but they don't change how Dart programs behave.

That, in my opinion, is not a type system, it's a documentation system. Writing

  String a = 1;

I think "beauty" is really a subjective consideration when it comes to programming languages.

Perhaps this is by design, though? Presumably the syntax doesn't look too bad to people who spend all day writing JavaScript (i.e. the target demographic for this language).

Presumably some bright spark will eventually write a Python-to-Dart compiler and then we'll all be happy :-)

  In Dart, you can often create objects directly from an interface, 
  instead of having to find a class that implements that interface

Sounds like Java's anonymous classes. Quite a useful feature, actually.

`var foo = new Bar()`?

Why can't a constructor just be a regular method that happens to return a new instance? What's with this new nonsense?

Where it shines IMHO is in the core library (http://www.dartlang.org/docs/api/index.html). Look there and you will find some interesting classes that deal with concurrency and asynchronous operations (Isolate, ReceivePort, Promise<T>). Also, unlike standard Javascript, there are collection classes for specific use cases (like Queue, Set, LinkedHashMap). This is where it is superior to both Javascript and mainstream static typed languages like Java.

  - Incredibly uninspired, boring Java-like syntax.

    grains.select{|g|
      g.is_a?(Salt) && g.value.blank?
    }.sort{|a,b|
      a.irrelevance <=> b.irrelevance
    }.first

    var q = from m in grains.OfType<Salt>()
            where m.Value.Contains(null)
            orderby m.irrelevance
            select m;

    return q.FirstOrDefault();

Yes, because Google is notorious for hiring "mediocre developers".

Or are Java developers especially considered "mediocre" by definition?

Or does dabbling in Ruby/Python/Lisp/Closure/Scala/Haskell make you "non mediocre" by definition?

It's the skills, it's not the language.

I would like to see something with the scope, ecosystem and functionality of, say, Eclipse, written in one of the non-mediocre languages (no, Emacs doesn't come close).

Why not? C# 1.0 was terrible and most of the version since have been exercises in trying to fix it by piling more stuff on, in order to replace previous tentative fixes which did not work for any value of "work" worth using because they lacked generality.

> We need less of them in mainstream language design and more pragmatism.

I hope that's a joke, PL theory experts are nowhere to be seen in mainstream language designs (some have managed to get a claw or two into C# to add actually useful features like... lambdas...), and the "pragmatists" have a field days reinventing problems (not solutions) instead (hello, Go)

The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.

Types add constraints, thus increasing coupling (and decreasing modularity).

Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.

Maybe I'm wrong, that'd be nice.