Benvie

"Null" is such a great name for a cat.

All iterable objects (Arrays, Strings, TypedArrays, Maps, and Sets) come with the same set of iterator-creating methods (keys, values, entries).

The ES6 spec draft is in its final stages of being revised. At this point there shouldn't be any substantial developer-facing changes except to a few final things that are being ironed out (mainly modules).

The features that are being shipped in Firefox are ones that are stable in the draft spec and not expected to change. At the point of spec stability, these features need to be actually tested in broader distribution to help find any potential compatibility corner cases, similar to the issues found with Array.prototype.values [1].

[1] http://www.esdiscuss.org/topic/array-prototype-values-breaks...

At one point we made the flow for connecting to Facebook pretty ambiguous, where "Skip" meant yes and "Continue" meant no.

Wow wow wow. That is beyond ambiguous into downright misleading. I've always stayed away from these games because I largely don't find them fun, but now I have the additional reason that they are trying to fuck me from the moment they are installed. I didn't realize it was quite that bad.

It does make me wonder, what things have I said about somebody's creation and then have them come along and see it

I passingly wrote some disparaging remarks in a github issue about the ES6 binary data strawman spec written by Dave Herman, pretty much out of my own ignorance, only to get a message from him a few months later asking for feedback on it and what I thought was wrong.

By this point I had learned more about the topic and reading the spec language and knew enough to know I had just been an idiot. I ashamedly responded with an apology and basically told him that my criticism could be ignored because it came from my lack of understanding and not a real problem with the spec.

I think he meant there's no difference between being unemployed and just starting as 1099, since there's basically no taxes paid to show you're making any income for a while.

Michael Crichton had this shit working for Congo with apes like two decades ago. This is nothing! hacker news dismiss w/ flourish

At this point, developer tools are essentially a required feature for a browser. All else aside, there's no way to debug a bug that's specific to a single browser without tools integrated into that browser.

const tail = ([, ...xs]) => xs;

Also Douglas Crockford worked at Yahoo.

Every JavaScript engine has its own implementation of the JS standard library. V8's, for example, is almost entirely implemented in JS itself, while SpiderMonkey's is implemented mostly in C++ (though is migrating to more self-hosted in JS).

All of these things are coming as part of the next version of JavaScript, ES6. Proxy is available in Firefox and Chrome behind a flag. Function.prototype.@@create/@@hasInstance is in the ES6 spec.

Also Tachyon is a full JS engine built in JS. It's incomplete but has the ability self-host itself and JIT compile machine code (all written in JS), so it gets bonus points to offset the fact that its implementation is incomplete https://github.com/Tachyon-Team/Tachyon

Well RPython is just that: a restricted subset of Python (hence the name). Similarly, asm.js is a (small) subset of ECMAScript targeted at compile-to-js code generators. It's just about specifying what the subset contains, not inventing a new language.

You need to do things like not dispatch to valueOf and toString for coercion. You basically just need to get rid of dynamic coercion dispatch, and do what you said (annotate types) and that's all that's really needed. But the ECMAScript runtime is pretty substantial so having a minimized subset of that runtime would make it possible to self-host most of the higher level interpreter in ES6-like code instead of having most of it implemented in ES3 (as it is now). This makes a significant difference in verbosity of the code. As converted to ES6, I estimate the code would be half of what it is now (currently it contains ~23k lines of ES3 code, 7k lines of ES6 code, so 30k total).

Caja and Narcissus are definitely comparable parallels, but Continuum is unique in that it fully implements the ECMAScript object model, runtime, and standard library (except for a few things which are still in progress). I would say that Continuum is the only one that qualifies to be called a "JavaScript engine" in its own right.

Narcissus is a meta-circular interpreter that puts a thin layer over the host engine, and requires that host engine itself to have some ES6 features (it can only actually run in Spidermonkey and V8 with the --harmony flag enabled).

Caja is more of a wrapper that protects access to capabilities than anything. In fact it specifically avoids fully parsing source code itself in order to be performant. Its goal is to sandbox code, not interpret it.

Continuum implements the ES6 Object Model and nearly fully implements the internal algorithms of the ~450 page ES6 specification (aside a small handful of things which are a bit out of date or remain to be implemented). In fact, the only thing it does not implement itself is RegExp, which it currently wraps the host engine's functionality to provide. It even fully implements the Date internal algorithms (https://github.com/Benvie/continuum/blob/gh-pages/engine/bui...).

Additionally, it self-hosts much of its own code. All of the ES6 standard library is itself written in ES6 (https://github.com/Benvie/continuum/tree/gh-pages/engine/bui...) and is executed in the virtual machine each time a realm is created. Roughly 25% of Continuum's code is written in ES6, while the other 75% is written in ES3 (I plan to reverse this ratio in time).

I had considered this, but it would also require the other end of it. RPython is basically compiled to C which is compiled to machine code. The ultimate output format for this needs to be JavaScript, something like the form specified by https://github.com/dherman/asm.js. So we need JavaScript (ES6) coming in one end and asm.js coming out the other end. At this point the only remaining usable pieces from PyPy are the processing that happens in the middle. Admittedly this is a huge part of it and would still be very valuable to have access to, but there's probably a better approach to this than having to redo both ends of the pipeline, and losing the ability to self-host the compilation process in a JavaScript engine (browser).

Perhaps pairing PyPy with emscripten would be the ideal solution for this, but that would have to be a completely new project because nothing that's currently in Continuum would be useful for that (except probably the standard library that's written in ES6 and executed in the VM).

Most useful features in CoffeeScript have been co-opted by ES6 and its proliferation will put pressure on CS to innovate some new features or become much less relevant. The "ideal" JS code near the end of the article almost is valid ES6. The following is valid ES6:

    var leftPartial = (fn, ...args) => function(...remainingArgs){
      return fn.apply(this, args.concat(remainingArgs));
    };
    

The actual code generator I haven't published because it was kind of a pile of crap. I created bindings to libclang as well here but haven't finished rewriting a more generalized code generator from it https://github.com/Benvie/node-clang/blob/master/bindings.js

This is the beginnings of a wrapper around various windowing Apis to create a Window class https://github.com/Benvie/node-Windows/blob/master/Window.js

This is the beginnings of a windows registry library https://github.com/Benvie/node-winreg

This is an example of creating a windowless event loop in order to create a low level keyboard/mouse hook https://github.com/Benvie/node-Windows/blob/master/input.js

The important bit is that this is THE core abstraction used in node and the node community. If for no other reason, you should do it (if you're using node) because it's how you hook into the existing libraries.

The main benefit here isn't that it's possible to do this thing, as many people pointed out the myriad ways this is accomplished elsewhere. The key point is that everything that manipulates data, node core as well as the userland libraries, implement the same interface.

For the love of god just give us the tools for effective persona blacklists. With Google's constant changes to the search site and the difficulty in efficiently and effectively monitoring live search results via browser extensions, it's been at best hit or miss. Whether that comes in the form of some API that can be tapped to make a good extension or having it built into the browser, I don't care.

Google of all companies I would have thought would understand and respect the important of giving people the power over their own technology experiences.