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.
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".
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.
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.
... 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!"
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).
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.