Channels
administrivia
announcements
bot-dark-forest
devlog-together
in-alberta
in-boston
in-germany
in-israel
in-london
in-nyc
in-ontario
in-seattle
in-sf
in-socal
introduce-yourself
linking-together
of-ai
of-end-user-programming
of-functional-programming
of-graphics
of-logic-programming
of-music
present-company
random-encounters
reading-together
share-your-work
thinking-together
two-minute-week
wormholes
Title
i
Ivan Reese
07/25/2019, 6:03 PMIt 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 evolvesWASM (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 programmerI'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
abeyer
07/25/2019, 7:10 PMbut you still need to use JS APIs to do any useful work, and I don't believe there's any plan to change thatCurious 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
Ivan Reese
07/25/2019, 7:48 PMHere'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
abeyer
07/25/2019, 8:04 PMMaybe 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
Ivan Reese
07/25/2019, 8:07 PMI 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
abeyer
07/25/2019, 8:09 PMSure, 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
Ivan Reese
07/25/2019, 8:16 PMYeah, I'd love to see it.
d
Deklan Webster
07/25/2019, 10:49 PM@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
Ivan Reese
07/25/2019, 11:31 PMSomething 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
abeyer
07/26/2019, 12:05 AMYeah, I'm certainly not disagreeing those general points.
w
Wouter
07/26/2019, 1:53 AMlook up WASI if you want to know what the future of WASM without JS glue looks like
š 1