Alan Kay has agreed to do an AMA today

Hey Alan,

You seem very disapointed and upset with the way computing has gone in the last decade. Speaking as a younger (15) and more satisfied (I still think the UNIX abstraction is pretty solid, despite what others may say) programmer, how do you not get depressed about the way technology is going?

Also, what do you propose to eliminate the "re-inventing the flat tire" problem? Should every programmer be forced through a decade of learning all of the significant abstractions, ideas, and paradigms of the last 50 years before they write anything? Because I don't see another solution.

I do get depressed -- how could one not? -- the trick with depression is to not allow it to take you into in-action.

Re: Unix etc. try to imagine computer systems without "operating systems" as they are thought of today (hint: look at the Internet, etc.).

The basic heuristic here is to avoid the "when you criticize something you are implicitly buying into it's very existence!". First try to see if there is anything worth existing! (OSs are not necessary ...)

How long does it take to learn real science? And shouldn't computer science be a real science?

Another way to look at this is that anyone could be a doctor until recently (really recently!) because no one knew what was going on. And a lot of damage was done (and is still being done.) Once some real knowledge is obtained, we can't afford to have random practitioners dabbling into important things. (The idea that this might be OK is another pop culture delusion and desire ...)

...and I'm not sure I agree. The idea that code from randoms shouldn't be put into critical infrastructure is certainly true. But the idea that people shouldn't tinker, hack on code, and learn, even if they end of with non-optimal, possibly broken code, is a dangerous one, because that's how people learn. And yes, they should dabble in important things. How else do they learn them. It's then our job, as the Real World, to analyze our dependancies, and make sure we can trust them to be well written, and that they aren't just toys.

As for whether operating systems are necessary, by most common definitions (being, as I understand it, a set of software that defines a common base of abstractions over hardware, so as to allow multiple other pieces of software to access said hardware at a higher level of abstraction), yes, they are, if you don't want to go mad. But I get the feeling that isn't what you meant...

In short, I can respect your opinions, but I do not agree with all of them. Much of this derives from the mindset that tinkering with even the most important things, regardless of skill, is important to learning. If that makes me stupid, so be it.

It's not the learning process that is in question, but the ramifications of really extending the industrial revolution to distributing broken code.

(No language has ever been more set up to allow tinkering with everything for the purpose of learning than Smalltalk -- I think you probably realize this.)

I think most people would not recognize most exiting OSs in use by your definition in your second paragraph.

> OSs are not necessary

Is this because web browsers are all we need? (I'm about thinking ChromeOS as an example.)

Currently, OSs are needed to create web browsers. Do you think there will be a time when a web browser will be able to compile itself (without requiring an "OS")?

Also, will the web servers also not require an "OS"?

It's worth pondering the real implications of real objects as real virtual machines intercommunicating by messages (they were inspired in part by the pervasive world-wide networking that was part of Licklider's vision).

One way to think about this is that "hardware objects" are merely caches for the software objects that will embody the processes and intents.

As a cache, each computer needs a small amount of code to deal with resources of time and space and i/o to and from the net. This could be called a "micro-kernel", but in an object world, it is also objects, not a "stack". For "doing things", we can imagine a system of "real objects" residing on one or more of the hardware caches. What mix depends on the individual resources of the caches.

The wonderful Gerry Popek did a first pass at this kind of caching architecture that worked over a mixture of machine types in the 1980s -- it was called LOCUS -- and there is an excellent book from MIT Press that explains the issues and how it works.

Its main limitations were that it was made as an extension of Unix processes, but it definitely proved the concept of how this part of really distributed "objects" with cached resources worked. (I tried to get Apple to buy this system when I first got there in 1984.)

Bottom line is that there is nothing that resembles any of the huge monolithic OSs of today that "try" to make software dependent on them rather than to allow software to run everywhere and move everywhere.

So "OSs are not necessary".

(Smalltalk at Parc did not run on top of an OSs ... etc.)

Okay. What is the definition of the OS in your opinion?

And thank you for taking the time to disagree with me respectfully. So many do not.

And I do recognize the tinkering capabilities of smalltalk. This is why I found your points odd.

I have yet to learn Smalltalk. The full environment, as opposed to text editor development feels odd to me, especillay after struggling with monsters like Eclipse. Also, SBE is several years out of date, and there isn't really much in the way of good documentation for those who don't already know what they're doing.

Well, ST at Parc was, by some definitions anyways, an OS. HW objects are certainly an interesting idea, though, and now I kind of get what you mean.