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

The State of JavaScript - Brendan Eich

brendaneich.github.com

Post reply on HN
Print view View original

151–160 of 266 posts

Re: The State of JavaScript - Brendan Eich

#151

Post by BrendanEich »

ianb wrote: post #148
_jmar777 wrote: post #99

Earlier quoted context omitted.

I think you're being too hard on JavaScript there. Type coercion, ASI, and function scoping are all language features, not errors. Likewise, eval is not an error; it's dangerous, but it's also a feature (and one that nearly all dynamic/scripted languages provide). As Crockford said, "JavaScript is the only language people feel like they don't need to learn to use." That statement alone describes why so many developer…

Eval sure, but the way that type coercion works in Javascript is an error. Boxing in Javascript is an error. You can figure them out, you can code around them, but they are bad and can't be justified. All coercion isn't bad, but some is. Have you seen code that uses .valueOf() for anything good or useful? new String()?

Pre-JIT-compiling JS VM days, I did see new String used intentionally to eliminate auto-boxing overhead on every method called on a big string.

For ES4 (after AS3), we tried eliminating boxing. This is overtly incompatible, a web-breaking change. It won't fly.

Java has primitives that can be autoboxed or explicitly boxed too, which is why JS has them. I was future-proofing for "LiveConnect", which shipped in Netscape 3 (Nick Thompson did the integration).

But I was also in a terrible ten day hurry, so found unboxed primitives easier to deal with in the Mocha first implementation.

If I did not have the "make it look like Java" and ten-day marching orders, I like to think I would have resisted the lazy-programmer second reason. But it's all water way under the bridge now.

Implicit coercions, e.g., '' => 0, were influence by Perl 4. Nuff said!

Re: The State of JavaScript - Brendan Eich

#152

Post by BrendanEich »

_urga wrote: post #66

I would really like support for 64-bit integers and native 64-bit math.

See https://bugzilla.mozilla.org/show_bug.cgi?id=749786 based on http://wiki.ecmascript.org/doku.php?id=strawman:value_object.... ES7 at this point. Help test. I need to put up a rebased patch...

Re: The State of JavaScript - Brendan Eich

#153

Post by saebekassebil »

BrendanEich wrote: post #142
saebekassebil wrote: post #139

Earlier quoted context omitted.

May be off-topic but: Is it just me, or are macros just a new way to get confused while reading JavaScript? Introducing language-foreign syntactic constructs seems to me superfluous and confusing - This is the job of transcompiling languages like CoffeeScript.

Reading the macros first helps. They must be defined at top of program or module, if I recall sweetjs.org's design correctly, for the staged hygienic expansion to work well. Aside from that, you're right. But JS has higher order functions and objects with ad-hoc methods, so it can be used according to many paradigms, which can make it hard for a reader unfamiliar with the dominant paradigm in code at hand. This is no…

Of course, as in every aspect of understanding, here for source code, it is important first to learn the context, here the macro definitions. My concern is that this will impose more than just a paradigm - it will impose new syntax which could effectively completely ruin the readability of JavaScript source.

The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable. Is the overall benefits of introducing macros to JavaScript really worth the costs of readability? And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?

Re: The State of JavaScript - Brendan Eich

#154

Post by BrendanEich »

bthomas wrote: post #79
_urga wrote: post #66

I would really like support for 64-bit integers and native 64-bit math.

What kind of apps would this help with? JS is never going to take over on the server for me until it can compete with Python's statistics support, I didn't see much in these slides that suggests it could.

Is the lack of bignums (more than int64) the real issue? JS has IEEE754 binary double so that's the same as in Python.

Library code can be cross-compiled a number of ways, so I wonder whether the blocker is the lack of Pythonic long.

Re: The State of JavaScript - Brendan Eich

#155

Post by aplzrtve »

BrendanEich wrote: post #149
haberman wrote: post #138

Earlier quoted context omitted.

There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to…

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel. Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I…

These are shallow arguments: * pepper is "inspired" by nsapi, clarify your point. * PNaCl performance lagging isn't a solid argument, you know it'll get better, the solution might even be to cut LLVM out save for bitcode. * "nobody does this at the moment" so why does it belong in the OS?

Re: The State of JavaScript - Brendan Eich

#156

Post by colin_jack »

BrendanEich wrote: post #130
colin_jack wrote: post #85

This is from the a section on custom iterators in the related blog post ( https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ): "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…

Python does not have a default iterator for its objects. It does for dicts of course, but JS objects are not dicts (lots of issues there).

I would just think default iterators are a sensible default especially for maps and that getting them in would be worth the very slight pain it might cause people wanting to attach custom iterators.

Re: The State of JavaScript - Brendan Eich

#157

Post by BrendanEich »

aplzrtve wrote: post #155
BrendanEich wrote: post #149

Earlier quoted context omitted.

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel. Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I…

These are shallow arguments: * pepper is "inspired" by nsapi, clarify your point. * PNaCl performance lagging isn't a solid argument, you know it'll get better, the solution might even be to cut LLVM out save for bitcode. * "nobody does this at the moment" so why does it belong in the OS?

In reverse order:

* Why in the OS? I didn't say "belong", just "likelier". That is because plugins are native code compiled by OS-dependent toolchains, and OS vendors are few (three that matter) and lock up native code these days via SDK licenses, app store rules, and even kernel-level restrictions.

In contrast, there are four or five competitive browsers, only one of which has Pepper and the rest do not -- and will not.

* I do not know how much better PNaCl can get. The shallow argument here is your assertion that "you know it'll get better". The same could be speculated about JS performance at Emscripten-generated code, and that works cross-browser. That's the cross-browser path of least resistance, compared to the practically unpassable Pepper barrier.

* Pepper is "inspired" by lots of APIs, but here the shallow shoe fits your new-HN-user drive-by. NPAPI is a sunk cost all browsers save modern IE have paid out for years. Pepper is new and much bigger. Have you even read all the interfaces?

The bottom line is that whatever PNaCl performance wins may lie in the future -- and I will believe them when Google does as shown by Chrome Web Store games being PNaCl'ed not NaCl'ed -- Pepper is the blocker for any cross-browser adoption in reality.

This ignores principled objections to more native code on the web, as a "social ill". Let's take that up separately, because it could override any technical argument. I'm happy to stop on the Pepper point for now, since Google manifestly is stuck there.

Re: The State of JavaScript - Brendan Eich

#158

Post by BrendanEich »

colin_jack wrote: post #156
BrendanEich wrote: post #130

Earlier quoted context omitted.

Python does not have a default iterator for its objects. It does for dicts of course, but JS objects are not dicts (lots of issues there).

I would just think default iterators are a sensible default especially for maps and that getting them in would be worth the very slight pain it might cause people wanting to attach custom iterators.

Maps have a default iterator as shown in my slides. Sets too.

Best to take this to es-discuss. For now, we're sticking with Python, which did not give its top-class (non-dict) Object a default iterator.

Re: The State of JavaScript - Brendan Eich

#159

Post by BrendanEich »

jeswin wrote: post #12

I think he missed mentioning the new lambda syntax. Hope it's still in ES6. Also, my pet peeve: there is no language that needs await/defer as much as JS. EDIT: Maybe it could be done with macros, which is on its way.

I skipped arrow function syntax (=> only in ES6). It was a bit much and I wanted to focus on APIs and compilation.

Re: The State of JavaScript - Brendan Eich

#160

Post by masklinn »

debacle wrote: post #97
MatthewPhillips wrote: post #94

Earlier quoted context omitted.

People already use it as though it had classes, so it makes sense to add the sugar. It will prevent errors such as SomeObject.prototype.foo = {} by not allowing data on the class body.

Some people already use it as though it had classes. I don't like those people.

Well it's not very good at not having classes either, due to the constructor mess (and `instanceof` being broken if you're doing constructorless JS as far as I know, which is very frustrating — of course it's even more broken if you have cross-frame objects involved) so...
Post reply on HN