Actually, we can do great particle systems with the shader language for
WebGL. This is a kind of native client mode expressed as a kind of SIMD,
with even better performance than star-squeak had. The reality is still
that a great algorithm will still win, especially when coupled with
strategically defined performance enhancements, as Squeak was. I agree that
NaCl is a revolution about to happen and we are in a very exciting time,


On Wed, Feb 29, 2012 at 6:09 PM, Alan Kay <> wrote:

> 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 it).
> 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 browsers.
> Holy cow folks!
> Alan
>   ------------------------------
> *From:* Duncan Mak <>
> *To:* Alan Kay <>; 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 <> 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?
> --
> Duncan.
> _______________________________________________
> fonc mailing list
fonc mailing list

Reply via email to