321–330 of 504 posts
Unless the compiler is improved a lot, dart->js' runtime overhead probably makes it impractical for any app less than gmail-size.
Earlier quoted context omitted.
Airplane: move people from point A to point B. Boat: move people from point A to point B.
Voiture: transport des personnes du point A au point B Car : move people from point A to point B
Systems language and web language are not just a different name for the same thing --like Voiture and Car.
And, no, that their function defined in abstract and in totally generic terms is the same, doesn't make them the same thing.
"move data from point A to point B" can be said for any programming language. As such, it's not particularly enlightening when comparing a language's suitability to a specific task.
Turing-completeness aside, your argument misses the point that a particular language's design, compiler, library, toolset, (heck, even a particular language's community) can make it better suited for system programming or for web programming or for some other field.
I was hoping for something like the Dylan language. http://en.wikipedia.org/wiki/Dylan_programming_language It was created in the 1990s and it still looks innovative, even compared to a lot of the new 'hot commodity' languages like python and ruby. I knew it wouldn't happen. If a big corporation like Google put money into something like that, I think it would dominate the market. But what they have delivered here isn…
Dylan could have been what Objectiv-C is now. It was an awesome project it just had bad timing.
Earlier quoted context omitted.
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…
Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever.
"On mobile devices, loading a lot of Javascript is expensive"
I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this?
"could be atleast partially statically optimized for a particular device platform"
I don't want this at all. That's too close to ActiveX for comfort.
"wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)"
You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.
Earlier quoted context omitted.
someString.append(System.getProperty("line.separator")); vs some_string += "\n" Edit: Someone's in disagreement with me, so I'll try and clarify. I'd classify boring code as code where the intent gets lost in the syntax/language or other constructs the maintainer of the code doesn't care about but are required anyway. Trying to open and read a file in Java is probably a better example as the intent (open this file an…
Well, for one you can probably make your own "+=" for strings, if not available, since Dart has operator overloading. Also, System.getProperty("line.separator") does not translate to n"\n". The first makes your program more portable. Of course it could be made accesible easier, eg as a constant System.NEWLINE or something. [UPDATE] Downvote? Really? Because someone thinks "\n" is the same as "line.separator"?
Earlier quoted context omitted.
Oddly enough, if in-browser Java had "won", we'd already have such a thing.
True. But in return we would have had to endure 10 years of in-browser Java.
It was really sad to see everybody moving to Flash JavaScript could've done video/audio and games a long time ago.
A question to ask yourself: If this had been Microsoft creating an IE10-only language to replace JavaScript, instead of Google, would you feel any differently about Dart?
But if they released an open-source version of IE, started shipping IE frequently for Windows, Macintosh and Linux and released the Dart language spec and implementation under an open-source license... well, then I'd like it a lot better.
The thing I was really hoping for from the dart site was an "about" section, or a "why" section, explaining about the language and their goals, instead of just jumping to code examples...
That's a fair point, but it's pretty annoying when you read about some cool new language but you can't find any good sample code anywhere. anic and newspeak come to mind.
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…
Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is. The keyword Brendan used was "de…
Sorry to be critical, but this looks like technology for technology's sake.