alankay1

The research community was "an arguing community", and knew how to argue "in good ways" (i.e. no personal attacks, only trying to illuminate the issues, etc.) This worked pretty well almost always ... (The weekly meetings were not for being creative, but for discussion ...)

Let me respectfully disagree with your contention. The point that is missed is not what the hardware could do, but what can you do without optimizing. It is very very hard to put on the optimization hat without removing the design hat, and once you've removed the latter you are lost.

The key to the Parc approach was to be able to do many experiments in the future without having to optimize. (There was a second part to this "key" but I'll omit it here)

There is a very old reading list online I made for the company that is now Accenture -- and this was the subject of a recent HN "gig". I think there is a URL for this discussion in this AMA.

What would a simulation of an epidemic look like? Or a simulation of ants finding food via pheromone trails. Or simulation of dye diffusing in water? Or a simulation of an object being dropped?

Etc

I think you can find much of what is worth knowing about these projects starting there.

Historically, (1) has not particularly depended on merit, and (2) would require a lot (because "nice atoms" were more interesting back in the 60s than today).

None of my peeves are "pets"

I like what Sam Altman is setting up and fostering

I don't keep track of them ...

"Most ideas are mediocre down to bad" -- and mine certainly have been.

Beyond ideas, I would do some process things differently, especially those that could have been done better if I had been able to understand people better.

If it were done much better ...

Too absolute, but I like Erlang

I had the great -- and lucky -- benefit of falling into a well established research community -- ARPA-IPTO -- in the 60s with roots going back into the 50s and 40s. They "knew how to make progress" and I learned most of what little I understand about "process" from growing up in it.

Here is a little tribute essay I wrote for this research community in 2004: http://www.vpri.org/pdf/m2004001_power.pdf

I wasn't involved in GRAIL, but was (and am) a huge admirer of what these people were able to do (and when they were able to do it). Worth really looking into the history here!

The current state of programming (visual or not) for children and adults is not good enough.

I like "messages" as "non-command" things. And I left out inheritance in the first Smalltalk because I didn't think Simula's version was semantic enough (and still don't).

The idea of a "generalization" from which you can get instances is good. Now the question -- then and now -- is how can you define the "generalization". We didn't do it well back then, and I don't know of a system that does this well enough today.

I'm not satisfied. They have more computing power and display resolution and depth than my minimums back then, but don't pay strong enough attention to "services" (one of the simplest they don't do well enough -- and they could -- is to really allow a person who knows how to draw to draw (and this means allow a person who doesn't know how to draw to learn to draw)).

There are a lot of similar quite blind spots in today's offerings, and none of them are at all necessary.

When I write code it is usually either "kiddicode" for future "kiddilanguages" or "metacode" (for future languages ".")

I did have a lot of fun last year writing code in a resurrected version of the Notetaker Smalltalk-78 (done mostly by Dan Ingalls and Bert Freudenberg from a rescued disk pack that Xerox had thrown away) to create a visual presentation for a tribute to Ted Nelson on his 70th birthday: https://youtu.be/AnrlSqtpOkw?t=135

This particular system was a wonderful sweet spot for those days -- it was hugely expressive and quite small and understandable (my size). (This was the Smalltalk system that Steve Jobs saw the next year in 1979 -- though with fewer pictures because of memory limitations back then).

I've written and talked about this over the last decade or so. I think a huge problem in even thinking about this is that the people who should be thinking about it have gotten very fluent in many ways of "programming" that are almost certainly not just obsolete but make it very difficult to think about what are likely to be the most important issues of today.

If we look at CAD->SIM->FAB in various engineering fields -- mechanical, electrical, biological, etc. -- we see something more like what is needed. From another view, if we look at the great need for designing and assessing, etc. we can see that the representations we need for "requirements", "specs", "legalities", etc have to be debuggable, have to run, and might as well just flow into a new kind of "CAD->SIM->FAB" process for programming. A lot of what has to happen is to replace main-stream "hows" with "whats" (and have many of the hows be automatic, and all of them "from the side).

Many valid programs are quite wrong.

Most people confuse "arguing" with "debating".

Take a look at what Sam Altman is doing with YC Research.

What are the most important purposes for our living in a society?

Sure -- and you have my permission to make things more clear in the process!

Just to say one more time here: the central idea is "meaning", and "data" has no meaning without "process" (you can't even distinguish a fly spec from an intentional mark without a process.

One of many perspectives here is to think of "anything" as a "message" and then ask what does it take to "receive the message"?

People are used to doing (a rather flawed version of) this without being self-aware, so they tend to focus on the ostensive "message" rather than the processes needed to "find the actual message and 'understand' it".

Both Shannon and McLuhan in very different both tremendously useful ways were able to home in on what is really important here.

Most humans are quite naive about this -- but it is endlessly surprising to me -- and depressing -- to see computer people exhibit similar naivete.

For example, the extent to which most code today relies on "outside of code" programmer views (and hopes) is astounding and distressing.

I was a big fan of science fiction in the 40s and 50s -- pretty much literally "read everything" -- and tapered off in the 60s -- partly because science was taking more of my time than science fiction, and partly because in many areas science and technology over-ran sci-fi, and partly because my favorite authors were writing less (and writing less good stuff).

There are several questions here.

A prime UI design principle -- which is also an education principle -- is that you have to start where the learners/users are. ("All learning happens on the fringes of what you know" -- David Ausubel)

For children especially -- and most humans -- a main way of thinking and learning and knowing is via stories. On the other hand most worthwhile ideas in science, systems, etc. are not in story form (and shouldn't be). So most modern learning should be about how to help the learner build parallel and alternate ways of knowing and learning -- bootstrapping from what our genetics starts us with.

And -- everything we are immersed in causes "normal" to be reset, for most people invisibly. This should be a conscious part of the "helping learning" process.

This could be too elliptical an answer ...

My favorite Alexander book by far is "Notes on a Synthesis of Form" (which he has disavowed ...)

Yes, and I don't really. An interesting one that has been around for a few years -- that can be used by the general public, children, etc. -- is NetLogo (a takeoff from StarLogo). There is also a StarLogo Nova that is worth looking at.

But these are not really general simulation languages of the kind we need in 2016 and beyond ...

I think this is "still to be done" and "still extremely important"

Sure ...

Take a look at the Internet itself -- and then take a look at Dave Reed's 1978 PhD thesis at MIT (can be found via the CSAIL website) -- we used many of these ideas in the Croquet project