Dart language (dartlang.org)

Agreed. I didn't say you couldn't get better at all, just not much better. I'd personally be in favor of ditching new (or conversely making it a method on the class).

> The speed and wide-spread use of Smalltalk with the regularity, flexibility and terseness of Java's syntax?

Oh, you. You may be right. Making a new language is crazy, especially if you're aiming for widespread adoption. Still, you have to try, right?

Dart is definitely more terse and more flexible than Java. Maybe not perfect, but it's heading in the right direction. Dart is no DSL-friendly beauty like Ruby, but I think:

    var odds = [1, 2, 3, 4, 5].filter((i) => i % 2 == 1);

http://www.dartlang.org/docs/technical-overview/index.html#h...

    document.querySelector('#menu').appendChild(sliderMenu.node);

It's like learning how to read, or learning how to read a new script. At first, you focus on the letters, composing words or sentences. When you get more experience, you read ever-larger blocks of text at once and you no longer need to read aloud or read aloud in your head, you can read whole lines or several lines at once and immediately transfer the concepts embodied in them into your mind (this is effectively how people read - chunks of text at a time, it's also why it's easy to read text where the letters of all words are mingled except the first and last one, a feat that is impossible when reading letter by letter or even word by word).

Anyway, in reading/writing code it's the same - at some point you no longer see a line with statements, you see a block with initializations, or no longer a set of if/then or switch statement, you see a jump table. Once you get to that level, dollar signs to denote variables disappear from the mental model you have, because you no longer see tokens - you see variables (same with semicolons, braces, most indentation, etc.). That's where the comparison came from.

(I also think that that's where eloquent code comes from - it's from programmers who make an efficient and recognizable translation from high-level concepts into the mechanics of the programming language, even if there is no explicit support for such concepts in the language).

If you semantically, and naturally, communicate "end of statement" with a line break to human readers, why should you have to say it again with a semicolon to the compiler? Programming languages should focus on being DRY.

> I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.

That's also been discussed. It has more going for it than may be at first apparent, but it has detractors too.

   a = 1
   a = "1"; // error

That said, CoffeeScript provides another interesting use for them: Simulating dynamic binding. Basically, the trick is that `this` becomes the dynamic binding context and `@` represents a dynamically bound variable. You use `fn.call @, x, y, etc...` if you want to pass the dynamic binding to callees. Nested bindings can be established with `Object.create`

    > leaky and half-featured classes.

    Dog = -> 
      ...
       
    Dog::bark = -> 
      ...

    Dog::run = ->
      ...

    class Dog
      bark: ->
        ...
      run: ->
        ...

Except for Isolates -> WebWorkers, there's not really anything that can't be emulated in IE6. GWT has to handle a significantly more complex set of semantics and still works on IE6.

But personally, I prefer if there wasn't IE6 support, or any non-HTML5 browser support for that matter. If you're going to do a new VM, do a clean-break, because legacy support is another factor which makes web development a pain.

I believe it compiles to ES 3, which is isn't exactly "modern JS features". IE6 is ten years old. At some point, you've gotta cut the cord!

Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.

The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?

For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)

Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.

Something like DVM, or a bytecode specifically designed for JS would be better I think.

Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)?

The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone.

I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.

Finally, you seem to have missed the fact that Mozilla is already working on an experimentatl implementation of SPDY in Firefox: http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-yo...

The keyword Brendan used was "decent", and frankly, I'll take a stab and say performance of Dart to JS will be beyond decent.

Google hasn't made dart so we can make our web apps faster. They made dart because there's a lot of java developers at google who believe that its easier to write monolithic javascript applications (GMail, G+, etc) using a language like java.

They believe it enough that they will try to convince others to follow suit.

Edit. I'll have to retract the above. BootToGecko is the mobile platform from Mozilla. It would be awesome to market it harder as such.

Server-side execution...

The only thing I like is underscore for private variables. Go does the opposite (which I think is a safer approach): anything you want public has to start with a capital. It really works—it is both easy to do and easy to read.

Web language: move data from point A to point B.

Do you even read what you write?

Server-side execution...

For example: " Dart supports optional typing based on interface types. 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."

What Dart brings to the table is a dynamic web language that's somewhat more structured than Javascript by using a class mechanism and optional typing. This is a great region of the design space, inhabited by languages like Common Lisp and Dylan.

Uh... like this? http://brendaneich.com/brendaneich_content/uploads/CapitolJS...

    void doSomething(String a) {
        // Do something 1
    }

    void doSomething(Integer a) {
        // Do something 2
    }

    doSomething("1");
    doSomething(1);

The fact that type errors are only manifested as warnings is a (perhaps odd) design decision, but it doesn't stop them being type errors. They could just as easily made them errors, and String a = 1 would give a compile time error.

Hopefully they'll be a 'warnings as errors' flag for those of us more used to type errors being compile errors.

Me too! We already have a very readable, simple and elegant language, let's use that. Anyone know why that wouldn't have worked? (Not using the current CPython implementation but maybe the same syntax but with a different (web-only) set of libraries, that is...)

It's only useful because Java lacks first class functions and syntax for lambdas. This is the single most irritating thing about Java to me. When this is fixed with the release of 8, the only thing Java will be missing is a really good implementation of persistent data structures a la Clojure.

    someString.append(System.getProperty("line.separator"));

    some_string += "\n"

Trying to open and read a file in Java is probably a better example as the intent (open this file and read the contents) is buried in about 6 lines of boilerplate code

I use Java as an example because in a previous life I used to write it and see this as perfectly acceptable

    Circle my_circle = new Circle();

    BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in));

I think the overhead of adding that 'new' is worth it. Without it: in var foo = Bar(), is Bar a type or a function? If you decide it should be colored like a type, your syntax colorer needs deeper information about the code, making it harder to write, slower, etc.

The from item in blah syntax is just SQL rearranged, and SQL isn't as expressive as programming language constructs, so why try to emulate it?

It encourages you to write the grain of salt statement I mentioned earlier, which requires programmers to read through and understand the implementation of what you are doing, instead of it being embodied in a meaningful method and called. Of course you could just wrap that in a method, and slowly grow the line to 2-3 wide-screen monitors as you add more conditions.

The more tools you add to the core of a language, the more of a monstrosity of a kitchen sink it becomes (c#/.NET). Now you can loop over a list in 6 different ways! Hooray! That is why Dart looks good - a few basic concepts that can be used to build things suited to a particular problem.

foreach (var g in grains) {

    if (g.TypeOf() == "Salt" && g.Value == nothing)

        saltGrains.Add(g);

saltGrains.sort(m => m.Value.irellevance);

return saltGrains.First();

or something.

    grains.select{|g|
      g.is_a?(Salt) && g.value.nil?
    }.sort_by(&:irrelevance).first

You can get away from this by having a structural type system, or by being dynamically typed (duck typing ultimately being another form of structural typing). But within the constraints of the type system, you can't get away from this by merely changing the design - unless you put everything into a single module, which is the ultimate in anti-modularity.

I agree that there are some amazing Java devs out there.

Most Java devs are not amazing (and heck most devs aren't amazing). But Java devs are not amazing with a frequency and depth that both boggles the mind and is entirely expected as that's the point of the language -- accommodate mediocre developers in a large shop producing boring enterprise code.

If you look where it's publicly known that Google uses Java, it's pretty much in Ads. The most boring, enterprisy kind of dev job Google has, but it's the money maker so it has to work despite having unmotivated "I'm just here for the paycheck" developers hacking on it.

Yeah, I know, it was used on the backend of Wave, and via GWT for the Wave web client (which was dog slow btw, I loved Wave, but have yet to encounter a web app as slow). And look where that got us.

As an aside, here's an interesting little writeup about why GWT is bad (with bonus example by pg of all people)

http://ryandoherty.net/2007/04/29/why-google-web-toolkit-rot...

And, at least publicly that's about it. If a dev can't be bothered to just learn the syntax of another language in a couple of weeks in order to properly support their target platform, they are a mediocre developer almost by definition.

What language do you think was perfect at it's first release?

I'm not sure exactly what you mean. Could you elaborate please?

I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Think of each of the applications that use that database as also having its own set of types - its classes or data structures in general. Now, an example of the "mechanism" I mean is that SQL provides a way for each app to translate data in the database's schema into its own data structures. If its data structures change, the SQL can change to adapt to that; similarly, if the DB's schema changes, it can also adapt by changing SQL (or even creating a virtual schema with another layer of SQL - a view). Of course, this only works if these are only changes of the representation of the information, and the information content itself is the same. If the information changes, in a way that the DB or an app depends on, then there's no avoiding that dependency.

A similar example are JSON/XML API's, where the JSON/XML is like the DB, and the data binding code is like SQL. The "type" of XML is often explicitly defined with an "XML Schema" document; JSON doesn't usually have that, but it is of an implicit expected form - which is still a type, just informally defined. There are also tools for converting between XML types - XSLT, and may GUI "XML mappers" that display two xml schema and let you draw lines between them.

tl;dr These enable "modules" with different types to interoperate without dependency. Each defines its own types at its own boundary, and so can be compiled independently. The middleware glue (SQL/databinder/XSLT/datamapper) facilitates interoperation by converting between types at the respective boundaries of two modules - provided those types are equivalent, i.e. contain the same information, just in a different schema/type.

Does your concept of "non-essential coupling" include the requirement of precisely identical types at the boundary? If so, by loosening that to only require the same information, this mechanism avoids that particular kind of non-essential coupling.