There are several good points here ... and of course I don't mean that the "software machines" that can use arbitrary hardware as caches have to or should be totally opaque -- or that the poor integration on personal computers today should be followed slavishly.
For example, we at PARC (or now in STEPS) did not have applications per se, but what would be called today "mashups of useful objects" -- (this is what *real objects* allow ...) I think you can see just how your desiderata can be served by sending and receiving *real objects* rather than just data structures or (now) adding programs in one chosen language. I hope my main point is not being lost here -- which is that good OS and language design is partly about being able to recognize that there are too many degrees of freedom and too many ideas and implementers to be able to serve their needs. Long ago in my thesis I took the point of view that if one were going to make a computer system for the Princeton Institute of Advanced Study, one should make an extensible system that the Institute members could shape in the directions they needed (this because it would be effectively impossible for the computer scientists on the outside to effectively meet the needs -- so personal computing would require widespread higher level interdisciplinary system making, and it was the job of the computerists to provide the extensible structures that the domain experts could make use of. In the case of the web, we have the irony that it is the deep computerists (who can make their own systems from scratch) who are being shut out. Javascript could act as "an Alto" if some of the techniques used in Squeak (i.e. something like SLANG) were added. But this is not the case at this point. Best wishes, Alan ________________________________ From: David Barbour <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Mon, July 25, 2011 12:29:06 PM Subject: Re: [fonc] Alan Kay talk at HPI in Potsdam On Sun, Jul 24, 2011 at 10:24 AM, Alan Kay <[email protected]> wrote: The main idea here is that a windowing 2.5 D UI can compose views from many sources into a "page". The sources can be opaque because they can even do their own rendering if needed. Since the sources can run in protected address-spaces their actions can be confined, and "we" the mini-OS running all this do not have to know anything about them. This idea of 'opaque' applications in a sandbox may result in a flexible UI, but not an especially composable or accessible one. Consider the following desiderata: * Accessibility - for screen-readers, search engines, language translators. * Zoomability - we should be able to constrain client-side resource consumption (CPU, bandwidth, memory) such that it is commensurate with user attention (as measured in terms of screen real-estate for visuals, or volume for audibles). * Service mashups and customization - grease-monkey scripts and extensions that modify an app require it have a clear structure. * Occasionally connected computing - links fail, power isn't always up, we might persist an app we aren't zoomed on at the moment. * Mobility - an app should be able to follow users from one computer to another. * Bookmarking, Sharing, CSCW - users should be able to share access to specific elements of their applications. * Optimization - the later we perform optimizations, the more we can achieve, especially if the language is designed for it. Access to the underlying code can allow us to achieve higher levels of specialization. This is how apps work on personal computers, and there is no reason why things shouldn't work this way when the address-spaces come from other parts of the net. Except, being opaque is also part of how apps consistently fail their users on personal computers. I.e. we should not be striving for apps as they exist on personal computers. Something better is needed. I agree that NaCl for Chromium is a promising technology. Though, I wonder if hardware virtualization might be more widely accepted. But the promise I see for NaCl isn't just rendering flexible apps to screen; rather, I see potential for upgrading the basic web abstractions, breaking away from HTTP+HTML+DOM+JS+CSS for something more robust and consistent (I'm especially interested in a better DOM and communications protocol for live documents). I.e. it would be easy to create 'portal' sites that effectively grant access to a new Internet. This offers a 'gradual transition' strategy that is not accessible today. >this [NaCl] approach will need to be adopted by most of the already existing >multiple browsers before it can really be used in a practical way in the world >of personal computing I agree that this is a problem for apps that can be easily achieved in JS. (And the domain of such applications will grow, given WebGL and WebCL and improved quality for SVG.) But for the applications where JS and WebGL are insufficient, mandating Chrome as a platform/VM for an application should rarely be 'worse' than providing your own executable and installer. >The sad and odd thing is that so many people in the computer field were so >lacking in "systems consciousness" that they couldn't see this What's with the past tense? Regards, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
