alankay1

Sure.

Try to avoid "growing old"!

A big problem with the general industry is the lack of subsidized "sabbatical years" -- these are a good way to recharge and re-orient. Xerox, amazingly, used to have them for employees. But I haven't heard of any such thing recently.

If you think about life as needing "renewables" then you shouldn't allow yourself to be "stripmined" (easier said than done).

I grew up in a house filled with books and parents and relatives who were in many fields. This ruined me for school (and that helped, though it was a struggle).

Here is a "personal essay" I was asked to write in 2004: http://www.vpri.org/pdf/m2004002_center.pdf

I think there is a lot of potential here (think 10 years and you might get something useful in the first 5). This will require great will on the part of those trying to make it happen (the market is not demanding something great -- and neither are academia or most funders).

"The softer an area, the tougher you have to be"

CDG has morphed into HARC, etc. And I do plan to be active.

I think "real AI" could help (because it could also explain as well as configure). Systems that can't explain themselves (and most can't) are a very bad idea.

I don't know -- I'm not a software engineer -- but I think this is a very tough profession to do well.

It would be great to have a notion of type that would actually pay for itself in real clarity. For example, what would be really useful in many dimensions is "semantic types" rather than value oriented types (which I don't think are particularly valuable enough).

Have you seen the "gyre" in the Pacific?

This is a really interesting issue and one we should all be thinking about ...

Parc in the 70s was an outgrowth of the ARPA projects that were started to be set up in 1962. Bob Taylor was a factor for both, and wanted young researchers who already had imbibed the mother's milk of "the ARPA dream", This created a culture that never argued about what the general vision and goals were, and also was able to argue in good ways about how to get there.

Such a homogeneous culture organized around a particular vision doesn't exist today (that I know of), and it means that places like HARC will have to do some of the culture building that was done in the ARPA projects (I think of the HARC initiatives as being more like the ARPA projects than like Parc at this point)

Please try to avoid too much planning for your future at this point and just try to get to a place where things are going on. Any good educational experience will take someone who is trying to get from A to B and instead get them to C (note that an under-educated person is not in a good position to make big choices -- so learn more!)

I'm not a huge fan of this particular approach (interesting as it is ...)

"There aren't any really good ones" -- so computing major students especially should have to learn 4 or 5 very different ones and write fairly major systems in them.

We should take another pass at design for both majors and non-majors ...

Let's give Dan Ingalls the majority of the credit here. I will admit to "seeing" what was possible, but Dan was able to make really great compromises between what Should Be vs what would allow us to make great progress in the early 70s on relatively small machines (give Chuck Thacker the majority of the credit here for similar "art of the possible" with the Parc HW).

I liked the MOP book because they carried the model more deeply into the actual definitions -- I very much liked their metaphor that you want to supply a "region of design and implementation space" rather than a single point.

Sure.

I think one of the biggest blindnesses of our field is scaling (and I'm not sure quite why). This leads to an enormous amount of effort at roughly the same scales of some good ideas decades ago. (I think my background in molecular biology -- which continues to a very small extent -- helped this a lot. At some point one has to grapple with what is more or less going on and why it more or less works so amazingly well.)

What would a programming language be like if we actually took the many dimensions of scaling seriously ... ?

Chris was fun to work with!

Steve was not the kind of person to have friends, but he and I were "pretty friendly" right up until his death -- this is partly because our lives intertwined closely a few times -- not just for Apple, but also for Pixar, and then later as I tried to get him back to real education as an Apple goal.

Our most unrealistic assumption was that when presented with really good ideas most people will most definitely learn and use them to make progress. In reality, only a tiny percentage can do this, and it is an enormous amount of work to deal with the norms.

The problems with most arguments is that they arguers assume they are in a valid context (this is usually not the case, and this is the central problem of "being rational"). Another way to look at it is "Forget about trying to win an argument -- use argumentation to try to understand the issues better and from more perspectives ..."

It's a big problem along many dimensions. A good start is to try to get a handle on what you think should be required. One hint is to forget about vocational goals and focus on "adults as real citizens in a large diverse society"

What are the three best books you've read on teaching anything to kids? Let me know, and we'll start from there.

A good heuristic for designing programming languages is to try to take the largest most complicated kinds of things you want to do, work them out, and then see if there is a "language lurking".

Most people make the big mistake of lovingly making small neat examples that are easy to learn -- these often don't scale at all well. E.g. "data" in the small "seems natural" but the whole idea scales terribly. And so forth for most of the favorite paradigms around today.

This is a perfect example of "systems blindness" in the face of real scaling.

What should a browser actually know in order to scale (and why didn't the browser folks realize this? (rhetorical question) -- this knowledge was already well around by the early 90s).

And ... ????

Sure!

We were lucky in the ARPA/PARC communities to have both great funding, and the time to think things through (and even make mistakes that were kept from propagating to create bad defacto standards).

The question you are asking is really a societal one -- and about operations that are like strip mining and waste dumping. "Hunters and gatherers" (our genetic heritage) find fertile valleys, strip them dry and move on (this only works on a very small scale). "Civilization" is partly about learning how to overcome our dangerous atavistic tendencies through education and planning. It's what we should be about generally (and the CS part of it is just a symptom of a much larger much more dire situation we are in).

One start to this is not to do "a web browser" -- or other software -- with such bad initial conceptions (see elsewhere above). There was nothing necessary about this.

We have a technology in which hacks are easy and can be really easily multiplied by the billions and sent everywhere. If we translate this into the world of medicine and disease and sanitation, what should we do? How far should we go?

(But it is still really hard for me to understand the nature and force of the resistance to "real objects" -- which -- as actual virtual encapsulated machines -- were invented to deal with scaling and replacement to parallel the same kinds of thinking we did for the Internet with physical objects (called "computers")

Yikes!

One of several major mistakes with the web has to do with thinking that the browser is some kind of application "with features" -- if you think of the actual scale of the Internet (and they didn't) you realize that at the very least, the browser, etc, has to be more like an operating system, and with as few features as possible: really to safely run encapsulated modules and deal out resources. It is crazy that after more than 20 years of the web that this CS101 principle still can't be done ... and it runs on machines that can do it....