Why is Dart keeping certain cruft from other languages? | Hacker News Reader

Why is Dart keeping certain cruft from other languages?

groups.google.com

24 pointsjarek-foksa55 comments

Maybe I'm missing something big but Dart looks to me like Slightly Better Java, yet another boring incremental improvement on languages that are well past their sell-by date. There are plenty of more daring and yet more mature alternatives that already provide the security of running on a Java or Javascript VM (Scala, CoffeeScript, etc) so I'm really fuzzy on just what they're trying to do here.

Well it's like different, but similar!

> CoffeeScript

How is coffeescript 'daring' in any way ? It is a thin veneer on top of javascript, syntactic sugar for your coffee.

Dart is a hundred times more daring. It is trying to push optional typing. No mainstream language has such a feature, and not even so much non-mainstream ones.

It doesn't say anything about my opinion of any of those two languages (i actually use and like CoffeeScript), but it just sounds to me like you're looking at syntax only, where the important part of a language is its semantics.

> Dart is a hundred times more daring. It is trying to push optional typing. No mainstream language has such a feature, and not even so much non-mainstream ones.

I long for the day when statically typed/dynamic language debates are considered quaint and old-timey.

There was an article posted to HN, where someone instrumented web apps and determined that after some short "warm-up" period, even variables in web apps written in dynamic languages had static types. If a tracing JIT eventually knows what type is in all the variables, why can't we have a development process that uses this information? Isolate all of the "dynamic" code in separate modules marked as such (the JIT could tell us what those sections are) and inject the type information back into the source code. Production servers could keep track of such information over many months, and the developers could know with a high degree of certainty what all the types in all of the variables are.

Closure Compiler for JS has optional typing.

> How is coffeescript 'daring' in any way ? It is a thin veneer on top of javascript, syntactic sugar for your coffee.

CoffeeScript does compile into JS, but so does Dart. Both are in that sense just syntactic sugar.

CoffeeScript does make quite big changes to syntax though (often inspired by Ruby, Python, etc.) in many cases more than Dart which seems inspired by Java - and I don't think anyone considers Java 'inspiring' (useful and familiar, sure).

> Dart is a hundred times more daring. It is trying to push optional typing. No mainstream language has such a feature, and not even so much non-mainstream ones.

ActionScript.

> ActionScript.

And Groovy =D

> CoffeeScript does compile into JS, but so does Dart. Both are in that sense just syntactic sugar.

With regards to Dart, that's like saying C++ is just syntactic sugar for assembly. When there's semantic differences between the mapping from one programming domain to another, I would argue that constitutes "compilation". I would agree with the statement for CoffeeScript though.

I don't understand, are you saying Dart doesn't compile to JS?

Dart does compile to JS while CoffeeScript retains a one-to-one mapping between CoffeeScript and JavaScript. Read the "golden rule."[0]

[0]: http://coffeescript.org/

This is a matter of degree.

Dart's types do not affect runtime behavior (at least in the compiled-JS route), so basic types are quite close to JavaScript's, much like CoffeeScript.

There are also no features in Dart that cannot be compiled into JS, like say threading with shared state.

So overall I think it is reasonable to say that both Dart and CoffeeScript are close to JavaScript and built specifically to compile into it.

For the most part it's designed to be easy to compile to JavaScript, but there are bizarre exceptions like support for arbitrary precision integers. (I believe this is ignored by the Dart to JS compiler.)

This is true, and a known bug: http://code.google.com/p/dart/issues/detail?id=1533

> ActionScript

From my understanding, ActionScript is a gradually typed language. Contrast with Dart, which is optionally typed. In Dart, static type annotations do not affect the runtime semantics of the code. In ActionScript, the types do affect the runtime semantics.

I'm not fully informed about Dart's optional typing, but how is it different from ActionScript 3's optional type system?

>Maybe I'm missing something big but Dart looks to me like Slightly Better Java, yet another boring incremental improvement on languages that are well past their sell-by date.

It wasn't made to be exciting. For exiting go look elsewhere.

It was made for some very pragmatic goals:

1) to be used in the same context as Javascript (web clients mostly but some server too) 2) Look familiar to JS programmers 3) be more like Java and remove the bizarro JS behavior 4) be able to be made faster than V8 5) add some handy stuff to the mix.

Exciting does not come into play at all, and with this goals it should not.

With "exciting" you get Haskell or Clojure, languages with such small following that they celebrate it with blog posts when they are used by some company (personally, I like both, and they are both better than Dart for tons of things but not for Dart's specific goals).

Not that Dart is used by anyone as of now, but one of their goals is to have it be used. And conventional beats "exciting" every time in this goal (All the major used languages: C, C++, Java, JS, Python, Ruby, Perl, C#, all fairly similar and conventional).

Except they are "only" trying to replace perhaps the single most ingrained language of all time, that is, Javascript in browsers. And I'll warrant that the more ingrained a language is, the more it's contender needs to be exciting, and yes, even hyped, and catter to developer motivation and happiness. For pure technical gains, I think there's huge resistance to be found.

Having said that, I think they could find some success in, say, making Chrome run Dart natively (as well as Javascript for the time being) and then getting other more hyped languages to compile to Dart.

>Except they are "only" trying to replace perhaps the single most ingrained language of all time, that is, Javascript in browsers. And I'll warrant that the more ingrained a language is, the more it's contender needs to be exciting, and yes, even hyped, and catter to developer motivation and happiness.

True, they need "hype", but exciting in the way asked above just throws most developers off of it. No exciting language ever gained a stronghold in the market. Even Lisp in the AI/Lisp Machines era and Smalltalk in its heyday were marginal.

<b>Having said that, I think they could find some success in, say, making Chrome run Dart natively (as well as Javascript for the time being) and then getting other more hyped languages to compile to Dart.</b>

They do have Dart run natively in Dartium, a special Chrome version IIRC. But obviously I can't see Apple/Mozilla/MS playing along and adding Dart to their browsers.

One way they could gain ground would be to use the server side advantage (since they want Dart to work on the server too):

Make a better Node.js like environment with Dart, with no callback-spaghetti and single-thread issues, and add a top-notch web framework for it, suitable for both Rails and client-rendering style web development. Add MySQL/PostgreSQL and Mongo drivers.

I think something like that will catch on like wildfire.

A strong, google-funded full-stack framework competitor to Meteor sounds like a good thing to the evolution of JavaScript (EDIT: evolution of browser rendering languages) everywhere. They're getting it right with Angular, so yeah I agree that could work out.

> Having said that, I think they could find some success in, say, making Chrome run Dart natively

That would fragment the web, just like if Microsoft made IE run .NET natively (or, like Microsoft made IE run ActiveX).

So hopefully that won't happen.

One of Dart's goals is to become a compelling and useful option for developers of many backgrounds to write awesome modern web apps. Compiling to JavaScript is crucial, as JavaScript is the lingua franca of the web. Embedding a Dart VM into a browser gives even greater performance for Dart apps and support for features such as snapshots (a quicker startup from a serialized binary heap).

If Dart, at first blush, looks familiar, then we've done our job. :) We freely admit that our job was not to make the world's most pure or esoteric language. Dart is a tool to get real jobs done and to be easy to use for a wide range of developers. Our hackathon experience shows that our learning curve is low.

That being said, if you poke around and try the language, you'll see quite a few significant improvements and exciting features. I wouldn't say it's "slightly better", I would say there are some significant enhancements.

Some significant improvements include:

* Isolates for shared-nothing concurrency. Shared-state threads are error prone.

* Optional types. You don't always need to prove the entire world is validated by some ceremonial type checker. Web programming especially is a workflow where you want to "write some code, hit reload" and iterate as fast as possible. Also, sometimes you just can't express what you want with your type system. Optional types is a way to say "I was going to cast to Object anyway, so let's dispence with the pleasantries and just use var."

* Everything is an object. No more "some things are primitives, some things aren't."

* Arbitrarily sized integers. 'nuff said.

* Not everything has to be in a class. Dart has top-level functions. This makes utility libraries significantly easier to use.

* A package manager as a native part of the ecosystem. This encourages 3rd party developers to share code early.

* Significantly faster start up. Go ahead and print out all the classes that are loaded when you run a simple Hello World program with the JVM. We'll wait. :)

* (related to the above) All Dart programs actually start running with main(). Turns out, this is not the case in JVM, due to how statics are initialized.

* Snapshots. Load code and libraries from a serialized binary heap. Significant startup performance improvements.

* Compile-time constants. These are canonicalized, and make for easy way to share data across isolates (they are immutable, for instance).

* Named optional parameters, with default values.

* All exceptions are uncaught.

* Throw any object. So you can throw "This is a crazy one-off error"

* Dartdoc comments can have markdown. This is awesome. :)

* A file can have a mix of classes and top-level functions.

* Lexical closures! (no more need for anonymous inner classes)

* Operator overloading.

* Method cascades. See http://www.dartlang.org/articles/m1-language-changes/#cascad...

All that really matters is "Are real developers more productive and having more fun? Are real developers launching more exciting apps?" That is the true test for Dart or any web language. Our experience is that evolutions, not revolutions, are a successful way to adoption.

Disclaimer: I'm a long time Java user and I have respect for the platform. I've written books on it, and launched many apps with it.

I smell comparison to Java in every point. How about comparing to Javascript, in whose domain Dart intrudes? Or, even better, CoffeeScript? ;)

Dart provides a complete "Batteries included" solution, i.e. Dart IDE, package manager, core libs, etc. Optional typing enables IDE's to maintain richer knowledge about your code, enabling proper intelli-sense and refactoring support. Dart IDE's intelli-sense is smart it can even infer types inside string literals:

http://news.dartlang.org/2012/08/dart-editor-improves-on-cod...

var v = document.query("input#id");

v. //brings up intelli-sense for InputElement

You can also debug natively in Chrome or inside the Dart IDE. JetBrains are also developing their own plugin for Dart: http://plugins.intellij.net/plugin/?idea&id=6351

It also transpiles to JS (like CoffeeScript) but also includes a Dart VM which contains innovative features like Snapshotting for instant start-up times.

The original post was about a "slightly better java", so you're right, I tried to enumerate some features that might be interesting to a Java developer.

I really don't like X vs Y stuff (too many subtle and contextual issues), so I'm just trying to help the original commenter dig a little deeper.

These are all superficial syntactic complaints, following Wadler's law. My experience is that every new language gets more than its fair share of these.

Any fool can have an opinion about syntax, mostly based on personal taste. To argue about semantics though you have to actually know something.

http://news.ycombinator.com/item?id=4516619

This shouldn't have been downvoted.

One thing I would love to see in languages that can work with single or double quotes is a practice like double quoted strings are text that will be displayed to users and single quoted won't. That way editors and tools can automatically help with localization, and can spot when you mix and match.

I can feel myself getting dumber reading this discussion. Christoph Husse is a donkey.

when did it become so trendy to hate semicolons?

A small but very vocal sub community of programmers hates semicolons. Really, semicolons are nice for readability and nice for your tools, as they make statement termination explicit. I was on the losing side (a semicolon lover) of this debate when it came to scala.

I think this is mostly bikeshedding, but I can't agree with your statement.

The claim is not that we shouldn't have explicit statement terminating characters. It's that we already have one - new lines - and that mandating semicolons is both redundant and bug prone.

Personally, and while it doesn't really affect my choice of languages, I think you should be able to use one or the other, but not two consecutively.

In any case, excuse me for posting this, and I promise I won't discuss it here any more.

I frequently split long statements over multiple lines for readability purposes. Having an explicit statement terminator makes this possible.

You can do this without an explicit statement terminator. In Scala, you can write something like this and just have it work.

  foo.bar(arg, objectToComputeArg2.computeArg(innerArg1, innerArg2,
    innerArg3), arg3)

You can do the same in Python or in Lua. Lua will yell at you when it's actually ambiguous, as in

  function_returning_a_function(arg)(arg_to_returned_function)
  (it_is_not_clear_whether_this_is_a_call_to_the_value_returned_by_the_previous_line())

You can disambiguate this with parentheses or using a semicolon, though. There's never actually a need to use a semicolon.

Having an explicit terminator makes it maximally flexible, but certainly not "possible". Python does it just fine, but the rules, while mostly sensible, do have a couple of corner cases that can catch you. Javascript does it somewhat less fine, with quite a few more corner cases, including a couple that definitely routinely hit people. But in both cases, it can be done. Nor are those the only two examples.

I do this all the time in Groovy and don't use semicolons...

> I do this all the time in Groovy and don't use semicolons

Groovy's semicolon-less mode has lots of syntax restrictions. E.g.this doesn't compile...

  println true
   ? "yes" : "no"

> Groovy's semicolon-less mode has lots of syntax restrictions. E.g.this doesn't compile...

I would't say 'lots'. It pretty much boils down to one thing: 'leave the operator on the previous line'

println true ?

        "yes" :

        "no"

For example is just fine.

This compiles and runs OK in Java...

  class Hello{
    public static void main(String[] args){
      System.out.println( true
       ? "yes" : "no" );
    }
  }

In order to work without semicolons, Groovy's grammar must restrict some things that work in Java. Semicolon-less mode in Groovy has a price.

Ok, I've always wondered about that '?' operator. What's the point?

It was said (at the time) that C-like syntax meant a program was a series of expression, not statements. So something like

   (void)1;

is valid syntax. Even compound expressions are valid:

   a=5, b=6;

Where I feel abandoned (betrayed?) is this: why then aren't compound statements also expressions? E.g.

   {
   int x=Foo(50);
   Bar(x);
   }

The value returned could just be the value of the final executed expression (Bar yields a value). No need for 'return' at all.

And no need for '?'.

   int x = { if (i > j) 5; else 6; }

You're right about statements being expressions and returning the last executed expression. In fact, since using Clojure I've gotten used to these, e.g.

  (-> (Foo 50) (Bar))
  (def x (if (> i j) 5 6))

I do miss the static typing and more readable syntax, though, and have appreciated Haskell in this regard. Too bad things like powerful macros and convenient syntax don't seem to gel together well in the same language.

That compiles just fine in groovy as well, the parathesis of the println call delimit the statement. Same is true for other delimiters:

  reportData = orders.collectMany {it.items}
                     .groupBy {it.product}
                     .collect { key,value -> [product: key,
                                               vendor: key.vendor,
                                                cases: value.sum() {it.actualQty},
                                        productCharge: value.sum() {it.totalProductCharge},
                                       platformCharge: value.sum() {it.portalCharge},
                                       shippingCharge: value.sum() {it.shippingCharge},
                                          dueProducer: value.sum() {it.totalDueProducer()}]}

Is perfectly valid groovy, spread on multiple lines with no semicolons.

You seem to be making this out like its some huge inconvenience. It is very rarely an issue and its not like there are 5000 things you can't do. Its really just line breaks in statements that aren't delimited any other way that are effected and all you have to do it put the operator on the line prior to the break...

I program in Python (no semicolons) and I also frequently split long statements over multiple lines. One doesn't need an explicit statement terminator to do it. You can do it inside parentheses for ex.

I have first hand experience that semicolons are good for tools. I've also helped people debug their Scala compilations by having them add semicolons on various lines to make the error messages more comprehensible.

If we didn't have multi-line statements, new lines would work great as statement terminators.

Isn't this part of a trend to reduce the presence of statements (enforcing order-based reasoning) ? With javascript ubiquity and mainstream presence of lexical closure people converge toward functional, encoding of patterns, even sequences.

I think you are right but I disagree with the trend. Debugging a wide horizontal expression is much harder than debugging a tall vertical sequence of statements.

'for now'. Current debuggers aren't built to handle this point of view. I agree it's quite frustrating, but I'd bet it will be fixed soon.

I work in this area and I'm not so sure the fix will be easy. There seems to be a real "cognitive" cost to abstractions such as deep chains of combinators, which spills over into debugging. How the heck are you supposed to debug something when the control flow is abstracted N-layers deep? You really can't, which means you have to resort to something like data-flow debugging.

Around the same time vi won over emacs.

since many realized they are not needed...?

why do you need semicolons?

Why does Dart look so boring? I'm just not buying that whole "familiarity" argument. If a language is truly great then I'm sure people will learn how to express their thoughts in that language.

I know syntax isn't everything in a language but it's pretty important. There are much better (IMO) ways to express yourself than the approach Dart takes.

> Why does Dart look so boring?

So it appeals to the widest (and thus) more average programmer.

Languages have an implicit audience and purpose. For example I consider Java a language designed to be consumed by code-monkeys. The mentality that you have a large enterprise project and you look to India to hire 200 programmers to finish it for you. The language has to have static typing, it has to be familiar to those learning previous languages (C++, C), IDEs are the preferred work environments, everything is very explicit and verbose.

Take Haskell, it is a language that would appeal to an academically minded developer. Someone who knows about catamorphisms, uses words like endofunctor, or say wouldn't mind struggling for weeks to comprehend what a Monad is.

Those are 2 different audiences. Neither language is better or worse, they are just tools and in some cases one is a better fit, in other case another one is.

Dart is closer to the Java.. It wants to be used in large code bases, by many (including average and junior) programmers. So adding things like fancy list comprehensions, de-structuring assignment, pattern matching and stuff like that, might not fit with its goals.

If code branches in the woods and no one is around to program it, does it start a flamewar?

Does anyone use Dart?

Reply on news.ycombinator.com