Hi Duncan

The short answers to these questions have already been given a few times on 
this list. But let me try another direction to approach this.

The first thing to notice about the overlapping windows interface "personal 
computer experience" is that it is logically independent of the code/processes 
running underneath. This means (a) you don't have to have a single religion 
"down below" (b) the different kinds of things that might be running can be 
protected from each other using the address space mechanisms of the CPU(s), and 
(c) you can think about allowing "outsiders" to do pretty much what they want 
to create a really scalable really expandable WWW.

If you are going to put a "browser app" on an "OS", then the "browser" has to 
be a mini-OS, not an app. 

But "standard apps" are a bad idea (we thought we'd gotten rid of them in the 
70s) because what you really want to do is to integrate functionality visually 
and operationally using the overlapping windows interface, which can safely get 
images from the processes and composite them on the screen. (Everything is now 
kind of "super-desktop-publishing".) An "app" is now just a kind of integration.

But the route that was actually taken with the WWW and the browser was in the 
face of what was already being done.

Hypercard existed, and showed what a WYSIWYG authoring system for end-users 
could do. This was ignored.

Postscript existed, and showed that a small interpreter could be moved easily 
from machine to machine while retaining meaning. This was ignored.

And so forth.

19 years later we see various attempts at inventing things that were already 
around when the WWW was tacked together.

But the thing that is amazing to me is that in spite of the almost universal 
deployment of it, it still can't do what you can do on any of the machines it 
runs on. And there have been very few complaints about this from the mostly 
naive end-users (and what seem to be mostly naive computer folks who deal with 

Some of the blame should go to Apple and MS for not making real OSs for 
personal computers -- or better, going the distance to make something better 
than the old OS model. In either case both companies blew doing basic 
protections between processes. 

On the other hand, the WWW and first browsers were originally done on 
workstations that had stronger systems underneath -- so why were they so blind?

As an aside I should mention that there have been a number of attempts to do 
something about "OS bloat". Unix was always "too little too late" but its one 
outstanding feature early on was its tiny kernel with a design that wanted 
everything else to be done in "user-mode-code". Many good things could have 
come from the later programmers of this system realizing that being careful 
about dependencies is a top priority. (And you especially do not want to have 
your dependencies handled by a central monolith, etc.)

So, this gradually turned into an awful mess. But Linus went back to square one 
and redefined a tiny kernel again -- the realization here is that you do have 
to arbitrate basic resources of memory and process management, but you should 
allow everyone else to make the systems they need. This really can work well if 
processes can be small and interprocess communication fast (not the way Intel 
and Motorola saw it ...).

And I've also mentioned Popek's LOCUS system as a nice model for migrating 
processes over a network. It was Unix only, but there was nothing about his 
design that required this.

Cutting to the chase with a current day example. We made Etoys 15 years ago so 
children could learn about math, science, systems, etc. It has a particle 
system that allows many interesting things to be explored.

Windows (especially) is so porous that SysAdmins (especially in school 
districts) will not allow teachers to download .exe files. This wipes out the 
Squeak plugin that provides all the functionality.

But there is still the browser and Javascript. But Javascript isn't fast enough 
to do the particle system. But why can't we just download the particle system 
and run it in a safe address space? The browser people don't yet understand 
that this is what they should have allowed in the first place. So right now 
there is only one route for this (and a few years ago there were none) -- and 
that is Native Client on Google Chrome. 

 But Google Chrome is only 13% penetrated, and the other browser fiefdoms don't 
like NaCl..... Google Chrome is an .exe file so teachers can't download it (and 
if they could, they could download the Etoys plugin).

Just in from browserland ... there is now -- 19 years later -- an allowed route 
to put samples in your machine's sound buffer that works on some of the 

Holy cow folks!


> From: Duncan Mak <duncan...@gmail.com>
>To: Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing 
>Sent: Wednesday, February 29, 2012 11:50 AM
>Subject: Re: [fonc] Error trying to compile COLA
>Hello Alan,
>On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay <alan.n...@yahoo.com> wrote:
>For example, one of the many current day standards that was dismissed 
>immediately is the WWW (one could hardly imagine more of a mess). 
>I was talking to a friend the other day about the conversations going on in 
>this mailing list - my friend firmly believes that the Web (HTTP) is one of 
>the most important innovations in recent decades.
>One thing he cites as innovative is a point that I think TimBL mentions often: 
>that the Web was successful (and not prior hypertext systems) because it 
>allowed for broken links.
>Is that really a good architectural choice? If not, is there a reason why the 
>Web succeeded, where previous hypertext systems failed? Is it only because of 
>"pop culture"?
>What are the architectural flaws of the current Web? Is there anything that 
>could be done to make it better, in light of these flaws?
fonc mailing list

Reply via email to