Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dart language

dartlang.org

Post reply on HN
Print view View original

391–400 of 504 posts

Re: Dart language

#391

Post by BrendanEich »

cromwellian wrote: post #359
BrendanEich wrote: post #313

Earlier quoted context omitted.

I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 for a clue. Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support. IE6 is irrelevant. The topic is modern browser with native Dart VM vs.…

What do you mean Dart-to-JS can't be faster than hand-code JS? That's like saying C can't be faster than hand-coded assembly. Unless you write unmaintainable code or spend efforts counting cycles and scheduling and pipeline harzards, this usually isn't the case, and is not the way most people write large application (all in asm). If you take your average hand-written Javascript and run it through closure compiler, in…

"That's like saying C can't be faster than hand-coded assembly"

Don't change the subject. The topic is not productivity as you seem to imply here. Also, JS engines are not hard to track super-scalar CPUs. A compiler can target one JS VM (e.g., V8) but then you're locked in. All the current JS VMs have peculiar optimization faults, some worse than others, many completely disjoint across VMs. No one has a compiler targeting each to best effect.

Hand-coders can do well in general against current JS trans-compilers, but that wasn't my point.

The point is that if you actually need bignums, a JS emulation will be slower than a native Dart VM built-in bignum implementation.

"Most of this worry over runtime performance I think is a red herring."

The "worry" (such as it is, or was) was over Google's politics, not its Dart-to-JS compiler's generated code performance in isolation. Pushing a native Dart VM into Chrome, rewriting major Google apps to use Dart, then seeing if that creates market pressure for native Dart support in other browsers, was all suggested or even explicitly called out in the leaked memo. That was the "worry".

But it sounds like a native Dart VM in Chrome won't be immediately released, and the Google web apps written in JS or Closure won't be rewritten quickly. I don't know. Maybe you do -- do you work for Google?

Re: Dart language

#392

Post by [deleted] »

ootachi wrote: post #332
enneff wrote: post #208

Earlier quoted context omitted.

Go allows you to take the address of any value. You just can't do pointer arithmetic like you can in C. That is, you can't address uninitialized memory.

I assume you mean "any lvalue"? You can't take the address of rvalues, can you?

[deleted]

Re: Dart language

#393

Post by SteveMcQwark »

ootachi wrote: post #332
enneff wrote: post #208

Earlier quoted context omitted.

Go allows you to take the address of any value. You just can't do pointer arithmetic like you can in C. That is, you can't address uninitialized memory.

I assume you mean "any lvalue"? You can't take the address of rvalues, can you?

Essentially, you are correct. Lvalues can have their address taken while rvalues cannot. However, the Go spec doesn't speak in terms of lvalue vs rvalue, it speaks in terms of the addressability of different kinds of expressions.

Re: Dart language

#394

Post by mabdt »

hbbio wrote: post #376

The current Dart buzz shows merely two things: (1) There is a need for better languages to program web apps. (2) Google marketing power is impressing. But, technically what Dart introduces is nowhere new. Have a look for instance at Opa ( http://opalang.org ) which is open source and already does more than Dart. If you take out the marketing bulls... that it is going to replace JavaScript, when it now just compiles i…

It looks like the website dartlang.org is down. I hope it will be up again soon so that we can compare the two languages in details.

Re: Dart language

#395

Post by leoc »

BrendanEich wrote: post #369
leoc wrote: post #329

Earlier quoted context omitted.

And in any case I seem to recall being assured by Mozilla that we don't need no Native Client because Javascript is going to be fast enough for everything . Even pre-existing non-JS code could just be compiled to mighty JavaScript, the Assembler of The Web™ and all would be well. But now Dart is unacceptable because Dart-to-JS won't be close enough to the performance of native Dart?

Go back to the other thread and re-read the argument there (or go back to school and learn how to argue). No one said Dart-to-JS by itself was bad for anything. The leaked memo spoke of a native Dart VM in Chrome and Chrome-first Dart as primary source web app authoring by Google. The clear intent was to pressure other browsers to adopt the native VM. Google can act like Microsoft (but with less market share) if it s…

You appear to have misunderstood.

On one occasion Mozilla has argued that the speed difference between a) non-JS code running natively and b) the same code rewritten in, or even compiled to, JS is (or soon will be) too small to be important. Now on this occasion Mozilla is arguing that the speed difference between a) native-VM Dart and b) Dart-to-JS is (and will remain) large enough to be important. I pointed out that these two claims are hard to reconcile. About the only way they can both be mostly-true is if the performance gap only happens to be large and important enough on exactly those occasions when that gap happens to bite Mozilla in its platform strategy. Not very likely, unless one assumes that the performance needs of the poor sods who just want to use the web (as publishers or consumers) are never all that important.

So the fact that Mozilla's problems with the relatively poor performance of Dart-to-JS would be solved if native-VM Dart went away has little relevance, because most other people's problems with the speed of JS are not helped by making there be no alternative to JS.

> or go back to school and learn how to argue

http://www.youtube.com/watch?v=SKm5xQyD2vE

Re: Dart language

#396

Post by cromwellian »

ootachi wrote: post #386
cromwellian wrote: post #375

Earlier quoted context omitted.

I'm super familiar with type arrays (I helped port GwtQuake which was one of the first apps to ever use them in large measure), but type arrays are an add-on API that doesn't change language semantics. Something that would change language semantics would be to offer early-bound namespaces. Early-binding would increase performance while simplifying VM implementation and make tooling easier.

Modules, which are statically bound, are part of ES Harmony [1]. Please stop spreading falsehoods. [1]: http://wiki.ecmascript.org/doku.php?id=harmony:modules

Sorry, I'm out of date, when ES4 was terminated, John Resig said this: "Some ECMAScript 4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony."

Is static scoping the same as early binding? For example, it is guaranteed that any class layouts within the module are statically frozen and cannot be altered at runtime? If you can add or remove methods from a class within a module, it's not really early binding, and this inhibits it's usefulness in a refactor or an IDE trying to do accurate usage search or code assist.

Re: Dart language

#397

Post by BrendanEich »

cromwellian wrote: post #353
starwed wrote: post #347

Earlier quoted context omitted.

The alternative to google developing Dart isn't doing nothing, but throwing more resources behind javascript. I think you are missing some of the context of Eich's comments. The very same leaked memo declared that Dart was developed b/c js could not be evolved into a suitable language. Obviously Eich thinks it can, but more to the point he's working on the committee that is responsible for guiding such evolution -- t…

If JS can be evolved, why has it taken over a decade, and still nothing much of substance? I think Javascript is much like Java, it is too hampered by concerns of remaining compatible with existing legacy semantics. Whenever you see a language where the only thing they can add is "syntactic sugar" it means they are unwilling to consider functionality that would break the underlying legacy VM assumptions, and that mea…

Such ignorance. Willful? You seem new around here, and you are not using your real name. If only we were on Google+ :-/.

The long stagnation from ES3 (1999) to ES5 (2009) had everything to do with Microsoft abusing its browser-tying OS monopoly to stagnate the web by disbanding the IE team after IE6. This was prosecuted in U.S. v. Microsoft. How old are you, to never learn or else to forget this?

When I brought Mozilla back to Ecma in 2004 as we were launching Firefox 1.0, the JS standards group within TC39 was fooling around with E4X. Only one MSFT and one ex-BEA (ex-MSFT before that by way of Crossgain) guy were doing the spec work, and IE was not ever going to implement E4X.

We had to restart browser competition to get the various parties (Apple and Opera too) back in the room and working productively on the core language.

Now, we have ES5 done and ES6 under way. ES5 had new semantics, ES6 has more along with syntax, chiefly the module system (a second class system to facilitate prefetching, along with a loader API for when you need to be dynamic).

This is all documented on http://wiki.ecmascript.org/.

So your trollish commentary notwithstanding, ES5 is done and shipping in the latest browsers (finally complete in IE10 previews), and ES6 is being drafted and pieces are being prototyped in SpiderMonkey and V8.

I'm the last person to defend Java, but the JVM deserves a word here: it has finally evolved a bit, and it is fairly thriving on the server side with Scala, Clojure, and other languages.

Java's stagnation was due to Sun's miscalculations and mismanagement over the years.

Re: Dart language

#398

Post by rgbrgb »

paulkoer wrote: post #243
fogus wrote: post #231

Earlier quoted context omitted.

Do you mind elaborating on the hackish parts of the ClojureScript workflow? It's alpha software at the moment, but we can always use some feedback.

Hello Fogus. What an honor! I loved your book ;) Well, I am certainly not complaining, I think it is mostly just that it needs to be compiled to javascript and that you need to have the right dependencies in place. If you are compiling from the command line it takes a long time (I know this is caused by the jvm startup time, but it still is a little annoying). I know there are workarounds such as cljs-watch but setti…

>>> I think to some part this reflects the fact that, well, Javascript was not really intended to be a platform to be compiled against, it is just used that way because it is the only platform in the browser.

I'm not so sure this is the case as it is VERY easy to get started with CoffeeScript and have it watch files for changes (at least on a mac with homebrew).

I've experienced general difficulty getting started with Clojure compared to something like Python or CoffeeScript. I suppose I haven't spent considerable time on it (Clojure is just a hobby for now) but the problems I've run into so far are an out of date version on homebrew (1.2 rather than 1.3) and difficulty just getting a usable REPL going (where I can edit lines and use the up-arrow). I'm very attracted to the aesthetics of Clojure but there is so much friction just to get started that I've only been using 4clojure (try-clojure has been non-functional every time I've tried it). I think this is an area that definitely needs to be addressed for Clojure/ClojureScript to get the mainstream traction that node.js/JS/CS enjoy.

Re: Dart language

#399

Post by cromwellian »

rictic wrote: post #379
cromwellian wrote: post #350

Earlier quoted context omitted.

Who said anything about Java bytecode? Java bytecode != bytecode. "I don't want this at all. That's too close to ActiveX for comfort." It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today. In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the…

I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).

It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.

Re: Dart language

#400

Post by SteveMcQwark »

masklinn wrote: post #237
4ad wrote: post #130

Earlier quoted context omitted.

Look at how C++ handled external feedback and what it became because of this.

There's kind-of a gap between accepting all external feedback (C++) and dismissing all of it (Go) don't you think?

The Go team has actually reacted to a lot of feedback. They just haven't made sweeping changes to the language willy nilly at request.
Post reply on HN