https://futureofcoding.org/ logo
Join Slack
Powered by
JS is an intrinsically fragile language. It is inc...
# thinking-together
i
JS is an intrinsically fragile language. It is incompatible with all the known research on proving programs correct, which is going on in Academia. I don't mind if it is JS under the hood in order to run in the browser; that is a current requirement (which may be relaxed in the future as WebASM evolves). The two main things that will distinguish the next generation of programming languages is 1) creating an ecosystem of interchangeable parts, and 2) drastically reducing the chance for error by the human programmer, which means both on the front side, by having the compiler make it very difficult to make an error, and also when an error does happen make it trivial to fix it. If your code doesn't work, it doesn't matter how pretty/fun it was to make. If nobody can understand your work, or you can't easily share it, then the world will continue to accumulate billions of lines of code. There is so much code today, yet it is very hard to use. So many dependencies crop up, that the final size of projects that one would think would be modest can be staggering. In the regard of interchangeable parts, the software field is way behind the hardware guys. They put in chips all the time that have clear specifications on how they are to be wired up, and they have delivered more than a million to 1 price/performance improvement over the last 25 years. Can software even claim 10:1 improvement over the last 25 years? Thread in Slack Conversation
It is incompatible with all the known research on proving programs correct, which is going on in Academia.
This doesn't square with Elm, or PureScript, does it? Those are languages that seem to do a remarkable job of offering strict guarantees about correctness, despite the alleged impurity of the underlying platform.
which may be relaxed in the future as WebASM evolves
WASM (as it is more commonly known) might serve well as a functional core, but you still need to use JS APIs to do any useful work, and I don't believe there's any plan to change that. My understanding is that JS will continue to be an important part of anything built on the web platform, no matter how much leverage you're able to get from WASM.
The two main things that will distinguish the next generation of programming languages is 1) creating an ecosystem of interchangeable parts, and 2) drastically reducing the chance for error by the human programmer
I'd wager that if you took a survey of folks in this Slack ā€” people who have spent considerable portions of their careers considering these exact issues ā€” you'd find a spectrum of people who vary from strong agreement to strong disagreement with that statement. I, personally, am so far on one end that I'd say I "stringly disagree" with that statement, in that I feel that there's plenty of room for, and benefit to be had from, a return to TCL-style string-based metaprogramming. More, looser dynamism. But I know, without any doubt, that that is just my opinion.
šŸ‘ 1
I'd be shocked if the next generation of programming languages were unified under any one umbrella. That's happened before, sure, but I expect it to get rarer as our technology matures. Rather, as the recent news about Cables and Nodes shows, we should expect every current approach to be furthered equally.
If your code doesn't work, it doesn't matter how pretty/fun it was to make.
There's an implication here that JS doesn't work. Was that your intent?
They have delivered more than a million to 1 price/performance improvement over the last 25 years. Can software even claim 10:1 improvement over the last 25 years?
This is totally an apples-to-oranges comparison for a tremendous number of reasons, but I will offer one angle of consideration that makes the mistake of taking your claim seriously: The number of people who are writing software now.. who are even able to write software.. has grown much, much faster than the number of people who are able to make their own hardware. Make of that what you will.
a
but you still need to use JS APIs to do any useful work, and I don't believe there's any plan to change that
Curious where you source that... Everything I've read makes it sound like the current limitations that require js are meant to be temporary until wasm matures a bit more, not inherent to the design
i
Here's a quote from webassembly.org
WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.
I should have said "Web APIs" instead of "JS APIs". Basically, the APIs that expose browser functionality to your code. Those APIs are designed around JS semantics, so there's probably no escaping some dissonance if you're trying to run a very pure, safe language inside WASM but still actually make something that people can use. (Yes, this is not that different from running a pure, safe language on top of any other platform designed for C or POSIX or what have you.)
I've never heard any mention that there'd be a move to design Web APIs primarily for WASM. I can't point to anything specific, just the impression I got time and again following the "extensible web manifesto" crowd.
a
Maybe I'm overly optimistic, but it seems like it would be a huge waste to define a shared language-agnostic runtime and not start to use that as the fundamental specification of new apis.
i
I can see features designed to offer high leverage to both JS programmers and WASM programmers. For instance, when doing Web Audio, you'd want JS programmers to be able to use a browser built-in reverb or compressor, and WASM programmers to be able to request and return raw audio sample data (in a typed arraybuffer or some such).
But I don't know that all, or even most, features that it makes sense to add to the browser would so cleanly have a foot in both camps.
a
Sure, no one's going to build a new web API anytime soon that doesn't have a js binding... But I don't see why we shouldn't start separating the specification of the API itself from the specification of languge specific bindings to it
Depends on who you ask I suppose... But I've certainly heard plenty of people who wholeheartedly hope that the day you can write your web frontend without ever thinking about js isn't too far off. They certainly see the value in every web API having first class wasm support
i
Yeah, I'd love to see it.
d
@Ivan Reese https://github.com/WebAssembly/webidl-bindings/blob/master/proposals/webidl-bindings/Explainer.md
The proposal describes adding a new mechanism to WebAssembly for reliably avoiding unnecessary overhead when calling, or being called, through a Web IDL interface.
i
Something like that would definitely help bridge the gap between WASM and JS, but that's still not the same as designing web platform APIs with WASM as the primary target. There are also all sorts of downsides to WASM compared to JS that we're glossing over ā€” for instance, JS is interpreted and the download, parse, and execute stages happen concurrently whenever possible for the sake of perceived performance. You can't do that with WASM.
Regardless, the fact that WASM exists as an alternative doesn't address the argument that JS is an "intrinsically fragile" language, and thus that it's folly to base Future Of Programming tools on JS. Why can't all the following be true? ā€¢ JS is a loose, dynamic, even sloppy language ā€¢ You can build valuable systems atop JS ā€¢ You can include support for JS in your Future-Programming tool, and that can be a good thing
Why does the first point (or other similar) render the following points (or other similar) invalid?
a
Yeah, I'm certainly not disagreeing those general points.
w
look up WASI if you want to know what the future of WASM without JS glue looks like
šŸ‘ 1
2 Views
Open in Slack
PreviousNext
Powered by