Dart language • Hacker News Board

Re: Dart language

#401

Post by cromwellian » Mon, Oct 10, 2011, 8:16 PM UTC

masklinn wrote: post #229

cromwellian wrote: post #151

Earlier quoted context omitted.

Well to be fair, the language it is replacing for the most part works, it's mostly just patching up problems: ability to optimize for startup performance, ability to program in the large, and ability to write tools easily (IDEs, etc) Most new programming languages are really just variations on those that came before them. You've got you're LISP derived, your Forth/Stack derived, your APL derived, your ML derived, etc…

> Well to be fair, the language it is replacing for the most part works They clearly disagree, since instead of taking part of cleanup/improvement efforts (e.g. Harmony) they decided to build a brand new language from scratch. > Here I think is where Dart hopes to excel -- make a JS-like replacement that supports a better runtime and tools story. I fail to see why that would happen, from what I've seen so far there's…

Google's build the Android Development Environment for Eclipse, the Google Plugin for Eclipse (AppEngine and GWT integration) and Dart already released an Eclipse environment, and a compiler. So the history seems to be that Google supports tools.

Google is taking part is JS cleanup efforts, but it's a large company with 20,000+ employees, so it has the reasons to pursue many different paths: Closure, GWT, Dart, Go, etc.

As for runtime improvement, if the team who has built the one of the best/fastest JS VMs (V8 team) says the language semantics allow them to do better, I think we should listen.

The early binding alone allows for substantial improvement. If all classes are early bound, then you can significantly optimize dead code, you can know object layouts immediately on load, you can detect effectively non-virtual methods immediately, and so on. You can pretty much snapshot important information that you normally have to discover each and every time you load the application.

Re: Dart language

#402

Post by rayiner » Mon, Oct 10, 2011, 8:16 PM UTC

zohebv wrote: post #147

mda wrote: post #120

Earlier quoted context omitted.

Could you enumerate what actually made you hate it? Familiarity is not necessarily a bad thing, and it seems it was one of the main goals of the language.

This http://www.dartlang.org/docs/technical-overview/index.html 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 inter…

Almost none of those things are relevant to a dynamically-typed language. If you want a statically-typed language use a statically-typed language.

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.

Re: Dart language

#403

Post by icebraining » Mon, Oct 10, 2011, 8:18 PM UTC

josephg wrote: post #224

icebraining wrote: post #116

Earlier quoted context omitted.

The key part is (...) compared to having the Dart VM in the browser. 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 fas…

> In fact, if VM is not much faster, why would they have it at all? 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.

No, I was asking "why would they have [the VM] at all?"

If the VM wasn't (much) faster than the Dart-to-JS compiler, there would make no sense to have both.

Re: Dart language

#404

Post by pacala » Mon, Oct 10, 2011, 8:22 PM UTC

dextorious wrote: post #378

pacala wrote: post #371

Earlier quoted context omitted.

Avion: transport des personnes du point A au point B Boot: Menschen bewegen von Punkt A nach Punkt B We are talking past each other :) Here is your first comment interpreted through your second one. There is no reason to have different languages, but it's OK to have different jargon.

I might not get the joke. Do you mean this ironically? There sure is reason to have different programming languages, and it's called specialization (see: necessary engineering compromises). My first comment says: two objects having the same generic functionality, does not mean that one and the same object can implement their specific (non generic) functionalities. My second comment says: the same thing, basically.

I mean that (programming) language is a special kind of object that has enough versatility to express any idea in a reasonable form. Historically, our programming languages weren't that good in versatility and made various utterances an universally agreed on pain. But we are getting better and there is no law in the universe saying that we'll be forever stuck in Babel.

To some extent, your point is that Shakespeare is better in English than in its German translation for style reasons. My point is that it doesn't really matter and that an universal language is better than Babel because of network effects. Life is too short to erect artificial communication barriers.

Re: Dart language

#405

Post by Someone » Mon, Oct 10, 2011, 8:26 PM UTC

phillmv wrote: post #314

nzonbi wrote: post #156

Earlier quoted context omitted.

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…

Can someone explain to me what's the point of having syntax like: `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?

Nitpick: you can make a constructor look like a regular method that happens to return a new instance, but you cannot make it one. How would that constructor make the instance that it returns?

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.

Re: Dart language

#406

Post by munificent » Mon, Oct 10, 2011, 8:50 PM UTC

chintan wrote: post #338

cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

IMHO, this is not a "break away" approach as originally indicated in the leaked memo. One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.

We are definitely trying to improve the DOM API with Dart, but, for performance reasons, ditching the DOM and starting over from scratch in Canvas doesn't really fly, at least not in the short term.

Re: Dart language

#407

Post by phillmv » Mon, Oct 10, 2011, 8:51 PM UTC

Someone wrote: post #405

phillmv wrote: post #314

Earlier quoted context omitted.

Can someone explain to me what's the point of having syntax like: `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?

Nitpick: you can make a constructor look like a regular method that happens to return a new instance, but you cannot make it one. How would that constructor make the instance that it returns? 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, ma…

>but you cannot make it one

Why not? It makes no difference whatsoever. Make it so that the only constructor in the system is Object.new(), and so everything else that inherits behaves just like a method.

>Without it: in var foo = Bar(), is Bar a type or a function?

That's easy. Make it so that only classes and consts can be capitalized.

Blammo!

Re: Dart language

#408

Post by munificent » Mon, Oct 10, 2011, 9:01 PM UTC

equark wrote: post #152

munificent wrote: post #107

Earlier quoted context omitted.

Type inference is a tooling feature, not a language feature for Dart. The tools can do some type inference now, and more may be added later. At the very least, I personally really hope we get fully inferred local variables.

You really need to make a list of these types of response on your webpage.

Good idea. At some point, we'll probably harvest a bunch of this and put together a FAQ.

Re: Dart language

#409

Post by cromwellian » Mon, Oct 10, 2011, 9:27 PM UTC

BrendanEich wrote: post #397

cromwellian wrote: post #353

Earlier quoted context omitted.

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 Mozil…

You accuse me of trollish behavior, yet resort to personal slights, asking how old I am? Irony. Did I ever question your age or intent? I am fully aware of Microsoft's behavior, but that still doesn't address the fundamental issue that language evolution within spec committees is painfully slow and the competing interests waterdown proposals. It happened to C++ and to Java too. It happens in our government as well, we often don't get what's best or right, only what you've got the votes for.

The issue is whether or not any large changes can be pushed through in a timely manner, if the need arises. I've seen, over several threads, you seem to simultaneously stress the idea that Javascript performance is good enough (vs native), a Dart VM performing better than JS is a problem, and that whatever performance problems there are, they'll be resolved by better JS VMs. Not only are those hard to reconcile, but it requires a great leap of faith to believe that they will, because we've heard it all before. We've heard the same arguments about Smalltalk performance, about Self performance, and of course, the JVM, that the performance differentials will be tackled.

As for the language ecosystem on the server, yes, it's wonderful, but happened in spite of the JVM, not because of any evolution in it. The fact remains, Java changes were often evaluated towards remaining binary compatible with existing bytecode (e.g. erasure vs reification) and that caused the vote down of language proposals. (the same problem did not occur in C#/CLR)

My question is, when can I write a mobile web app using Javascript, that performs as delightful, in startup time, in runtime performance, in lack of janky-ness, for a mobile device, that doesn't burn battery or memory? Are you promising that evolved JS is going to fix this issue?

Re: Dart language

#410

Post by wbhart » Mon, Oct 10, 2011, 9:41 PM UTC

cromwellian wrote: post #297

wbhart wrote: post #268

Hmm. print('${(1 print('${(1 print('${(1 print('${(1 (I've used x instead of star here as the latter does not display on HN.) This is completely nonsensical.

It has the same numeric semantics as Javascript. Javascript does not have a 64-bit integer.

From the Dart documentation:

"Integers are not restricted to a fixed range. Dart integers are true integers, not 32 bit or 64 bit or any other fixed 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.