Eric Bier Demonstrates Cedar

The Oberon channel has several videos of Oberon in action, link While Oberon was quite cool, people should also learn about its Xerox influence, "Eric Bier Demonstrates Cedar" ▶ this video Also dive into what happened afterwards, Oberon-2, Active Oberon, Zonnon,... Active Oberon could be considered quite modern, also makes the distinction between safe and unsafe pointers, which improves the experience for low level coding. link One of the best things about these systems is proving what systems programming with automatic memory management were capable of. Given Oberon-2's influence on Go, maybe improving Fyne (link) with something like gRPC for the dynamic experience, could be a possible sucessor.

Previous HN discussion about that video: link ▶ this video I posted about PCR: link This is a great video! They discussed and demonstrate Cedar's early text selection, copy and move commands, and compare them to Larry Tesler’s cut and paste (which didn't require any special keys or more than one mouse button). The Tioga text editor and other Cedar applications made common operations like repeatedly copying text into a document from different places very easy and streamlined (fewer actions than cut, copy and paste), by using the shift key while selecting text. Cedar took full advantage of the three button mouse as well as the control and shift keys (for 12 combinations of actions in any context, that worked the same everywhere). I think SunView and maybe even OpenWindows also supported a similar (but obscure) “quick paste” mode, where you hold down the special “Copy” function key, select some text without disturbing the current input focus, cursor position, or text selection, and then when you release the key, that text is pasted into the current input focus at the current position, moving the cursor forward. That way you didn’t have to lose your current selection or position, in order to just select some other text and copy it in. Here, I found the code to do it in an old version of NeWS -- it was the cut key to move, or the paste key to copy, and it's called the "Secondary" selection (rank=Secondary): link % Cut key: Either delete the primary selection (stashing it % on the clipboard) or move the secondary selection to the % focus, if one was made. % Paste key: % Insert either the secondary selection (if one was made) % or the contents of the clipboard. When he browses through the code, you can see a whole bunch of X11 stuff. 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. CSL-89-8 June 1989 [P89-00DD6] link >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

> Thanks for sharing, I love these types of stories. Really makes me pine for the "old" days, and wonder if there's a parallel universe where technology took a very different route such that languages like APL, Lisp, and Smalltalk are used instead of JavaScript, Java, and C#, and what that world looks like. Easy, here is some time travel, "Alan Kay's tribute to Ted Nelson at "Intertwingled" Festival" link "Eric Bier Demonstrates Cedar" ▶ this video "Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo" link However to be fair, Java, C# and Swift alongside their IDEs are the closest in mainstream languages to that experience, unless you get to use Allegro, LispWorks or Pharo.

On Oberon, Mesa/Cedar and Lisp Machines, the experience extends to the whole OS and any application, or REPL, not just a plain text editor. Althought I haven't mentioned, Smalltalk also provides a similar experience. Here are some videos that try to convey it, from my playlists, "Eric Bier Demonstrates Cedar" ▶ this video "Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0" link "SymbolicsTalk28June2012" "SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO" link "Symbolics Lisp Machine demo Jan 2013" link The Native Oberon demos available at link

Be prepared to be amazed with what Xerox PARC and others were doing, while Bell Labs was busy pushing for UNIX. "Eric Bier Demonstrates Cedar" ▶ this video "Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0" link "Documents as User Interfaces Video Demo" link "SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO" link "Alto System Project: Dan Ingalls demonstrates Smalltalk" link "Action!, the worlds first dynamic interface builder - 1988" (Interface Builder percursor, written in Lisp) link "The Interlisp programming environment" link And the cherry, how Lucid used Lisp ideas for their Energize C++ IDE, including an image based format for AST storage link link

Good that you mention Engelbart, because none of the mainstream desktop OSes are close to his ideas, or what the Xerox workstations allowed for, ironically Windows is probably the one most closest to it. While GNU/Linux have the necessary tooling for making it as well, but thanks to the fragmentation and some communities hatred against GNOME/KDE, it will never happen. This is what a modern desktop OS should look like, "Eric Bier Demonstrates Cedar" ▶ this video Including the part of being written on a memory safe systems programming language.

It is a bit hard to explain in an HN comment something that requires live experience, You can start by having a look at, link "Eric Bier Demonstrates Cedar" ▶ this video "Alto System Project: Dan Ingalls demonstrates Smalltalk" link "SYMBOLICS CONCORDIA ONLINE DOCUMENTATION HYPER TEXT MARKUP 1985" link You can see how NeXT builds on many of these concepts on the famous "NeXT vs Sun" marketing piece, link Sun also had some ideas along these lines with NeWS, "NeWS: A Networked and Extensible Window System," link Naturally OS/2, BeOS, Windows, macOS, iOS, and even Android share some of the ideas. Now, before I proceed note that actually modern Linux distributions have all the tooling to make these concepts happen, but it fails short to have everyone agree on a proper stack. So basically, the main idea is to have a proper full stack in place for developing a Workstation computer as one single experience, from bottom all the way to the top. On Xerox's case, they used bytecode with in-CPU execution via programmable microcode loaded on boot, and later on just a thin native glue on top of host OS. The environments had frameworks / modules for the whole OS stack, supported distributed computing, embedded of data structures across applications (OLE can trace its roots back to these ideas), REPLs that not only could interact with the whole OS (commands, modules, running applications), it was also possible to break into the debugger, change the code and redo the failed instructions. Linux distributions get kind of close to these ideas via GNOME and KDE, but the whole concept breaks, because they aren't part of a full OS, rather a bunch of frameworks, that have to deal with classical UNIX applications and communities that rather use fvwm (like I was doing in 1995), and use a bunch of xterms, than having frameworks talking over D-BUS, embedding documents, all integrated with a REPL capable of handling structured data, and call any kind of executable code (including .so, because the type information isn't available). And then every couple of years the sound daemon, graphics stack or whatever userspace layer gets redone, without any kind of compatibility, because it is open source so anyone that cares should just port whatever applications are relevant. It is quite telling that most Linux conferences end up being about kernel, new filesystems, network protocols, and seldom about how to have something like a full BeOS stack on Linux. Even freedesktop can only do so much.

Ah, what a delightful rabbit hole your comment led me down.. I've got about twenty tabs open now, articles on the history of (and the relationships between) programming languages and graphical user interfaces. Will enjoy this food for thought! My recent reading has included: Unix: A History and a Memoir (Brian Kernighan) - link The Development of the C Language (Dennis Ritchie) - link JavaScript: The First 20 Years (Brendan Eich) - link (PDF) This morning, this little phrase jumped out: > C was created on a tiny machine as a tool to improve a meager programming environment. What this made me realize is that a language is a user interface. It makes sense how C evolved with UNIX as an operating system, that a language is deeply fundamental to a computing environment (and its development). There's a parallel with JavaScript and Netscape. The language was meant to provide users with an interface to operate the web browser, create dynamic documents, and (as it turned out) to let users develop the web environment. ..Which brings me back to the Cedar/Tioga programming environment you mentioned. While searching around, I happened across another comment of yours (I see it's a favorite topic! :) and found the good stuff: Eric Bier Demonstrates Cedar - ▶ this video (video) Active Tioga documents: an exploration of two paradigms - link (PDF) The Mesa Programming Environment - link (PDF) Fascinating. I saw a phrase, "active document applications", which interestingly is what the web has become, in its own monstrous way. It's a good point about "re-introducing" old ideas. I was lucky to have grown up in the earlier days of computers, to have breathed (a little) of its different culture and worldview, that I've learned to appreciate its history and the wealth of ideas - what made possible our current networked computing environment, and visions yet to be fully realized.

Only for those ideologically against GC in systems programming languages. link > Docker Desktop avoids this problem by forwarding all traffic at user-level via vpnkit, a TCP/IP stack written in OCaml on top of the network protocol libraries of the MirageOS Unikernel project. link link And to go back to the 1980s, more broadly than only OCaml, "Eric Bier Demonstrates Cedar" ▶ this video Or if you prefer bare metal stuff, with hard real time requirements, and somehow more mainstream language, > Aonix PERC Ultra Virtual Machine supports Lockheed Martin's Java components in Aegis Weapon System aboard guided missile cruiser USS Bunker Hill link > Thales Air Systems Selects Aonix PERC Ultra For Java Execution on Ground Radar Systems link Nowadays Aonix has been integrated into PTC. link

Including how to build a full workstation with memory safe systems languages, besides Smalltalk, Interlisp-D, now recovered and playable in the browser, link Mesa with XDE (think the safety Zig is selling today, but in 1985) link Cedar, a full graphics workstation in the evolution of Mesa, now with proper mix of reference counting + cycle collector, as full GC implementation, Here the demo done by Eric Bier for the Computer History Museum, ▶ this video

I remember trying out Plan 9 a few years ago. I like its underpinnings; I like how the designers pushed the Unix notion of "everything is a file" to its limits, with various services being presented to the operating system as file servers implemented using a protocol named 9P. It's a cool research operating system with a lot of very interesting ideas, but ultimately it's not my daily driver due to a lack of hardware and software support, though I am working on a research project (but for conventional *nix operating systems) that takes advantage of 9P. Carmack's description of the rio GUI is apt; rio is heavily based on Xerox PARC's Cedar environment from the mid-1980s (▶ this video). I had a hard time getting used to rio, though eventually I learned it. I even purchased an old Sun three-button mouse (with no click-wheel) since Plan 9 didn't like my click-wheel mouse. rio does not adopt a lot of the conventions that were introduced by the Apple Lisa, Apple Macintosh, and Microsoft Windows, resulting in a completely foreign experience for most new Plan 9 users. There is a misconception that Apple and Microsoft simply stole the idea of GUIs from Xerox PARC without further innovating on it. This misconception is false; the Apple Lisa and the Apple Macintosh introduced many GUI conventions that were not present in Xerox PARC's GUIs (this video comparing the Apple Lisa to the Xerox Star highlights the differences: link), and Windows introduced additional innovations. Back to Plan 9, the result is a GUI that has many conventions that were explored by Xerox PARC but were not adopted by the Mac or Windows, such as mouse chording (link). Hence, there's a learning curve for those accustomed to conventional GUIs. Even so, the ideas behind rio seem to do a good job with exploiting Plan 9's architecture and showing how it could support a more tools-oriented design. Moreover, it was borrowed from Xerox PARC's Cedar. It would have been quite a research effort to create a Mac- or Windows-like GUI for Plan 9 that made full advantage of Plan 9's "everything is a file" architecture. Merely implementing a Mac- or Windows-like GUI to Plan 9 might not have taken full advantage of Plan 9's architecture, which I think is the key difference between Plan 9 versus other operating systems. Perhaps in some alternate universe where Apple and AT&T merged in the 1990s and Apple built their successor to the classic Mac OS on top of Plan 9 with Apple people like Larry Tesler, Bruce Tognazzini, and Alan Kay joining forces with Dennis Ritchie, Ken Thompson, and Rob Pike....come to think of it, it's quite interesting to think about that possibility, though I don't think Apple would have made its post-1997 comeback without Steve Jobs, no matter how good "Mac OS Plan 9" would've been.

And the foundation of one of the very first memory safe systems programming languages, with automatic resource management, using a mix of reference counting with a cycle collector, Cedar. "Eric Bier Demonstrates Cedar" ▶ this video Mesa also provided the very first IDE experience for strongly typed languages, with code completion, typo correction, dynamic code loading, a REPL, incremental compilation,... "The Mesa programming environment" link Indeed, so many still catching up to Xerox PARC vision.