Seems like most (all?) people in this thread are not picking up on the key insight that he's putting forward here -- which is the encapsulated process & security capability model that was in E.
I think he's absolutely right that the "right" replacement for JS is something built on that kind of foundation. It's not a matter of a language with a better syntax or a better arbitrary runtime like WASM, or whatever. It's the component and security model itself.
Unfortunately 30ish years on, people still don't seem in general to understand capabilities and what this can provide for us, especially in a environment with the trust model of the browser, which is executing arbitrary code from all over.
I encourage people to read up on caps, and actually on E itself.
I'm glad to see Fuchsia running with the capabilities baton. And it's in a lot of devices in the form of SeL4. But almost never exposed as an aspect of "end user" programming.
>Unfortunately 30ish years on, people still don't seem in general to understand capabilities
That's because they think they've seen it, and what they saw was horrible.
First was the UAC stuff in Windows Vista that caused no end of unnecessary headaches. Next was all of the permissions flags (capabilities) in their phones in the name of "security"
It's a Java/Javascript situation. I'm not sure what the best way to route around this is. Recently I've used these analogies:
Cash in a wallet - if you hand someone $10, there's no way that it can lead to a loss of more than $10, as opposed to access to your entire wallet
Circuit breaker / Outlet - An circuit is only capable of delivering up to the limit of the circuit breaker that is protecting it
Yes the conceptual model behind capabilities is perhaps the hardest part to understand fully, and completely translate back to end users. We're so used to this "identity" and "API" separation now, we just take it for granted. And I suspect it has a lot to do with our own mental modeling of problem domains like they're hierarchical social problems. Administrator is the King and He Can Do All. Others are Serfs. Whatever.
The notion that the "handle" or "reference" is the capability and the API itself is the 'permissions' layer is harder to explain maybe. I still struggle fully with the vocabulary around it.
Capability Based Security - No, you really don't know what it is (like Java/Javascript, there's confusion.. it's not Windows Vista UAC, nor the flags for apps on your phone, not even AppArmor or SElinux)
Currently, when you start your favorite GUI based editor, and tell it to open a file, it calls on the OS to present a dialog box, who chooses file(s), those names are then passed back to the editor. The editor then uses the users permission to open the file(s), and allow you to edit your data. Note that there is NOTHING stopping the program from getting confused or malicious and opening any arbitrary file using that user's account.
The exact same workflow happens in a Capabilities based OS, except the names of the parts and constraints (that you don't see) are different. It works exactly the same, as far as the user is concerned.
Instead of calling on the OS to present a dialog, then directly accessing the files, the program calls the OS to present a PowerBox to the user, and it returns capabilities to files or folders, the program has NO access to any other folders or files. No matter how confused or rogue the editor can not corrupt anything outside of the objects specifically chosen by the user.
WASI and the WASM component model proposal [1] are moving to a capability based system (enabled by unforgeable references aka `reftype`) and to isolation between different parts of your code, which would make isolating and restricting dependencies really easy.
Combined with interface types (essentially a universal cross-language ABI) the ecosystem has the building blocks for building very secure systems.
Sadly progress has been very slow, with no end in sight, but I remain hopeful.
Agreed. I have been watching this as well a bit, esp as the startup I'm now working at is working in the "hosted WASM" area. But it still seems early days. And not clear if their goals correspond to mine (WASI doesn't fit their/our use case generally, but a lightweight component model for WASM does).
Probably I should watch this more closely, or see if there's a reasonable way I could get involved.
I still think there's a long rough road to "get there from here" in the context of the browser though, which has already defined its own (non-capability based) security and component model. Luckily what I work on right now doesn't involve the browser.
Hear, hear. Many, possibly most, security failures I see reported seem to be at least related to ambient authority-type sins at one level or another. If only that was widely recognized after all this time.
In your opinion, what expected changes in JavaScript are going to be the most important?
"The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language, which should look more like E than like JavaScript."
Well he is right about that, the amount bloatware in terms of frameworks, libraries. I wish JS would have better goal or vision than to just make it like all for one kind of language mentality. These JS committees are hell bent on creating browser OS so they could eventually force everything to subscription based garbage software in running browsers requiring 64GB of ram. I guess we might be headed for those future sooner than we think.
PS: Sorry for grim outlook but it kind makes sense from business perspective.
If you count frameworks and libraries, I agree that the amount of bloatware is insane, but I don't think this is because of JavaScript. It's just that a few large companies which happen to use JavaScript (as most tech companies do) have been pushing their complex frameworks and tools onto everyone else and these happen to be bloated; they're only really effective in an environment where the employee headcount is not a concern - The real purpose of bloated tools (which are obsessively focused on 'code safety' as opposed to good architecture) is to allow companies to throw 10x more employees at a problem and not reduce the reliability of their development processes... But if they had chosen to hire better employees in the first place (with better hiring processes), they wouldn't need 10x more employees to get the job done in the same amount of time.
Framework bloat is community-scale efficiency. [Everybody uses a different 20% of the framework](https://www.joelonsoftware.com/2006/12/09/simplicity/), but it means that the core infrastructure, team, QA, etc are pooled. If you need to expand to 21% you already have that covered. If you look at the popularity of Spring Boot you see that people want more integration and between libraries not less. Now, it drives me nuts and definitely offers many sub-optimal solutions, but we need to face it, large frameworks are here to stay. Large frameworks are the new operating systems. You can do better with custom on bare-metal but there is a reason the Linux nevermade it on the desktop.
He knows perfectly well there is zero chance JS is going to be retired. It certainly has some serious flaws but the ecosystem is only growing richer by the day. Typescript plus React/Svelte/Vue etc is an extremely productive development experience.
In order to displace an entrenched technology it's not enough to be marginally better. You need to be an order of magnitude more productive to get people to pay the switching costs. None of the proposed JS replacements meet that criterion.
You basically just summed up what he said. He's referencing the security model and defining a common interface across browsers. Sounds order of magnitude-ish.
it will probably be replaced as part of a paradigm shift on the order of the web itself. what that will look like is hard to say, but maybe it will be a move towards more privacy oriented computing or high level specification languages for self-programming computers.
Mr Crockford has done a lot for the JS world, but I think he's on the wrong track. The best thing we should be doing is focusing on building a best-of-breed VM replacement in WebAssembly where the language is disconnected from the page itself.
Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.
There was NaCl, PNaCl by google. Didn't fly though, i think because there was no fallback possible. Near-native performance (within 10% margin), any concurrency you can think of. Played Bastion game in browser on crappy old macbook Air many many years ago
PNaCl was a terrible, terrible hack on top of LLVM's intermediate representation. The only good thing that came of it was paving the way for WebAssembly.
This is worse, the runtime overhead will always persist. It's nature is to be secure, not fast. It can be faster than JS in instances where you're doing heavy lifting of memory/algorithms. But that is limited to languages like C/Rust that are compiled directly without need for a runtime.
There's no such thing as "not secure" for web-based languages. If the language is not secure, it's simply a non-starter. You cannot bolt on security to the web. You simply cannot build with "fast" as a primary motivation.
It's a spectrum. JIT is inherently insecure, but is "secure enough" given other guards. We use it because it's fast, at the added risk.
We can infact make things provably safe within certain contexts. But we don't, because it's hard, and it can never perform as well.
Wasms safety is dependent upon the runtime implementation, not the language.
"Fast" is a motivation in web. If it renders slow, it loses money. We have 20 years of hacky methods to make JavaScript fast. These lead to security flaws.
I don’t think its popularity (other than obviously dead projects won’t get updates).
‘Growing a Language’ by Guy Steele is probably more relevant than ever here — and for all the dislike Java as a language gets, it is remarkable in how lean it remains even today, resisting the urge to add everything and the kitchen sink.
While I call myself literate in C++, I often chuckle when I see the latest round of C++ features in a new draft. I can write C++, but not using all the stuff introduced in my lifetime.
I have no idea how anyone could ever keep up with all this stuff. The language spec just grows ever larger each year. It's just far too much.
Imagine if all the authors of C++ compilers got together for an international symposium and some catastrophe struck. Like a gas leak causes an explosion and they all die tragically. I could absolutely see the language transitioning to being an anachronism. All the knowledge to actually work on the language implementation would be lost. We could still maintain existing software in C++ for a while, but eventually we'd even need to use legacy systems just to host the compilers.
C would really need some serious overhaul as it still can’t be used to implement even the most basics of zero-cost abstractions, like sane strings or a vector. So I’m not sure it’s a great example.
Being pedantic, it is either true and completely useless, xor false. Feel free to believe any of the options, it won’t make a sane vector implementation in the language possible for generic datatypes.
Your statement that C cannot be used to implement zero cost abstractions is factually false. There are no other options here. You said something that is incorrect.
JavaScript is far too popular to be retired any time soon. It may be that one day it will go the way of Perl - still used in niche areas, even still maintained as a language, but effectively replaced in the mainstream by something else - but it's going to be around for a long, long time.
The JVM + applets were supposed to be the future. Flash was supposed to be the future. ActiveX, Silverlight, OpenLaslo, etc.
HTML, CSS, and JavaScript have so much momentum behind them. They are each a warty mess, but upon that warty mess is built the foundation of the worldwide information ocean.
The worst thing about javascript is all the legacy cruft, but if you could get everyone to agree to replace javascript with something else you could probably also get them to agree to break support for legacy stuff to clean up the language.
"We have a time every morning when the team gets together and reviews all of the code and designs that were developed the previous day."
That seems much better than the mandatory code reviews that are pervasive nowadays. Most of my annoyance with those is the mandatory part - I think it increases the threshold to make small improvements sufficiently that they either don't happen, or happen together with unrelated changes, which is then a reason for the resident purist to scold you. I also think doing them asynchronously, as a form of email, rather than in-person or video introduces friction unnecessarily.
Amiga E was pure distilled productivity, built in a way that it wouldn't make sense anywhere else but on an Amiga. I wish there was an equivalent on modern systems.
It's already happening isn't it? When WebAssembly gets direct DOM access, there will be many contenders to JavaScript's throne, e.g. Rust or some superset of AssemblyScript. Perhaps TypeScript will eventually transpile directly to WebAssembly.
Well I'm reading between the lines a bit, but one of the WebAssembly high-level goals [1] is to "access browser functionality through the same Web APIs that are accessible to JavaScript" and "Once GC is supported, WebAssembly code would be able to reference and access JavaScript, DOM, and general WebIDL-defined objects."
For me, the most valuable part of this interview was -
In filmmaking, there is a time in the morning called "dailies", when the previous day's footage is examined. It looks like everyone is just sitting around watching movies and wasting time, but it is critically important in finding problems early and assuring the quality of the product. I believe that we should do the same thing in programming. We have a time every morning when the team gets together and reviews all of the code and designs that were developed the previous day.
The benefits are obvious. As an individual, you collect professional experience points faster by reviewing the work of others. As a team, you have more eyes looking for errors and faulty designs and giving praise for good work and instruction where needed.
It is easy to convince smart programmers to adopt this practice. It is harder to convince managers because the code reading time looks like lost time. But it is not. It is explicitly scheduling quality into the process. It usually does not take much time because we can not write that much code in a day. It can only work if management requires it and it becomes part of the culture.
The Bushnell anecdote is pretty funny. Especially considering Bushnell was famously offered a 1/3 stake in Apple for $50K and declined. Who knows how that might have changed history, but 1/3 of Apple today would make him the richest man in the world by a mile.
I think he's absolutely right that the "right" replacement for JS is something built on that kind of foundation. It's not a matter of a language with a better syntax or a better arbitrary runtime like WASM, or whatever. It's the component and security model itself.
Unfortunately 30ish years on, people still don't seem in general to understand capabilities and what this can provide for us, especially in a environment with the trust model of the browser, which is executing arbitrary code from all over.
I encourage people to read up on caps, and actually on E itself.
I'm glad to see Fuchsia running with the capabilities baton. And it's in a lot of devices in the form of SeL4. But almost never exposed as an aspect of "end user" programming.
EDIT: obligatory WP links: https://en.wikipedia.org/wiki/Object-capability_model and https://en.wikipedia.org/wiki/E_(programming_language)