Live data from Hacker News

Dart language

dartlang.org

101–110 of 504 posts

Re: Dart language

#101

Earlier quoted context omitted.

> This looks like Java for Javascript, if that makes any kind of sense. It completely does. And I love that it manages to be completely incoherent with Go, the other "Google Language". That's so symptomatic of what google does on that front.

Weird that a systems language and a web language are different, huh?

One has pointers and no security model and produces binary processor-dependent artifacts, the other has to support untrusted code, mobile code that runs on any device.

Re: Dart language

#102
post #70

Earlier quoted context omitted.

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.

I love Python. I prefer working without semicolons. But from a new language standpoint, it's not worth dropping them. The ridiculous arguments that come out of it, the programmers who refuse to use the language because of it, they're things that can and should be avoided by using semicolons like most languages. I'll never understand why programmers care so much about this, but hey, that's life.

Programmers care about it because it adds extra noise to your program.

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.

Re: Dart language

#103

Earlier quoted context omitted.

You raise a good point. I'd like to see more about testing Dart.

We have a rudimentary unit test framework [1] that we've been using for the samples, though we're still playing with different styles. Personally, I'm fond of the Jasmine-inspired stuff I tried to slap together here [2]. This is of course different from the testing infrastructure for the language itself, which is its own thing. [1] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/#dart%2Fclien…

Thanks! I will take a look at these.

Re: Dart language

#105
I like it. And if they make it work great on the server as well, that's a big plus. A google supported node.js would be great.

Re: Dart language

#106

Earlier quoted context omitted.

From the menu example: document.query("#menu").nodes.add(sliderMenu.node); So, yes, DOM manipulation is there albeit kind of ugly.

Not perfect, but I prefer that over: document.querySelector('#menu').appendChild(sliderMenu.node); If you have suggestions for improvement, please do pass them along.

Bake in a jQuery-like thing, or make it easy to build jQuery-like things, since I would much rather write something like the following in any language:

  $('#menu').append(sliderMenu);

Re: Dart language

#107
post #23

To me this looks a lot like Java but with optional types.

Why didn't they go a bit further and have type inference? They proved already with Go that you can have type inference in a language and still have a fairly light/dynamic feel.

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.

Re: Dart language

#108

Earlier quoted context omitted.

If they're not mandatory, they should be out altogether unless required. Making them just optional is a path straight to js-land weird edge cases.

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.

And pretty much all functional languages get by just fine without semicolons (Lisp, ML, Haskell, etc).

Re: Dart language

#110

Earlier quoted context omitted.

This is not a product launch.

The lack of browser support implies architectural choices that will always make old browsers lag behind. It means that the generated JS uses modern JS features. If it would be easy to support older browsers, they would've done so already - at least to some extent. The fact that it compiles only to JS for the very latest versions of a small number of browsers gives me the impression that a lot of language/compilation…

Or maybe they've only been working on this thing for a few months and were slavishly fixing bugs right up to the announcement, and IE6 support wasn't really a priority?

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.

Post reply on HN