HN Theater @HNTheaterMonth

Enjoy the demo of Mesa/Cedar then,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

One for Oberon,

https://www.youtube.com/watch?v=OJGnpmnXR5w

IBM Redbooks are a source of information for IBM i and z

https://www.redbooks.ibm.com/

And Burroughs is still sold as ClearPath MCP.

https://public.support.unisys.com/search2/DocumentationSearc...

Nope,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

Or, for another example,

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

It is only incompatible with UNIX school of thought.

You're right, it should be compared to Mesa/Cedar,

https://www.youtube.com/watch?v=z_dt7NG38V4

It is, and for Apple, it is the successor of their system languages, explicitly stated on Swift documentation.

Here enjoy a full graphical workstation OS developed at Xerox PARC, Mesa/Cedar uses reference counting with a cycle collector.

https://www.youtube.com/watch?v=z_dt7NG38V4

However, RISC OS (Acorn), 1987, with an icon bar. :-)

Project lead Paul Fellows is quoted in this article [1] as follows ("Arthur" being the code name for one of two competing projects, which became RISC OS),

> "I found this page I was very pleased by: 'Apple acquired the Dock from Steve Jobs' NeXTstep OS which stole it from Acorn's Arthur Operating System of 1987.'"

and,

> "There was a guy at Colton Software with us… who joined Microsoft in Seattle, and it was shortly after that that Windows acquired an icon bar. I know how that idea got there."

And on the rationale behind it,

> "In case anyone ever asked where it came from, we were sat in a room thinking 'how do we design this to be different, so we don't get sued by Apple?' The Mac had a menu bar of text across the top, so we thought 'we can't go across the top, we'll have to go across the bottom – and we can't use text, so we'll have to use icons.' That's why it's like that,"

[1] https://www.theregister.com/2022/06/23/how_risc_os_happened/

Edit: That said, Xerox PARC had the Cedar development environment in the 1980s and this featured sort of a task/icon bar already. Notably, the second, long ongoing project for an Acorn operating system, written in Modula 2, was conducted at ARC (Acorn Research Center) in Palo Alto, next to PARC. There may have been some exchange (and inspiration) involved.

[2] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1...

[3] Video, "Eric Bier Demonstrates Cedar", CHM YT channel, https://www.youtube.com/watch?v=z_dt7NG38V4

Demo of Mesa/Cedar system, the lesser known system from Xerox ones, written in memory safe systems programming language of the same name, with reference counting and a cycle collector, and those unsafe code blocks.

https://youtu.be/z_dt7NG38V4

Replicates the Lisp and Smalltalk development experience, introduces ideas that were inspiration for Oberon Gadgets, OLE and OpenDoc, had networking, file servers, only downside was being single user workstation.

We as industry are still catching up with that experience and overall system safety.

⬐ agumonkey

I really wonder if we're not ready for a compression phase. Simpler, safer, expressive sets of ideas to unify OS/stack/network/UI.

⬐ ilaksh

Take a look at MirageOS (ocaml)

⬐ pjmlp

In a sense that is what unikernels/managed runtimes running on top of type 1 hypervisors represent, now if we ever get a consumer OS with that approach, it remains to be seen.

I don't expect to still see it during my lifetime.

Maybe when computing gets rebooted with quantum computing, if you check the languages being used for research (Q#, Qiskit, visual), none of them are classical C or C++ like.

⬐ agumonkey

That's on the bare metal side, without disagreeing I was mostly thinking about the ~user/programmer side notion of computing. Tiny blocks of near stateless logical operations streamed (so sync or async or threaded .. no difference). But in a way unikernels are also a way to rethink what a system is.

⬐ thrwawy283

I'd like to think these ideas have been around and well-known for decades, and we're starting to see the hardware rise up to support them. If you told someone in 2001 that Linux would be rewritten in say, Java, with a garbage collector it would have been dismissed as starkly inefficient. Nowadays we have hardware that makes certain safeties negligible on performance (memory tagging, bounds checking, etc). Nowadays we can make an OS out of Java and it will stand just fine. Or Rust. Faster hardware means we run slower (and safer) software. Not everything gets isolated into an ASIC, of course.

⬐ kaba0

They could have made an OS in a managed language decades ago.

⬐ mcswell

They did. They were called LISP machines.

⬐ pjmlp

It would still be dismissed as starkly inefficient, because the problem isn't technology, rather mentalities.

Midori powered Asian Bing as proof of its capabilities, and yet Windows team was dismissal of its capabilities and instead went on reinventing .NET with COM, aka .NET Native and C++/CX alongside WinRT. A kind of ironic given that it was .NET original design (codename Ext-VOS), before they decided to reboot COM with a managed runtime, alongside the J++ issues that caused COOL to become C# instead.

Quite interesting feedback from Joe Duffy how everything went down,

"Safe Systems Programming in C# and .NET" - https://www.infoq.com/presentations/csharp-systems-programmi...

"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing" - https://www.youtube.com/watch?v=EVm938gMWl0

> OS and tools for building dependable systems. The Singularity research codebase and design evolved to become the Midori advanced-development OS project. While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia.

https://www.microsoft.com/en-us/research/project/singularity...

Ironically, despite still having the Linux kernel underneath and enough C++, Android and ChromeOS are probably the mainstream OSes that are closer to the overall idea, at least in what concerns userspace applications.

As on the Microsoft side, WinDev seems to always sabotage those ideas, as you can infer from Joe Duffy talks, and from Apple side although Swift is supposed to play a major role going forward, C, C++ and Objective-C still represent the majority of the stack.

⬐ Maursault

>> The Singularity research codebase and design evolved to become the Midori advanced-development OS project. While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia.

> https://www.microsoft.com/en-us/research/project/singularity...

> Ironically, despite still having the Linux kernel underneath and enough C++, Android and ChromeOS are probably the mainstream OSes that are closer to the overall idea, at least in what concerns userspace applications.

Singularity uses a proprietary language-based microkernel. Midori was allegedly an attempt at a commercial version of Singularity, and I'm not sure what is different about the two, but Midori also uses a microkernel. Linux famously uses a monolithic kernel. Also, consider, any operating system that uses the Linux kernel... is Linux by definition, though technically Linux is the kernel, GNU/Linux is the OS.

There is a piece of container management software, I think that's what it is, called Singularity, and it uses the Linux kernel running on Linux. Maybe you were thinking of the wrong Singularity.

⬐ pjmlp

Yes Singularity uses a C++ based microkernel and everything else is written in Sing#, what is your point?

Midori has nothing to do with Singularity in architecture other than being a second attempt from the same group of researchers at a memory safe OS.

Android and Chrome OS aren't Linux, they use a highly customized Linux kernel, in fact after Project Treble it is so customized that it could almost be considered a pseudo-microkernel, as all Treble drivers exist as user processes, use Android IPC to talk to the kernel and since Android 8 all drivers must be Treble based (Android considers the Linux kernel drivers as "legacy drivers").

Finally I don't see how Singularity and the Linux kernel have anything to do with each other, my examples with Android and ChromeOS are what I mentioned in relation with the Linux kernel.

⬐ Maursault

> Ironically, despite still having the Linux kernel underneath

I misread what you were referring to is all. I thought you were saying Singularity ran on the kernel linux, but you were not saying that at all. You were talking about the GNUless Android and ChromeOS. Comprehension is underrated.

⬐ Rochus

Yes, Cedar was impressive, like the adult version of the Oberon system. I wonder if the source code of the Cedar environment is available somewhere. There is an interesting report by Atkinson (and Jacobi, who is on the panel in the posted video) where they migrated the environment to Unix using C as an intermediate layer. This is apparently the version used for the demonstration. But I couldn't yet find this source code anywhere. Maybe someone has a link.

⬐ pjmlp

Some of the Xerox PARC digital archives have printouts from Cedar, including the bytecode and microcoded CPU instructions, now if everything is there, no idea.

⬐ pmcjones

That version of the Cedar source was on a CD-ROM accompanying the blue-and-white version of this SOSP'93 paper:

Carl Hauser, Christian Jacobi, Marvin Theimer, Brent Welch, and Mark Weiser. 1993. Using threads in interactive systems: a case study. SIGOPS Oper. Syst. Rev. 27, 5 (Dec. 1993), 94–105. https://doi.org/10.1145/173668.168627

⬐ Rochus

Thanks for the hint. It seems the additional data is not available from the ACM site. Was really the source code of the whole environment including the Mimosa compiler on the CD? Do you know anyone who has access to it? I might be interested (if feasible) to migrate and run it on contemporary operating systems.

The Oberon channel has several videos of Oberon in action,

https://www.youtube.com/results?search_query=The+Oberon+Chan...

While Oberon was quite cool, people should also learn about its Xerox influence,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

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.

https://github.com/metacore/A2OS

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 (https://fyne.io/fynedesk/) with something like gRPC for the dynamic experience, could be a possible sucessor.

⬐ badsectoracula

While these are called "Oberon", judging from the screenshots (i haven't watched the videos), they seem to be way beyond the minimalistic nature of the Oberon system shown in Project Oberon.

I think the emulator linked at the bottom left side is a better way to check out Oberon in action as you can easily (well, after you figure out how things get compiled, etc :-P) see it in practice and how a few individually simple (if not outright primitive) things can be combined to create something nice. For example i always found it amusing that the "menu bar" in each window is really just a regular text area and the commands shown are really methods that are called when you (IIRC) middle click them, like any other text in a window (so the main "GUI" for a program can really by just a text file with methods to click on - and of course since it is editable you can simply customize the GUI by editing the text file).

⬐ pjmlp

They are Oberon, the system that was described on the first edition of Project Oberon was the version 1.

ETHZ researchers and Niklaus Wirth then iterated further on the Oberon (the OS) and Oberon (the language).

The definitive Oberon (the OS) version that still uses the plain Oberon (the language) from original project was System 3, which is what those videos relate to.

In Active Oberon used to write AOS (BlueBottle OS), you can still relauch System 3 as a nested OS.

⬐ badsectoracula

Yes they are Oberon too but my point is that they've evolved and added a ton of stuff that go further than the minimalistic nature of the linked site. The "Project Oberon" in the site doesn't even have overlapping windows or color for example.

⬐ pjmlp

That is like evaluating what MS-DOS was capable of by looking at MS-DOS 1.0 instead of 6.22.

Oberon 1.0 isn't what was the daily driver at ETHZ, beyond its initial introduction.

⬐ badsectoracula

The point of the linked project isn't to evaluate what the most advanced version of Oberon is but to show a minimalistic system built from the ground up in a way that can be entirely understood by a single person. It is mentioned at the top of the page.

⬐ wrycoder

I consider Active Oberon and AOS to be forks, and I think Wirth does, also. I believe that he feels that Project Oberon is his final word on the subject.

Wirth created Oberon-7 largely by removing features[0]:

Revised Oberon (Oberon-07) is a revision of the original language Oberon as defined in 1988/1990. It is accepted by the compiler recently completed for the ARM processor. Most changes in the language might easily be called features of a dialect. However, there are a few that merit a stronger distinction, because they should be considered as permanent, and as corrections of unsatisfactory properties of the original Oberon. These are the elimination of the loop statement, function result specification, array assignments, constant parameters, and read- only import of variables. All changes were made in the interest of regularity, simplicity, completeness, and well-structuredness.

See also [3] for confirmation that Oberon-7 is the language of Project Oberon.

I'd recommend reading the papers on Wirth's personal site [2].

[0] https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf (pdf) (15Jul2011 update)

[1] https://people.inf.ethz.ch/wirth/Oberon/OberonAtAGlance.pdf (pdf) (20Nov2013)

[2] https://people.inf.ethz.ch/wirth/Oberon/index.html

[3] https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf (pdf) (2013)

⬐ pjmlp

Project Oberon cannot be his final word, given that it is only the first version, later upgraded up to System 3 version.

It is hard to consider them forks, when they originated on the same department and he also collaborated in some form.

Component Pascal and Zonnon, those are proper forks.

While I admire Wirth's work, his goal to pursue a minimalist Oberon with Oberon-07 is not so interesting to me.

My pocket phone is more powerful than any Xerox workstation, why should we keep searching for such minimalist endeavours, instead of the rich development experience provided by them.

⬐ badsectoracula

> While I admire Wirth's work, his goal to pursue a minimalist Oberon with Oberon-07 is not so interesting to me.

While it may not be interesting to you, it is what the linked project is all about.

⬐ kragen

Your pocket phone is more powerful than any Xerox workstation, but you and I are less powerful than Wirth, so if we want systems we can understand and restructure at will, they probably need to be simpler than what Wirth could handle, not more complex.

⬐ kragen

To be entirely meticulous about the genealogy, I think Wirth was at PARC in 01976, and what inspired him most there was Mesa; Lampson first described (Mesa's successor) Cedar in PARC TR CSL-83-15, Xerox Palo Alto Research Center, December 01983, and without rereading the report, I think Cedar's development began about 01981. So Cedar is Oberon's sibling, not its parent.

The connecting link at ETH between Mesa and Oberon was the Lilith workstation with its system software written in Wirth's Modula-2 (01977–01984).

As for Golang, the relationship is much more direct! The first public version of Golang is mostly a slightly modified version of Pike's Newsqueak, but at the point Golang became Golang, Pike was working with Griesemer and Thompson. IIRC Griesemer did his dissertation under Wirth at ETH on extending Oberon to parallel computers.

⬐ _fz_

Here's a Project Oberon emulator in Go: https://github.com/fzipp/oberon

And a Go port of the RISC compiler: https://github.com/fzipp/oberon-compiler

⬐ elcapitan

Totally OT, but I was wondering why you are writing years in 5 digits? :D

⬐ kinjba11

Perhaps OP should be writing 11976 not 01976

https://en.wikipedia.org/wiki/Holocene_calendar

⬐ renewedrebecca

Planning ahead.

⬐ iso8859-1

https://longnow.org/

⬐ LargoLasskhyfv

There was another sibling of the Lilith:

https://en.wikipedia.org/wiki/Kronos_(computer)

⬐ pjmlp

Yes, mostly correct.

⬐ kragen

I'd be delighted if you'd correct whatever isn't!

⬐ pjmlp

Go is mix of Limbo and Oberon-2.

I also remember reading somewhere that Wirth found Cedar too powerful, or complex, so Oberon was designed with the goal to be as capable as Cedar environment, while using a simpler language.

So not sure which kind of relation I would put them, besides being an inspiration.

⬐ kragen

Thank you!

What are the Oberon-2 features in Golang that aren't in Limbo?

I should have clarified the Squeak → Newsqueak → Alef → Limbo → Golang lineage, but from my point of view Newsqueak is already recognizably a version of Golang (and Squeak isn't.)

⬐ pjmlp

The way methods are declared (Oberon-2 syntax), the unsafe package (SYSTEM in Oberon) and package initialisation blocks.

⬐ kragen

Thank you!

⬐ Rochus

> was at PARC in 01976, and what inspired him most there was Mesa

Wirth was twice at PARC. In his HOPL3 paper he writes in section 4 "From Modula to Oberon":

"As my sabbatical year at Xerox in 1976/77 had inspired me to design the personal workstation Lilith in conjunction with Modula-2, my second stay in 1984/85 provided the necessary inspiration and motivation for the language and operating system Oberon [29, 30]. Xerox PARC ’s Cedar system for its extremely powerful Dorado computer was based on the windows concept developed also at PARC for Smalltalk. [...] Thus the idea was born of gaining first-hand experience by designing such a modern operating system on my own, with Cedar as the primary source of ideas."

> IIRC Griesemer did his dissertation under Wirth at ETH

His supervisor was actually Prof. Mössenböck, the author of Oberon-2 (from which Go inherited its type-bound procedure syntax), see https://www.research-collection.ethz.ch/bitstream/handle/20....

⬐ kragen

Thank you very much for the corrections! I haven't read HOPL3 yet, but he probably said similar things in the Oberon book and I just misremembered it.

Apologies for misleading readers!

⬐ Rochus

In fact, I'd be very interested to know what Wirth thinks about Smalltalk; I haven't read a statement from him about it anywhere, or heard anything from him about it in the many interviews; interestingly, Kay asked him a question at the Turing Price lecture and even introduced himself by name, and you didn't get the impression that Wirth knew him.

I also find it remarkable that while Wirth refers to the windows concept and Smalltalk in the HOPL paper, which was written as recently as 2005, Cedar does not use overlapping windows at all, but rather - like the Oberon system - a tiling window manager; the Oberon user interface looks very similar to Cedar and has little resemblance to the Smalltalk-80 user interface.

⬐ scroot

> In fact, I'd be very interested to know what Wirth thinks about Smalltalk; I haven't read a statement from him about it anywhere, or heard anything from him about it in the many interviews

I'd be interested to know as well. It might be worth writing him a physical letter asking about it. There is a mailing address for his department at ETH here (https://people.inf.ethz.ch/wirth/index.html) and I'm willing to bet they know how to forward him correspondence.

⬐ Rochus

His home address and phone number are even in the phonebook, but I don't consider myself or the subject important enough to bother him with it. But maybe someone else here has insider information. That said, there's plenty of circumstantial evidence that he either didn't know Smalltalk in the nineties or didn't think it was worth mentioning. After all, Xerox themselves did not use Smalltalk in their products either, and even at PARC the other teams tended to work with BCPL or Mesa rather than Smalltalk. I read an interview with Larry Tesler where he describes that for a demonstration of a Smalltalk application they had to fast forward the movie so that the menus would pop up fast enough. Not surprisingly, Tesler then brought Object Pascal to life at Apple in collaboration with Wirth, instead of using Smalltalk as he had in his previous job (even though Apple had a license - that was used nota bene later for Squeak).

⬐ i_don_t_know

There's a hint of what he thinks about Smalltalk in his book "Programming with Oberon" (co-authored with Martin Reiser). See sections 12.6.1 and, in particular, 12.6.2 (pages 236-239): https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf

⬐ kragen

§§12.6.1–2 are on pp. 253/338 to 256/338. Initially I went to the wrong pages. Definitely worth a read.

Interestingly his point (3) on p.219 (236/338) ("Within the text of a specific action procedure, a regional type guard is required to allow access to the state variables defined in the extension of the base type") was precisely Abadí and Cardelli's motivation for defining the ς-calculus. This limitation means that Oberon's type system is insufficient to statically guarantee the safety of object methods ("action procedures") and this is an obviously desirable thing. He mentions another similar limitation on the Oberon type system on p. 237 (254/338): "The fact that the compiler cannot check whether a message is ‘understood by the object’ may be an advantage or a disadvantage, depending on the type of the application."

⬐ Rochus

Thanks for the reference; unfortunately we don't know who of the two authors has written the paragraph, and it is also not very specific. Meanwhile I found the following paragraph in Wirth's tutorial titled "Programming in Oberon" (of which a version can be downloaded from https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf, and the first version of which apparently is from 2004); on page 57 we can read:

"The designers of Smalltalk clearly wished to present not only a new language, but also a new paradigm, a new approach to programming. To be effective and convincing in this endeavor, they provided also a new terminology to underscore a different quality of programming. In this effort, record-structured variables became objects, their associated procedures became methods, a data type became a class, and calling a procedure is now termed sending a message to an object. This is denoted as object.method(message)"

It is interesting to note that "object.method(message)" has nothing to do with Smalltalk syntax at all (which supports my assumption that he had little to no personal contact with it). In his 1988 papers Smalltalk is just referenced as one of many OO languages, next to Simula 67, ObjectPascal and C++.

Stuck in the past indeed, using IDEs was already a thing in Windows 3.x and Mac OS classic, exercise for the reader when they came to be.

Or better yet, the development experience of using Toga in Mesa/Cedar (1987).

http://toastytech.com/guis/cedar.html

https://www.youtube.com/watch?v=z_dt7NG38V4

Or Smalltalk, Interlisp-D or Lisp Machines for that matter.

The time a language must be usable with Notepad alone is long past due.

⬐ nyanpasu64

The problem with non-greppable code isn't that "you should use an IDE". I use rust-analyzer and I dislike non-greppable code.

One concrete issue I ran into is that when cleaning up a list of imports, I can't use Ctrl+F to find out which ones are unused, since I can accidentally remove a trait which is never used by name but only imported for its methods. And I can't count on rust-analyzer's unused import detection working 100% of the time. And it's bad that some methods (for example the infamous `Read` or two `Write` traits) are inaccessible unless you add a trait import (which rust-analyzer sometimes knows how to add when I press Ctrl+.).

To me, the overarching value of Rust is locality of reasoning, and clearly indicating nonlocal reasoning in explicitly-readable and machine-checkable ways (eg. the `Cell` family of types). Trait methods are nonlocal reasoning, and they aren't clearly demarcated (a trait import behaves as`use module::Trait::*` but isn't written that way in the source code). If you're opposed to wildcard module name imports, you should be opposed to wildcard trait method imports.

⬐ pjmlp

That only shows how much it is lacking versus proper IDE experiences.

IDEs for other languages provide plenty of capabilities to code navigation, no need to go Ctrl+F.

I recently posted some info and links about Mark Weiser to the HN discussion of "Calm Technology":

Calm Technology (calmtech.com)

https://news.ycombinator.com/item?id=29115653

https://calmtech.com/

https://news.ycombinator.com/item?id=29117340

>Mark Weiser was my friend and mentor at the University of Maryland, so I've posted some stuff about his work and life here in the past.

>As usual, I've checked and updated the broken links to archive.org. (One of my favorites is the 1995 Computer Chronicals video at the end with a profile of Mark's band, Severe Tire Damage, the first band to ever perform live over the internet, who upstaged the Rolling Stones over MBone, using up half the bandwidth of the internet on Friday, November 18, 1994!)

[...much more at the article I linked to, and in the HN discussion of Calm Technology...]

Also some recent comments I wrote about the term "Pervasive Technology":

https://news.ycombinator.com/item?id=29931283

I've also mentioned his work with Chris Torek on the Maryland Window System, which was based on Gosling's Emacs display driver:

https://news.ycombinator.com/item?id=22457846

And only yesterday there was an HN discussion about the Mesa Programming Language:

Xerox PARC Mesa Programming Language 5.0 (1979) [pdf] (bitsavers.org)

https://news.ycombinator.com/item?id=29976630

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3...

I posted to that about his work on PCR (Portable Common Runtime, for porting Cedar apps to Unix) and conservative garbage collection, and linked to an HN discussion of a video demo of Cedar and Tioga running on Unix with PCR:

https://news.ycombinator.com/item?id=30003729

Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)

https://news.ycombinator.com/item?id=22375449

https://www.youtube.com/watch?v=z_dt7NG38V4

Mesa was later replaced by the more modern Cedar programming language integrated with Tioga programming and desktop environment by Xerox, after they've evaluated few languages for potential replacement including Lisp for the later part of the 80s and 90s [1],[2],[3].

Apple and Microsoft copied their modern GUI desktop idea from Xerox in the 70s but interestingly nobody has copied the excellent Cedar/Tioga programming environment until today.

[1] A Description of the Cedar Language:

https://www.microsoft.com/en-us/research/publication/descrip...

[2] Eric Bier Demonstrates Cedar:

https://youtu.be/z_dt7NG38V4

[3] The Tioga Editor:

http://www.bitsavers.org/pdf/xerox/parc/cedar/Cedar_7.0/07_T...

⬐ pjmlp

I like to think that Java and .NET is the closest we got that far, but so much is still missing from that whole experience.

⬐ DonHopkins

Previous HN discussion about that video:

https://news.ycombinator.com/item?id=22375449

https://www.youtube.com/watch?v=z_dt7NG38V4

I posted about PCR:

https://news.ycombinator.com/item?id=22378457

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):

https://github.com/duncanmak/noticias/blob/6f0a78186ee074828...

    % 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]

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8...

>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.

https://en.wikipedia.org/wiki/Boehm_garbage_collector

This is the 1988 "Garbage Collection in an Uncooperative Environment" paper by Hans-Juergen Boehm and Mark Weiser:

https://hboehm.info/spe_gc_paper/preprint.pdf

>Similarly, we treat any data inside the objects as potential pointers, to be followed if they, in turn, point to valid data objects. A similar approach, but restricted to procedure frames, was used in the Xerox Cedar programming environment [19].

[19] Rovner, Paul, ‘‘On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent Language’’, Report CSL-84-7, Xerox Palo Alto Research Center.

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7...

My guess is that the BDW garbage collector had its roots in PCR (pun intended, in fact this entire message was just an elaborate setup ;), but I don't know for sure the exact relationship between Cedar's garbage collector, PCR's garbage collector (which is specifically for Cedar code), and the Boehm–Demers–Weiser garbage collector (which is for general C code). Does anybody know how they influenced each other, shared code, or are otherwise related? Maybe there's a circular dependency!

⬐ AlbertCory

Great summary.

I know you meant a different PCR, but the late Kary Mullis, inventor of Polymerase Chain Reaction, which we've all unfortunately gotten to know about, spoke at Google and I got to hear him.

He said he had taken a programming class and the idea of "looping" had really caught his imagination, and that was part of what inspired PCR.

Of course we wouldn't have had a genetic revolution without PCR.

There's a quite nifty and recent demonstration of Cedar on YouTube.

https://www.youtube.com/watch?v=z_dt7NG38V4

I guess NeWS [0] is a likely candidate, as Mesa/Cedar[1] as well.

Many of these ideas also kind of exist in Windows, with COM/OLE/.NET/Powershell, or GNOME/KDE, although not in consistent way.

I always felt SOM was much better than COM, it even had metaclasses as concept.

[0] - https://en.wikipedia.org/wiki/NeWS [1] - https://www.youtube.com/watch?v=z_dt7NG38V4

⬐ criddell

Oh wow - I've never heard of NeWS before. That sounds like it was 20 years ahead of it's time and all the ideas had to be reinvented in Javascript to succeed. Thanks for the links.

Well, have a look at

http://www.softwarepreservation.org/projects/LISP/interlisp_...

Then follow up with "The Interlisp Programming Environment"

https://www.computer.org/csdl/magazine/co/1981/04/01667317/1...

"Graphical Programming in Interlisp-D"

https://www.youtube.com/watch?v=wlN0hHLZL8c

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

Cedar was the very first graphical workstation for something like .NET and Java would later kind of try to become.

⬐ travisjungroth

Thanks!

⬐ LargoLasskhyfv

While that seems to be like almost lost history, and a forgotten art, it is not!

Because

[1] https://interlisp.org/

&

[2] https://github.com/interlisp

Have a look at Mesa/Cedar as well. Those OSes have explored only a subset of its ideas.

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

Well ideas there are plenty to steal from, that is true.

But maybe we could start by actually catching up with having full stack OSes written in safe systems programming languages.

https://youtu.be/z_dt7NG38V4

https://youtu.be/NqKyHEJe9_w

This is a very exciting development, similar in spirit to the proposal by Bret Victor for Learnable Programming [1].

I'm also excited by the fact that from their website the CRDT for local-first collaborative editing and Jupyter like alternative are also in the pipeline [2].

For those who are interested in the history of structure editor you can check the venerable Tioga editor in Xerox's Cedar programming environment [3],[4].

[1]http://worrydream.com/LearnableProgramming/

[2]https://hazel.org/

[3]http://www.bitsavers.org/pdf/xerox/parc/cedar/Cedar_7.0/07_T...

[4]https://www.youtube.com/watch?v=z_dt7NG38V4

Nope, just like the Xerox PARC environments, for Niklaus Wirth the programming language and OS overlap, hence why it is kind of tricky to disassociate them.

By the way, Cedar was the inspiration for Oberon.

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

⬐ jhbadger

Although it is certainly possible to separate the two. For example, the Oxford Oberon Compiler for UNIX and Windows, which is just a compiler for the Oberon language (basically an object-oriented Pascal) rather than the OS/environment

http://spivey.oriel.ox.ac.uk/corner/Oxford_Oberon-2_compiler

⬐ pjmlp

Sure, that is why "Oakwood Guidelines for Oberon-2 Compiler Developers" eventually came to be,

http://www.edm2.com/index.php/The_Oakwood_Guidelines_for_Obe...

My remark was more about how Niklaus Wirth saw the system he designed and his goals behind it.

> 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"

https://www.youtube.com/watch?v=AnrlSqtpOkw

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo"

https://www.youtube.com/watch?v=NqKyHEJe9_w

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.

⬐ Qem

Nice links. For a taste of what to program in Pharo is like, see https://avdi.codes/in-which-i-make-you-hate-ruby-in-7-minute...

We also lost this, https://www.youtube.com/watch?v=z_dt7NG38V4

Depends, the future could already have been here, instead of playing catchup with the past.

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

The only tension is for people that don't get how both are possible.

- https://en.wikipedia.org/wiki/Modula-3

- http://joeduffyblog.com/2015/11/03/blogging-about-midori/

- http://www.projectoberon.com/ (see https://www.astrobe.com)

- Eric Bier Demonstrates Cedar (https://www.youtube.com/watch?v=z_dt7NG38V4)

⬐ LAC-Tech

I'm somewhat in agreement.

There are a lot of people in 2021 who - for whatever reason - feel like they need to program personal computers without using GC. As you point history shows that's a lot less true than people think, but nevertheless - that is the sentiment.

Dlang tries spends a lot of effort trying to attract these people, by making more and more of the stdlib nogc, having @nogc annotations, experimenting with deterministic manual memory management etc etc. But I feel like they'll never convert most of them.

⬐ pjmlp

Meanwhile C# and Go keep being improved to play on the same place that D wants to be.

I also agree with the sentiment, the language issues with some not so well worked out features should be fixed, instead of trying to please everyone.

⬐ ku-man

"... the language issues with some not so well worked out features should be fixed, instead of trying to please everyone."

This. For average programmers like myself, latest and fanciest language features are of little value. C++ and (unfortunately) D are in the same quest: to incorporate every programing language paradigm available, the extra complexity be damned. In the specific case of D, I'd rather have a good assortment of native D libraries than more bells and whistles added to the language.

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"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"

https://www.youtube.com/watch?v=HP4hRUEIuxo

"SymbolicsTalk28June2012"

"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"

https://www.youtube.com/watch?v=gV5obrYaogU

"Symbolics Lisp Machine demo Jan 2013"

https://www.youtube.com/watch?v=o4-YnLpLgtk

The Native Oberon demos available at

https://www.youtube.com/channel/UCw6NbzmjW-wLvqVbxOXj7Ug/vid...

No, because Oberon wasn't only programming language, rather a full workstation OS, with a developer experience inspired on Mesa/Cedar.

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Oberon (Native Oberon 2.3.7)"

https://www.youtube.com/watch?v=OJGnpmnXR5w

It is inspired by it as the wikipedia[0] article notes. Both are inspired by Cedar/Mesa[1] from PARC. There is a great video of Eric Bier showing some of cedars capabilities on youtube[2].

[0] https://en.wikipedia.org/wiki/Acme_(text_editor) [1] https://en.wikipedia.org/wiki/Mesa_(programming_language) [2] https://www.youtube.com/watch?v=z_dt7NG38V4

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"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"

https://www.youtube.com/watch?v=HP4hRUEIuxo

"Documents as User Interfaces Video Demo"

https://www.youtube.com/watch?v=0-_zVkrWCOk

"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"

https://www.youtube.com/watch?v=gV5obrYaogU

"Alto System Project: Dan Ingalls demonstrates Smalltalk"

https://www.youtube.com/watch?v=uknEhXyZgsg

"Action!, the worlds first dynamic interface builder - 1988" (Interface Builder percursor, written in Lisp)

https://vimeo.com/62618532

"The Interlisp programming environment"

http://larry.masinter.net/interlisp-ieee.pdf

And the cherry, how Lucid used Lisp ideas for their Energize C++ IDE, including an image based format for AST storage

https://www.youtube.com/watch?v=pQQTScuApWk

https://www.dreamsongs.com/Cadillac.html

⬐ hcarvalhoalves

Watching the Symbolics demo nowadays, it's amazing what they had back then.

⬐ vblxt

These lock-in IDE environments, while impressive, thankfully never got really popular.

I find superior languages like Lisp or Standard ML most enjoyable in text files.

⬐ pjmlp

Look better around you.

- macOS, Windows, Android, ChromeOS

- InteliJ, Visual Studio, XCode/Playgrounds

⬐ nsm

I'd also add this talk "Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram " https://www.youtube.com/watch?v=baxtyeFVn3w

as well as the whole series of things that Tudor Girba & co. are doing with Glamorous Toolkit https://www.youtube.com/channel/UClLZHVq_-2D2-iI4rA2O8Ug

I'd still recommend folks use Pharo over GToolkit for most things, as GToolkit lacks a bunch of polish and documentation (not to say that even Pharo documentation approaches anything of the quality of the Rust and Python ecosystems).

Besides what others have written.

It is a complete single user graphical workstation OS, written in a GC enabled systems programming language.

Niklaus Wirth got his inspiration out of Mesa/Cedar during his second sabbatical at Xerox PARC (during his first one he ended up creating Modula-2 inspired by Mesa).

You can see what Mesa/Cedar was capable of by checking this videos,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

The original Oberon system was a simplified version of it in more affordable hardware, then from its roots, a series of other variants were born, Oberon-2, Active Oberon, V4, System 3, Component Pascal, Zonnon, are the most well known. Eventually Niklaus Wirth decided to go back and see how much he could remove from original Oberon and still have it be a systems programming language with GC, thus Oberon-07 was born, with a couple of revisions, the latest one from 2016.

Going back to the original one, this is what you got in the package:

- A full stack single user graphical workstation, in a GC enabled systems programming language

- The only kind of application are modules, loaded dynamically

- Applications are just modules that register themselves into the system to be available on the REPL or in menus when loaded, e.g. Module.Command will load Module and call the procedure named Command, which can then be fed data from the REPL, mouse selection or selected application window

- This brings dynamism similar to Smalltalk and Lisp machines where you get access to whole OS and each application is extensible

At a given point during the 90's the ETHZ IT department had plenty of people using Oberon based workstations.

For a couple of screenshots about Oberon System 3 and Active Oberon, with links about Xerox PARC related stuff have a look at https://www.progtools.org/article.php?name=oberon&section=co...

⬐ a9h74j

With a view to a portable environment, I was thinking earlier today that it would be nice to have a second, all-in-one application to use over different OS environments, to complement a modern browser. Something with a file explorer, editor, support for scripts -- and possibly extensions. It appears non-native Oberon could be a fit to that; the lack of an up-to-date browser would not be a weakness.

⬐ pjmlp

For that I would actually advise something like Smalltalk.

https://pharo.org/

Shells inside IDEs are an idea that goes back to Xerox PARC workstations, the UNIX folks just have an hard time grasping that in spite of urban myths, there aren't other ways to achieve the same.

Even better, because IDE integrated shells are many cases graphical REPLs with additional interaction capabilities and graphical abilities.

As for the travel into memory lane, here out of 1977,

https://en.wikipedia.org/wiki/Xerox_Development_Environment

You can have a nice view how it worked, by following the Wikipedia links, or checking the presentation on Mesa/Cedar, which was the evolution of XDE as Mesa evolved into Cedar, and one of the latest version of XDE as well.

"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"

https://www.youtube.com/watch?v=HP4hRUEIuxo

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

And naturally Smalltalk-80 and Interlisp-D enviroments that precedded it,

"Emulating Smalltalk-80 DV6 on a Xerox 1186 (6085 Daybreak Development Kit)"

https://www.youtube.com/watch?v=dpjRZnUw8MU

"The Interlisp Programming Environment", 1981

http://larry.masinter.net/interlisp-ieee.pdf

The lack of teaching of the computing world outside Bell Labs leads to a UNIX cult, unaware of the progress that was actually already available in the 70 and 80's, but unfortunely failed to pick up due to several reasons, so in the end there is this idolatration of the UNIX shell.

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"

https://www.youtube.com/watch?v=z_dt7NG38V4

Including the part of being written on a memory safe systems programming language.

⬐ Koshkin

> what a modern desktop OS should look like

I take this as a joke. There is nothing modern-looking about it. Geeky, yes. Not designed for touch interface. Resembles Oberon, which I would not call modern, either. Maybe, we are not ready for it yet. Belongs in the future, then. (Or, more likely, in the past.)

⬐ pjmlp

Then the joke is on you by failing to understand the OS concepts that are exposed there.

To proper understand a book one has to read more than just the back cover overview.

⬐ zepto

Can you say more about why Windows is closest?

I’m not looking to debate - just that it’s not obvious and I suspect the specific reasons why would be interesting to know about.

Thanks!

⬐ pjmlp

Sure, first a short overview of how those OSes used to work and how one can map those ideas into Windows.

Mesa/Cedar also shares some ideas with the other workstation variants from Xerox PARC, namely Interlisp-D and Smalltalk, just based on a strong typed language for systems programming, with reference counting and a cycle collector.

The language itself compiles to bytecode, because Xerox PARC machines used bytecode with microcoded CPUs, whose interpreter was loaded on boot. So in a sense it was still native somehow.

The full OS was written in Mesa/Cedar, and everything was kind of exposed to the developers.

The shell is more like a REPL, where you can access all that functionality, meaning the public functions/procedures from dynamically loaded modules, interact with text selection from any application window, or execute actions on a selected window. And as REPL, it worked on structured data.

Basically similar to what Powershell offers, with its structured data, and ability to call any COM/UWP, .NE or plain DLLs libraries.

Then you could embedded objects into other objects and this the basis of the compound document architecture, basically the genesis for OLE in Windows and COM (COM is just the basic features which OLE is built upon, although more the OLE 2.0, the 1.0 was more complicated still).

The way Office works between applications and its inline editing of OLE documents can be found in Xerox PARC workstations, as Charles Simonyi brought Bravo ideas into Word, as one of Bravo creators.

Since Windows Vista, most new APIs are actually a mix of .NET and COM (now UWP), which expose a similar high level set of OS API (bare bones Win32 has hardly changed since XP days).

Now, many of these concepts can also be found in GNOME and KDE, however due to the way distributions get put together, it is hard to really provide such integrated developer experience across the whole stack.

And while REPL like shells do exist for UNIX clones, their adoption is a tiny blip when compared against traditional UNIX shells.

It is a bit hard to explain in an HN comment something that requires live experience,

You can start by having a look at,

http://toastytech.com/guis/cedar.html

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Alto System Project: Dan Ingalls demonstrates Smalltalk"

https://www.youtube.com/watch?v=uknEhXyZgsg

"SYMBOLICS CONCORDIA ONLINE DOCUMENTATION HYPER TEXT MARKUP 1985"

https://www.youtube.com/watch?v=ud0HhzAK30w

You can see how NeXT builds on many of these concepts on the famous "NeXT vs Sun" marketing piece,

https://www.youtube.com/watch?v=UGhfB-NICzg

Sun also had some ideas along these lines with NeWS,

"NeWS: A Networked and Extensible Window System,"

https://www.youtube.com/watch?v=4zG0uecYSMA

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.

⬐ EricE

> 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.

A perfect summation!

Basically the same as Mesa/Cedar, but in more affordable form than Xerox PARC hardware would require.

http://toastytech.com/guis/cedar.html

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

About 1h video with some developers from Mesa/Cedar done by Computer History Museum.

As for what breakthrough, this are full stack graphical workstations written in GC enabled systems programming language.

To bring it to modern context, imagine something like Windows being fully written in .NET Native, but in the 80's.

⬐ 082349872349872

... in the 80's, with a headcount of 2 (who had other academic duties).

> "The primary goal, to personally obtain first-hand experience, and to reach full understanding of every detail, inherently determined our manpower: two part-time programmers. We tentatively set our time-limit for completion to three years. As it later turned out, this had been a good estimate; programming was begun in early 1986, and a first version of the system was released in the fall of 1988."

I think of Wirth and Gutknecht as demonstrating that one need not be as far out as Terry A. Davis to do small-team end-to-end work. (compare Carver Mead's tall thin person)

The Computer History Museum organized a session with Eric Bier, and several other folks demoing the Mesa/Cedar environment.

https://youtu.be/z_dt7NG38V4

The only modern environments that seem to have kept alive several of these ideas are Windows/.NET/COM, the ones designed by Apple/NeXT and to certain extent Android (although with a messed up execution).

Even Linux could grasp many of these ideas, if D-BUS would be properly taken advantage of and settled on a specific development experience.

Somehow it looks like we are still missing so much from Xerox PARC ideas.

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) - https://www.cs.princeton.edu/~bwk/memoir.html

The Development of the C Language (Dennis Ritchie) - https://www.bell-labs.com/usr/dmr/www/chist.html

JavaScript: The First 20 Years (Brendan Eich) - https://zenodo.org/record/3710954/files/jshopl-preprint-2020... (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 - https://www.youtube.com/watch?v=z_dt7NG38V4 (video)

Active Tioga documents: an exploration of two paradigms - http://cajun.cs.nott.ac.uk/wiley/journals/epobetan/pdf/volum... (PDF)

The Mesa Programming Environment - http://www.digibarn.com/collections/papers/dick-sweet/xdepap... (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.

Anything based on the workstation concepts explored at Xerox PARC, and further pursued at ETHZ, TI and Genera.

Bitsavers has all the necessary papers and manuals, and computer museum as well.

Here are some video sessions.

"Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo"

https://www.youtube.com/watch?v=NqKyHEJe9_w

"Alto System Project: Dan Ingalls demonstrates Smalltalk"

https://www.youtube.com/watch?v=uknEhXyZgsg

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"The Final Demonstration of the Xerox 'Star' computer"

https://www.youtube.com/watch?v=_OwG_rQ_Hqw

The end of the road from Plan 9, Inferno.

http://www.vitanuova.com/inferno/index.html

http://doc.cat-v.org/inferno/4th_edition/

⬐ krebs_liebhaber

Small tangent: It's sad that the Mother of All Demos still looks like the future of computing. Google Docs and its siblings come close, but they still don't match it in scope.

I'm surprised nobody mentioning the similarity of TeXmacs to Tioga editor within the legendary CEDAR desktop environment from Xerox [1]:

I've read somewhere some years ago that if you can create a usable hybrid combination of MS Office Word document (WYSIWYG) and TeX then you have a killer application for document editor. Additionally, similar to Tioga with the fact that you can also use other programs inside TeXmacs (e.g. spreadsheet, Octave, etc) is a huge boon for productivity [2].

I think the naming of the TeXmacs does create confusion though since it creates the impression that this is combination of TeX and Emacs but it's neither of them. Just like the Holy Roman Empire after the collapsed of Roman Empire, it's neither Holy nor Roman nor an Empire.

Now hoping for the modern incarnation version of CEDAR desktop environment.

[1] https://www.youtube.com/watch?v=z_dt7NG38V4

[2] http://cajun.cs.nott.ac.uk/wiley/journals/epobetan/pdf/volum...

⬐ mgubi

Interesting! I didn't knew the Tioga editor. All these pioneering work is really inspiring! Our goals fits very well into the paradigm of active documents and we have already many features implemented and beautifully typesetted : https://www.texmacs.org/joris/icms14/icms14.pdf

If you want to see your life ruined, watch this deep dive into Mesa/Cedar environment. :)

https://www.youtube.com/watch?v=z_dt7NG38V4

One of the first workstation OSes written in a memory safe systems programming languages, early 80's at Xerox PARC.

⬐ BaronSamedi

This was so interesting. The way it handles copy & paste seems better than our current convention. Its use of typography was elegant. I suppose that is a benefit of using a text editor that can also format documents for publication. I don't understand why open source projects don't build on original great ideas like these and those found in Symbolics' Genera.

⬐ TurboHaskal

Can we go back in time and kill UNIX?

⬐ pjmlp

No need to kill it per se, it would have been enough to allow Bell Labs to sell it at the same price as VMS, OS/360 and other competing mainframe OSes, instead of distributing its source code for symbolic price.

⬐ maire

The most that would have happened is Bell Labs would have shut down the clones. There were already Unix clones in 1979. I worked on Cromix at Cromemco before I worked on Mesa/XDE at Xerox.

If I remember correctly nobody outside Xerox used Mesa or Cedar or any of the other amazing things at Xerox because Xerox never sold them. You must have worked at Xerox.

I went to Apple after Xerox and programmed in C++ using a pretty bad development environment. I certainly missed Mesa's exception handling and development environment. Mesa was missing garbage collection as did C++ at the time.

⬐ pjmlp

Yeah, garbage collection came into Mesa via Cedar, with reference counting alongside a cycle collector, hence Mesa/Cedar, the replacement for XDE.

Had UNIX been a commercial product from day one, there wouldn't be any clones to start with, as they were mostly bootstrapped by the free beer source code that was taken via backup tapes from Bell Labs into a couple of collaborating universities.

⬐ AnimalMuppet

I'm not sure about that. What you describe was enough to bootstrap university interest. That didn't lead Sun, Apollo, SGI, et al to decide that Unix was the right OS for making workstations, though. It didn't lead Sperry to decide that they needed to have a UNIX available on their mainframes (!) back in the mid-80s. And those were commercial licenses, not university bootlegs.

⬐ pjmlp

For a symbolic price, nowhere the same as something like VMS or OS/360 would cost.

Hence why AT&T went after BSD afterwards, when the the context changed and they were allowed to sell UNIX at market prices.

⬐ AnimalMuppet

What are you trying to say? Are you saying that the commercial Unix licenses (to Sun et al) were only for a nominal price? Or are you saying that they were not for a nominal price, hence the BSD suit?

I agree that "the context changed" - IIRC, when the AT&T consent decree expired. That was 1982. Sun Microsystems was also founded in 1982. It was based on BSD, which had to go through the lawsuit to be proclaimed, essentially, a cleanroom Unix.

When Sun licensed from AT&T, (early 90s?) it was (I presume) at market price.

All that detail doesn't change my point: People cloned Unix because they wanted Unix. There wasn't a Berkeley VMS, not just because VMS was expensive, but because nobody wanted VMS that badly. (Why clone the thing you're getting for close to free, anyway? Doesn't it make more economic sense to clone the thing that you can't afford (VMS or OS/360), and pay the nominal price for the almost-free thing?)

People cared about Unix in a way that nobody cared about VMS or OS/360. Perhaps the ability to see the source code was part of that. But the story you're telling seems far too simplistic.

⬐ pjmlp

To clone UNIX, in whatever form they had to have had access to it in first place.

Which was with the tapes that flown out of Bell Labs into several universities and the commercial licenses that were almost gratis, given the price difference to other OSes.

https://www.bell-labs.com/usr/dmr/www/licenses.html

People keep reinventing history as if UNIX won based on merit, when it was licensing that made all the difference.

Like the fairy tale that before C no one ever did a high level systems programming language.

⬐ AnimalMuppet

> People keep reinventing history as if UNIX won based on merit, when it was licensing that made all the difference.

I think you keep reinventing history as if licensing was the only thing that made the difference. I think you are badly mistaken. The licensing may have made it popular with the university crowd, but it didn't do much to move the workstation customers.

⬐ flavio81

This. Well said.

⬐ maire

From personal experience Cromix was written in 6502 assembly language. The comments were all in C but personal computers were not fast enough to run a C OS in 1979. I doubt it was licensed since they reverse engineered the API (which is legal). I actually learned C by reading the comments.

Small piece of history - Cromix was written single handedly by Roy Harrington who left Cromemco to found Informix.

Having said that - Mesa/XDE was awesome. I am sure Mesa/Cedar was even better.

⬐ hhas01

I think Xerox was pretty renowned for their “we’re a photocopier company; we make and sell photocopiers” attitude, or they’d never have given such golden opportunities away. Much as Kodak is a photographic film company that makes and sells photographic film… oh, wait.

https://www.businessinsider.com/this-man-invented-the-digita...

But I’m sure senior management collected their fat salaries and performance bonuses as-per always, so that’s alright then.

There are definitely a lot of difficult issues and trade-offs about implementing true "WYSIWYG" editors that let you layout text and graphics that looks exactly the same on the screen and when printed.

This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get.

https://www.youtube.com/watch?v=z_dt7NG38V4

Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical.

And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different.

NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that.

NeWS 1.1 manual, page 146:

http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801...

>setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch

Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful.

Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously.

Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time.

It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements.

And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode).

Now printing text on paper is only an afterthought, something wasteful to be avoided. So fewer people actually need to edit two-column paginated text just like it will appear printed on paper in a journal, or fuss about exact text layout and worry about terrible "rivers" ruining their otherwise perfectly justified paragraphs.

https://en.wikipedia.org/wiki/River_(typography)

https://en.wikipedia.org/wiki/WYSIWYG

WYSIAWYG; what you see is almost what you get, similar to WYSIMOLWYG.

WYSIMOLWYG, what you see is more or less what you get, recognizing that most WYSIWYG implementations are imperfect.

http://foldoc.org/WYSIWYG

What You See Is What You Get <jargon>

(WYSIWYG) /wiz'ee-wig/ Describes a user interface for a document preparation system under which changes are represented by displaying a more-or-less accurate image of the way the document will finally appear, e.g. when printed. This is in contrast to one that uses more-or-less obscure commands that do not result in immediate visual feedback.

True WYSIWYG in environments supporting multiple fonts or graphics is rarely-attained; there are variants of this term to express real-world manifestations including WYSIAWYG (What You See Is Almost What You Get) and WYSIMOLWYG (What You See Is More or Less What You Get). All these can be mildly derogatory, as they are often used to refer to dumbed-down user-friendly interfaces targeted at non-programmers; a hacker has no fear of obscure commands (compare WYSIAYG). On the other hand, Emacs was one of the very first WYSIWYG editors, replacing (actually, at first overlaying) the extremely obscure, command-based TECO.

See also WIMP.

⬐ fanf2

The Acorn Archimedes had anti-aliased text using 8 grey levels on a 4 or 8 bit display, on computers with 0.5MB RAM in 1990... http://telcontar.net/Misc/GUI/RISCOS/#text so in theory it could have been practical for Sun ...

⬐ DonHopkins

If your display only has gray levels, then anti-aliasing is easy since you don't need to worry about rendering text over non-white backgrounds, and you don't need to worry about a colormap. But 8 bit displays with colormaps make it much harder to support anti-aliased text practically, especially over arbitrary backgrounds (because it would look terrible as well as being slow).

NeWS used a color cube with only a certain number of grays, and those were only useful for anti-aliasing black text against a white background (or the other way around), and you didn't have a lot of colors to choose from for antialiased color text or against colored backgrounds. It's much easier to render anti-aliased text in 24 bits, or with pure gray scale, since you aren't restricted to an 8 bit color palette, and you can efficiently mathematically blend colors together, instead of looking up rgb values in a colormap, blending to get the ideal desired color, and then searching for the nearest color to each pixel in the colormap (or indexing the color cube for the nearest color) (which won't be very near, and will look flat and washed out without dithering).

Better visually to render the whole image with antialiased text in full 24 bits, then use error diffusion dithering over the entire image at once (to avoid flat washed out regions, and distribute the error over space) to make an 8 bit palletized version, but that's quite slow and memory intensive.

Of course your application (like a monochrome PostScript previewer) could switch in an all-gray ramp colormap for efficiently rendering and beautifully displaying anti-aliased text, but then all the other windows on the screen would be shown in the wrong colormap, and the colormap would flash back and forth when you moved your focus between windows.

⬐ fanf2

Ah, yes, Acorn didn't try to anti-alias properly over varying backgrounds. ArtWorks did full anti-aliasing but it was quite a lot slower to render https://en.wikipedia.org/wiki/ArtWorks

In this video of Eric Bier and his colleagues from Xerox PARC demonstrating Cedar, they discuss writing resolution independent applications, and the problem and approaches to matching the text and formatting displayed on the screen, with how it looks when printed:

https://www.youtube.com/watch?v=z_dt7NG38V4

>Eric Bier Demonstrates Cedar. Computer History Museum, Recorded on January 24, 2019.

>This interpretive production was created from archival footage of Eric Bier, PARC research scientist, demonstrating the Cedar integrated environment and programming language on January 24, 2019. Cedar was an evolution of the Mesa environment/language, developed at PARC’s Computer Science Laboratory originally for the Xerox Alto. Mesa was modular and strongly-typed, and influenced the later Modula family of languages. Cedar/Mesa ran on the D-machine successors to the Alto (such as the Dorado) and added features including garbage collection, and was later ported to Sun workstations. Cedar/Mesa’s integrated environment featured a graphical window system and a text editor, Tioga, which could be used for both programming and document preparation, allowing for fonts, styles, and graphics to be embedded in code files. The editor and all its commands were also available everywhere, including on the command console and in text fields. The demo itself is running through a Mac laptop remotely logged into Bier’s Sun workstation at PARC using X Windows. Bier demonstrates the Cedar development environment, Tioga editor, editing commands using three mouse buttons, sophisticated text search features, the command line, and the Gargoyle graphics editor, which was developed as part of Bier’s UC Berkeley Ph.D. dissertation. Bier is joined by Nick Briggs, Chris Jacobi, and Paul McJones.

Here are some notes about that I took:

There were several window systems developed for Cedar: Warren Teitelman developed Docs. Lots of functionality, but slow. Scott McGregor developed Viewers. It was lean and fast, in response to Docs. Michael Plass built the Cedar imager.

The Experimental Programming Environment Research Project looked at different competing projects to decide which to standardize on. Cedar/Mesa came out of that and played a dominant role in the 80's. The Smalltalk people contributed ideas but were (not railroaded but) frustrated.

Cedar had a ubiquitous almost-wysiwyg structured text and code editor called Tioga. It was important in Cedar, because it's everywhere, even the text fields. The terminal window has a stripped down text editor with subset of commands.

Setting the so-called "clipping level" in Tioga (like a folding outliner) goes back to Englebart's NLS. Bill Paxton and Doug Wyatt were NLS people who also worked on Tioga.

Key ideas were applicable in any possible place in both systems. The Alto had small memory, and each program took over the entire system. It was not integrated. Simple little editors for code. Fancier editors for documents. Using the same component everywhere is something Smalltalk was pioneering even on the tiny Alto. When Cedar came along, running on a much bigger more powerful 1 megabyte D-Machines, it pulled together those ideas, and added so much more, including much more advanced graphics, way beyond what the Alto could do.

Tioga could display and edit formatted code with different levels of indentation and formatting. Tioga was not completely WYSIWYG. Print mode shows two columns, but you edit one column. You could get a pretty good idea of what it would look like, but in the early times it did not have smooth fonts. Bitmap fonts measure differently on the printer, so text is necessarily broken and flowed differently. The printer used Interpress, the predecessor of PostScript. You could preview Interpress files in Cedar. (The video shows a demo of both editing a document in Tioga, and previewing the Interpress file that it produced for the printer.)

Recently I wrote about the differences and similarities between Forth and PostScript, and the influences of Evans and Sutherland's "Design System" on John Warnock and Martin Newall's "Jam", then Jam's influence on John Warnock and Charles Geschke's "Interpress", then Interpress's influence on PostScript:

https://news.ycombinator.com/item?id=21968175

>Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc).

>But its most obvious similarities with Forth are based on generic Computer Science concepts like stacks, which is not something particularly unique to Forth itself, so saying PostScript was influenced by Forth ignores other much more influential languages like Interpress, JaM, and Design System, which directly influenced PostScript and were designed by the same people. Also, PostScript is not threaded like Forth. But it's homoiconic, unlike Forth and Lisp.

https://en.wikipedia.org/wiki/Threaded_code

https://en.wikipedia.org/wiki/Homoiconicity

https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient...

The heavily commented PostScript source code of PizzaTool for NeWS shows Owen's OOP PostScript system in action:

https://donhopkins.com/home/archive/NeWS/pizzatool

PostScript was a direct descendent of and heavily influenced by Xerox PARC's Interpress, by John Warnock and Charles Geschke, which itself was a direct descendent of JaM, which stands for "John and Martin", by John Warnock and Martin Newall. And JaM was a descendent of Evans and Sutherland's Design System, by John Warnock and John Gaffney.

https://en.wikipedia.org/wiki/John_Warnock

http://historyofinformation.com/detail.php?entryid=1213

https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient...

https://en.wikipedia.org/wiki/Charles_Geschke

https://en.wikipedia.org/wiki/Interpress

https://en.wikipedia.org/wiki/Evans_%26_Sutherland

Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript.

https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist...

http://glennreid.blogspot.com/

Here's a post I wrote earlier:

https://news.ycombinator.com/item?id=19874245

>DonHopkins 8 months ago [-]

>Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:

https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us...

>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.

There's more interesting discussion about the relationship between PostScript and Forth on c2:

http://wiki.c2.com/?ForthPostscriptRelationship

Here's a lot more stuff I've written about PostScript and Forth (two of my favorite topics!):

https://news.ycombinator.com/item?id=11479364

https://news.ycombinator.com/item?id=13198492

https://news.ycombinator.com/item?id=13705664

https://news.ycombinator.com/item?id=13705739

https://news.ycombinator.com/item?id=18317280

https://news.ycombinator.com/item?id=18692144

https://news.ycombinator.com/item?id=18695275

https://news.ycombinator.com/item?id=18696116

https://news.ycombinator.com/item?id=19873630

https://news.ycombinator.com/item?id=19874245

https://news.ycombinator.com/item?id=19882301

⬐ williamDafoe

Once upon a time I was wandering through PARC and I wandered into a closet where a giant Ceder machine (Dorado) was running. It has an un flipping believable 512x512 COLOR display! It was an entire eight foot tall rack and its fans for the ECL logic roared like a hurricane. This deluxe personal computer from Xerox ran as fast as a Decsystem 20 massive time sharing machine that normally hosted 20-40 users.

Unfortunately everybody at PARC believed Butler lampson when he said you could write a personal computer program and if it crashed once per day that's okay you just pressed a button and rebooted it! Everybody took that to heart and wrote buggy unstable software and all the D-machines (wildflower architecture) including Dorado Dolphin Dandelion and Dandetiger crashed once per hour! it seems Butler lampson didn't consider joint probability distributions...

Xerox made okay programming environments but Pilot and Smalltalk and Interlisp were horrible operating systems compared to UNIX v7.

⬐ Rochus

Cedar was a programming language and a development environment (not an operating system) and also run on Solaris as demonstrated in the demo, and I didn't see it crash during the two hour demo.

⬐ williamDafoe

Pilot would crash with probability 0.9^p, where p is the number of things you did at once, p=4 was a limit I never surpassed. With UNIX p=30 was commonplace.

⬐ pjmlp

It is easy not to crash, when everything that one is able to do are text based applications.

⬐ gumby

Not exactly. The three main environments (Smalltalk, Interlisp-D and Cedar) took over the machine completely. Each had its own network stack, window system, et al. Those environments didn't have memory protection so from an OS perspective they were more like classic MacOS rather than current MacOS.

They weren't general purpose OSes: there was a single "environment" running bare on the machine. That's why porting Cedar, Symbolics images etc is possible: you stick the whole thing in a single address space in user space.

⬐ gumby

I used to do a lot of development on a Dorado (usually at night -- I was low enough on the totem pole that I wouldn't grab one during the day, and used a Dolphin instead). They didn't crash all the time, at least in the InterLisp world I was using.

⬐ Rochus

I like these presentations of the CHM very much. Cedar is an impressive environment and it's very interesting to see where the Oberon System which I have recently become involved with (see https://github.com/rochus-keller/OberonSystem) got its inspirations from.

⬐ TomMasz

I joined Xerox in the mid-90s, past the era when they were creating their own processors and programming languages but they still couldn't resist building one last operating system for a new digital printer/copier. The product was late and while it was full of cool technology it was outsold by a Fuji Xerox product built on an older digital printer. Cool doesn't always translate into something customers will pay for.

⬐ Aloha

It's too bad little of this software has ever been released to the world.

⬐ DonHopkins

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):

https://github.com/duncanmak/noticias/blob/6f0a78186ee074828...

    % 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]

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8...

>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.

https://en.wikipedia.org/wiki/Boehm_garbage_collector

This is the 1988 "Garbage Collection in an Uncooperative Environment" paper by Hans-Juergen Boehm and Mark Weiser:

https://hboehm.info/spe_gc_paper/preprint.pdf

>Similarly, we treat any data inside the objects as potential pointers, to be followed if they, in turn, point to valid data objects. A similar approach, but restricted to procedure frames, was used in the Xerox Cedar programming environment [19].

[19] Rovner, Paul, ‘‘On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent Language’’, Report CSL-84-7, Xerox Palo Alto Research Center.

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7...

My guess is that the BDW garbage collector had its roots in PCR (pun intended, in fact this entire message was just an elaborate setup ;), but I don't know for sure the exact relationship between Cedar's garbage collector, PCR's garbage collector (which is specifically for Cedar code), and the Boehm–Demers–Weiser garbage collector (which is for general C code). Does anybody know how they influenced each other, shared code, or are otherwise related? Maybe there's a circular dependency!

⬐ pinewurst

Plus Mark Weiser did SDI, one of my favorite SunView games. :)

⬐ DonHopkins

Pie Menus in SDI by Mark Weiser

Demonstration of Mark Weiser's Pie Menus implementation for his classic game SDI for SunView, written while snowed in at home in 1987.

https://www.youtube.com/watch?v=WTtEPbIE10I

(You can configure which icon to use for the cities, so I used icons of linear menus, that get nuked!)

⬐ kragen

Did you save a copy of the noticias repo? It's gone now.

⬐ DonHopkins

Oops, it must be a private repo. That was a link to The NeWS Toolkit 1.0 soures, which shipped with OpenWindows 1.0, and was a lot different than TNT 2.0, which shipped with OpenWindows 2.0, and whose motto was "Twice the speed at half the size". TNT 1.0 was terribly over-engineered, which TNT 2.0 addressed.

⬐ DonHopkins

I found the SunView 1 Beginner's Guide which explains all about "secondary selections", which are a lot like moving text in Cedar, but using the dedicated function keys [Copy], [Paste], [Cut] and [Find] on the left side of the keyboard, instead of the shift key:

http://chiclassiccomp.org/docs/content/computing/Sun/softwar...

p. 104:

6.7. Secondary Selections

A secondary selection is a selection you make while holding down a function key. The action takes place when you release the function key. This feature lets you do many Copy, Paste, Cut and Find shortcuts with function keys.

The secondary selection is always underlined. It lasts only as long as you hold down the function key. During that time, you can adjust the secondary selection the same way you adjust a primary selection.

You can also scroll while making a secondary selection, as long as you continue to hold the function key down. That way, you can adjust the selection to encompass characters that aren't currently visible in the window.

With secondary selections, you can do editing operations that require both a source and a destination, such as duplicating and moving text. Secondary selections also let you perform an operation without changing the current primary selection and insertion point.

You've already learned one method for copying text from one place to another:

- Select some text and press [Copy].

- Select the destination and press [Paste].

For an easier way to duplicate text, use secondary Paste. The example changes "strawberry" to "strawberry vanilla":

- Click LEFT to set the caret where you want the text copied.

- Hold down the [Paste] key while selecting the text to be copied. The text is underlined to indicate that it's a secondary selection.

- Release the [Paste] key. The secondary selection is pasted at the caret.

NOTE: When you use secondary Paste to get text from another window, be sure the pointer is in the "to" window when you first press the [Paste] key; otherwise the keyboard focus will shift and you'll paste in the "from" window. The secondary selection is pasted into the window that has the keyboard focus at the time you press the function key.

You can use secondary selections to specify operands for [Copy], [Paste], and [Cut], as well as for [Find].

To delete text without changing the insertion point, use secondary Cut:

- Hold down the [Cut] key while selecting the text you want to delete.

- Release the [Cut] key. The text is deleted and placed on Clipboard. The caret remains in its original position.

To set the insertion point for the destination without losing the primary selection, use secondary Copy:

- Make a primary selection.

- Hold down the [Copy] key while setting the caret by clicking LEFT.

- Release the [Copy] key. The primary selection is copied to the left or right of the secondary selection, depending on which end you clicked nearest to. The caret moves to the end of the insertion.

Finding a Secondary Selection

To search for a secondary selection, hold down the [Find] key while selecting text. The secondary selection is searched for when you release the function key, and the first occurrence that's found is highlighted. The search is in a forward direction, but you can reverse it by holding down [Shift-Find] while selecting text. This is a handy way to search without changing the Clipboard or the current primary selection. Note that the search begins at the caret, not at the secondary selection.

Stopping a Secondary Selection

When you start a secondary operation -- for example, hold down [Paste] and select some text -- and then decide you don't want to complwete the operation, press the [Stop] key to reset the window.

NOTE: If a text window gets stuck so it makes only secondary selections, press the [Stop] key to reset the window.

[Also there is a comprehensive Table 6-2: Quick Editing with Secondary Selections, on page 109, that I won't transcribe, but you can look at in the pdf if you're interested. There's even a way to SWAP: Exchange locations of primary selection and secondary selection: Make primary selection: pending-delete; Make secondary selection: [Control-Copy] then regular [Paste].]

⬐ nibbula

Now 30 some years later I finally see what all that weird and broken stuff in in SunView and XView was trying to do, and what a blatant but poorly executed copy it was. But now seeing how much better than Cedar/Mesa was than C, it's a wonder they even pulled that off. Sun's textedit seems a very far cry from Tioga, but they were so into it that the Sun keyboards had all the necessary keys for many years later. We could have had "buttonls" for all these years??

⬐ klotz

I remember using the Boehm GC in C++ in 1989. I wrote a Symbolics Lisp to G++ compiler called XL when. I was at Fuji Xerox and PARC and used it to convert Statice, the first object-oriented database, from Lisp to C++. The server side was a transactional block server and didn't do much consing, but the code flow for the Lisp side did not conveniently map into the C++ stack/ctor/dtor model of memory allocation, so I used the Boehm GC. sadly, the compiler, XL, got lost in a tar fire.

⬐ nibbula

Like a literal tar fire? Or a tar format archive fire? Or is that a California expression I'm not familiar with?

Also this makes me have a sick curiosity if one could have transpiled a whole Genera world to C with cfront or something then loaded it back in with Symbolics C and have it work?

⬐ pmarin

Actual demonstration starts at 14:30

⬐ mrandish

About a decade ago I worked for a very senior and highly respected guy who was near the end of his career. After working closely with him for over a year he decided it was finally time to retire and he left.

Recently, many years later, I'm reading an interesting history of Xerox Parc during that "golden era" where a small group created all the stuff that rocked Steve Jobs world during the legendary 70s demo that led to those concepts ending up in the Lisa and Mac (ie GUI, mouse, etc), and I see that my former boss was on that team and wrote key parts of that stuff early in his career. I look on YouTube and he's one of the people demoing on stage at that big event where the original team got all that code working again on restored original hardware to recreate 'the mother of all demos' so it could be recorded for posterity.

I reached out to him and said, "Dude, I worked with you all that time and you never thought to even mention in all those conversations we had about interface design that you were one of the people who invented a lot of what became computer interaction as we know it?"

He replied, "Oh, that. I didn't think it was important."

It just says a lot about the character and class of these guys, especially in an era where I see too many people who go out of their way to ensure everyone they work with knows they were "one of the first 50 employees at..." (some recent unicorn startup).

⬐ kilroy123

My uncle is one of those people who worked at Xerox Parc during that same era. (I'm sure he would know this person you're speaking of.)

He too is _very_ humble and reserved about the whole thing.

⬐ Rochus

Then his name most likely was not Alan Kay ;-)

⬐ snickmy

I've recently saw a documentary on General Magic. I've been working in tech for 15 years and had never heard about that company. I think we all have a lot to learn, and should pay more respects to the giants that took us here.