81–90 of 266 posts
What's the point of "Map" and "Set" in Javascript? Objects can already act like either.
(HN Thread: https://news.ycombinator.com/item?id=4629544)
Hope they have the video out sometime! Seems to be some crossover with his keynote at Fluent: http://www.youtube.com/watch?v=Rj49rmc01Hs - but these slides go into a lot more depth and include some of the newer goodies coming along.
The fact is that adding classes to JavaScript fundamentally alters the lispyness of the language in a detrimental fashion. I don't want to see JavaScript turned into Java script.
I think there's a lesson from C and C++: don't add complexity unless it's absolutely necessary.
> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross-browser bytecode alternative to Javascript, preferably running in a VM accessible outside of a web browser.
For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download, and it may mean that the GC can't do all the low-level things that modern GCs do to get good performance. Is this an acceptable tradeoff for the web? I believe questions like this one are the important ones.
"We require opt-in to avoid future-hostility against custom iterators for collection objects. Such objects probably do not want any kind of general property iterator default, which if left on Object.prototype, might be object-detected and prevent installation of the correct custom iterator factory."
I can see the sense in that but I find all the little caveats in JS are one of it's weaknesses which makes me dislike this idea. Am I wrong to think they should have just put in a default iterator but made it easy to spot it so that you could replace it with a custom iterator where appropriate?
The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical scoping.
Language designers tend to incrementally add junk to languages until they are complex, unweieldy monstrosities like C++ or Java. Rarely do they fix fundamental errors in the language because that would require backward-incompatible changes. So they stick to adding lipstick to the pig. But JavaScript isn't like other languages: its fundamental errors are so glaring, and impact so negatively on the language, that the benefit of jumping to a "JavaScript 2.0" massively outweighs its incompatibility disadvantages. That's why we see languages like CoffeeScript cropping up despite all their downsides, notably debugging.
The class bit particularly made me sad: JavaScript has a perfectly cromulent, even elegant, object model in the form of prototypes. But a variety of syntactic sugar hacks, weird constructor stuff, and general desperation to be a class-based language have sullied what would otherwise be an elegant mechanism. The solution appears to be: move more towards classes! Thus we still have all the language hacks, and two generally incompatible object models to boot. Plus structs!
Somehow after reading this presentation, I was struck with Yoda's admonition: Eich seems to be looking to the future, never his mind on where his language was.
> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
Rust is never going to be part of the Web. Content will never be able to execute Rust code. If Mozilla had been proposing to integrate Rust as a potential client-side scripting language (which wouldn't happen to begin with), the process would have been totally different.
> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
Rust is never going to be part of the Web. Content will never be able to execute Rust code. If Mozilla had been proposing to integrate Rust as a potential client-side scripting language (which wouldn't happen to begin with), the process would have been totally different.
@pcwalton Please assure me that rust won't compile to javascript, and it will remain Native (C/C++ compatible, ahead-of-time). Rust is my last haven, let it remain rust only!!
Kind of annoying presentation style quirk: but some slides are on a vertical stack which you can access by hitting the down arrow instead of going right. You can tell in the bottom right which directions are available from the slide you're on.