Future of Coding History
Tight zoom-in — mid-September 2024 — virtual roomful of online humanoid computer brains who maintain material co-presence in LA, or are translocating to SPLASH in October
There's going to be an unconference hosted by Ink & Switch on the 26th of October.
This has not been broadly announced yet. We're in the "invite the people who you really want to be there" phase. That means all of you!
Take a look at the list of attendees. Brilliant weirdos, the lot. You should come, you should come, you should come.
A full-blown tutorial on DIY functional reactive programming, from one of the Spritely folks. Also collects relevant PL dissertations on dataflow, e.g. FrTime and propagators, as well as explorables like Holograph.
This is a great article. i'm a big Hoot fan
I'm surprised the article doesn't mention SolidJS! solid's responsible for popularizing Signals again in JavaScript. Its fine-grained/narrow updates to specific ui nodes are powered by the reactive graph. no vdom, components don't rerun. i think he might like it!
also i'd never seen the linked Holograph before, that's so sick i love it ! !
I love the metaprogramming aspects of Holograph, i.e. accessing and setting properties of the visual elements!
Does the first example (temperature converter) work for others? For me (Firefox, macOS), when I change the "Celsius" value, it goes into an endless update loop. Which is not that surprising, given that the graph has cycles.
Strangely enough, updating the Fahrenheit value leads to a one-sweep stable update.
Curious which value you put in for Celsius that makes it loop? I can try to reproduce it. In any case, propagators only fire when cells have changed- that's what allows networks to reach a stable states despite having loops.
@Dennis Hansen Here is what I did:
Here is what happens:
hm, shouldn't oscillate like that- might be a firefox thing- haven't tried it on that i'll have to investigate. Thank you!
@Dennis Hansen Something I wonder about: you say "propagators only fire when cells have changed." In the temperature converter, you have division in the cycle, which is inexact unless you use rational numbers (which JS doesn't have). So the cycle could propagate change forever. That's probably not what is happening here, as the oscillating values differ too much to be amplified round-off, but I wonder how you deal with numerical issues in general.
A fascinating 1992 mailing list post from Tim Berners-Lee where he briefly outlines his desires for a programming language for the web — basically, what JavaScript could have been.
The principles of hypertext are on full display:
You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership.
Then there's the PL nerdery:
Ideally, the language should include object-oriented inheritance, a basically functional nature, and a clean syntax. It should be interpretable and compilable. At least one public domain. A pre-compiled standard binary form would be cool too.
My favourite bit, though, is the desire for the client/server to negotiate over the language of the executable document, just like they negotiate other details. There are some wild isomorphism implications here.
In reality, what we would be able to offer you real soon now with document format negotiation is the ability to return a document in some language for execution, with the option of being able to provide it in several languages, the language being a "data format" which can be negotiated between client and server at run-time. For, for example, one could provide it in viola script and/or in /bin/sh which would cover most ofthe unix world.
Could have been? I mean, this is pretty visionary, and I feel like we just got there.
With the data-urls we finally have model-view independence for serializable stuff, combine with WebSocket for multi-client applications. (Caveat that I'm not working with distributed object programming, which sounds like it's just for safely mutating the objects.) Or are you pointing in the direction of embedding other languages, e.g. clingo ASP via WASM?
The claim of ES6 to myriad useful forms is quite strong. Here I thought we'd magically emerged from the bad old jQuery days. But seeing ES6's full lineage in 💬 #linking-together@2024-07-29 was revelatory.
Universal readership! Hahaha. The hypertexts were so successful that now we have too much of a good thing.
Reminds me of some of my own "web future" ideas (currently languishing in private notes I should publish some day)...
The most fundamental innovation of the web is the addressable, decentralized distribution of software / pages / data over the network, together with a trusted user agent watching out for the user's security and privacy while it runs untrusted code.
Over the decades, various giant monolithic browser engines have piled more and more specs and features on top of this core idea. It's not possible to select just the bits you need for your own project. Many of those features became deprecated long ago, but can't be removed for fear of breaking compatibility.
This project reimagines the web as a tools for all, instead of screen for consumption. This vision empowers authors to build whatever they desire, while also supporting users with a safe, trusted environment, as well as inviting them to participate and customize however they wish through new tools and abilities everyone can understand. Creative documents and interactive experiences should not be trapped inside the monolithic browsers we have today. It should instead be more like an customizable OS service, an integral part of the core computing workflow, but also one which is managed and presented in the way the user finds most optimal for each document or experience.
A website would essentially describe a set of modules (perhaps Wasm or something else) that are then used (safely) to display the content, so authors can escape some of the constraints of today's web while retaining the key innovation of safe distribution of untrusted programs.
Without voicing support or dissent, I just want to flag an interesting contrast between what you wrote:
safe distribution of untrusted programs
… and what Tim BL wrote:
a document in some language for execution
Concretely, the framing of "program" versus "document" feels worth reflecting on.
Ah yeah, interesting… I suppose my mental model of the web thinks of all “documents” as programs, even if they are “static pages”… Those are just simpler programs. 🙂
I think an important part of "document" is that it suggests an "editor" for it exists and is readily available. Whereas "program" often implies a compiled artifact.
Your self-quote talks about tools. I think we're agreeing on goals, I just find the word choice interesting.
Ah yeah, I see what you mean with document and editor. Compiled-ness implication is unintentional, so something for me to mull over if I ever finally publish it.