Insightful point about how the struggle to converge on a well-designed UI paradigm is related to a larger question of how the industry is still experimenting and exploring the problem space, particularly:
> reactivity, which is at heart incremental computation
Another comment that caught my attention up-thread was talking about "incremental lambda calculus", which is the same question in different words. My impression was that ideally it needs a language-level solution to be able to support "diff" and "patch" not only on the data but the running code, perhaps built from primitives like continuations.
> feels to me a bit like async
Maybe part of the difficulty with reactive UI is fundamentally related to how the language "solves" async, for which there's still no real concensus on the best way to solve it.
From the abstract, I get the impression it would require very granular atomic-level language transformations, that are only practical for languages that are designed from the ground up to support creating and applying such deltas. Rust and JavaScript/React seem overly complex for reducing down to that level of granularity, especially the latter for strictly typed and deterministic changes. Maybe a language like Haskell is more suitable, since I've heard that it (or a subset) can be compiled down to typed combinators as primitives.
> probably need a language with HKT
Ah, that sounds related to the thought above, that the technique may be best implemented at the level of language design. Does "HKT" mean "higher kinded types"? Closest I could find was a library for TypeScript: https://majorlift.github.io/hkt-toolbelt/
> _truly_ immediate mode framework where each widget is a pure function
It sounds like the "functional reactive" paradigm, which I think React is loosely based on and probably UI libraries like Imgui and others in Rust also. But none of them are "pure" like you describe because the languages they're built on are not pure all the way to the bottom. (Maybe Rust is, but it's likely too complex to practically "diff" and "patch" not only the data models but the running code incrementally, though I may be misunderstanding.)
Umberto Eco is a wonderful writer, up there with Borges. They shared a deep philosophical interest in language, exploring it from various angles in their works. Both widely versed in obscure literature, approaching it with wit and humor.
> Automath ("automating mathematics") is a formal language, devised by Nicolaas Govert de Bruijn starting in 1967, for expressing complete mathematical theories in such a way that an included automated proof checker can verify their correctness.
That reminds me of a quote by Freeman Dyson on Stephen Wolfram's work.
> "There's a tradition of scientists approaching senility to come up with grand, improbable theories. Wolfram is unusual in that he's doing this in his forties."
I always felt it was an unfair dismissal of someone's life's work. Maybe it was true but it didn't enrich the discussion or our understanding. I suppose it means even a respected thinker can be guilty of shallow dismissals and saying hurtful things in public about others.
It's similar to a "thought-terminating cliché", in that it just reinforces an existing opinion without adding anything, making us think deeper, or furthering the conversation.
In addition to the importance of making "mistakes", I would say "surprise" is a big element in creativity and humor. Perhaps these are related concepts, because a mistake is surprising. It's an unexpected departure from the normal routine and habit of behavior or thinking.
The term "surprisal" is used in information theory:
> For a given probability space, the measurement of rarer events are intuitively more "surprising", and yield more information content than more "common" events.
Can a machine surprise us? Given enough complexity, I think so. They can produce unpredictable results, even novelty, something we've never seen before. But does that mean a machine can be creative? Or funny? Maybe there's a threshold of acceptance, where eventually its output will become surprising enough that we might as well call it creative.
The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.
Part of the problem is that of human alienation. By excluding humans in the construction process, it has taken away any skin-in-the-game for humans. So, there could be a point where some bugs become unresolvable because LLMs dont have an adequate causal model and fixes by trial-and-error wont work in cases where root-causes are not properly addressed - and the project gets abandoned as a result. Witness the C compiler in rust [1], what happened to that after the initial press releases ?
This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.
Soon: Microsoft announces entire TypeScript language ported to Rust using LLM, with a 1M LoC merged after a week of intense vibe coding. And nobody would be surprised.
The way of Jobs is how you "earn" a billion dollars.
reply