“Both Doug and I had a lot to do with the birth of the language,” Miller told us. “We were quite in love with the language that we had created.”
Miller considers the language itself dead — an open source language, E never attracted more than 100 users to the community, he said.
12 Angry Men and ECMAScript
“Have you seen the movie 12 Angry Men?” Miller asked me. I have, I replied. “I think that movie is the best way to explain what the ECMAScript committee was like at the time that I joined Google.”
Crockford convinced Miller to join the committee in 2007 as an additional Google representative. The committee was focused on upgrading ECMAScript 3 to ECMAScript 4 but it wasn’t going well.
“The committee had been meeting continuously from 1999 to 2007 at this point, and they still did not have a successor standard. Most of the committee was focused on ECMAScript 4, which in my opinion was a horrible language,” Miller said. “Doug started off as the one holdout — the Henry Fonda character saying, ‘No, we will not agree on this.’”
“I joined his revolt against ECMAScript 4, and that revolt had several other members by that time — just like in 12 Angry Men — he incrementally convinced the jurors to come over to his camp,” Miller said. Eventually, the revolt won. The successor to ECMAScript 3 became ECMAScript 5, the version designed by the revolters while the rest of the committee focused on ECMAScript 4.
One fundamental aspect of E they brought over in ECMAScript 5 was support for the object-capability security model, he said.
In ECMAScript 5, they introduced several enablers, the primary being Object.freeze(). Despite its name, it has nothing to do with immutability, Miller said. Instead, it tamper-proofs the surface of an object so that the clients of the object can now only interact with the object — according to the object’s explicit behavior, Miller explained. The provider of the object can populate it with methods that capture internal state variables and can encapsulate that state, so the clients of the object cannot tamper with it. By “freezing,” what’s meant is that the properties of the object can no longer be changed, he added.
“The client can no longer change the shape of the object. So the shape of the object is fixed. The internal state is now hidden from the clients,” he said. “Now the object becomes something that can only be interacted with according to the object’s design.”
The SES-shim library, at the beginning, when it initializes, does some repairs on the primordials, then hardens all of the primordials, he said. That ensures all of the implicitly shared objects are now genuinely immutable.
“We did some repair on the committee so that the primordials didn’t have any hidden mutable state or hidden I/O abilities,” he said.
Everything that was implicitly shared is completely powerless and immutable, he added, so that sharing does not violate isolation.
Those host-provided global variables are not standardized as part of the language standard, but are brought in by the host that provides all of the I/O abilities for affecting the outside world or for sensing the outside world.
“A promise is an object returned by an asynchronous function. … the promise object provides methods to handle the eventual success or failure of the operation,” explains MDN web docs. E in a Walnut explains promises in more detail. Essentially, in promise systems before E, the calling thread would at some point block, waiting for the operation to complete. In much the way one wouldn’t wait for someone to finish a task on a project before beginning to work on one’s own tasks, E’s non-blocking promises made it possible to handle the eventual success or failure of the operation without blocking to wait for the resolution.
”I do not see it as a lost cause,” he told The New Stack. “I’m very proud of what we’ve continued to accomplish in the efforts of the committee, enabling us to use it as an E-like distributed secure language.”