I think Alan Kay would disagree with that (and I do too, having written a lot of responsive layout code in PostScript, including a user interface toolkit (The NeWS Toolkit), a hypermedia browser (HyperTIES), and a HyperCard-like PostScript extensible interface builder (HyperLook), and various apps (PizzaTool, SimCity, etc), all that handle window resizing, dynamic responsive layout, and high resolution printing).
See his answer to the question "Should web browsers have stuck to being document viewers?" (And the ensuing discussion.)
You have to log in to see the replies to his reply, which includes a discussion about JAM and NeWS and PostScript based browsers and rendering.
>Alan Kay, Still trying to learn how to think better
>Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
>It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
>It’s both surprisingly and dismayingly difficult to get people — especially computerists — to criticize the web and the web browsers — even more so perhaps today.
>This is despite the glaring fact that the interactive media provided by the web and browsers has always been a hefty and qualitative subset of the media on the very personal computers that run the web browsers.
>[...]
>This led to a “sad realization” that sending a data structure to a server is a terrible idea if the degrees of freedom needed on the sending side are large.
>And eventually, this led to a “happy realization”, that sending a program to a server is a very good idea if the degrees of freedom needed on the sending side are large.
>John Warnock and Martin Newell were experimenting with a simple flexible language that could express arbitrary resolution independent images — called “JAM” (for “John And Martin” — and it was realized that sending JAM programs — i.e. “real objects” to the printer was a much better idea than sending a data structure.
>This is because a universal interpreter can both be quite small and also can have more degrees of freedom than any data structure (that is not a program). The program has to be run in a protected address space in the printer computer, but it can be granted access to a bit-buffer, and whatever it does to it can then be printed out “blindly”.
>This provides a much better match up between a desktop publishing system (which will want to print on any of the printers available, and shouldn’t have to know about their resolutions and other properties), and a printer (which shouldn’t have to know anything about the app that made the document).
>“JAM” eventually became Postscript (but that’s another story).
>Key Point: “sending a program, not a data structure” is a very big idea (and also scales really well if some thought is put into just how the program is set up).
Anyway, as I recall, Kay is making essentially the exact same argument as the Adobe guy, and the way he said it in that talk (Programming and Scaling, thanks below) displays astonishing ignorance for such a brilliant guy.
If Kay is right, then he should just create a web that is based on a VM. And then he can see how far it goes. It will never go anywhere because it will be broken by design.
And I'll elaborate on that and say that Kay's designs are probably brilliant for small scales, but not for large scales and heterogeneous problems.
It's easier to design something for a small scale. You can get a more coherent result that feels nicer locally.
But the whole point of the web is large scale -- WORLD WIDE was in fact TBL's original vision (e.g. see original proposals linked below). That's a much more constrained and thus harder design problem.
Alan Kay is opposed to the "principle of least power" and instead believes the web should consist of turing-complete "objects" which manage their own rendering.
Basically he wants a web consisting purely of "black box" Java Applets rather than of web pages. I think this vision have failed multiple times for obvious reasons.
Repeating what I said in the original comment: the web should HAVE a VM; it shouldn't BE a VM.
The web is hyperlinked DATA that optionally leads you to CODE. The VM-centric design is mistaken and broken, and it's a moot point because it won't ever be deployed in at a large scale in practice.
Like Kay's other designs, it's OK for a small scale and clean slate, but not for a large scale.
Importantly, the web can have and has had MULTIPLE VMs -- Java (via NSAPI), Flash, JavaScript, WebAssembly, and I would say PDF since all browsers now have readers built-in. The design of languages for code is more difficult and ephemeral than the design of languages for data.
The web scales with TIME (decades), not just users (billions of people). Kay's designs don't scale in either direction.
Kays vision is like if we only had JavaScript drawing directly to the screen, and no HTML or any of the other web standards. In such a web we wouldn't have search engines, probably not even links.
The object oriented paradigm (with data and behavior encapsulated in black-box objects) works fine for software systems, but it absolutely fails for large decentralized communication systems. TBL understood that and instead based the web on declarative data formats, and eliminated the behavior to a few verbs (GET, POST etc.) with constrained semantics.
OOP is great when appropriate but it seems Kay doesn't recognize the limitations of the paradigm. Even Java have abandoned the strict object-dogmatism and embrace more data-oriented patterns.
Yes exactly; I think of the web as a modest and humble (and thus brilliant) extension of Unix. It adds simple networking and hyperlinks to hierarchical namespaces (and extends hierarchical names as URLs).
Those principles scale. GET/POST is basically the Unix/Plan 9 principle of read() / write() of declarative formats.
On a small scale you can avoid that and use more tightly coupled RPC (and maybe you should), and you can design more elaborate VMs.
On a large scale it all becomes REST (e.g. what do you talk to Github with, what does a Debian repo look like, etc.). It's less about the technical design and more about the social issues -- who owns each end of the wire? If you own both ends of the wire, you have a much different problem, but that's not the problem the web is solving.
When watching the Kay talk, I was struck that he seems to be lumping every "good" in software engineering under the term "object oriented". Virtual machines are objects. Servers are objects. Numbers should be objects. All abstraction is objects. It was not really a useful or enlightening way of thinking about the world.
See his answer to the question "Should web browsers have stuck to being document viewers?" (And the ensuing discussion.)
You have to log in to see the replies to his reply, which includes a discussion about JAM and NeWS and PostScript based browsers and rendering.
https://www.quora.com/Should-web-browsers-have-stuck-to-bein...
>Should web browsers have stuck to being document viewers?
https://twitter.com/kocienda/status/1355344814166876163?s=21
>Alan Kay, Still trying to learn how to think better
>Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
>It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
>It’s both surprisingly and dismayingly difficult to get people — especially computerists — to criticize the web and the web browsers — even more so perhaps today.
>This is despite the glaring fact that the interactive media provided by the web and browsers has always been a hefty and qualitative subset of the media on the very personal computers that run the web browsers.
>[...]
>This led to a “sad realization” that sending a data structure to a server is a terrible idea if the degrees of freedom needed on the sending side are large.
>And eventually, this led to a “happy realization”, that sending a program to a server is a very good idea if the degrees of freedom needed on the sending side are large.
>John Warnock and Martin Newell were experimenting with a simple flexible language that could express arbitrary resolution independent images — called “JAM” (for “John And Martin” — and it was realized that sending JAM programs — i.e. “real objects” to the printer was a much better idea than sending a data structure.
>This is because a universal interpreter can both be quite small and also can have more degrees of freedom than any data structure (that is not a program). The program has to be run in a protected address space in the printer computer, but it can be granted access to a bit-buffer, and whatever it does to it can then be printed out “blindly”.
>This provides a much better match up between a desktop publishing system (which will want to print on any of the printers available, and shouldn’t have to know about their resolutions and other properties), and a printer (which shouldn’t have to know anything about the app that made the document).
>“JAM” eventually became Postscript (but that’s another story).
>Key Point: “sending a program, not a data structure” is a very big idea (and also scales really well if some thought is put into just how the program is set up).
>[...]
(Log in to Quora to see the entire discussion.)