alankay

Thank you for this comment, I found it to be tremendously useful in helping me understand some of the attitudes of the present day.

I did understand the situation I was in, and I do see that the world has changed.

Arguments against passionately held positions are usually fruitless, and I don't like debate as a form. I will point out e.g. that there was nothing at all "top down" about the Xerox Parc process (that can be easily checked).

Leaving out the "anti-elite anger", I think that another round of the ARPA-IPTO type funding and research community (of which Parc was a part in the 70s) would make an enormous difference in the richness and levels of ideas and technologies available for computing to choose from. But let me note that the uptake of the 60s and 70s inventions by the larger field was a bit spotty and introduced a fair amount of noise when something was adopted at all. This would likely be the fate of many of newer better inventions than we were able to do 40 and more years ago.

The writer says: "For most of the rest of us, we have to get by with minimal funding and try to push ideas to an over saturated market." There's no question that the current side-conditions in commercial computing are stifling (and they were when I was a journeyman programmer in the early 60s: every important choice -- of problem, HW, tools, etc was already made and stipulated).

It's worth pointing out here that e.g. many of the most important inventions at Xerox Parc were done by a grand total of 25 researchers plus about an equal number of support folks. That represents a tiny percentage of "mad money" that most Fortune 500 companies would regard as "nothing". The cost in dollars is not the reason they don't invest in new inventions in computing, especially software.

One observation that I think obtains here, is that a very large percentage of computer people take much more joy in "devising" than "learning" -- and haven't tackled the idea that "lots of learning" will greatly uplift "devising".

I found the list above very illuminating in understanding where the author might be coming from. What's interesting is that it does represent "new things" that have appeared in the general world of computing -- and have happened after many of the ARPA/PARC etc. inventions.

I think that anyone who can find the perspectives to be able to criticize this list will also be able to see some of what has happened. What does it mean in the large that these are the solutions endorsed in the current day?

Something not on the list per se is the web and especially the web browser. Most computerists I talk to are unable to really criticize these, especially the latter. (The "new normal" seems to be inescapable "reality".)

I think a good one to pick on the list here would be "Docker" and "containers". There is a lot to be learned here, both about computing and people who do computing if this could be criticized deeply, and alternatives identified.

I find it interesting that the author purports to read my mind. This doesn't seem to be working.

Yes, the separate timelines of "Dealers" quite missed the cross fertilization and synergies of Parc (which were its main unusual features), so to me, this is a real drawback to this book. On the other hand, "systems" don't parse well into sequences, and Parc was a system, and thus needs something more like a 2D or 3D or 4D chart to do a decent explanation.

There are at least two big issues regarding cost that many people miss: (a) the first is the difference between what should be spent on "prototypes for learning and vetting" and what can be done when designing for manufacturing, and (b) the second is the the difficulty most people had with valuing what personal computing might be for them.

In the first public paper I wrote about the Dynabook I pointed out that Moore's Law meant that powerful tablet sized personal computers would likely wind up costing what a color TV set would cost (they would have pretty similar components, and most of the cost in electronics is in packaging).

But we also had another analogy that we though could work via education: that of the personal automobile in the US. People value cars enough to be willing to pay quite a bit more for them than for most consumer devices. This was very interesting because the ARPA dream of an interactive personal computer connected to a world-wide network was a kind of "information and intelligence vehicle".

If people could see this, then they might be willing to pay what they would pay for a car. Certainly most computer people and most scientists and engineers would be able to assign value in this way. We thought most knowledge workers would eventually be able to see this also, and that there would be an intermediate phase before getting to the TV set kind of technologies.

An analysis of what happened to eventually quash this idea is beyond the scope of this note. (But, to make a point in talks, I've tried to get people to think about what "a car's worth" of personal computer could be like (the average car in the US a few years ago was a Toyota Avalon at $28K, so about 10 times what most personal computers go for).

This is a different slant than the problem that DEC and similar companies had (which was to not be able to understand personal computing in any reasonable form).

Parc was an "extension" or "outgrowth" of the ARPA (before the "D") sponsored computer research in the 60s that was catalyzed by Congress overreacting to Viet Nam protests and changing ARPA's charter for the worse.

ARPA/Parc as a community had the best and most enlightened funding for computing research starting in 1962 (Parc started in 1970), and a very large percentage of the familiar technologies of today -- including personal computing, tablets, dynamic OOP, the GUI, the Internet, etc -- were invented by it.

The best (and pretty accurate) book about this remarkable group is "The Dream Machine" by Mitchell Waldrop.

Bob Taylor, who had been a director of the ARPA computing research, looked for a way to fund some of the "ARPA Dream" projects that Congress was curtailing, and found Xerox (which wanted to set up a longer range research lab).

Taylor was particularly interested in recruiting a number of the young Phds that ARPA had funded, and I was one of them.

Thanks!

A very nice remembrance by John Markoff in the NYTimes: https://mail.yahoo.com/d/folders/1/messages/AOkUKy0vu8HQXk9u...

The best book about the ARPA/Parc research community (Parc sprouted from ARPA) is "The Dream Machine" by Mitchell Waldrop: it is both the most complete and most accurate.

"Dealers of Lightning" is at the next level but far from the bottom. Its flaws are too much "Heroes' Journey" and a very complex and confused jumping around timeline (I had trouble myself orienting in some of the spots). But it also has a lot of good stories, of which a reasonable number are "true enough".

"Fumbling The Future" is extremely inaccurate.

Most of the people who were at Parc who are still alive are still doing research.

Pretty much only one wanted to get rich (and did). Several were more or less forced into becoming rich. Money has its own dynamics and none of these folks wound up doing further research.

But Butler Lampson (the "Oppenheimer" of Parc) is still going strong, as am I and many others.

It was a calling, never a job.

Please take the trouble to look more closely at what they did, and when.

No, that is Bert.

I knew Larry Tesler as a colleague, friend, member of my research group, manager, etc. for more than 50 years, almost as long as I knew Bert Sutherland.

There is an excellent obit for Larry at: https://gizmodo.com/larry-tessler-modeless-computing-advocat...

... and I expect another one from John Markoff -- who was a friend of his -- in the NYTimes.

In many ways, Larry did too many interesting things and had so much influence in too many areas for there to be any chance to characterize him technically. In short, he was a superb wide-spectrum(real) computer scientist who was also a very talented and skilled programmer.

His passing was sudden and unexpected, and I may return later to this note to add more details of his rich career.

For now, I remember him as great to work with in all aspects of his life. He was a great guy, and perhaps that sums him up as best as can be.

I knew Bert for well over 50 years, and the first word that comes to mind to describe him is "lovable", and the second is "foundational".

It is too early for those of us who loved him to recount "Bert stories" and especially "Bert and Ivan" stories, but Dan has provided the links to the YouTube video CHM tribute to the two brothers. Everyone should also read the Wikipedia article about Bert.

Bert's PhD thesis is most often characterized by its title "Online Graphical Specification Of Procedures", but once you look at it you realize that he was one of the first (if not the first) inventor of "dataflow" programs, and in fact this thesis was central to the many "prior art" definitions to quash lawsuits about dataflow ideas.

Another dimension to Bert's scientific and engineering career that is not mentioned enough is that he was one of the earliest and main drivers of what is called CAD today (a rather small number of people in different places made this happen in the early 60s -- including Bert's brother Ivan -- and Bert focused some of the powerful human and computing resources of Lincoln Labs on this vital technology).

Bert's personality was sunny, friendly, and "sweetly firm", to the point that many people clamored to have him as their manager (including only half-jokingly: Ivan). I was completely thrilled when Parc brought in Bert to run the Systems Science Lab in which my group, Lynn Conway's group, Bill English's group etc were all ensconced.

Bert, as with the other enlightened ARPA research managers knew that "the geese wanted to lay their golden eggs" and the manager's job was to support these efforts, not to try to tell the geese how to lay the special eggs). He was superb at this, and many critical inventions and systems happened because he was the nurturer.

I guess I should tell a "Bert and Ivan" story. Their father was a civil engineer who brought not just blueprints home but gadgets and kits for the two brothers -- who were just two years apart in age -- to play with. Bert would recall that Ivan was so smart that he would just start putting the stuff together while Bert read the manual. At the 95% point Ivan would get stuck and Bert would know what to do next. The two brothers with very different personalities got along wonderfully well over their entire lives, and would occasionally do a company together.

A big deal when the kids were young was their mother driving them down from Scarsdale to Murray Hill to Bell Labs to meet Claude Shannon. Years later at MIT, Shannon wound up being a thesis supervisor of both of their PhDs done a few years apart.

I think most of us from 50+ years ago in the ARPA community just revered and were in awe of the research generations that came before us, especially the one right before us. It was tough to do computing back then, but they didn't let this bother them at all. They would program anything they wanted to have happen -- mostly in machine code -- and they would design and build any hardware they needed to run the programs they needed -- mostly with discrete components and relatively high voltages over sometimes acres of computer.

They showed us how to work and play and design and sculpt and the deep art that lies behind the components. We can never thank them enough, and can only "pay forward" by helping those who come after us.

Gary was a wonderful person, an engineer's engineer, with an inquisitive scientific bent and warm sense of humor about and love of invention.

His move from Rochester to Xerox Parc in its earliest days was his "last chance" according to Xerox management. There he found kindred spirits who welcomed him and would up quickly loving him for his fearless approach to invention, no matter how difficult.

He was a great guy to work with and be with (one of the raft of things I did in the early days of Parc was to experiment with the design and making of high quality display fonts using an allout video system* that could reach the limits of video). We realized that it could barely do the much larger characters needed for the first laser printing system and rigged a coax from "the old character generator room" down the hall to Gary's lab to provide test pages for Gary's early experiments.

The story below about the use of Edmund Scientific "hobby" reflecting telescopes is more or less the way it happened -- except that the front part that says he was "annoyed" is not. That was not Gary's style; he just moved forward, and what happened is very similar in spirit to the computer researchers at Parc building their own simulated mainframe (MAXC) also in the first year because Xerox wouldn't allow us to buy a PDP-10 which was made by a competing company.

I also object to him being called "a badass" (I realize it is suppose to be a compliment, but it quite misses what really top talents are like in its attempt to suggest some kind of pop-culture teenage aggressiveness. Gary was an artist who simply transcended difficulties put in his way.)

He now joins another great engineer's engineer at Parc -- Chuck Thacker -- in our memories of truly great people who could do truly great things.

--------- * designed by Butler Lampson, Bill English and Roger Bates, and mostly built by Roger, with an excellent interactive font design program made by Ben Laws.

In the HOPL paper is some discussion of the first design for Smalltalk, that I was working on when "the bet" happened and brought Smalltalk-72 to life as the answer to "the bet" (it used a combination of Lisp and Meta II techniques to win the bet). This made it quite easy to implement, and once Dan Ingalls implemented it, we started using it.

Smalltalk-71 was never implemented (and never had its design finshed, so there is less that can be claimed about it). But, germane to this discussion, I really liked Carl Hewitt's PLANNER language, and the entire approach to "pattern directed invocation" as he called it -- this was kind of a superset of the later Prolog, and likely influenced Prolog quite a bit.

The PLANNER ideas could be used as the communications part of an object oriented language, and I thought this would be powerful in general, and also could make a big difference in what children could implement in terms of "reasoning systems" (not just imperative action systems).

For Smalltalk-72 I used a much more programmatic approach (Meta II) to recognize messages (that also allowed new syntax/languages to be defined as object protocols (to win the bet) but this was not done comprehensively enough to really use what was great about PLANNER.

There were a few subsequent attempts to combine objects with reasoning, but none of them that I'm aware of were done with end-users in mind.

I thought the subsequent ACTOR work by Carl and his colleagues produced really important theoretical results and designs, most of which we couldn't pragmatically use in the personal computing and interface work on the rather small Xerox Parc personal computers.

This is a quite inaccurate comment. The catalysts (in 1966) for the ideas I had included Sketchpad (especially), Simula I (a few days later), the ARPAnet (under discussion), operating systems inter-process communications (especially Project Genie), the Burroughs B5000, my old biology and mathematics majors. All these are mentioned in "The Early History of Smalltalk" that I wrote for the ACM History of Programming Languages"

Actors appeared after I gave a talk at MIT about the very first Smalltalk.

There were several later ideas that were discussed at Parc but not taken up because of the whirl that was already going on. One of these was derived from McCarthy's "fluents" and "situations" (essentially a labeled states/layers idea for allowing concurrencies without race conditions -- this was done very well in David Reed's 1978 MIT thesis.

Another was not waiting for replies. This was in the original set of ideas -- via biology and OS techniques -- but never got implemented in a deep way. The hardware we had at Parc was tiny and Smalltalk was expressive enough to fit a lot into a little.

Another set of ideas that were completely missed appeared in LINDA by Gelernter. This (and the larger ideas around it) are very good ways to deal with larger scalings, etc.

From the very proper English lady across the table from me at a supper at Douglas Adams' house: "You Americans have the best high school education in the world -- what a pity you have to go to college to get it!"

Actually, I said: "I invented the term "object-oriented", and I didn't have C++ in mind".

In other comments here I explain why "object-oriented" was a too quick and bad choice for what I thought I was doing ...

Merrill Engineering Building! I'm glad it is still around. Those long hallways were used as a "display" to unroll the many pages of Simula machine code listings down one corridor so that three grad students -- including me -- could crawl over it and coordinate to try to understand just what Simula might actually be (the documentation in Norwegian that had been transliterated into English was not understandable).

It's out of the context of this thread, but we were quite sure that "simulation-style" systems design would be a much more powerful and comprehensive way to create most things on a computer, and most especially for personal computers.

At Parc, I think we were able to make our point. Around 2014 or so we brought back to life the NoteTaker Smalltalk from 1978, and I used it to make my visual material for a tribute to Ted Nelson. See what you think. https://www.youtube.com/watch?v=AnrlSqtpOkw&t=135s

This system --including everything -- "OS", SDK, Media, GUI, Tools, and the content -- is about 10,000 lines of Smalltalk-78 code sitting on top of about 6K bytes of machine code (the latter was emulated to get the whole system going).

I think what happened is that the early styles of programming, especially "data structures, procedures, imperative munging, etc." were clung to, in part because this was what was taught, and the more design-intensive but also more compact styles developed at Parc seemed very foreign. So when C++, Java, etc. came along the old styles were retained, and classes were relegated to creating abstract data types with getters and setters that could be munged from the outside.

Note that this is also "simulation style programming" but simulating data structures is a very weak approach to design for power and scaling.

I think the idea that all entities could be protected processes (and protected in both directions) that could be used as communicating modules for building systems got both missed and rejected.

Of course, much more can and should be done today more than 40 years after Parc. Massive scaling of every kind of resource requires even stronger systems designs, especially with regard to how resources can be found and offered.

An interesting and unfortunately true commentary on the lack of civilized behavior using technology that actually required a fair amount of effort -- and civilized behavior -- to invent in the first place.

I'm the "computing Alan Kay" from the ARPA/Parc research community (there's a clarinettist, a judge, a wrestler, etc.) I did create a new account for these replies (I used my old ARPA login name).

Again, please do your homework.

That isn't what happened at all (see the rebuttal by revvx). Joe was a great guy and also a great systems thinker. And he was the last person to worry about "bandwagons" (quite the opposite!)

I didn't coin the term "object" -- and I shouldn't have used it in 1966 when I did coin the term "object-oriented programming" flippantly in response to the question "what are you working on?".

This is partly because the term at the time meant a patch of storage with multiple data fields -- like a punched card image in storage or a Sketchpad data-structure.

But my idea was about "things" that were like time-sharing processes, but for all entities. This was a simple idea that was catalyzed by seeing Sketchpad and Simula I in the same week in grad school.

The work we did at Parc after doing lots of software engineering to get everything to be "an object", was early, quite successful, and we called it "object-oriented programming".

I think this led to people in the 1980s wanting to be part of this in some way, and the term was applied in ways that weren't in my idea of "everything from software computers on a network intercommunicating by messages".

I don't think the term can be rescued at this point -- and I've quit using it to describe how we went about doing things.

It's worth trying to understand the difference between the idea, our pragmatic experiments on small machines at Xerox Parc, and what is called "OOP" today.

The simplest way to understand what we were driving at "way back then" was that we were trying to move from "programming" as it was thought of in the 60s -- where programs manipulated data structures -- to "growing systems" -- like Smalltalk and the Internet -- where the system would "stay alive" and help to move itself forward in time. (And so forth.)

The simplest way to think about this is that one way to characterize systems is that which is "made from intercommunicating dynamic modules". In order to make this work, one has to learn how to design and maintain systems ...

This is way off. Please try to do more homework.

P.S. Joe and I have had the most wonderful conversations, right up to a few months ago. We'll miss him terribly and remember him vividly!

Rumors of my passing have been greatly exaggerated!

What a wonderful spirit he was, never to be forgotten. We had lots of great interactions over the years, and he greatly enriched computing with his ideas and actions.

What a wonderful spirit he was, never to be forgotten

For "discovered" vs "invented" I think you have to posit your definition of "exist". This puzzled Russell, Whitehead, Wittgenstein, etc.

The Peano axioms describe constraints for instances within a set. Is something already "there" just because we can test the constraints after it appears, or use them to make it?

The foundations of OMeta go way way back (starting with Meta II by Val Schorre ca 1964 -- and in the context of the many different approaches to parsing in the 60s). The modern addition to help make OMeta was the packrat parsing idea. It wouldn't be surprising if some Prolog lore wafted its way in, but I don't recall that any of the many parsing schemes that Prolog has been used for were in the conversations. One of the Ur-centers that most parsing theory has to contend with is "Earley Parsing". However, the idea that a dynamic proof can be used to parse goes very far back.

The "someone" for Smalltalk was Dan Ingalls.

I came up with the Smalltalk half-pager because John McCarthy had shown how to do it -- and because message-passing OOP can be a not too crazy perspective on Lisp (especially a variant of "apply", and especially if you use the FEXPR and closure ideas).