this was a fun thing to read, Alan Kay’s reply: <...
# linking-together
👍 2
🍰 3
For anyone who missed it, this is in reply to a tweet from Ken Kocienda (who worked on the original Safari team at Apple)
My complaints about the web and the web browsers have been about how poorly they were thought about and implemented, and how weak are both the functionalities of web content and the means for going forward and fixing as many of the most critical mistakes as possible.
So it seems Alan is burying the lede a bit, and actually agrees with Ken, albeit arriving at that point from a different start. Given the web we got (not the web we wanted), it is a mistake to try to retrofit it into an app platform, especially in such an ad hoc / incremental / design-by-accretion way. Short of a time machine, though, I'm not sure how we get that web of objects with end-user editing we ought to have. As an aside, this bit stuck out:
One of the great realizations of the early Unix was that the kernel of an OS — and essentially the only part that should be in “supervisor mode” — would only manage time (quanta for interleaved computations) and _*space*_(memory allocation and levels) and encapsulation (processes) — everything else should be expressible in the general vanilla processes of the system.
That's what game engines are (naturally). But game engines also don't have to worry as much about all the security, IO, hardware, and other baggage of modern OSes. That means game engines end up being quite pure articulations of that "time + space + process" conceptual structure, and I really feel that when working with them. (And others seem to too — quite a few game developers even pass it through to the player via gameplay. Thinking of games like Roblox, Minecraft, Sim[x], etc.)
🙌 2
yeah agreed, the term ‘web browser’ is very specific to current assumptions. The HTML / CSS / JS paradigm. Then people debate if the browser should do more or less, but often by focusing on the current set of assumptions instead of starting from first principles. If you started from first principles, you may not really even need a browser. Or rather, it’d be something way different and the use of that word / naming may be inaccurate!
earlier in linking together a video from unison was mentioned, it seems over time runar has become very fond of the ideas and design principles of smalltalk. Albeit still from a very very strong functional programming perspective. I'm uncertain if the extreme late binding which alan kay puts as one of smalltalks key features is possible with something of the likes haskell or any other static FP language implementation that runar likes. I have that Intuition that a Lisp may be better herre, there are static lisps too but.. well lets see...
In General I have to say I'm quite optimistic , ah I will take it to a new , my own thread