Live data from Hacker News

Dart language

dartlang.org

171–180 of 504 posts

Re: Dart language

#171

The one thing I don't understand is why people work on new languages for the browser instead of giving us a platform (virtual machine / intermediate representation, whatever) to implement languages against. I mean here in this thread we are already seeing it. Some people like semicolons, some people don't. Some people like a prototype based object system, some people like a class based system. And on and on. I think…

I think the Dart VM will be a nice target for compilation from other languages. 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.

Before Google I worked on an academic project that built a small Smalltalk-like VM that was also a compilation target for something that was very close to unthreaded Java. Worked pretty well.

Re: Dart language

#172

Earlier quoted context omitted.

I disagree with his premise. The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser. If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar co…

I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language". If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en…

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore.

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.

Re: Dart language

#173
This is completely the wrong thing to do.

Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.

That is something I could see Mozilla and Apple getting behind.

Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web.

I had hoped that Dart would surprise us and turn out to be a 'machine-code for the web' implementation. This would have been a much smarter move, I believe.

Re: Dart language

#174
post #156
post #65

From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages. What is frustrating is that there are so many people who can d…

Agree with parent comment. My opinion, so far: Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc) The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java…

I agree with you about the syntax - I was hoping for something more like Python.

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

Re: Dart language

#175
post #65

From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages. What is frustrating is that there are so many people who can d…

AFAICT, Google is a lost cause when it comes to PLs.

Re: Dart language

#176

Aaaarghhh! It is full of semicolons. Is it really necessary in the 21st century to create a language that terminates lines with semicolons? I am sure I have seen some other languages in the past that get by just fine without them.

The language isn't done yet. Now is the time to let us know if you want semicolons to go away. I know some of us on the team do too, but public interest will help a lot.

Please make semicolons and braces optional. Unless they are explicitly required for marking blocks and endlines they are just wasted characters to people from prettier languages :-)

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.

Re: Dart language

#177
post #139
post #65

From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages. What is frustrating is that there are so many people who can d…

Sorry man, accidental downvote. It was actually a +1. I agree with you, the first impact with the language is terrible, the syntax is too reminiscent of Java. It seems that at Google Java is popular for web apps (GWT, Closure, ...). This must have had an influence. I still fail to see what are the improvements over Javascript (while they managed to get the syntax worse ). I guess a concurrency model, optional static…

Have you seen ES.next? It's worse. I want to see T39 just start over and aim for the same elegant JS-style solutions that Dart has shown for things like class declarations and a separate int type. Instead they're adding things nobody gives a damn about, like debuilderstructors and shit.

Re: Dart language

#178
post #158

A language that compiles to JavaScript really needs better browser support. Decent web apps use feature detection to provide graceful degradation for browsers from the stone age. Dart breaks this by making it impossible to run any code at all. I mean, "IE9 support coming soon!", what the hell? What about IE6? This isn't a CSS style or an animation library we're talking about.

Fuck IE6 and all its users.

Wait, I get downvoted and you don't?

Re: Dart language

#179

Earlier quoted context omitted.

That's not true. Go, Python, Ruby and Scala all have optional semicolons without insanity. It's just that JavaScript's specific semantics for semicolon insertion (instead of newline elision!) are batshit crazy.

> That's not true. Go, Python, Ruby and Scala all have optional semicolons without insanity. Python (and Haskell) solve that issue by not using semicolons unless required. The Dart code in the examples is full of semicolons, that makes it an "optional semicolons language" akin to javascript more than a "possible semicolons language" akin to Python or Ruby.

> The Dart code in the examples is full of semicolons, that makes it an "optional semicolons language"

Well of course they do because semicolons are currently required, but that says nothing about its relationship to JavaScript's inane semicolon insertion semantics, and I'm pretty sure you're smart enough to know that. All Dart needs to do is:

1. Treat both newlines and semicolons as the same kind of token (call it whichever you like). 2. Pick an elision strategy. Go's or Python's work fine. 3. Remove all of the ";" from your source files.

No crazy JavaScript "rewind the parse and try again" insanity.

Re: Dart language

#180
post #155

Earlier quoted context omitted.

> var greeter = new Greeter() Well, it's hard to get that much better than that. > Plus there are classes, interfaces... It's just Java? Java didn't invent classes. It certainly looks a lot like Java, but it's more Smalltalk under the hood.

> Well, it's hard to get that much better than that. Ok, fine, but why have both forms?

Sometimes you care about the types, sometimes you don't.
Post reply on HN