During our morning standup this morning one of my colleagues pulled up the archive and dug up some of my source files from 40 years ago. He had been my colleague back then so I found some of his.
Great to hear you still making software! I assume because you still like it :)
Just out of curiosity, what kind of development are you doing at the moment? Can imagine after so many years it gets harder to find a challenging project.
There is no shortage of interesting code to write and I’m sure there always will be.
I was still working on symbolic AI but dropped it in 2021 in order to work on a more urgent problem, fighting climate change. So mostly it’s chemistry/engineering though there is also software to write.
Our standup was about building a test fixture for our lab.
What was the working/creative environment back at your PARC tour-of-duty?
The usual office politics or a special environment where everyone got along and collaborated?
Minimal politics, at least as far as I could tell, and lots of collaboration. Since PARC made its own tools there was a fair amount of cross-lab communication but really I just talked to other people in ISL (intelligent systems lab). I was just a kid.
The labs seemed to be renamed and organized from time to time so maybe there was politics I was too naive to see.
It was like google’s reputation 15-20 years ago: although Jeff ( my colleague today) and I didn’t work together we knew each other, also later knew each other from Stanford KSL/CSLI and later worked briefly together and work together today. I later worked for Doug Lenat at MCC (another research lab) whose office had been down hall from mine. And I still see other former PARC colleagues who are all over the Valley. So not an ivory tower.
Lots of interesting odds and ends, I've only perused it casually but I do wonder about the Cedar demo Eric Bier did a few years back, if the runtime system for that is included...
Also if anyone is interested in Medley Interlisp-D, do be aware that the project has been resurrected and is under active development on GitHub for contemporary operating systems using a permissive license.
Wow, is this the Mesa and Cedar compiler and development environment source code?
Is anyone around who knows what to find in which of the numerous subdirectories? I would like to build some supporting tools to analyze and cross-reference the code.
Is the source code of the Solaris port of Cedar also available? If yes, maybe it's feasible to port it to Linux.
Meanwhile I implemented a little viewer (https://github.com/rochus-keller/Cedar/ ) and started to study the source code, but was very surprised that there doesn't seem to be any object orientation. I had a look at Lampson's Cedar language description some years ago and had the impression that it included OO support, but this was apparently not implemented. I'm particularly interested because Wirth created Oberon after his second stay at PARC where he was exposed to the Cedar language and environment, and Oberon has inheritance (and there are quite many similarities of his Oberon System UI with the Cedar UI).
The Cedar language version manifested in the now published source files (including the Solaris version by 1993) seems to be rather Mesa plus garbage collected structures implicitly "interiting" from ANY for late binding, but no general inheritance and apparently also no polymorphism.
The CD includes a subdirectory called "ppcr/v1.13" with the note "We weren't able to include the source for ppcr with this CDROM, but you will find the header files here describing its interface."
In the paper "Experiences Creating a Portable Cedar" (1989) by Atkinson et al. the PCR Runtime System is described.
Do you happen to know whether this code is included in the now published archive somewhere. Or is it available somewhere else?
thanks for the hint; with the -r option I was indeed able to download the whole directory which took ~3.5 hours (31638 files, 18678 of which hidden, 942 MB in total); the tree includes 3441 .mesa files and ~1900 C source files, a lot of which apparently generated.
PCR (Portable Common Runtime") from PARC was a reimplementation of the runtime that Cedar and Mesa and even a PostScript interpreter used, so they could be ported to run on Unix (Sun SPARC and maybe 68k). It included the Bohem/Weiser garbage collector, among other stuff.
That's what Eric Bier was demonstrating in the Computer History Museum Cedar Demonstration video I linked to below. I've written more about PCR before:
>So there was an ongoing discussion about the best way to do it all over again from scratch. Scheme was obviously an excellent language to use instead of PostScript. Here are some notes from February of 1990 (before the abomination that is CORBA was thrust upon the world), discussing how to apply John Warnock's "linguistic motherboard" ideas to other languages like Scheme, and how to implement them on top of something like Xerox PARC's "PCR" (Portable Common Runtime, essentially the virtual operating system runtime that Cedar and other Xerox software like Interpress required to run on other platforms like Unix).
>(But first here's some other stuff I wrote recently about Cedar and PCR, for context. And I've inserted some links into the notes.)
>You know what's a lot like Ada in a good way is Mesa, which evolved into Ceder, from Xerox PARC. I know people who really loved programming in it. They'd call it "Industrial Strength Pascal". It was a successful experiment in code reuse. A strongly typed language with strong separation between interfaces and implementations, which encouraged creating robust, hardened code.
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
>Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
>I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it.
>Experiences Creating a Portable Cedar.
Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser.
>>Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the performance of our "Portable Cedar".
>PCR implemented threads in user space as virtual lightweight processes on SunOS by running several heavy weight Unix processes memory mapping the same main memory. And it also supported garbage collection. Mark Weiser worked on both PCR and the Boehm–Demers–Weiser garbage collector.
The Computer History Museum is not out to get you. It's just as annoying for me to watch people whine and complain about being surprised and disappointed that web sites don't work well when you disable JavaScript, as it is for you to look at ads. It's as if some people just performatively use JavaScript blockers to make themselves martyrs so they have something to complain about and pretend to be surprised and disappointed web sites don't work as expected. You're free to waste your own time, but please don't waste mine too by complaining about predictable problems you knowingly and willingly inflicted on yourself. If you really want the Computer History Museum to improve their web site, then volunteer to work on it for free, or contribute some money at least.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
