Eric Bier Demonstrates Cedar

Computer History Museum

AI-assisted summary of Eric Bier Demonstrates Cedar — original source. Check the original for full context.

Source published: 2019-04-17

Key ideas

Cedar evolved from Mesa at Xerox PARC to combine an industrial-strength, strongly typed modular programming language with an automated garbage collection engine and an integrated operating environment. (2:57)
The Tioga text editor served as a universal interaction substrate across Cedar, allowing embedded typography, mathematical symbols, and vector graphics inside source code without interfering with compiler execution. (26:53)
Cedar packages relied on Description Files (DF files) for dependency management and automated linking, enabling tools like BringOver to populate workspaces across remote file servers transparently. (67:34)
Xerox Dorado workstations featured microcode-driven hardware cursors that continued tracking mouse movement and flashed numeric diagnostic codes even during fatal operating system freezes. (113:04)

Detailed notes

## Background Published on YouTube by the Computer History Museum on April 17, 2019, this archival demonstration features Xerox PARC research scientist Eric Bier showcasing the Cedar integrated programming environment and language recorded on January 24, 2019. The session illustrates Cedar's evolution from Mesa on Xerox D-machines like the Dorado to Sun workstations, highlighting its tiled window manager, universal Tioga text editor, package management, and the Gargoyle graphics suite.

## TL;DR In this technical demonstration and panel discussion, Eric Bier, joined by former PARC colleagues Chris Jacobi, Paul McJones, and Nicholas Briggs, demonstrates the live Cedar environment hosted on a Sun workstation via remote X11. Bier walks through the innovative two-column Viewers window manager, chorded three-button mouse commands, and the Tioga editor, which embedded rich text formatting, styles, and interactive graphics directly into compilable source code. The presentation explores the Gargoyle vector illustration system and its snap-dragging mechanics, Cedar's modular DF package management infrastructure, and the underlying language architecture, including closures, multiple return values, reflection via REF ANY, and pervasive multithreading.

## Atmosphere & style The session has the warm, intimate, and deeply nostalgic atmosphere of a reunion among veteran computer scientists marveling at tools they built and mastered decades prior. Bier's live demonstration is casual yet authoritative, punctuated by chuckles, shared in-jokes like the 'Let's Do the Roll Back Again' song, and spontaneous technical commentary from Jacobi and Briggs. Watching it feels like peering over the shoulder of systems pioneers who remain genuinely fond of Cedar's ergonomic speed, laughing about enduring muscle memory while contrasting its cohesive elegance with the quirks of modern computing.

## Bulletin - [02:57](https://www.youtube.com/watch?v=z_dt7NG38V4&t=177s) Cedar evolved from Mesa at Xerox PARC to combine an industrial-strength, strongly typed modular programming language with an automated garbage collection engine and an integrated operating environment. - [26:53](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1613s) The Tioga text editor served as a universal interaction substrate across Cedar, allowing embedded typography, mathematical symbols, and vector graphics inside source code without interfering with compiler execution. - [01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) Cedar packages relied on Description Files (DF files) for dependency management and automated linking, enabling tools like BringOver to populate workspaces across remote file servers transparently. - [01:53:04](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6784s) Xerox Dorado workstations featured microcode-driven hardware cursors that continued tracking mouse movement and flashed numeric diagnostic codes even during fatal operating system freezes.

## Key takeaways - [06:49](https://www.youtube.com/watch?v=z_dt7NG38V4&t=409s) Cedar prioritized strong typing and strict separation between interface definitions and underlying implementations, fostering high code reuse and robust compiled binaries across PARC. - [08:33](https://www.youtube.com/watch?v=z_dt7NG38V4&t=513s) Automated garbage collection was the definitive architectural upgrade that transformed Mesa into Cedar on second-generation D-machines like the Dorado. - [13:37](https://www.youtube.com/watch?v=z_dt7NG38V4&t=817s) PARC launched the Experimental Programming Environment (EPE) project to evaluate Mesa, Smalltalk, and Interlisp, ultimately seeing Cedar emerge as the dominant internal development platform. - [14:35](https://www.youtube.com/watch?v=z_dt7NG38V4&t=875s) The Viewers window manager utilized a lightweight, two-column tiling model with custom icon trays and persistent layout restoration. - [20:05](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1205s) Cedar placed scrollbars on the left margin to minimize cursor travel from left-aligned text, integrating hierarchical outline collapsing via Ctrl and Shift modifiers. - [23:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1434s) Combining three mouse buttons with Ctrl and Shift modifiers provided twelve instant operations per context, including point-and-shoot text copying without focus shifting. - [47:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2874s) Tioga files maintained a dual-representation architecture where an ASCII null boundary separated compiler-visible plain text from post-null rich formatting and embedded vector artwork. - [58:58](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3538s) The Gargoyle 2D graphics editor introduced snap-dragging techniques based on geometric ruler-and-compass constructions, embedding vector graphics directly into Tioga documents. - [01:01:43](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3703s) Gargoyle operated on a 'documents as user interfaces' paradigm, constructing its own menus as clickable drawings that supported multi-button mouse accelerators. - [01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) Description Files (DF files) automated remote dependency resolution and compilation workflows via BringOver, bypassing manual linker configurations. - [01:20:42](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4842s) Tioga unified hierarchical structural nesting inspired by Doug Engelbart's NLS with Smalltalk's ubiquitous user interface principles on 1-megabyte Dorado workstations. - [01:37:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5821s) Cedar language semantics natively supported multiple return values, explicit integer subranges, and custom array index bounds. - [01:40:21](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6021s) Porting Cedar to Sun workstations required replacing proprietary Alto keyboard assignments, such as the left-arrow assignment symbol, with standard characters like ':='. - [01:43:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6195s) Rather than relying on formal class keywords, Cedar achieved object-oriented patterns and multithreading through first-class function variables, closures, and Mesa monitor primitives. - [01:45:36](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6336s) Runtime reflection and polymorphic data handling were implemented via the universal pointer type REF ANY in place of parameterized generics. - [01:53:04](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6784s) Cedar incorporated session-checkpointing mechanisms that allowed engineers to suspend execution, write complete memory states to disk, and roll back running environments.

## Detailed walkthrough ### [00:10](https://www.youtube.com/watch?v=z_dt7NG38V4&t=10s) Eric Bier’s Background and First Encounters with Cedar

On January 24, 2019, Hansen Hsu convenes a session with PARC research scientist Eric Bier to discuss and demonstrate the Cedar integrated environment and programming language. Bier begins by recalling that he first encountered Cedar in 1981, during his second summer working as an intern at Xerox PARC. That summer, he worked with his host Rick Cattell building databases, and Cattell insisted they be implemented within the Cedar programming environment. Bier participated in MIT’s 6-A co-op program, which entailed working three summers and one fall at a host company and then writing a master’s thesis based on the final six months of effort.

During his third summer at PARC, Bier's host was John Warnock within the Imaging Sciences Laboratory, managed at the time by Chuck Geschke. There, Bier developed a 3D solid modeling system dubbed "Solidviews," which ultimately formed the basis of his MIT master's thesis. He operated Cedar primarily on the Xerox Dorado—a high-performance machine commemorated at the Computer History Museum. Dorado machines were scarce at the time, requiring engineers to sign up for scheduled time slots.

Bier vividly recalls taking a shuttle bus from his office down on Hanover Street up to the main PARC facility at 3333 Coyote Hill Road just to claim a one-hour reservation on a Dorado. During an earlier summer using Smalltalk, his first experience on the machine left an indelible impression: “And what I remember was almost laughing out loud because I wasn't waiting for the computer, it was waiting for me.” Dorados achieved their extreme speed by utilizing emitter-coupled logic (ECL). Because ECL ran intensely hot, machines were not kept directly in individual offices; instead, they were installed down the hall in a dedicated air-conditioned computer room, connected to desk displays and peripherals by thick trunks of cabling routed through the ceilings.

[02:57](https://www.youtube.com/watch?v=z_dt7NG38V4&t=177s) Cedar as a Universal Environment for Code Reuse

Bier highlights a defining attribute of Cedar: it was conceived from the ground up as an environment for both technical researchers and administrative support staff, serving simultaneously as a software engineering platform and a publishing engine. Screen examples show formatted documents embedding inline illustrations and styled typography alongside code. In Cedar, researchers, administrative assistants, and artists shared the same underlying tools.

When asked to characterize Cedar for those unfamiliar with it, Bier explains that it encompasses both the language (often referred to as Cedar Mesa) and an expansive ecosystem of shared runtime libraries and tools. In the 1980s, the team routinely summarized it to outsiders as an "industrial-strength Pascal" to convey a general feel for its syntax. Crucially, the system enforced strict packaging and interface definitions, sparking an extraordinary culture of shared code across dozens of colleagues who built atop one another’s work.

```mermaid flowchart TD accTitle: Cedar Modular Architecture and Application Ecosystem accDescr: Diagram illustrating how the core Cedar language and libraries feed into diverse modular user applications. subgraph Core ["Cedar Platform Core"] A["Cedar Mesa Language (Strong typing, Pascal-like syntax)"] B["Runtime & Libraries (Interfaces vs. Implementations, GC)"] A --- B end

subgraph Applications ["Application Ecosystem"] C["Document Processing & Tioga Editor"] D["2D / 3D Graphics (Solidviews, Gargoyle)"] E["VLSI Circuit Design Tools"] F["Database & Networking Infrastructure"] G["Email Clients & Interactive Debuggers"] end

Core --> Applications ```

The modular discipline meant developers frequently extended or patched software authored by their peers. As Bier explains: “And because it was fairly close-knit community and because of the way the programming environment itself worked, you could constantly be building on other people's software, and even sometimes you would discover a bug in someone else's software and rather than bother them with it, you would just fix it.” If a bug proved intractable, ownership was so transparent that a fix could be arranged with the original author immediately. PARC funded this massive effort because leadership believed that maintaining an extraordinarily productive, state-of-the-art programming platform was the only way to remain at the cutting edge of computer science research.

- Applications built directly within Cedar included email readers, comprehensive debugging utilities, 2D and 3D graphics suites, document publication processors, database engines, networking protocols, and VLSI circuit layout tools. - Strongly typed language boundaries cleanly separated external interfaces (`.bcd` / interface files) from underlying implementations, allowing modular compilation and transparent linkage.

[06:49](https://www.youtube.com/watch?v=z_dt7NG38V4&t=409s) Comparing Cedar, Smalltalk, and Interlisp

Hsu asks how Cedar compared to PARC's other two prominent programming environments of the era: Smalltalk and Interlisp. Bier points out that the three systems represented radically different philosophical choices and execution paradigms. Smalltalk was deeply dynamic and interactive, allowing a developer to type a snippet of code directly into an on-screen window and execute it immediately in an interpreted loop. Interlisp offered extreme structural flexibility through Lisp's uniform syntax, enabling programs to generate, inspect, and immediately execute code on the fly—making it the tool of choice for PARC’s artificial intelligence community.

In contrast, Cedar focused on building hardened, large-scale systems. Its hallmark was strong typing coupled with the strict decoupling of public interfaces from concrete implementations: “What Cedar was really strong at was a strongly typed language with separation between interfaces and implementations, which meant as I said that it was tremendously good at allowing code reuse, and the code that you produced was, you know, fairly robust and likely to, you know, if it compiled it was probably going to run.” This made Cedar ideal for constructing complex applications that could transition into production-grade, commercial products.

[08:33](https://www.youtube.com/watch?v=z_dt7NG38V4&t=513s) Hardware Evolution: Alto, Dolphin, and Dorado

Bier traces his early computing hardware progression through PARC's internal workstations. During his first summer, he was assigned an original Xerox Alto. At the adjacent desk, Andy Daniels was equipped with a Xerox Dolphin—a newer, microcoded processor running roughly 1.5 to 2 times faster than the Alto. Whenever Daniels stepped out of the office, he would generously offer his Dolphin to Bier to speed up work.

Both machines were ultimately eclipsed by the Dorado, which Bier describes as operating at roughly one MIPS (million instructions per second). Although one MIPS sounds modest by modern standards, Bier clarifies that these were rich, microcoded instructions capable of executing substantial computational work per instruction cycle rather than simple clock ticks. Dorado hardware memory configurations varied; the reservation signup sheets noted the memory capacity of each physical box in the machine room. Most Dorados offered 768 kilobytes of RAM, but if an engineer arrived early or was fortunate on the sheet, they could claim the prized "big Dorado" equipped with a full megabyte.

Regarding operating support across hardware generations, Bier notes that while Mesa ran on the Dolphin, he does not believe Cedar ever ran on the Alto, and he doubts whether full Cedar ever ran on the Dolphin either. Mesa was famously chosen as the systems implementation language for Xerox's commercial workstation products, including the Xerox Star (8010 Information System). Bier remembers a celebratory patio party at PARC in the summer of 1980 marking the Star's rollout. However, base Mesa lacked modern developer conveniences: it lacked automatic garbage collection, forcing programmers to explicitly manage pointer lifecycles and storage allocation. Adding automated garbage collection represented the major evolutionary milestone separating Cedar from legacy Mesa.

[11:44](https://www.youtube.com/watch?v=z_dt7NG38V4&t=704s) Panel Introductions and the Origins of Cedar Mesa

Hsu introduces three additional PARC alumni in the room who contributed directly to Cedar and related systems: Paul McJones, Chris Jacobi, and Nicholas Briggs. Each shares their operational background with Xerox software engineering:

- **Paul McJones** worked across the street at Xerox SDD (Systems Development Division) from 1976 through 1981 on the Star office automation system and the Pilot operating system, which later functioned as the foundational low-level platform for Cedar. - **Chris Jacobi** joined PARC in 1983 as an early user of Cedar, authoring an enormous VLSI design tool before shifting to Cedar development itself, where he authored portions of the Cedar compiler and its graphical window system. - **Nicholas Briggs** arrived at PARC in 1984, initially working on the Interlisp environment before transitioning to Cedar to leverage its imaging subsystem for document printing architectures.

Reflecting on the origin of Cedar Mesa, McJones adds that throughout the mid-to-late 1970s, teams were quite satisfied building commercial software in standard Mesa. Because physical memory was so constrained, programmers had to carefully track and allocate every individual byte. Around that time, intense debates erupted across the street at PARC regarding the architectural direction of their next-generation systems, setting the stage for the Cedar experiment.

[13:37](https://www.youtube.com/watch?v=z_dt7NG38V4&t=817s) The Experimental Programming Environment Project and the Origins of Cedar

The push toward Cedar emerged from Xerox PARC's desire to consolidate its fragmented software landscape. While researchers across the laboratory were collaborating and sharing packages, they remained divided across three distinct programming environments: Mesa, Smalltalk, and Interlisp. To address this divide, PARC launched the Experimental Programming Environment (EPE) research project. Its mandate was to evaluate all three environments and determine whether a single language could be selected or synthesized to become the standard PARC programming language.

```mermaid flowchart TD accTitle: Language Convergence into Cedar accDescr: Three original PARC environments converge through the Experimental Programming Environment project into Cedar/Mesa. subgraph S1["Original PARC Environments"] M["Mesa\n(Modular & Strongly Typed)"] ST["Smalltalk\n(Object-Oriented)"] IL["Interlisp\n(Dynamic & Interactive)"] end EPE["Experimental Programming\nEnvironment (EPE) Project"] C["Cedar / Cedar Mesa\n(Dominant by the 1980s)"]

M --> EPE ST --> EPE IL --> EPE EPE --> C ```

Out of this initiative emerged Cedar Mesa, which grew to play a dominant role across PARC by the 1980s. However, the consolidation was not entirely harmonious. While Smalltalk and Interlisp practitioners contributed core ideas and capabilities to Cedar's design, they remained skeptical of adopting it wholesale. As one participant reflects on the internal politics of the project:

> “And yet I think the people from Smalltalk and Interlisp felt not exactly railroaded, you know, they definitely contributed a bunch of ideas to what went into Cedar, but they weren't convinced that that was going to replace their their own language.”

- **Participating languages:** Mesa, Smalltalk, Interlisp. - **Formal initiative:** The Experimental Programming Environment (EPE) research project. - **Resulting system:** Cedar Mesa became dominant at PARC during the 1980s, though researchers from the Smalltalk and Interlisp camps continued to defend and maintain their own platforms.

---

[14:35](https://www.youtube.com/watch?v=z_dt7NG38V4&t=875s) Demo Setup and the Viewers Tiling Window System

Demonstrating Cedar in the 1980s would have meant sitting directly in front of a Xerox Dorado with a high-resolution monochrome display. For this 2019 presentation at the Computer History Museum, Eric Bier reconstructs the environment using a MacBook Pro running X11/X Windows, connected over a secure VPN to a Sun Microsystems workstation at PARC running Cedar on top of Solaris.

Bier explains that Cedar underwent multiple window system iterations. Warren Teitelman originally developed a rich window manager called Docs, but it proved somewhat heavy and slow in practice. In response, Scott McGregor designed "Viewers"—a lean, fast, and highly responsive window manager that defined the canonical Cedar interface. The screen layout is strictly organized:

```mermaid flowchart TD accTitle: Cedar Viewers Screen Layout accDescr: Structural organization of the Cedar Viewers screen from the top status bar down to the bottom icon tray. Top["Top Bar: System Status & Launcher Buttons ('Command', 'New')"] subgraph Columns["Two-Column Tiling Area"] LeftCol["Left Column Viewers\n(Scrollbars on Left)"] Divider["Adjustable Split Line"] RightCol["Right Column Viewers\n(Scrollbars on Left)"] LeftCol --- Divider --- RightCol end Bottom["Bottom Screen Area: Application Icons (Patterned & Color-Coded)"]

Top --> Columns Columns --> Bottom ```

At the top of the display sits a global status bar featuring utility buttons. Clicking `command` spawns a terminal viewer known as the Commander, while clicking `new` creates a blank text viewer running the Tioga editor.

Unlike modern overlapping window managers where windows layer arbitrarily on top of each other, Viewers enforces a strict two-column tiling model. Viewers placed in either column can be repositioned horizontally or vertically: - An arrow button shuffles a viewer into the adjacent column. - The vertical boundary dividing the left and right columns can be grabbed and dragged to rebalance column widths. - A viewer can be expanded to fill its entire column using the `grow` button, which temporarily pushes every other viewer in that column down into the bottom icon tray. - If that maximized viewer is subsequently closed or destroyed, Cedar's window manager remembers the prior layout state and automatically restores the previously displaced windows. - Users can customize menus and default tool layouts through configuration files, and viewers can be stripped down to minimize chrome and maximize visible text. - Minimized viewers collapse into icons lined along the bottom border of the screen, where distinct bitmap textures and later-added color palettes identify the underlying application. Cedar even supplied an "icon editor" tool so users could design and edit their desktop icons one pixel at a time.

---

[20:05](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1205s) The Left-Hand Scrollbar and Structured Tioga Navigation

Bier highlights a distinct ergonomic feature that he and Chris Jacobi still miss in modern graphical systems: Cedar's placement of scrollbars on the extreme left margin of viewers rather than the right. Bier explains that in both text editing and software development, code and prose are naturally left-aligned, leaving the right side of the window filled with ragged whitespace. Because the user's cursor is constantly hovering over text near the left margin, reaching the scrollbar requires only a tiny, effortless gesture rather than a long sweep across the display to the far right.

Furthermore, the Tioga scrollbar acts as a rich control panel rather than a simple slider: - **Instant positioning:** A single click instantly moves the selected line of text directly to the very top of the window, eliminating continuous, imprecise dragging. - **Middle-button "thumbing":** Clicking the middle mouse button transforms the cursor into an arrow, instantly jumping directly to that proportional location in the document (e.g., three-quarters down the file). - **Outlining and level control:** Tioga documents and source code are hierarchically structured by indentation levels. While top-level menus allow collapsing the text to a coarse outline view or expanding it back out, these operations are integrated directly into the scrollbar via modifier chords: - Holding `Ctrl + Shift` while clicking collapses all subordinate levels into an outline view. - Holding `Ctrl` while clicking expands the structure back to full detail, simultaneously aligning the clicked line to the top of the viewer.

Bier demonstrates this flexibility on a draft of a conference paper: with one chorded click, the manuscript collapses into a clean table of contents; another click on "Section 5" expands only that section while instantly scrolling it into view. These combined shortcuts allow experienced users to navigate long documents and complex source files with immense speed.

---

[23:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1434s) Mouse-Chord Combinations and Multi-Window Programming

A defining element of the Cedar user interface is its reliance on mouse chording across a three-button mouse. Rather than hiding functionality inside nested menus, Cedar mapped deep command sets directly onto physical button combinations. Combining the left, middle, and right mouse buttons with the `Ctrl` and `Shift` keyboard modifiers yielded an immediate palette of twelve independent operations available from any cursor position. As Bier points out, the entire system is architected around this input paradigm:

> “So with Ctrl and Shift, that gave you four combinations plus three mouse buttons basically gave you 12 commands in any given context that you could trigger just with those keys and and the mouse buttons, and Cedar made a lot of use of that as you'll see as we go along.”

This input efficiency supported an exceptionally fluid programming workflow: - **Screen density:** Cedar paired high display resolutions with small, crisp, legible proportional and bitmap fonts. Because the text and window frames were compact, developers routinely kept three, four, or more source code modules tiled side-by-side simultaneously without running out of screen real estate. - **Cross-module refactoring:** Bier illustrates this by tiling three modules at once within the two-column view, demonstrating how an engineer could effortlessly extract logic across disparate files. Text chunks could be selected in one viewer and pulled directly into another module with minimal mouse movement. - **Advanced retrieval commands:** To support rapid cross-viewer work, Cedar featured specialized search and navigation commands such as `OpenR` and `FindR`, setting up rapid cross-module search and cross-buffer text manipulation.

[26:53](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1613s) Release Commands and the Everywhere Nature of the Tioga Editor

Eric Bier explains the release-oriented commands in Cedar, focusing on how `find` and `open` work when combined with an `r` suffix. While regular commands search the local working environment, adding `r` instructs Cedar to search the official release directories stored on remote file servers. Executing `FindR` with a pattern matching `.df` files queries the system's package registry: Cedar takes a path starting with `cedar13.0`, maps it via an internal directory service to a physical file server, and locates all matching DF (Description File) packages inside a central subdirectory named `Top`.

```mermaid flowchart LR accTitle: Cedar Release Lookup Architecture accDescr: Flow showing how release commands query remote package directories and open files directly in Tioga. subgraph Client["Local Cedar Environment"] Cmd["Command Line ('FindR' / 'OpenR')"] TiogaUI["Tioga Editor Window"] end subgraph Resolver["Cedar Path Resolver"] Map["Cedar 13.0 Path Mapping"] end subgraph Storage["File Server"] Top["/cedar13.0/Top/"] DF["*.df (Package Files)"] Doc["*.doc (Documentation)"] end Cmd --> Map Map --> Top Top --> DF Top --> Doc Doc -.->|"OpenR"| TiogaUI ```

The companion command `OpenR` retrieves the matched file directly from the release repository and opens it immediately within Tioga, Cedar’s native structured text editor. Because Cedar packaging standardizes on `.doc` as the file extension for package manuals, running `OpenR Tioga.doc` automatically pulls and displays the official documentation for the editor itself without requiring the user to know the remote storage topology.

Bier emphasizes that Tioga is not simply a standalone word processor; it is architectural infrastructure integrated across the entire Cedar operating system. Unlike modern terminal applications that provide only rudimentary, line-oriented editing buffers, Cedar embeds the complete Tioga engine into every text interface, including standard command line terminals and dialog input boxes. Users can apply full Tioga keystrokes, select text across separate windows, and even manipulate inline character looks directly within a running command tool. To prove the point, Bier selects text in the middle of a command prompt and formats it as bold type, noting: “Tioga is really important in Cedar because it's everywhere.”

- Cedar release commands append an `R` (such as `FindR` or `OpenR`) to target system-wide release trees rather than the current working directory. - Release directories contain a `Top` folder housing all system `.df` (Description File) package configurations. - Package documentation uniformly adheres to the `.doc` file extension convention across all Cedar distributions. - Tioga windows maximize screen utility by combining file path display labels and action buttons into a single, compact header bar. - The command terminal provides full Tioga capabilities, supporting rich text styling, font changes, and structural selection inside console prompts.

---

[30:44](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1844s) The Edit Tool: Search, Replace, Looks, and Stylesheets

To complement the editor, Cedar provides the **Edit Tool**, a persistent utility window designed to operate universally on whatever window currently holds the selection. Rather than spawning a separate search-and-replace dialog inside every text window, Cedar uses a single, screen-wide Edit Tool that targets whichever document the user is working on. It allows searches not only by character string, but also by typographical looks, style tags, and structural properties.

After adjusting the parameters in the tool, Bier demonstrates how it can locate literal text (such as the term `memos`) or hunt strictly for character properties by querying the document for any run of text flagged with the bold attribute. It can also perform combined operations, simultaneous replacing text while mutating its styling:

```mermaid flowchart TD accTitle: Unified Edit Tool Workflow accDescr: Diagram illustrating how the centralized Edit Tool controls any open document buffer using looks, text, and styles. ET["Centralized Edit Tool Window"] DocA["Document Window A (Tioga File)"] DocB["Document Window B (Terminal / Buffer)"] ET -->|"Search/Replace Text"| DocA ET -->|"Filter by 'Looks' (Bold, Italic)"| DocA ET -->|"Apply Macro Replay"| DocB ET -->|"Inspect Cascading Style Sheets"| DocA ```

When inspecting bold text within a sample conference paper, Bier highlights Cedar's dual approach to styling: 1. **Explicit Looks:** Characters directly tagged with an inline property code, such as `b` for bold. 2. **Cascading Style Sheets:** Structural markup where elements inherit presentation from defined style rules without hardcoded attributes.

Examining a section header reveals no hardcoded bold attribute. Instead, the Edit Tool inspector indicates the paragraph is governed by an underlying cascading stylesheet named `chi2columnreduced` (built for submissions to the ACM SIGCHI Computer-Human Interaction conference), where the node is assigned structural level `head1`.

Beyond property matching, the Edit Tool features command recording and macros. Bier demonstrates how typing a series of actions—navigating behind a word, applying a bold look, and typing additional punctuation—can be instantly replayed across any other target text with a single keystroke. When an edit goes wrong, Cedar offers rapid recovery: pressing `Shift+Escape` issues a one-level Undo across Cedar tools, while clicking the `Reset` button discards all unsaved modifications and reverts the buffer to the clean state stored on disk.

---

[35:03](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2103s) Structural Repeat Macros and Contextual Button Actions

Cedar provides built-in macro replay directly in the base text editor, operating independently of whether the auxiliary Edit Tool window is visible on screen. When an author executes an editing sequence on a text element—such as changing its look to italic, adding punctuation, and appending a numeric string—Tioga silently tracks the full sequence of actions executed since the selection was initialized. By making a fresh selection elsewhere on the screen and pressing the `Escape` key, the editor automatically applies the entire recorded mutation to the newly targeted text. As Bier notes: “You would often find as you were using the Tioga text editor that you wanted to do something over and over again and often it would do just what you were hope what you would hope it would do.”

This design highlights a core Cedar paradigm: commands frequently expect an active text selection somewhere on screen before a user clicks an action button. To illustrate:

1. A Tioga window exposes knowledge of its local directory context (e.g., the `TiogaFiles` folder). 2. The user highlights an arbitrary file name string appearing inside the directory listing or within any open document buffer. 3. Clicking the `Get` button loads that selected file directly into the active editing pane. 4. Clicking the `Prev` (Previous) button instantly restores the previous buffer contents without requiring manual navigation or file picker dialogs.

While Bier acknowledges that this selection-first pattern proved divisive—admitting that “one thing about Cedar, some people liked it, some people didn't, was that a lot of the commands required that you make a text selection before you did them”—it dramatically accelerated routine editing workflows by turning any arbitrary piece of text on screen into functional input for application buttons.

---

[38:27](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2307s) The Cedar Mousing Model: Point-and-Shoot Copy and Node Selection

Nick Briggs asks Bier to detail the operational differences between the standard desktop interaction model and the Cedar mousing model, specifically prompting: “Eric, can you say something about the different mousing model, the insertion point and Shift-select, copy-selects, those operations that are quite different from what we usually encounter today?”

Bier contrasts mainstream desktop computing with Cedar's accelerated mechanics. In modern operating systems, copying requires a disjointed series of steps: highlight the source, trigger a copy command, reposition the cursor elsewhere, and trigger paste. Cedar bypasses this context switching entirely through **Point-and-Shoot Copy**:

> “In Cedar there is a more efficient method, and it's it's enough more efficient that I continue to use Cedar deep into the 1990s just so as not to have to give give that up along with some other features, but that was a big one.” — Eric Bier

To execute a copy in Cedar: 1. The insertion cursor (caret) remains anchored in the active document where work is currently taking place. 2. The user spots the desired text anywhere else on the display screen. 3. Holding the `Shift` key signals the system that mouse clicks should act as a copy source. 4. Clicking the target text instantly duplicates that text directly into the primary caret position without moving the caret or altering the original window's focus.

```mermaid flowchart TD accTitle: Mouse Button Selection Granularity accDescr: Hierarchy of mouse clicks in Cedar mapping from characters to trees of nodes. subgraph SingleClicks["Single Clicks"] Left["Left Mouse Button Select Character"] Middle["Middle Mouse Button Select Word"] Right["Right Mouse Button Extend Selection (Current Level)"] end subgraph DoubleClicks["Double Clicks"] DLeft["Double Left Click Select Node / Line"] DMiddle["Double Middle Click Select Entire Branch / Subtree"] DRight["Right Click (Post-Double) Extend Selection by Node / Tree Level"] end Left -->|"Right Click"| Right Middle -->|"Right Click"| Right DLeft -->|"Right Click"| DRight DMiddle -->|"Right Click"| DRight ```

This interaction is driven by Cedar's three-button mouse mapping: - **Left Mouse Button:** Selects a single character anywhere on screen. - **Middle Mouse Button:** Selects an entire word. - **Right Mouse Button:** Extends the selection boundary outward at the active level of granularity (character-by-character if the start was a character, or word-by-word if the start was a word). - **Double Left Click:** Selects an entire structural **node** (which in source code files maps directly to a full line). - **Double Middle Click:** Selects an entire hierarchical branch—meaning the parent node plus all child lines nested underneath it. - **Right Click Following Double Click:** Extends the selection across consecutive lines or complete hierarchical statement blocks (entire functions or routines), allowing developers to move complex program structures across files with a few mouse gestures.

[42:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2554s) Rapid Copying with Shift-Clicks in Tioga

Eric Bier demonstrates the mechanics of moving and copying text using Tioga’s selection paradigm. When the Shift key is held down, the entire repertoire of selection commands—left clicks, middle clicks, right clicks, and double clicks—remains active, but shifts into a copy-paste context. Holding down Shift while double-left-clicking allows a user to instantly pull an entire line of code from elsewhere in the buffer right into the current insertion point.

Because the cursor immediately advances and positions itself to receive the next piece of text, copying becomes an extraordinarily fluid stream of actions. Rather than the traditional sequence of selecting text, copying, moving to the destination, clicking, pasting, and moving back, a programmer can simply hold Shift and click across disparate locations in the file. As Bier puts it, “instead of copy move click paste move back copy and so forth it's shift click shift click shift click and you can really throw text around in a hurry with with that way of doing things.”

- **Shift modifier**: Re-evaluates standard selection clicks (characters, words, lines) as copy-insertion actions directly at the active caret position. - **Continuous cursor positioning**: Keeps the insertion point primed after every copy, allowing chained imports of code lines or phrases from multiple file locations without manual refocusing.

---

[43:37](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2617s) Orthogonal Commands, Muscle Memory, and "Tioga Everywhere"

Chris Jacobi chimes in to highlight a profound architectural quality of the Cedar environment that is difficult to appreciate in a brief visual demo: its strict orthogonality. In Cedar, once an interaction pattern combining keyboard chords, mouse buttons, and double-clicks is learned in one context, that identical pattern works everywhere across the entire system. Jacobi explains that this consistency explains why Bier could seamlessly operate the interface despite a 16-year hiatus, noting: “for me it's 18 years since I haven't used Cedar I still make errors I still use Cedar key combinations sometimes on my PC with the tool which absolutely has no idea what to do for that.”

Jacobi also expands on Bier’s earlier observation that the Tioga editor is ubiquitous throughout Cedar. Every surface displaying text is a full-fledged Tioga instance. If a running program crashes or encounters a fault and prints an error message to the console, the user can immediately execute Tioga commands directly on that error text to edit, select, or modify it. Jacobi jokes about the rare boundary of this design: “I think I know one exception if in a chip design you have some metal with the pattern of letters that doesn't work with Tioga commands.”

- **Strict orthogonality**: Common mouse and keyboard chording rules govern text editing, system tools, file viewers, and consoles without special-case variations. - **Universal text model**: Console outputs, error notifications, and input prompts are interactive Tioga text buffers rather than dumb terminal output streams.

---

[45:50](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2750s) Split Views, Normalization, and Laser Font Previews

Returning to Tioga's interface controls, Bier walks through the window management buttons lining the top of the viewer. Among these is `Split`, an advanced view-splitting feature that allows a programmer to open multiple scrollable viewports into the exact same file simultaneously. This capability allows one to inspect a distant helper function—such as `CopyCircle`—and copy or drag it directly up to the top of the file without losing position. Furthermore, `Split` can be invoked multiple times within a single document viewer, providing simultaneous read/write access to several distinct regions of a large codebase.

Bier also highlights navigation power tools such as `Normalize`, which repositions the current selection nearly to the top of the window, deliberately leaving a few lines above it to preserve visual context. Tioga also maintains a selection history buffer, enabling users to re-select previous text ranges easily. Lastly, Bier toggles the `StyleKind` button, which recalculates the on-screen document typography using proportional laser printer fonts rather than the hand-tuned bitmap screen fonts. Although the laser preview accurately depicts physical print output, Bier quickly switches back to bitmap fonts, noting how much more readable they are on CRT and workstation displays.

- **`Split` viewer**: Multiplies scrollable viewports on a single underlying file buffer to facilitate cross-cutting edits and reference checks. - **`Normalize` command**: Re-scrolls the active selection near the top margin while preserving an overhead buffer of lines for immediate context. - **`StyleKind` switch**: Toggles between screen-optimized bitmap typefaces and hardcopy print simulation fonts.

---

[47:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2874s) The Dual-Representation Architecture of Tioga Files

Bier reveals the underlying file format that enables Tioga to function both as an efficient source-code editor and as a rich publication-grade document system. Behind the scenes, a Tioga document is cleanly partitioned into two sections separated by an ASCII null character (`\0`). The first part, preceding the null byte, contains the plain text stream. Everything following the null character consists of binary formatting records that govern character appearances (bold, italics, font families), document hierarchy, and embedded illustrations.

```mermaid flowchart LR accTitle: Tioga File Format Architecture accDescr: Diagram showing how a Tioga document splits plain source text from formatting metadata using a null character boundary. subgraph File["Tioga Document (.mesa)"] direction LR subgraph PreNull["Part 1: Plain Text (Compiler View)"] A["Source Code Stream\n(Keywords, Identifiers, Operators)"] end NullChar["Null Character\n(\\0)"] subgraph PostNull["Part 2: Binary Metadata (Tioga Looks)"] B["Font Looks & Faces\n(Bold, Italics, Greek)"] C["Comments & Annotations"] D["Embedded Illustrations\n(Gargoyle Artwork)"] end A --> NullChar NullChar --> B NullChar --> C NullChar --> D end ```

Crucially, the Cedar and Mesa compilers only read the text prior to the null character, ignoring everything that follows. This means comments, style definitions, and illustrations are stored entirely within the trailing metadata segment rather than within the compiler's lexing stream. In modern IDEs, syntax highlighting is typically computed dynamically on the fly based on grammar heuristics. In Cedar, styling commands are explicit, persistent properties attached to the document. To illustrate, Bier clears all "looks" using the Edit Tool and removes the comment status from a line, converting a stylized `HelloWorld` program back into flat plain text.

- **Null-delimited structure**: The compiler reads source code up to the null byte; rich formatting, artwork, and comments reside after the null byte. - **Zero compiler overhead for comments**: Because comments are stored in the post-null metadata rather than interleaved in the plain text stream, the Mesa compiler never spends cycles scanning or stripping them. - **Explicit formatting commands**: `Ctrl+\` toggles whether a block of text is marked as an ignored comment; `Ctrl+M` automatically parses Cedar Mesa syntax to assign standard typestyles across the document.

---

[51:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3094s) Mathematical Notation and Embedded Illustrations in Source Code

Because styling metadata is decoupled from the raw characters seen by the compiler, developers can apply specialized formatting to enrich code readability. Bier demonstrates writing an interpolation formula between two variables, `x0` and `x1`, parameterized by a blending variable named `a`. By selecting the letter `a` and pressing the "looks" chord `Look-G` (for Greek), the character instantly displays as an elegant $\alpha$ on screen, rendering the source code with mathematical clarity while retaining its underlying identifier identity for the compiler.

```mesa -- Interpolation formula rendered in Tioga with Greek looks: (1 - α) * x0 + α * x1 ```

Taking visual integration even further, Tioga allows vector illustrations to be embedded directly into source files. Bier opens `GGCirclesImpl.mesa`—a module from the Gargoyle illustration system he created for his UC Berkeley Ph.D. dissertation—and scrolls down to the `CircleMeetCircle` procedure. Embedded directly inline with the algorithmic logic is a full geometric diagram showing intersecting circles, annotated with the exact variable names used in the surrounding code.

- **Typographic looks in code**: Pressing `Look-G` on the character `a` transforms it into $\alpha$, preserving ASCII identity under the hood while delivering clean mathematical rendering. - **Embedded Gargoyle graphics**: Procedural code files can host labeled vector diagrams to visually explain complex geometric calculations like circle intersections.

---

[54:18](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3258s) Cedar Modules: Interfaces, Implementations, and `Get Info`

Bier explains that the Cedar software architecture is built around a rigorous separation between interfaces and implementations, a design pattern inherited from Mesa that directly contributed to PARC's high degree of software reuse. Every library must define an interface (a `Definitions` module) specifying procedure signatures, types, and constants. These definitions contain no implementation bodies whatsoever. For example, a constructor routine that produces a circle from a center point and a `REAL` (floating-point) radius defines its return type purely as an abstract `Circle`.

Implementation code resides in one or more separate files, conventionally designated with an `Impl` suffix (such as `GGCirclesImpl.mesa`). This decoupling allows multiple interchangeable implementations to exist for a single interface, making it possible to swap between stable and experimental versions of an engine at compile or bind time. Tioga bridges these conceptual layers directly within the editor: selecting an interface name and clicking the `Get Info` menu button instantly resolves and opens the corresponding implementation module exporting that interface.

- **Rigorous separation of concerns**: Cedar `Definitions` files declare public API contracts; `Impl` modules contain the actual executable bodies. - **Multiple implementation backends**: A single definitions file can be backed by multiple implementations, enabling side-by-side experimental code or partitioning oversized files. - **`Get Info` cross-navigation**: A built-in Tioga menu command that instantly pivots from an interface definition directly into its concrete implementation module.

[57:07](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3427s) Code Navigation and Introducing the Gargoyle Graphics Tool

Eric Bier demonstrates how Tioga integrates code navigation directly into its top menus. By highlighting an identifier and clicking the "Def" button in the menu, the editor immediately jumps to the source code definition of that procedure. As Bier notes, “So all of those things just are built right into the menus at the top of Tioga and available to you anytime that you're programming.”

Changing gears, Bier closes his working window to introduce Gargoyle, the 2D illustration tool developed as part of his UC Berkeley doctoral dissertation. Moving the Gargoyle window to the left column of the display, he explains that while it provides basic geometric primitives like squares, circles, and triangles, its core innovation lies in interactive precision drawing. Gargoyle is built around a technique called "snap-dragging," which allows users to construct complex, exact shapes dynamically. Bier also points out the menus arranged along the top of the Gargoyle window, remarking that they were actually drawn using Gargoyle itself under an architectural paradigm known as "documents as user interfaces."

[58:58](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3538s) Snap-Dragging and Precision Drawing in Gargoyle

Bier explains the philosophy behind snap-dragging, likening it to classical geometric construction: “So the idea of the snap dragging techniques for drawing precise shapes is that you can ask the system to give you some guidelines; it's kind of like a ruler and compass construction approach except without all the tedium that you remember from ruler and compass construction in high school.” With automatic mode active, the system generates dynamic alignment lines and intersection rays as the user sketches.

To demonstrate, Bier draws an equilateral triangle with a horizontal base measuring exactly one inch on a side simply by dragging along the system-provided guide rays. He pauses briefly while recalling the exact keystroke and mouse combinations for transformation operations, testing rotate and scale before setting up an angled construction. Setting guideline constraints to 0 degrees (horizontal) and 60 degrees (slanted just past vertical), he sketches out a stylized, italicized letter "G" directly on the canvas without needing manual coordinate entry.

[01:01:43](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3703s) Mouse Button Modalities and Stuffing Graphics into Tioga

Gargoyle carries over the three-button interaction language of the Tioga text editor. Bier middle-clicks an edge of the drawn letter "G" to select the segment, then right-clicks adjacent segments to extend the selection across multiple connected lines, mirroring the gesture used to extend text selections from words to phrases in Tioga. He then uses the drag operation, snapping the selected segments along the 60-degree construction guidelines to reshape the letter with geometric precision.

```mermaid flowchart LR accTitle: Gargoyle to Tioga Graphic Transfer accDescr: Workflow showing how a graphic constructed in Gargoyle is transferred into a Tioga document using Interpress and mouse accelerators. subgraph Gargoyle["Gargoyle Vector Editor"] G1["Draw/Select Shape (e.g., Purple 'G')"] G2["Interpress Menu (3-Column Pop-up)"] G1 --> G2 end subgraph Accelerator["Shortcut Trigger"] A1["Middle-Click Menu Button (No Shift / No Ctrl)"] G2 --> A1 end subgraph Tioga["Tioga Document"] T1["Target Node Selection (Double-Click)"] T2["Graphic Embedded Inline ('Stuff to Tioga')"] T1 --> T2 end A1 --> T2 ```

After tinting the "G" purple and scaling it down, Bier demonstrates embedding the illustration directly into a Tioga document. In the Interpress menu, he locates the "Stuff to Tioga" operation and highlights the structure of Gargoyle’s pop-up menus. Rather than displaying a single linear list, options appear in three columns corresponding to left, middle, and right mouse clicks, modified by Shift and Control:

- Left column operations trigger with a left mouse click. - Middle column operations trigger with a middle mouse click. - Right column operations trigger with a right mouse click. - Combinations with Shift and Control map up to twelve distinct operations to direct accelerators without opening submenus.

Because "Stuff to Tioga" is mapped to a middle-click with neither Shift nor Control held, Bier selects a target node in the Tioga document with a double-click, invokes the command, and the vector artwork embeds directly into the document text flow.

[01:04:57](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3897s) Documents as User Interfaces and Clickable Buttons

Bier elaborates on the concept of "documents as user interfaces," explaining that graphic elements and text in Cedar can be imbued with active programmatic behavior. In Gargoyle, any geometric shape or text label can have associated behavioral code that fires when clicked. Pop-up palettes—such as font selection panels where a Control-right-click sets the largest bold font—are regular Gargoyle drawings wired up as control surfaces. As Bier observes, “The more you use Gargoyle, the faster you get at operations like this because of the way the menus work.”

This capability extends throughout the Cedar environment wherever Tioga handles text display. In the Commander console, Bier runs `ButtonLS`, an enhanced version of the traditional directory listing command. Alongside each listed file name, `ButtonLS` renders a small graphic rectangle. The rectangle is an interactive Tioga active element: clicking it automatically invokes an open command on that specific file, turning a plain terminal output stream into an ad-hoc graphical navigation panel.

[01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) Package Management in Cedar: DF Files, SModel, and BringOver

Bier shifts focus to software configuration and release management, contrasting modern tools like CVS, Subversion, and Git with Cedar's DF (Description File) system. He highlights its central role in day-to-day work, stating, “Let me talk a little bit about DF files and the commands BringOver and SModel because they were another key to why we were so productive in the Cedar environment.” In Cedar, every package includes a `.df` file specifying all files belonging directly to the package, as well as the external Cedar libraries it requires.

```mermaid flowchart TD accTitle: DF Package Management Dependency Resolution accDescr: Diagram illustrating how BringOver reads a DF file, fetches local sources, and recursively fetches dependencies using Using clauses. subgraph Package["Hello.df Package Description"] DF["Hello.df Author: EBSU Directory: Cedar 13.0"] Local["Local Source: HelloWorldImpl.mesa"] DF --> Local end subgraph Imports["Imported Subsystems"] I1["Atom"] I2["Basics"] I3["Commander"] I4["IO"] I5["Ropes (Immutable Strings)"] end DF -->|"BringOver (Using Clause)"| Imports subgraph SModelAction["Remote Sync"] SM["SModel Command (Commit / Push to Server)"] end DF -.-> SM ```

Examining a minimal example, `Hello.df`, Bier walks through its structure: - **Header Metadata**: Automatically records the author (in this instance, `EBSU` for "Eric Bier Super User") and target server directory (`Cedar 13.0`). - **SModel Command**: The tool used to commit or push packages to the central file server (where "S" stands for "System" modeling). - **Direct Files**: Lists implementation units belonging directly to the project (e.g., `HelloWorldImpl`). - **Imports with `Using` Clauses**: Explicitly declares imported modules—such as `Atom`, `Basics`, `Commander`, `IO`, and `Ropes` (Cedar’s immutable string data type). The `Using` clause ensures that only the interface definitions needed to compile the local package are retrieved rather than the entire remote subsystem. - **Version Rules**: Syntax such as `~=` specifies package version constraints, permitting developers to check out the latest release, freeze against a specific timestamp, or download only if the server version is strictly newer than the local copy.

To demonstrate dependency resolution in action, Bier locates an existing `Cedar 13` version of the Gargoyle package on disk, runs the `FindR` utility to locate `Gargoyle.df`, and invokes `BringOver` to begin pulling its source tree and dependencies into his local workspace.

[01:11:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4294s) Fetching Files via DF and Compiling Hello World

Using a shift-select gesture to paste into the command area, Eric Bier triggers Cedar's Description File (`.df`) machinery. The system resolves the Gargoyle `.df` file and automatically recurses into all dependent `.df` packages, pulling over 366 files into the local directory. Running a directory listing confirms that the complete set of interfaces and implementation files has arrived, allowing Bier to open and edit local copies of Gargoyle modules such as `GGCircles.mesa` and its implementation (`GGCirclesImpl`).

```mermaid flowchart TD accTitle: DF File Dependency Resolution and Compilation accDescr: Flowchart showing how Cedar retrieves package dependencies and compiles a module into a registered command.

subgraph DF_Machinery["DF Package Management"] DF["gargoyle.df"] --> Recurse["Recursive DF Resolution"] Recurse --> Files["366 Local Files Fetched"] end

subgraph Compile_Run["Compilation & Execution"] Edit["Edit HelloWorldImpl.mesa"] --> Compile["Compile Module"] Compile --> Register["Register Command with Commander"] Register --> Exec["Execute 'hello' in Command Shell"] end

Files -.-> Edit ```

To demonstrate the edit-compile-run loop, Bier opens a simple `HelloWorld` program. He modifies the text from "January 24 2019" to include a specific time—"10:30 a.m."—and saves it. While Cedar includes comprehensive tools to compute build dependencies automatically across entire packages, Bier triggers compilation on the single module (`HelloWorldImpl`). Once compiled, running the module registers a new command called `hello` with Cedar's Commander shell. Bier executes `hello`, and the terminal immediately prints out the updated message. Chris Jacobi points out an essential architectural convenience:

> “Here Eric didn't say anything about linking because whatever the linking is will be read out of that one DF file which seems so simple.”

- The DF machinery recursively retrieved 366 files required to build and run Gargoyle. - Linker documentation in contemporary systems could span dozens of pages, whereas Cedar derived linking and loading specifications directly from the `.df` package definitions without requiring manual link steps.

---

[01:15:50](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4550s) The Philosophy of Tioga: Unified Text Editing and Pending Delete

Prompted to discuss why Tioga served simultaneously as a publication document editor and a software development editor, Bier explains the immense practical benefits of a ubiquitous text editing substrate. Once a user internalizes motor patterns—such as paragraph styling, bolding, or multi-button mouse selection chords—those habits work identically across every UI element in Cedar, from single-line text input fields in forms to full conference research papers. It made collaboration effortless; a researcher could lean over an administrative assistant's shoulder and guide their actions using the exact same keystrokes and shortcuts used in programming. Chris Jacobi adds historical perspective on the design choice:

> “It's actually obvious: you need a program editor, you have a text editor, so why not use that? So if you had to argue and to reason at that time, you would have to reason why you would not want to do it that way.”

Bier demonstrates the power of Tioga's selection and editing semantics. Selecting text highlights it in reverse video, which activates "pending delete"—typing any new character immediately overwrites the entire selected range without needing a prior backspace or delete command. Furthermore, moving and copying follow consistent modifier combinations with mouse selections: holding `Shift` while selecting copies text into the caret location, while holding `Ctrl` and `Shift` simultaneously cuts the selection from its original spot and moves it directly to the target cursor position.

- Selection chords allow rapid boundary definition from word to word. - Reverse-video selection doubles as visual confirmation of pending deletion. - `Shift` + mouse drag/click performs an in-place copy. - `Ctrl` + `Shift` + mouse drag/click performs a move (cut-and-paste) in a single operation.

---

[01:20:42](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4842s) Historical Lineage: Engelbart's NLS, Smalltalk, and Alto Roots

Paul McJones and Eric Bier reflect on the origins of Cedar's core user interface paradigms. McJones notes that Tioga's structured statement nesting and "clipping levels" can be traced back to Doug Engelbart's NLS (oN-Line System), an effort contributed to by researchers like Bill Paxton—who co-developed Tioga alongside Doug Wyatt. During the mid-1970s at Xerox PARC, the Xerox Alto suffered from severe memory constraints, forcing each standalone application to monopolize the entire machine; programmers used primitive code editors for development and separate, heavier tools for formatted documents.

```mermaid flowchart LR accTitle: Lineage of Cedar UI Paradigms accDescr: Historical progression of concepts from NLS, Alto, and Smalltalk into Cedar.

NLS["Doug Engelbart's NLS (Hierarchical clipping levels)"] --> Cedar["Cedar Environment"] Alto["Xerox Alto Tools (Left scrollbars, selection models)"] --> Cedar Smalltalk["Smalltalk-76 / Smalltalk-80 (Unified editors across UI)"] --> Cedar Cedar --> Workstations["1 MB+ Workstations (Dorado / Sun)"] ```

Smalltalk pioneered running a single graphic and text toolset uniformly across an entire system despite the Alto's hardware limits. By the time Cedar emerged on larger "1 megabyte computers" (such as the Dorado workstation and subsequent architectures), these diverse concepts coalesced: NLS-style hierarchical levels, the Alto's left-hand scrollbars and selection models, and Smalltalk's architectural ubiquity. Bier demonstrates how structural levels function inside raw code: clicking repeatedly on an indentation level expands or collapses nested blocks, providing an outline view that makes navigating multi-page procedures manageable.

---

[01:23:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4995s) Tioga's WYSIWYG Nature and Interpress Printing

Addressing whether Tioga qualified as a full "What You See Is What You Get" (WYSIWYG) system, Bier clarifies that while formatting styles and embedded graphics rendered directly on screen, layout rendering was not 100% identical to the final printed output. For example, opening a conference paper formatted for two-column output displayed as a continuous single column within Tioga's editor; multi-column pagination occurred only during translation to Interpress or upon transmission to a laser printer.

Chris Jacobi observes that during Tioga's initial creation, screen rendering and physical printing necessarily diverged:

> “In the very early times we did not have smooth fonts—actually smooth fonts were still secret—but so we had bitmap fonts, which means when the text goes from the screen to the printer it will print with a mildly different font, and they had to be different because screen resolutions could never match printer resolutions at that time.”

Over time, outline and smoothed font advances narrowed that divide. The discussion turns to Interpress, Xerox's binary page description standard (and direct forerunner of PostScript). Bier searches his local directory for generated `.ip` (Interpress) files—such as those created for his "Toolglass and Magic Lenses" papers—and confirms that while dedicated tools like `IPViewer` allowed on-screen examination of raw printer streams, the standard workflow was generating Interpress raster descriptions and routing them directly to networked Xerox laser printers.

[01:26:32](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5192s) Previewing Printable Files and Interface Learnability

Examining printable files directly on the monitor revealed that characters often looked awkward due to screen font limitations. Users rarely edited printable target files directly; instead, they worked in Tioga files. Subtle differences existed between formats: text line-breaking in Tioga was tied dynamically to window width, whereas hardcopy column adjustments followed separate page-layout formatting.

An interlocutor notes that while the Cedar user interface feels consistent and meticulously designed, the heavy reliance on three mouse buttons gives the impression of a tool geared strictly toward power users, raising the question of how easily novices or non-programmers could discover commands and learn the system. Eric Bier explains that usage extended far beyond computer science researchers to administrative assistants and graphic artists. Several factors made the system approachable: - Package documentation was easy to locate and followed strict naming conventions. - Strong cultural norms governed updates: developers used SModel to commit new versions, followed standardized email notification templates detailing every change, and were expected to update documentation simultaneously.

```mermaid flowchart TD accTitle: Cedar Package Update Workflow accDescr: Standardized developer workflow for updating, tracking, and documenting a Cedar package. subgraph Development ["Code & Docs"] A["Modify Package Code"] --> B["Update Documentation File"] end subgraph Release ["Release Process"] B --> C["Save via SModel"] C --> D["Send Standardized Email Template"] end ```

[01:29:03](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5343s) Non-Expert Usability, Preview Tool, and Application Consistency

Bier attempts to load the `Preview` package to view a conference paper. It initially complains about missing fonts, but he succeeds in opening a viewer displaying full font outlines. While the text appears small at full page view, scaling it up makes the rendered outlines legible.

Chris Jacobi reflects on the apparent contradiction between hearing about Cedar’s complexity versus actually sitting down to use it. Jacobi points out that verbal explanations often overcomplicate things because developers take pride in design decisions:

> “When you actually sit on the machine and you are not thinking, you just use your fingers to do the fingering for you, then you will see the the logic behind it.”

Because the overarching design principles were logical, users could frequently guess how an unlearned command should work, and their intuition proved correct. Administrative assistants could compose and format complex documents without having to write Tioga code, while specialized tools maintained consistency: - Chip design editors required domain-specific commands (such as pressing `m` for a metal line or `t` for a transistor). - Even domain-specific tools retained familiar Tioga interaction patterns wherever possible.

[01:31:55](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5515s) The Origins of Gargoyle and Snapdragon

Asked about his involvement with the Gargoyle vector illustration system, Bier recalls that the project originated from his doctoral dissertation at UC Berkeley and was documented in a 1986 SIGGRAPH paper. His research focused on the Snapdragon technique—an interactive snapping mechanism functioning like a dynamic "ruler and compass on steroids."

PARC maintained an active dogfooding culture where research tools were adopted by the internal community. Users wanted to embed rich illustrations in documents, prompting Bier, Ken Pier, and Maureen Stone to develop Gargoyle. The system leveraged Michael Plass's Cedar Imager, an underlying library supporting: - Resolution-independent graphics - Arbitrary polygons and spline curves - Geometric clipping algorithms

PARC staff artist Steve Wallgren adopted Gargoyle to create posters for the PARC Forum, event brochures, and presentation graphics.

[01:35:04](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5704s) Snapping in 3D and Berkeley Advising

Bier expanded the Snapdragon interaction model into three dimensions with Gargoyle 3D. A key finding was that the identical 2D mouse and keyboard commands operated naturally in 3D environments without needing an exotic 3D cursor. By treating the cursor ray as a line projected from the user's eye into the scene, interactions snapped directly to 3D alignment guidelines, planes, or the surfaces of spheres (the spatial counterpart to compass circles).

Bier recalls the weekly routine of shuttling his progress across the bay: - Every week, he recorded a video demonstrating new snapping features. - He drove the tape across the Bay Bridge to UC Berkeley's Evans Hall. - His PhD advisor, Carlo Séquin, alongside Brian Barsky, reviewed the video alongside the Berkeley computer graphics lab graduate students.

[01:37:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5821s) Language Features: Multiple Returns, Explicit Ranges, and Constraints

Returning to the Cedar code viewer, Bier opens `GGCirclesImpl` to highlight Cedar's language features using the `CircleMeetCircle` procedure, which computes the intersection between two geometric circles:

``` CircleMeetCircle: PROC [circle1, circle2: Circle] RETURNS [points: ARRAY [1..2] OF Point, hitCount: [0..2], tangent: BOOL] ```

Bier contrasts this directly with languages restricted to returning single values: - **Multiple return values:** The procedure simultaneously returns an array of intersection coordinates, an intersection count (`hitCount`), and a boolean flag (`tangent`). Naming these return values in the signature automatically creates local variables that can be assigned directly inside the procedure body. - **Custom array indices:** The array specifies `[1..2]`, making it explicit that the indices run from 1 to 2 rather than starting at zero. - **Subrange integer constraints:** Rather than using a generic integer for the intersection count, Cedar allows constraining the type declaration to the exact valid domain: `[0..2]`. - **Assignment operator:** Cedar uses a distinct left arrow character (`←`) for variable assignments rather than an equals sign.

[01:40:21](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6021s) Character Sets, Keyboards, and Assignment Syntax

Eric Bier demonstrates how default return values could be specified directly in a method header. A question arises from the audience about whether Cedar relied heavily on non-standard ASCII characters. Bier and Chris Jacobi clarify that it used only a small handful, the most notorious being the left-arrow character (`←`) for assignment. On original Xerox Alto and D-machine hardware, physical keyboards had dedicated keys for those characters. When Xerox PARC ported Cedar to Sun Microsystems workstations and SunOS in the late 1980s, these idiosyncratic keys had to be mapped onto standard Sun keyboards. Bier recalls that he was personally involved in creating that keyboard mapping table, as well as porting the Viewers window system to SunOS around 1987 under an internal project nicknamed "Windows by Winter," which aimed to have Viewers up and running on Sun hardware before December 21st.

```mermaid flowchart LR accTitle: Evolution of Cedar Keyboard and Assignment Syntax accDescr: Diagram showing the transition of Cedar assignment syntax from Xerox hardware to Sun workstations. subgraph XeroxHardware["Xerox Alto & D-Machines"] A["Physical Left-Arrow Key (←)"] --> B["Built-in Hardware Character Set"] end subgraph SunPort["Sun Workstations (Late 1980s)"] C["Windows by Winter Project"] --> D["Custom Sun Keyboard Mappings"] D --> E["Standard Syntax: ':=' for assignment"] end XeroxHardware -->|"Ported to SunOS"| SunPort ```

Jacobi points out that once the problematic left arrow was replaced by the standard Pascal-style `:=` operator, Cedar required no exotic characters to compile. Jacobi also reflects on how deeply the syntax ingrained itself into former PARC researchers: “And when I left Xerox I did for years to come—still occasionally today—I write equals and I mean with equals that we do a comparison and not an assignment, but considered colon-equals versus single equals is so much more intuitive than having two equals or just one equal.”

- Keyboards on Alto and D-machines (Dorado, Dolphin, Dandelion) directly supported Xerox’s extended character set. - The Sun port required software translation layers to map these keys onto commodity workstation layouts. - Replacing the left arrow with `:=` removed the last non-standard character dependency from the language core.

---

[01:43:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6195s) Object-Oriented Patterns and Multithreading via Language Primitives

Jacobi elaborates on the philosophical design of Cedar. While Xerox PARC pioneered object-oriented programming with Smalltalk, the Cedar language itself intentionally launched without built-in, formal object-oriented keyword constructs. Instead, Cedar provided a concise set of flexible primitives: first-class function variables, closures, and nested functions. These primitives allowed developers to write idiomatic object-oriented code without language bloat. Jacobi remarks: “I am not aware of a single program which didn’t use the object features of Cedar, but they were done with the primitives which were basically function variables and closures and nested functions.” Anonymous closures and lambda expressions were used ubiquitously across PARC codebases, even without explicit lambda syntax defined in the formal manual.

Paul McJones and Jacobi also discuss Cedar’s concurrency model. Threading was baked into the ecosystem from the start, descending directly from Mesa's pioneer work on monitors and threads. Jacobi notes that practically every Cedar program was multithreaded; the sole exception he could recall was the Cedar compiler itself. Concurrency was managed with robust synchronization primitives, complemented by an advanced exception-handling framework that permitted catching, inspecting, and re-throwing errors.

- Modularity and multithreading in Cedar were inherited from Mesa, but were streamlined for ease of daily use. - Concurrency was ubiquitous throughout the operating environment, driving asynchronous background tasks and UI event queues. - Exception handling formed the basis not only for fault recovery, but also for diagnostic communication between subsystems.

---

[01:45:36](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6336s) Rich Typographic Code and Runtime Type Inspection (`REF ANY`)

Bier highlights a visual feature of the Tioga editor: integrating styled typography into executable code. He brings up an example where a variable named `d2` represents a distance squared; by formatting the `2` as a superscript exponent ($d^2$) directly in the editor, its mathematical meaning is immediately recognizable.

```mermaid flowchart TD accTitle: Cedar REF ANY Type Inspection Architecture accDescr: Flowchart illustrating how REF ANY acts as a generic reference that enables runtime type introspection. A["Generic Pointer: 'REF ANY'"] --> B{"Runtime Type Inspection"} B -->|"Type query / NARROW"| C["Circle Object ('REF CircleObject')"] B -->|"Type query / NARROW"| D["Viewer Object ('REF ViewerObject')"] B -->|"Type query / NARROW"| E["Arbitrary Dynamic Type"] C --> F["Execute specific handler / method"] D --> F E --> F ```

The conversation shifts to the Cedar type system. Jacobi explains that because the original Cedar interactive debugger was written in Cedar itself, the language needed the ability to introspect any memory structure. This design resulted in runtime type inspection (reflection) decades before it became common in mainstream languages. Central to this capability was `REF ANY`, a universal pointer type: - Any heap-allocated reference could be assigned to a `REF ANY`. - Programs could inspect the runtime type tag of a `REF ANY` pointer dynamically using type-switch and select statements. - When asked if Cedar supported generic types, Jacobi clarifies that Cedar lacked parameterized generics, substituting `REF ANY` instead. While this incurred a slight dynamic dispatch/indirection overhead compared to modern zero-overhead templates, the high performance of Dorado hardware made the distinction negligible in practice.

---

[01:49:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6541s) Function Variables, Callbacks, and Reference Semantics

Jacobi and Bier discuss how programming against `REF ANY` and nested function variables shaped Cedar architecture. Standard library routines frequently accepted a `REF ANY` payload alongside a callback function pointer. Because nested procedures closed over the lexical scope of their enclosing blocks, developers could pass callbacks back and forth across abstraction layers. Jacobi acknowledges that this pattern could sometimes devolve into convoluted spaghetti logic—where a callback invoked another callback deep inside a client module—yet it delivered immense extensibility.

Bier notes a key syntactic distinction in Cedar code between a value and a reference to that value, citing an interface example: - A `CircleObject` represented the underlying structure record. - A `Circle` was defined as `REF CircleObject`. - Creating an instance required declaring a variable of type `Circle` and assigning it `NEW CircleObject`.

Jacobi adds that while `Circle` and `CircleObject` were strictly distinct types in the compiler's symbol table, the language offered convenient syntactic sugar: dereferencing was automatic. Programmers could simply use dot notation (`circle.radius`) across chains of pointers without manually dereferencing each pointer step.

---

[01:53:04](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6784s) The Dorado Hardware Cursor, Status Codes, and State Rollback

Bier shares a hardware anecdote regarding the Xerox Dorado's cursor rendering. On the Dorado, cursor positioning was hardwired into dedicated microcode and CPU cycles:

> “One of the interesting things about the Dorado was that it dedicated some of its CPU time to drawing the cursor on the screen; every few cycles the cursor would be updated, and what that meant was that the cursor was one of the most reliable objects on the screen. Even if there was a problem and the rest of Cedar had frozen, the cursor would still move around, track your mouse nicely.”

Because the hardware cursor remained operational even during total operating system freezes or unhandled crashes, PARC engineers turned it into an out-of-band diagnostic display. The system flashed numeric diagnostic codes directly inside the cursor bitmap itself. Developers memorized these numeric codes to immediately identify system failures; Bier and Jacobi single out error code `815` as one of the most infamous fatal crash codes.

The segment concludes as Jacobi humorously expresses nostalgia for Cedar's development capabilities: “I wish I had it.” Bier then introduces Cedar’s powerful session-checkpointing mechanism, which allowed users to suspend their active session, snapshot the exact memory state to disk, and instantly roll back the entire running environment whenever needed.

[01:55:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6901s) Suspending State and "Let's Do the Roll Back Again"

Reflecting on how the system handled session persistence, Eric Bier recalls the mechanics of suspending and resuming execution by storing state. He shares a humorous anecdote from PARC lore about an in-joke parody song crafted around this workflow: “As a joke one year someone wrote a little song to the tune of ‘Let's Do the Time Warp Again’ from Rocky Horror, except it was ‘Let's Do the Roll Back Again.’”

As the presentation comes to an end, Bier invites any final thoughts, asking, “Anyway, anyone else have any last words?” The attendees respond with warm appreciation, thanking him for the in-depth walkthrough of Cedar, to which Bier graciously replies, “You are very welcome.”

[01:55:35](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6935s) The OpenR and FindR Commands

Before wrapping up completely, Bier highlights a specific set of commands he had been quietly invoking on screen during the final moments of the demonstration without full explanation: `OpenR` and `FindR`. He clarifies the naming convention and purpose behind them, explaining: “I believe the R is for release, and open in the sense of I've opened something for editing or viewing.”

- **`OpenR` and `FindR`**: File-access commands in the Cedar environment, where the trailing "R" signifies opening or finding an official "release" version of a document or source file for viewing and editing.

## Notable quotes > [01:15:50](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4550s) It's actually obvious: you need a program editor, you have a text editor, so why not use that? — Chris Jacobi

> [01:43:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6195s) I am not aware of a single program which didn’t use the object features of Cedar, but they were done with the primitives which were basically function variables and closures and nested functions. — Chris Jacobi

> [26:53](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1613s) Tioga is really important in Cedar because it's everywhere. — Eric Bier

## Mentioned ACM SIGCHI, Andy Daniels, Bill Paxton, Brian Barsky, BringOver, ButtonLS, Carlo Séquin, Cedar, Cedar Imager, Cedar Mesa, Chris Jacobi, Chuck Geschke, Commander, Computer History Museum, Computer Science Laboratory, Dandelion, Docs, Dolphin, Dorado, Doug Engelbart, Doug Wyatt, Edit Tool, Eric Bier, Evans Hall, GGCirclesImpl, Gargoyle, Gargoyle 3D, Hansen Hsu, IPViewer, Interlisp, Interpress, John Warnock, Ken Pier, Maureen Stone, Mesa, Michael Plass, MIT, Modula, NLS, Nicholas Briggs, Pascal, Paul McJones, Pilot, PostScript, Preview, REF ANY, Rick Cattell, SModel, SIGGRAPH, Scott McGregor, Smalltalk, Snapdragon, Solaris, Solidviews, Steve Wallgren, Sun Microsystems, SunOS, Tioga, UC Berkeley, Viewers, Warren Teitelman, Windows by Winter, X Windows, X11, Xerox Alto, Xerox Dolphin, Xerox Dorado, Xerox PARC, Xerox SDD, Xerox Star (8010 Information System)

## Video description [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.

Catalog number:102781041 Lot number: X8888.2019

[Source](https://www.youtube.com/watch?v=z_dt7NG38V4)

中文简报

Eric Bier 演示 Cedar 系统在这场技术演示与专家座谈中，Eric Bier 联同前 PARC 同事 Chris Jacobi、Paul McJones 以及 Nicholas Briggs，通过远程 X11 在 Sun 工作站上实机演示了运行中的 Cedar 环境。Bier 详细介绍了创新的双列 Viewers 窗口管理器、三键鼠标和弦按键指令，以及能够直接将富文本格式、样式和交互式图形嵌入到可编译源代码中的 Tioga 编辑器。演示还探讨了 Gargoyle 矢量绘图系统及其贴靠拖拽（snap-dragging）机制、Cedar 的模块化 DF 软件包管理基础设施，以及包括闭包、多返回值、通过 REF ANY 实现的反射和无处不在的多线程在内的底层语言架构。 Cedar 由施乐帕洛阿尔托研究中心（Xerox PARC）的 Mesa 演进而来，将工业级、强类型的模块化编程语言与自动垃圾回收引擎及集成操作系统环境结合在一起。 (2:57) Tioga 文本编辑器是贯穿整个 Cedar 的通用交互底层架构，允许在源代码中嵌入排版格式、数学符号和矢量图形，且不干扰编译器的执行。 (26:53) Cedar 软件包依赖描述文件（DF 文件）进行依赖项管理和自动化链接，使得 BringOver 等工具能够跨远程文件服务器无缝填充工作空间。 (67:34) 施乐 Dorado 工作站配备了微代码驱动的硬件光标，即使在操作系统发生致命死锁时，它仍能继续追踪鼠标移动并闪烁显示数字诊断代码。 (113:04)

Reading summary

In a 2019 demonstration organized by the Computer History Museum, Xerox PARC alumnus Eric Bier, joined by colleagues Chris Jacobi and Paul McJones, illustrated how the Cedar programming language and environment unified systems programming, structured text editing, and publishing into a cohesive, highly modular platform. Consolidation and Architectural Goals of Cedar (6:49) Xerox PARC launched the Experimental Programming Environment project to reconcile the laboratory's fragmentation across Mesa, Smalltalk, and Interlisp. While Smalltalk offered interpreted dynamism and Interlisp provided structural flexibility for artificial intelligence research, Cedar Mesa focused on building hardened, large-scale systems. The language combined strong typing with an enforced decoupling of public interfaces from concrete implementations, ensuring high code reusability and operational stability across diverse software tools. Tioga Editor and Interaction Ergonomics (20:05) A defining attribute of Cedar was the universal presence of its structured editor, Tioga, which governed every textual surface including code buffers, console streams, and documentation. Tioga featured an ergonomic left-hand scrollbar tailored to left-aligned text, supporting instantaneous line alignment, middle-button proportional jumping, and hierarchical indentation clipping derived from Doug Engelbart's NLS. Input relied heavily on mouse chording across a three-button mouse and keyboard modifiers, generating twelve distinct operations that included point-and-shoot copying and pending-delete selection. Dual-Representation Files and Integrated Graphics (47:54) Tioga files maintained a dual-representation architecture partitioned by an ASCII null character. The pre-null region contained standard plain source text for compilers, while post-null records stored binary metadata for styles, typographic looks, and embedded artwork. This design allowed developers to display Greek mathematical symbols and superscripts in source logic without breaking compiler identification, as well as embed inline vector diagrams created via Bier's snap-dragging illustration tool, Gargoyle. Advanced Language Features and Concurrency Cedar extended systems programming with features uncommon in the early 1980s, such as procedures returning multiple named values, custom array indices, subrange integer constraints, and multithreading backed by monitors and exception handling. Rather than implementing dedicated object-oriented keyword constructs, the system implemented object patterns using first-class function variables, closures, and nested scopes. Through the universal pointer REF ANY, Cedar also incorporated runtime type inspection and reflection, driven by the requirement that its interactive debugger be written directly in Cedar. Package Management and Hardware Execution (67:34) Software configuration relied on Description Files (.df), which tracked explicit file versions and dependencies across remote servers via tools like BringOver and SModel. Cedar initially ran on microcoded Xerox Dorado workstations operating at roughly one MIPS with 768 kilobytes to one megabyte of RAM. Because Dorado cursor tracking was handled directly in microcode, the on-screen cursor remained responsive during system freezes, functioning as an out-of-band diagnostic display that flashed fatal numeric error codes. While Cedar established high productivity, rigorous interface decoupling, and pioneering interactions that influenced later systems, its deep reliance on specialized three-button mouse chording, custom keyboards, and microcoded hardware architectures reflected an era of specialized workstation environments that diverged from later mainstream computing models.

精炼阅读摘要

施乐帕洛阿尔托研究中心（Xerox PARC）研究员埃里克·比尔（Eric Bier）系统展示了20世纪80年代的Cedar集成编程与运行环境，阐明其如何通过接口隔离、通用排版编辑器与严密交互体系支撑高复用度的大规模系统研发。起源与定位：整合PARC软件版图 (13:37) Cedar诞生于PARC的“实验性编程环境”（EPE）研究项目，旨在解决此前Mesa、Smalltalk与Interlisp三大技术栈分裂的局面。比尔与前工程师保罗·麦克琼斯（Paul McJones）指出，Mesa虽严密但因早期内存极限需要人工精确管理字节，Smalltalk注重纯粹动态交互，Interlisp擅长人工智能领域的代码即时动态生成，而Cedar则定位于构建工业级强度的生产型大型系统。系统继承了Mesa的静态强类型体系，严格隔离公开接口定义文件与具体实现模块，使得若代码通过编译就大概率能正常运行，由此在PARC内部形成了数十人相互调用底层包的软件复用生态。 Tioga编辑器：排版代码一体的双层架构 (47:54) Cedar将Tioga结构化文本编辑器作为全局基础设施，贯彻“Tioga无处不在”的设计理念。从操作系统控制台报错输出到最终学术出版物，所有展示文本的界面均具备完整的Tioga编辑功能，甚至能在命令行列表输出中嵌入可点击的图形动作按钮。Tioga文件采用了以ASCII空字符（\0）为分界线的底层双重表示结构：前半部分是提供给编译器的纯文本代码流；后半部分则是二进制格式排版元数据。这种解耦让开发者能在源码中嵌入希腊字母、数学上标乃至由Gargoyle系统绘制的矢量几何示意图，而编译器会自动忽略空字符后的排版数据。正交交互模型：三键鼠标与左侧滚动条 (38:27) Cedar确立了极高一致性的正交物理操作模型，大幅降低了用户的认知与切换成本。克里斯·雅各比（Chris Jacobi）强调，系统将三键鼠标与Ctrl、Shift修饰键组合出12种核心操作，并在全系统任意文本区域保持语义一致。比尔演示了“瞄准即射”（Point-and-Shoot）复制机制：编辑光标保持在目标位置不动，用户按住Shift键并在屏幕任何其他窗口点击文字，该内容便会瞬时被抓取插入，避免了常规选中、复制、切换焦点再粘贴的繁琐链路。同时，Viewers平铺式窗口将滚动条置于视窗最左侧，契合代码与文本靠左对齐的人机工程学特征，使光标微调与大跨度跳跃的鼠标移动距离降至最低。语言与硬件协同：高级抽象与底层诊断 (103:15) 在语言机制与运行时层面，Cedar未引入臃肿的面向对象专有关键字，而是通过第一类函数变量、闭包、嵌套函数以及通用引用指针REF ANY构建面向对象模式与反射机制。语言还原生支持多返回值、显式自定义数组索引区间以及子范围整数约束；并发方面则直接沿袭Mesa的管程与线程模型，除编译器自身外全系统几乎所有程序均以多线程并发运行。比尔与雅各比回忆，在约1 MIPS性能的Xerox Dorado工作站上，硬件甚至为光标分配了专用的微码与CPU更新周期，使其即便在系统遭遇类似“815”等严重崩溃冻结时仍能移动，并直接在光标位图中闪烁显示致命错误诊断码。工程化交付：DF依赖管理与状态回滚 (67:34) Cedar构建了远早于现代包管理工具的代码交付工作流。系统通过描述文件（.df）精确追踪本地代码依赖以及远程文件服务器上的外部组件版本，通过BringOver命令即可全自动递归解析并检出成百上千个关联模块源码。团队配套建立了标准化的SModel发布提交流程，涵盖自动发送变更邮件与同步更新文档的严格文化约定。比尔还展示了其完备的状态持久化机制：用户能够对当前运行时的完整内存镜像进行检查点快照与磁盘挂起，并在遭遇异常或测试后瞬间回滚整个系统环境，在PARC内部甚至由此诞生了改编自流行歌曲的“让我们再回滚一次”的行业俚语。 Cedar展示了20世纪80年代计算机工作站软硬件高度一体化的巅峰工程水准，但在硬件架构从施乐专有D机器转向Sun通用工作站后，其依赖专用物理按键、微码协同和封闭生态的设计在向现代开放计算体系过渡时付出了重新映射与兼容的妥协代价。

Detailed notes — zh

## Background 该视频由计算机历史博物馆（Computer History Museum）于 2019 年 4 月 17 日在 YouTube 平台发布。内容记录了 2019 年 1 月 24 日施乐 PARC 研究科学家 Eric Bier 现场演示 Cedar 集成开发环境与编程语言的实况，并由 Nick Briggs、Chris Jacobi 和 Paul McJones 共同参与对谈。演示通过现代 Mac 远程连接至 PARC 内部运行 Solaris 的 Sun 工作站，重现了 Cedar Mesa 语言、Viewers 平铺视窗系统、Tioga 富文本编辑器以及 Gargoyle 矢量绘图工具的历史风貌。 ## TL;DR 演示中，Eric Bier 深入展示了 20 世纪 80 年代施乐 PARC 的核心旗舰环境 Cedar，强调其兼顾专业排版与强类型软件工程的一体化设计。内容细致剖析了 Viewers 高密度平铺窗口的交互哲学、高度依赖三键鼠标修饰键组合的击键流，以及‘无处不在’、支持语法树级选取和级联样式表的 Tioga 编辑器。此外，Bier 还实机操作了他博士期间开发的 Gargoyle 矢量插画系统，展示了基于尺规作图思想的 Snap-Dragging 几何对齐、代码内嵌图解与公式排版，并结合 DF 文件包管理机制完成了从依赖拉取、原地修改到编译注册全局命令的全流程。随后的深入探讨还揭示了 Cedar 原生支持多线程、动态类型自检（`ref ANY`）以及利用硬件高刷新光标进行崩溃容灾诊断等诸多超前于时代的技术实现。 ## Atmosphere & style 全场散发着浓厚的复古黑客气息与深切的学术怀旧感，宛如一场跨越数十载技术光阴的老友重聚。演示者与老同事们在面对十几年未曾触碰的操作界面时，指尖依然能凭借肌肉记忆行云流水地盲敲出复杂的三键鼠标快捷键，流露出由衷的自豪与会心欢笑。讨论既严谨探讨软硬件工程架构的底层取舍，又穿插着关于 ECL 芯片机房、改写摇滚歌曲调侃系统回滚等实验室轶事，现场氛围既充满极客探索的专业敏锐，又洋溢着温暖的人文温情。 ## Bulletin - [02:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=174s) Cedar 是 Xerox PARC 在 Mesa 语言基础上演进出的强类型、模块化集成开发环境，引入了自动垃圾回收机制，兼顾高强度软件工程研发与专业文档出版排版需求。 - [26:53](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1613s) Tioga 编辑器构成了 Cedar 全局一致的泛在文本基础设施，终端控制台及系统报错均内嵌其编辑能力，并支持在代码中直接嵌入带标注的矢量几何图形与希腊数学字符。 - [42:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2554s) 交互设计全面挖掘三键鼠标与修饰键的笛卡尔积组合，结合左侧滚动条与大纲折叠机制，配合 Shift 键可实现光标不移位的高速跨窗口代码抓取与复制。 - [01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) Cedar 依托 .DF（Description File）系统描述文件自动化解析递归依赖并消除显式链接步骤，同时支持类似 Git 流程的 BringOver 与 SModel 版本同步操作。 - [01:51:38](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6698s) 硬件层面，Dorado 计算机为光标分配独立专用 CPU 周期，使其在系统完全冻结或报错崩溃时仍能顺畅移动并以内部数字代码形式对外通信报错。 ## Key takeaways - [06:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=361s) 在 PARC 内部三大阵营对比中，Cedar 凭借强类型系统与接口与实现的严格分离，在软件健壮性与大规模跨团队代码复用上优于 Smalltalk 和 Interlisp。 - [01:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=94s) Cedar 早期主力硬件 Dorado 采用 ECL（发射极耦合逻辑）芯片构建，因发热量巨大必须安置在恒温专用机房，并通过天花板走线连接研究员办公室的桌面终端。 - [15:31](https://www.youtube.com/watch?v=z_dt7NG38V4&t=931s) Viewers 窗口系统采用双列平铺（Tiling）布局，支持窗口记忆恢复、动态列宽调整及最大化展开（Grow）模式，有效替代了早期 Docs 系统并提升了响应速度。 - [20:05](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1205s) Tioga 颠覆常规地将垂直滚动条置于视窗左侧，契合代码与文本大多左对齐的视觉与操作重心，大幅缩减了鼠标在文本与导航之间的位移距离。 - [20:05](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1205s) Tioga 滚动条深度融合了 Doug Engelbart NLS 系统的层级大纲思想，支持通过按键组合在长篇代码与多层级学术论文中快速折叠展开大纲。 - [47:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2874s) Tioga 文档底层采用以 Null 字符（\0）为界的二分法物理存储结构，前半部分为纯 ASCII 文本，后半部分存放排版元数据、样式及被编译器自动忽略的代码注释。 - [30:44](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1844s) 早于现代 CSS 出现前，Tioga 就实现了直接字符外观（Looks）与级联样式表（Cascading Style Sheets）的分离，为学术出版提供规范化排版。 - [58:07](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3487s) Gargoyle 矢量绘图系统源于 Eric Bier 的博士课题，其核心技术 Snap-Dragging 将尺规作图数字化并由系统自动推算投影辅助线，实现了极高精度的几何绘图。 - [01:04:57](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3897s) Cedar 践行“文档即用户界面”哲学，Gargoyle 的菜单与终端 buttonLS 目录输出的方块图标均依托 Tioga 底层对象实现可点击脚本交互。 - [01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) 系统建模工具（SModel）与 DF 文件构成了完备的包版本管理机制，利用 USING 子句精确控制依赖树导入，摆脱了传统操作系统繁琐的手动链接过程。 - [01:37:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5821s) Cedar 原生支持命名多返回值，过程定义中的输出变量可直接作为函数内部的局部变量进行赋值运算。 - [01:37:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5821s) Cedar 具备高度安全的类型系统，支持从 1 开始计数的自定义数组下标，并能通过子区间类型（如 [0..2]）在编译期约束数值范围。 - [01:43:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6195s) 虽然缺乏显式的 OOP 类关键字，但 Cedar 依靠函数变量、闭包与嵌套函数等语言底层原语，在实践中构建了全面的面向对象范式与多线程并发模型。 - [01:46:29](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6389s) 系统通过通用引用类型 ref ANY 实现了运行时类型自检（Type Inspection）与类似泛型的灵活抽象，同时在语法糖层面允许直接用点号自动链式解引用。 - [01:51:38](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6698s) Dorado 计算机的硬件级光标设计兼具极高容灾能力，不仅在系统冻结时仍能实时响应，还能通过光标内部的数字代号传达操作系统崩溃诊断信息。 ## Detailed walkthrough ### [00:10](https://www.youtube.com/watch?v=z_dt7NG38V4&t=10s) 进入 PARC 与 Cedar 项目的早期渊源采访者 Hanson Hsu 开场并介绍日期为 2019 年 1 月 24 日，随后向 Eric Bier 询问他是如何加入施乐帕洛阿尔托研究中心（Xerox PARC）并参与到 Cedar 项目中的。Bier 回忆道，他最初接触 Cedar 是在 1981 年夏天，那是他在 PARC 担任暑期实习生的第二年。当时他的导师是 Rick Cattell，负责数据库相关项目，Cattell 坚决要求使用 Cedar 编程环境进行开发，这成为了 Bier 接触 Cedar 的契机。 Bier 在 PARC 度过了连续三个暑假，这是麻省理工学院（MIT）“6-A 项目”（Co-op 合作项目）的一部分。按照该项目的机制，学生在企业工作三个暑假以及一个秋季学期，并基于最后六个月的研究成果完成硕士论文。在第三个暑期，Bier 的导师换成了 John Warnock，所在实验室大约是影像科学实验室（Imaging Sciences Laboratory），当时的实验室主管是 Charles Geschke。在该期间，Bier 开发了一套名为“Solidviews”的实体建模系统，这套系统最终成为了他在 MIT 的硕士学位论文。 - 1981 年暑期（第二期实习）：在导师 Rick Cattell 指导下，用 Cedar 编写数据库软件。 - 1982 年暑期（第三期实习）：在 John Warnock 与 Charles Geschke 领导的影像科学实验室开发 Solidviews 实体建模系统。 - 学业背景：通过 MIT 6-A 合作项目在 PARC 实习并完成硕士论文。 --- ### [01:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=94s) 初遇 Dorado 计算机：从排队预约到澎湃性能 Bier 谈到自己大多是在 Dorado 计算机上与 Cedar 打交道。当时 Dorado 属于极其稀缺的计算资源，中心并未达到人手一台的水平，必须提前在登记表上预约时段。他第一次申请到了一个小时的机时，由于他的办公室位于汉诺威街（Hanover Street）的园区建筑，他必须乘坐穿梭巴士上山，前往位于土狼山路 3333 号（3333 Coyote Hill Road）的主楼去赴那个一小时的预约。那段记忆发生在更早一个暑期接触 Smalltalk 的时候。谈及坐在 Dorado 面前的操作感受，Bier 忍不住笑出声来： > “And what I remember was almost laughing out loud because I wasn't waiting for the computer; it was waiting for me.” Dorado 之所以速度飞快，是因为它采用了发射极耦合逻辑（ECL，Emitter-Coupled Logic）芯片构建。但 ECL 的巨大代价是发热量极其惊人，机器根本无法放在普通办公室内，只能统一安置在走廊尽头的专用空调机房中，天花板内布满了密密麻麻的走线。 ```mermaid flowchart LR accTitle: Dorado Remote Architecture accDescr: Dorado host in air-conditioned room connects to user terminal via ceiling cabling. subgraph Office["研究人员办公室"] Terminal["终端显示器与键鼠"] end subgraph MachineRoom["恒温机房"] Dorado["Dorado 主机 (ECL 硬件)"] end Terminal <-->|"天花板高密度走线"| Dorado ``` --- ### [02:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=174s) Cedar 的定位：兼具科研开发与文档出版的一体化环境 Bier 强调，Cedar 最独特的亮点在于它的受众同时涵盖了科研人员与文秘职员，兼顾高强度程序编写与日常出版排版。屏幕上展示的文档兼具精致排版的文本与高精度的内嵌图形。在 PARC 内部，不仅是核心系统研究员在使用 Cedar，行政助理以及美术设计人员也都在同一个环境下完成工作。在 Hanson Hsu 的追问下，Bier 对 Cedar 进行了系统界定。Cedar 既指一种编程语言（亦称 Cedar Mesa），也指整套应用程序与系统库。如果向 80 年代的同行描述其语法，大家通常戏称它为“工业级 Pascal”（industrial-strength Pascal）。但 Cedar 最深远的影响在于代码复用（code reuse）。其语言机制几乎强制要求开发者以高度模块化的方式打包代码，使得整个社区内的数十位开发者能够互相调用下层库。 - 工具链生态：包括文档处理系统、邮件客户端、各类调试工具、出版物排版、2D/3D 图形工具、VLSI 超大规模集成电路设计系统、数据库以及网络协议软件等。 - 社区协作文化：若在他人代码中发现了 Bug，开发者往往不会打扰原作者，而是直接动手修复；若自己无法解决，也能通过清晰的接口归属迅速定位负责人推进修复。 --- ### [06:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=361s) 平台对比：Cedar、Smalltalk 与 Interlisp 的三足鼎立 PARC 当时向 Cedar 投入了大量时间和资源，其核心诉求是极大地提高科研产出效率，确保实验室在各项计算机前沿课题中始终保持领先地位。面对 Hanson Hsu 提出的“与 Smalltalk、Interlisp 相比有何不同”这一问题，Bier 细致地对比了 PARC 内部的三大计算阵营： 1. **Smalltalk**：极富交互性，用户可直接在终端窗口敲入一行代码并立即执行，基于完全的动态解释运行范式。 2. **Interlisp**：得益于 Lisp 语言极其精简统一的 S 表达式语法，能够轻易实现“动态生成代码并立即执行”，因而在 PARC 内部主要被人工智能（AI）研究团队青睐。 3. **Cedar**：走强类型（strongly typed）路线，强制将接口（interface）与实现（implementation）解耦分离。关于 Cedar 在软件健壮性上的优势，Bier 总结道： > “What Cedar was really strong at was a strongly typed language with separation between interfaces and implementations, which meant... that it was tremendously good at allowing code reuse, and the code that you produced was... likely to, you know, if it compiled, it was probably going to run.” 这种编译通过即大概率能稳定运行的特性，使得 Cedar 产出的系统非常健壮、坚固，极易实现向生产级工业产品的转化。 --- ### [08:33](https://www.youtube.com/watch?v=z_dt7NG38V4&t=513s) 硬件演进：从 Alto、Dolphin 到 Dorado 机器 Bier 梳理了他在 PARC 见证的硬件性能跃进。第一个暑假时，他的办公桌上放的是一台 Alto；隔壁的 Andy Daniels 配备了一台更新的 Dolphin。Dolphin 比 Alto 快了大约 50% 到两倍，每当 Daniels 外出，Bier 便会借用他的 Dolphin。然而 Dorado 的性能比 Dolphin 还要高出整整一个量级。 Dorado 的处理能力约为 1 MIPS（每秒百万条指令）。虽然以当今标准看似数值不高，但由于 Dorado 是全微码化（microcodable）机器，每条指令能完成极其繁重的操作，绝非单纯的时钟频率所能度量。此外，预约表上会清晰标注每台 Dorado 的内存规格：绝大多数机器配有 768 KB 内存，但偶尔会有运气极好的时候，能抢先约到拥有一整兆（1 MB）RAM 的“大 Dorado”。在软件运行平台的兼容性方面： - Alto 内存与算力不足，从未运行过 Cedar。 - Dolphin 主要用于运行原生的 Mesa 语言，Bier 怀疑 Cedar 是否真正在 Dolphin 上稳定运行过。 - Dorado 以及后续的 D 系列工作站（D-machines）是 Cedar 展开研发的主力平台。 --- ### [10:33](https://www.youtube.com/watch?v=z_dt7NG38V4&t=633s) 从 Mesa 到 Cedar 的跨越与特邀嘉宾登场从 Mesa 演进到 Cedar 的核心驱动力是开发体验与内存管理机制的革新。Mesa 是施乐早期的系统级语言，并支撑了多项核心商用产品。Bier 回忆道，大约在 1980 年夏他刚到 PARC 时，公司在户外露台举行了盛大的派对，热烈庆祝 Xerox Star（8010 信息系统）的正式发布，而 Star 的系统底层便是由 Mesa 写就的。然而 Mesa 并不具备现代编程语言的诸多便捷特性，最致命的痛点是缺乏自动垃圾回收（Garbage Collection, GC）。开发者不得不耗费大量心力在底层显式管理指针、手动分配与释放内存。Cedar Mesa 引入自动垃圾回收之后，彻底减轻了开发者的心智负担，成为软件工程效率的一次巨大飞跃。随后，现场邀请了三位曾亲历该技术周期的 PARC 校友加入对话并作自我介绍： - **Paul McJones**：1976 年至 1981 年任职于施乐系统开发部（Xerox Systems Development Department, SDD，位于 PARC 街对面）。曾参与开发 Star 办公自动化系统以及 Pilot 操作系统。Pilot 系统后来成为了 Cedar 底层的关键构建构件。 - **Chris Jacobi**：1983 年加入 PARC，最初作为 Cedar 的重度用户，使用 Cedar 编写了一套规模极庞大的 VLSI 设计工具；后期深入 Cedar 系统内部，参与了编译器核心组件及窗口系统的开发。 - **Nicholas Briggs**：1984 年加入 PARC，起初从事 Interlisp 系统工作，后来作为文档打印系统的一员，深度采用了 Cedar 的图形与影像处理模块（imaging code）。 Paul McJones 补充回顾了当时的技术背景：在 70 年代中后期，他们使用 Mesa 开发商业产品整体非常顺畅，但由于硬件内存极度匮乏，团队只能“小心翼翼地精确分配每一个字节”，而当时在 PARC 内部围绕是否要通过新技术摆脱这种束缚，正掀起一场深入的路线探讨。 ### [13:37](https://www.youtube.com/watch?v=z_dt7NG38V4&t=817s) PARC 的语言统一之争与实机演示架构讨论首先回顾了施乐帕洛阿尔托研究中心（Xerox PARC）内部关于编程语言整合的尝试。当时研究人员各自依托不同的包体系开展工作，但面对三大截然不同的语言环境，有人希望将各自的优势熔于一炉，于是发起了“实验性编程环境研究项目”（Experimental Programming Environment research project），评估是否能确立一种 PARC 通用标准语言。这场角逐最终催生了 Cedar/Mesa，并在 20 世纪 80 年代占据了主导地位。但其他阵营并非完全顺从，现场讨论提到：“来自 Smalltalk 和 Interlisp 的人虽然没有感到完全被强行排挤，他们确实为 Cedar 的诞生贡献了大量构想，但他们并不信服这能取代他们自己的语言。” 随后，Eric Bier 介绍了本次重现演示的技术拓扑结构。如果回到 20 世纪 80 年代初，该演示本应运行在一台配备黑白显示器的 Xerox Dorado 计算机上。而在当下（2019 年），演示环境是由一台位于计算机历史博物馆现场的 MacBook Pro 运行 X Windows 系统，通过 VPN 隧道远程连接到留在 PARC 的一台 Sun Microsystems 工作站；该工作站运行着面向 Solaris 的移植版 Cedar，再将 X11 图形界面实时回传到现场屏幕上。 ```mermaid flowchart LR accTitle: Cedar Remote Demonstration Architecture accDescr: MacBook Pro running X Windows at the Computer History Museum connects via VPN to a Sun Microsystems workstation running Cedar on Solaris at PARC. subgraph CHM["计算机历史博物馆（演示现场）"] Mac["MacBook Pro (运行 X Windows)"] end subgraph Network["网络链路"] VPN["VPN 远程连接"] end subgraph PARC["施乐 PARC 实验室"] Sun["Sun 工作站 (Solaris 系统)"] Cedar["Cedar 运行环境"] end Mac <--> VPN VPN <--> Sun Sun --- Cedar ``` ### [15:31](https://www.youtube.com/watch?v=z_dt7NG38V4&t=931s) Viewers 平铺式窗口系统架构与紧凑界面设计 Cedar 最直观的特征是其图形窗口系统。在 Cedar 演进过程中曾出现过若干个窗口子系统，例如 Warren Teitelman 开发的 Docs 系统功能丰富，但运行偏慢；针对其性能短板，Scott McGregor 随后构建了一套极其轻巧迅速的替代方案，命名为“Viewers”，屏幕上的所有窗口单元自此被称为“Viewer”。整个界面从上至下布局，顶端是状态栏与全局动作按钮：点击 `Command` 按钮可生成一个命令行终端窗口（在 Cedar 中称为 Commander），点击 `New` 按钮则会唤出全新的 Tioga 文本编辑器。 Viewers 系统的核心设计哲学是最大化利用有限的屏幕面积，支持用户同时平铺打开海量窗口。窗口顶部的菜单可以精简折叠，隐藏次要功能，甚至能通过配置文件定制默认展开的控件排布。屏幕最下方是图标托盘（Icon Tray），窗口关闭后会最小化到底部并变成带特定黑白纹理或彩色点阵的图标，以此直观区分具体应用；系统甚至附带了一个小巧的像素级图标编辑器（Icon Editor），供用户逐像素绘制个性化图标样式。 - **Docs 与 Viewers 对比**：Docs 功能丰富但速度受限；Scott McGregor 的 Viewers 以精简和高响应速度为核心目标。 - **Commander 终端**：由顶部状态栏的 `Command` 按钮激活，承载 Cedar 的控制台交互。 - **图标定制机制**：最小化窗口至底部图标区，后期版本加入色彩与纹理标识，内置 Icon Editor 允许单像素微调。 ### [18:18](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1098s) 双列平铺布局、动态伸缩与上下文记忆与当下主流的层叠重叠式（Overlapping）窗口管理器不同，Viewers 采用严格的双列平铺（Tiling）布局。所有新打开的 Viewer 均会自动落入左列或右列之中。用户可以点击窗口标题栏的右箭头，将该窗口无缝移入右侧列。当某一列内容繁杂、干扰视线，或是需要更大阅读空间时，用户可直接点击 `Grow` 按钮，该 Viewer 随即独占整个竖列，同列的其他窗口则自动被压入底部的图标状态。双列之间的分界线可以通过鼠标拖拽自由左右调节。更精妙的是 Viewers 对窗口布局状态的自动记忆机制：如果用户彻底销毁（Destroy）了当前被最大化的窗口，系统会自动判定当前已无需全屏，并瞬间将先前被挤走隐藏的同列窗口恢复还原到原位，省去了人工逐个找回并重新排列的繁琐劳动。 ### [20:05](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1205s) 左侧滚动条哲学与大纲级别折叠 Eric Bier 与 Chris Jacobi 讨论了他们至今仍然怀念的 Cedar 交互细节，其中最突出的便是反常规置于窗口“左侧”的垂直滚动条。在现代图形操作系统中，滚动条几乎一律居右，但 Cedar 用户认为左侧滚动条是经过深思熟虑的卓越设计： > “ Cedar 用户认为这非常棒。将滚动条放在左侧的一大好处是，对于文本文档——特别是当你编写软件代码时——文本往往集中在窗口的左侧，而不是右侧；右侧往往留有大量空白。由于你在处理文档时经常要用鼠标光标指向内容，你不会去点那些空白，而是去点文本，而文本偏偏都在左边；既然你本来就在窗口左侧附近，移动到滚动条开始操作就只需要极其微小的位移。” Tioga 的滚动条不仅仅用于移动视野，还深度集成了大纲结构导航与结构化编辑指令： | 交互操作 | 快捷键 / 鼠标按键 | 对应功能行为 | |:--- |:--- |:--- | | **单点顶置** | 鼠标单选对应行 | 选中文本行立即跳跃至屏幕最顶端，无需拖曳试错 | | **整体收拢** | `Ctrl` + `Shift` + 点击 | 折叠下级内容，将文档或代码收拢为多级大纲视图 | | **层级展开** | `Ctrl` + 单击 | 展开下一级细节，并同步将指定节点移到屏幕顶端 | | **精准飞梭** | 中键单击（Thumb） | 光标变为小箭头，按比例直接纵跳到全篇相应位置（如 3/4 处） | 这种机制无论在阅读冗长代码还是在撰写多层级的会议学术论文（Conference Paper）时，都能让熟练用户凭借极少的肌肉动作完成复杂大纲的高速跳转。 ### [23:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1434s) 三键鼠标组合逻辑与多模块高效协同编码 Cedar 体系将 Xerox 的三键鼠标能力挖掘到了极致。界面操作极大地依赖左键、中键、右键与修饰键的笛卡尔积组合。配合键盘上的 `Ctrl` 键与 `Shift` 键，两者构成 4 种状态，与 3 个鼠标按键组合后，光标在任何特定上下文里都能在不呼出二级菜单的情况下直接触发 12 种完全不同的操作指令。此外，由于 Cedar 选用的系统字体虽然偏小但极具可读性，同屏信息密度非常高。开发人员可以毫无顾虑地在同一个视口中纵向并排平铺三到四个独立的程序代码模块，每个模块依然能展现出可观的代码行数。Eric Bier 现场演示了同时打开三个模块文件，通过极少的光标移动与指令触发，直接从模块 A 和模块 B 中撷取代码片段快速拼装写入目标模块；随后，他顺带切入对没有显式解说过的快捷定位命令（如 `OpenR` 与 `FindR`）的交互演示。 ### [26:53](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1613s) Release 目录检索与 Tioga 随处可用的编辑器特性 Eric Bier 首先展示了两个与 Cedar 发行版本（Release）相关的核心命令：`FindR` 与 `OpenR`。其中“Find”表示匹配某种模式并列出所有符合条件的文件，“Open”则是将文件打开以供查看或编辑，而后缀“R”则代表指示系统不要在当前目录查找，而是去 Cedar 系统自身的发布目录中检索，无论这些目录实际位于哪台文件服务器上。例如，Cedar 源码发行包中存在大量以 `.DF` 结尾的文件（DF 代表 Description File）。在终端中执行查找后，系统输出了文件在服务器上的具体映射路径：路径以 `cedar13.0` 开头，其下包含一个名为 `top` 的子目录，所有顶层 DF 文件都存放在那里。而配对命令 `OpenR` 则更进一步，一旦找到匹配文件就直接在 Tioga 文本编辑器中将其打开。按照 Cedar 的命名约定，每个软件包的文档均以 `doc` 结尾。Bier 输入 `OpenR Tioga.doc`，系统随即精准调出并打开了 Tioga 编辑器的用户手册。 ```mermaid flowchart TD accTitle: Cedar 发行版文件查找与打开流程 accDescr: 展示 FindR 与 OpenR 命令如何解析路径并在 Tioga 中打开文件 subgraph UserAction["用户输入命令"] A["FindR / OpenR [模式]"] end subgraph Resolution["Cedar 路径映射系统"] B["映射虚拟路径: cedar13.0/..."] C["定位远端文件服务器目录 (如 /top)"] end subgraph Display["执行结果与展现"] D["FindR: 终端列出匹配路径列表"] E["OpenR: 自动载入并在 Tioga 窗口中排版呈现"] end A --> B B --> C C --> D C --> E ``` 随后，Bier 将焦点转向 Tioga 自身的核心架构设计——Tioga 之所以对 Cedar 至关重要，关键在于它“无处不在”（everywhere）。在标准的 `.tioga` 文档窗口中，窗口顶部的信息栏兼顾了文件路径显示与各类操作按钮，极致节省屏幕空间；但更重要的是，Tioga 不仅存在于常规文档编辑窗口中，它同时也是整个操作系统的通用文本输入与编辑组件。例如在 Cedar 的控制台终端（Terminal）中，并不像现代操作系统那样只提供一个严重阉割、仅支持少数基础指令的简易行编辑器，而是完整内嵌了 Tioga。用户可以在终端内直接使用 Tioga 的 Shift-Select 跨窗口拖曳抓取文本，甚至能直接在命令行提示符处修改文本样式：Bier 随手将终端内的一串文字改成了粗体（Bold），证明这套富文本编辑环境是全系统通用的底层基础设施。 - Cedar 发行版文档命名规范：软件包的使用手册及技术说明文件统一以 `.doc` 结尾。 - 窗口头部双重复用：文档窗口顶栏既作为当前文件的路径标题栏，其下方同时紧凑排列了常用交互按钮。 - 全局一致的编辑模型：控制台与终端应用完全具备完整 Tioga 编辑器的全部能力，而非轻量级替代品。 --- ### [30:44](https://www.youtube.com/watch?v=z_dt7NG38V4&t=1844s) Edit Tool：基于样式检索、样式替换与级联样式表紧接着，Bier 演示了 Tioga 的主力配套工具——Edit Tool。在日常工作流中，屏幕上通常只需要常驻一个 Edit Tool 窗口，即可对当前激活或打开的任何文本窗口生效。除了基础的字符文本查找替换外，Edit Tool 最强大的特性在于它支持对“外观样式”（Looks）进行模式匹配和操作。尽管 Bier 笑着自嘲道“显然我已经太久没摆弄这个了”，但他很快重新调谐了参数：Edit Tool 不仅能够把匹配到的单词 `memos` 替换成另一个词，还能同时将其外观属性改为粗体。更令人惊叹的是无字文本匹配——用户可以完全不输入具体的字面内容，仅指定样式属性（如查找所有带有粗体属性 `b` 的文本），Edit Tool 便能在全文中高亮定位所有粗体字。系统还配备了基础撤销机制，使用经典的 `Shift + Escape` 快捷键可在多种 Cedar 应用中执行单级撤销（Undo）；若想放弃所有未保存修改，直接点击窗口顶部的 `Reset` 即可一键恢复到磁盘文件状态。 ```mermaid flowchart LR accTitle: Edit Tool 样式与内容替换处理流 accDescr: 展示 Edit Tool 如何支持字面内容、纯样式或两者结合的双重替换 subgraph Input["检索目标定义"] T1["字面文本匹配 (如 'memos')"] L1["外观样式匹配 (如 Look 'b')"] end subgraph Engine["Edit Tool 处理引擎"] M["模式匹配器 (Match Anywhere / Literally)"] end subgraph Action["执行替换操作"] R1["内容重写"] R2["样式重置 (字体/字重/格式)"] U["支持 Shift+Escape 撤销"] end T1 --> M L1 --> M M --> R1 M --> R2 R1 --> U R2 --> U ``` 深入剖析文档外观时，Bier 结合自己当年的一篇学术会议论文展示了 Tioga 对直接样式（Direct Looks）与结构化样式表（Style Sheets）的区别。论文中某处粗体文字的属性直接标记为字母 `b`（代表 Bold），表明是手动赋予的内联样式；而另一处标题文本虽然同样显示为粗体，其底层却完全没有应用粗体样式。Bier 指出： > “What's happening instead is that there are style sheets behind Tioga, they are even cascading style sheets...” Tioga 早在数十年前就引入了级联样式表机制。该段文字绑定的是名为 `CHI-2-column-reduced` 的排版样式（专为 ACM CHI 人机交互会议定制的两栏精简格式），段落属性被归类为一级标题（`head1`）。Tioga 在极早阶段就已经实现了现代字处理与网页排版中内容结构与呈现样式完全分离的思想。 - `Shift + Escape`：Cedar 多数组件通用的撤销快捷键，提供一步撤销保护。 - `Reset` 按钮：直接丢弃内存中未存盘的改动，安全重新加载磁盘原始副本。 - 样式系统：同时支持直接按字符打标签的“Looks”（如 `b` 代表 bold）以及基于规则的级联样式表（CSS 雏形）。 --- ### [35:03](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2103s) 动作宏、全系统选区驱动与三键光标选择模型在完成样式演示后，Bier 介绍了 Edit Tool 的宏（Macros）与重复操作能力。Tioga 能够自动追踪并记录用户在两次光标选区之间执行的所有微操作序列。例如选中一个对象、移动插入点、将后续字符设为斜体、输入标点和数字；在此之后，只要在文档任意其他位置选中另一个目标并按下 `Escape` 键，系统便会精准“重做”（Redo）方才的一整套编辑流水线。用户无需刻意开启复杂的宏录制模式，重复性修改即用即走。同时，Cedar 具备鲜明的“基于选区（Selection-driven）”交互哲学——“Some people liked it, some people didn't, was that a lot of the commands required that you make a text selection before you did them.” 例如从当前目录载入新文件时，用户只需在任何窗口中随意用鼠标选中一段文件名文字，再点击目标窗口的 `Get` 按钮，该文件便会立刻载入；点击 `Prev` 则能退回前一个文件。整套系统允许用户将屏幕上任何可见文本作为命令参数传递给任何应用。此时，现场同行（Nick Briggs / Chris Jacobi / Paul McJones）提议让 Bier 详细讲解 Cedar 独特的三键鼠标机制、插入点模型以及颠覆现代剪贴板的复制模型。Bier 极为认同，并直言正是这种惊人高效的操作流，让他甚至到了 1990 年代末期依然深扎在 Cedar 系统中不舍离去： > “In Cedar there is a more efficient method, and it's enough more efficient that I continue to use Cedar deep into the 1990s just so as not to have to give that up along with some other features, but that was a big one...” 现代操作系统的“复制-粘贴”流程繁琐笨拙：必须离开当前编辑位置 -> 前往目标区域选中文字 -> 按下复制键（Ctrl+C） -> 移回原工作位置重新定位插入点 -> 按下粘贴键（Ctrl+V）。而在 Cedar 中，用户的打字光标始终固定在当前输入位置不动；当意识到即将输入的内容已存在于屏幕某处时，只需按住键盘上的 `Shift` 键，并配合鼠标三键直接进行选区，松开后目标文本即被瞬间拉取复制到当前光标处： | 鼠标按键 / 动作 | 选取颗粒度（Granularity） | 说明与扩展机制 | |:--- |:--- |:--- | | **左键单击** (Left Click) | 单个字符 (Character) | 选取屏幕上光标下的任意独立字符。 | | **中键单击** (Middle Click) | 单词 (Word) | 选取光标所命中的完整词汇单元。 | | **右键单击** (Right Click) | 延伸选区 (Extend) | 保持当前颗粒度延伸选区（若前次选字符则按字符延伸，选词则按词延伸）。 | | **左键双击** (Double Click) | 语法节点 / 整行 (Node/Line) | 选取 Tioga 文本树中的单个节点，在代码文件中通常严格对应一行代码。 | | **中键双击** (Double Middle Click) | 语法子树 / 整个分支 (Tree/Branch) | 选取该节点及其下嵌套的所有下级代码块（包含整个方法、子例程或函数体）。 | | **右键延伸（双击后）** | 节点或子树级别延伸 | 以整行或整块子树为单位批量选取，便于快速搬迁、重构大段程序逻辑。 | 通过将结构化语法树（Node 与 Tree）直接映射至鼠标底层点击语义，程序员在 Cedar 中重构、挪动多个函数或方法时，无需逐行拖曳高亮，仅需几次中键与右键点击即可精准框定整个语法树结构。这套深度契合语言抽象的交互范式，展现了施乐 PARC 对人机交互与编程环境融合的极深造诣。 ### [42:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2554s) Shift 键快速复制与 Cedar 界面的正交性设计 Eric Bier 演示了在 Cedar 中利用修饰键进行高效文本操作的技巧。在标准选择模式下，用户拥有左键、中键、右键以及双击等各种选择指令；而一旦按住 Shift 键，这些按键组合就会全部切换到复制上下文。例如，按住 Shift 键并在某处双击左键，就能立刻将文件其他位置整行代码抓取并粘贴到光标所在处。更强大的是，光标会自动留在就绪位置，允许用户继续从文件各个区域连续抓取行。这种机制省去了现代编辑器中繁琐的“选中、移动、点击复制、移回、点击粘贴”流程，变成了流畅连贯的“Shift 点击、Shift 点击、Shift 点击”，能以极快速度在文件中搬运重构代码。 ```mermaid flowchart LR accTitle: Cedar Shift-click Copy Workflow accDescr: 传统复制粘贴流程与 Cedar Shift 键单步抓取流程的对比 subgraph Traditional["现代传统流程"] A["移动到源文本"] --> B["选中并复制"] B --> C["移动回目标位置"] C --> D["点击粘贴"] end subgraph Cedar["Cedar 快速模式"] E["光标保持在插入点"] --> F["按住 Shift 键并在源处点击"] F --> G["文本瞬间拉入当前位置"] end ``` 随后，Chris Jacobi 插话强调了 Cedar 界面深层设计的精妙之处——正交性（orthogonality）。他指出，某种鼠标、键盘和双击的交互组合只要在一个地方有效，在其他任何地方都以完全一致的逻辑运作。Chris Jacobi 由衷感慨：“If anybody wondered how that Eric after having 16 years not use Cedar still is able to demonstrate the key clicks, then you see how clever the user interface is done so that there is a small number of facts to remember.”（如果有人好奇 Eric 为何在整整 16 年没用过 Cedar 的情况下，仍能熟练演示这些按键操作，你就能看出这个用户界面的设计是多么高明，需要记忆的规则微乎其微。）Chris 补充说，自己即便已有 18 年未碰 Cedar，日常在现代 PC 上工作时依然会下意识按出 Cedar 的快捷键，导致那些完全无法理解该指令的现代工具频频报错。 - **快速复制机制**：光标停留在目标位置，按住 Shift 键在源文本上点击或双击，即可瞬间吸取字符、单词或整行。 - **正交性设计**：鼠标与键盘命令的语法高度统一，只需极少的心智负担即可在全系统中举一反三。 --- ### [44:51](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2691s) “Tioga 无处不在”与强大的视窗分割功能 Chris Jacobi 进一步阐释了“Tioga 编辑器无处不在”的具体含义，并举了一个极具戏剧性的例子：如果用户的程序运行时报错并输出了错误信息，用户竟然可以直接使用标准的 Tioga 编辑指令去就地修改那条错误信息。在 Cedar 体系中，只要屏幕上出现文本的地方，底层就是 Tioga。Chris 幽默地提到了唯一的例外：“I think I know one exception: if in a chip design you have some metal with the pattern of letters, that doesn't work with Tioga commands.”（我想我能想到一个例外：如果是在芯片设计中，金属布线层排成了字母形状，那是无法用 Tioga 命令编辑的。）回到演示界面，Eric 展示了窗口顶部的各种高阶控制按钮，特别是极其超前的“Split（分割）”功能。这一现代程序员视作标配的特性在当时的 Cedar 中已非常成熟，它允许用户在不同滚动进度下同时查看同一个文件的多个位置。比如开发者可以一边看着文件顶部，一边开出新分割视窗定位到底部的 `copy circle` 过程，轻松将其整段挪动；而且 Split 允许无限次切分。此外，系统还包含“Normalize”功能，可将选中的文本直接提拉至屏幕近顶端并保留上下文边距，并具备选中历史记忆、激光打印预览字体切换（Style Kind）等专业工具。 - **泛在编辑**：系统运行报错日志、控制台乃至各类图形控件内的文本均挂载完整的 Tioga 编辑内核。 - **Split 多重视窗**：支持对单文件进行任意次数的视窗分割与并行滚动比对。 - **视窗定位与预览**：`Normalize` 命令可快速对齐视野；`Style Kind` 按钮可一键在屏幕点阵字体与高精度激光打印机轮廓字体间切换视图。 --- ### [47:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=2874s) 文件的底层二分结构与显式格式化机制 Eric 详细揭示了 Tioga 能同时胜任专业排版出版与日常软件开发的核心秘密：文档底层存储的二分法设计。在底层实现中，Tioga 文件在逻辑上被一个空字符（Null Character，`\0`）划分为两个独立部分。前半部分纯粹是文件的普通文本字符；在空字符之后，则存放着一系列二进制附加数据，专门记录诸如字体样式、粗体、斜体、版式控制甚至是内嵌插图的定位信息。最惊人的是，Cedar/Mesa 代码中的注释并不会被编译器解析，因为这些注释同样被置于空字符之后的区域，编译器在读取源文件时遇到空字符便会直接截断停止。 ```mermaid flowchart TD accTitle: Tioga Document Binary Structure accDescr: Tioga 文档由 Null 字符分割的文本段与元数据段结构 subgraph FileStructure["Tioga 文件底层存储结构"] direction TB TextPart["文本数据区（Text Content） 代码正文、纯 ASCII 内容"] NullByte["空字符分隔符（Null Character '\0'） 编译器在此处终止读取"] MetaPart["扩展元数据区（Metadata & Comments） 排版样式、加粗斜体信息、注释文本、内嵌矢量图"] TextPart --> NullByte --> MetaPart end ``` 现代 IDE 的语法高亮通常是编辑器根据语言语法树在运行时动态生成的（On-the-fly），而 Cedar 完全不同，它是显式地将外观样式（Looks）附加到字符属性上。Eric 载入了一个微型的 `HelloWorld` 示例进行证明： - 文件顶部的斜体字是系统的注释，编译器完全不可见； - 全大写的关键词会以美观的小型大写字母（Small Caps）渲染； - 过程名称自动加粗。为了证明这一点，Eric 打开编辑工具执行“清除所有样式”（Clear Looks），并取消注释标记，代码瞬间还原成一段扁平无格式的纯文本。随后，他按下 `Ctrl + \` 快捷键，文本立刻重新被推入空字符之后成为注释；按下 `Ctrl + M`，标准的 Cedar/Mesa 语法排版外观便重新批量应用到了整篇代码中。 --- ### [51:28](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3088s) 数学希腊字符支持与代码内嵌矢量插图利用 Tioga 这种显式样式机制，开发者可以在代码中享受极具数学美感的书写方式。Eric 演示了线性插值计算的写法：当需要输入公式 `(1 - α) * x0 + α * x1` 时，开发者只需先键入字母 `a`，然后按住 Looks 键并按下字母 `G`（代表 Greek），字母 `a` 瞬间就会被渲染为希腊字母 `α`。不过 Eric 也提醒道，由于编译器底层看到的仍然是空字符前方的 ASCII 字符 `a`，“I do have to remember that that's really an 'a' behind there because the compiler isn't going to see the Greek looks on that, so I can't have another variable named 'a' in the same method as that alpha.”（我必须牢记它的本质仍然是 a，因为编译器看不到上面的希腊外观修饰，所以不能在同一个方法中另外定义一个名为 a 的变量。） ```mermaid flowchart LR accTitle: Greek Look Transformation Flow accDescr: 字符 a 添加希腊样式前后在界面与编译器视角的差异 Input["键盘键入 'a'"] --> LookKey["组合键：Looks + G"] LookKey --> Display["屏幕呈现：希腊字母 'α'"] LookKey --> Storage["底层存储：文本区为 'a'，元数据区记录 Greek Look"] Storage --> Compiler["编译器视角：识别为变量 'a'"] ``` 紧接着，Eric 展示了他在加州大学伯克利分校攻读博士学位期间开发的 Gargoyle 矢量绘图系统源代码（`GG circles in pole Mesa` 模块）。在涉及复杂的直线、圆弧与圆相交几何计算时，Tioga 允许在代码中直接嵌入带标注的矢量插图。在 `circle meet circle` 算法上方，赫然嵌入了一张包含两圆几何相交关系、并清晰标有算法对应变量名的插图，使原本晦涩的几何算法意图一目了然。 - **希腊数学字符**：通过 `Looks + G` 将英文字符赋予希腊外观，让公式贴近数学书写习惯。 - **代码中嵌图**：打破代码仅限纯字符的界限，直接在过程实现旁并列展示算法几何图解。 --- ### [54:18](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3258s) 接口与实现解耦的模块化体系架构 Eric 进一步剖析了 Cedar/Mesa 极其卓越的软件复用性设计。在 Cedar 环境中，任何提供给外部调用的函数库都必须强制定义一个独立的接口文件（Interface，即 Cedar Definitions）。在展示的圆几何接口模块中，所有过程仅声明 API 参数与返回值规范（例如输入一个点和一个实数半径，返回一个 `Circle` 类型的对象），绝对不包含任何具体实现代码。这种设计带来了巨大的工程灵活性： 1. **接口与实现完全分离**：具体逻辑一律放在后缀通常为 `impl` 的独立程序模块中； 2. **一对多拆分**：一个接口可以被拆解由多个实现模块共同实现，避免单个源代码文件过大膨胀； 3. **多态与多版本替换**：同一个接口可以并存多种不同的实现版本（例如生产实现与实验性测试实现），最终打包构建运行时可按需链接； 4. **编辑器级无缝联调**：Tioga 工具栏内置了对语言语义的支持，Eric 选中接口中的文本并点击“Get Info”按钮，视窗几乎在一瞬间自动索引并跳转打开了对应的实现源文件，直观展现了该模块对接口定义的导出与引用。 > “One of the reasons why software reuse worked so well in the Cedar environment was that anytime you wrote some library of routines that were going to be called by another module, you had to define an interface saying what the API was, what the definitions were for the various procedures that were going to be available in the library.” > —— Eric Bier 强调接口与实现解耦是 Cedar 软件复用机制极其高效的核心根基。 ### [57:07](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3427s) 从 Tioga 跳转定义到切换至 Gargoyle 图形编辑器 Eric Bier 首先向大家演示了 Tioga 编辑器内置的代码导航功能。他提到，如果在编辑器顶部的菜单中使用类似“Defs”这样的按钮，就能够直接跳转到某个符号的具体定义处。他边说边操作：“让我们看看行不行，我先选中这个，然后点击 Defs——瞧，我们立刻就跳到了拥有该特定名称的过程定义处。”这些功能全部直接内嵌在 Tioga 顶部的菜单中，开发者在编写代码时随时可以调用。随后，Bier 决定转换话题，切换到一个截然不同的应用程序上。他先将当前窗口临时关闭（因为稍后还会用到），接着启动了名为 Gargoyle 的图形工具，并将其拖动到屏幕左侧的列中，清理掉上面原本残留的旧对象。Bier 解释说，大家眼前的 Gargoyle 是一个矢量绘图与插画工具，它内置了多种基础图形供用户调用，比如正方形、圆形和三角形。 --- ### [58:07](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3487s) Gargoyle 与“Snap-Dragging”尺规绘图技术 Bier 充满热情地指出，Gargoyle 真正令人兴奋的地方不在于这些预设的基础图形，而在于它让用户构建自定义几何对象的方式。该系统内置了一项名为“Snap-Dragging”（对齐拖拽）的技术，其核心哲学源自传统几何学中的尺规作图（ruler and compass construction）。Bier 笑着对比道，传统的尺规作图繁琐至极，而 Snap-Dragging “有点像是尺规作图的方法，但完全没有你在高中记忆中尺规作图的那种枯燥乏味，因为这个系统会自动为你生成所有的辅助线”。屏幕顶部陈列着一系列绘图操作菜单。Bier 特别说明，这些菜单本身就是直接用 Gargoyle 编辑器绘制出来的，背后采用了被称为“文档即用户界面”（Documents as User Interfaces）的设计思想。在辅助线生成方面，由于开启了自动模式（automatic mode），系统会在用户下笔时智能推算并投射辅助线。例如，Bier 演示了如何徒手绘制一个底边水平、边长恰好为 1 英寸的等边三角形：光标一旦移动，参考线瞬间吸附锁定，眨眼间一个规整的等边三角形便绘制完成。紧接着，他尝试调用变换命令演示拖拽、旋转与缩放功能，在菜单间稍作摸索和确认后，成功调出了缩放操作。 --- ### [01:01:03](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3663s) 绘制斜体“G”与三键鼠标选择机制为了进一步展现精确绘图的威力，Bier 演示了如何绘制一个具有斜体风格的字母“G”。他在系统中设定了两组关键辅助线角度：一组是代表水平方向的 0 度，另一组是略微向右倾斜的 60 度。两条辅助线确立后，他在画布上迅速勾勒出字母的大致外形轮廓，并移除了多余的参考辅助圆。在对局部线条进行微调时，Bier 强调 Gargoyle 沿用了许多与 Tioga 文本编辑器完全相同的鼠标交互哲学，深度挖掘了三键鼠标的潜力： - **中键单击**：选中整条几何线段（类似于在 Tioga 中单击中键选中整个单词）。 - **右键单击**：将当前选区扩展至相邻的线段，从而连续选中多个轮廓线段。选定特定线段后，Bier 执行拖拽操作，仅对被选中的局部边缘进行位移调整。此时如果将光标先行定位，系统还会自动沿着先前设定的辅助线吸附移动，确保结构比例分毫不差。随后，Bier 将绘制完成的“G”填涂为紫色，并等比例缩小到适合版面的尺寸。 --- ### [01:03:10](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3790s) 嵌入 Tioga 文档与基于鼠标按键的快捷菜单系统完成图形绘制后，Bier 展示了如何将图形直接插入到 Tioga 文档中——无论这份文档是源代码文件还是一篇学术会议论文。他先在右侧的目标文档中放好光标，接着回到 Gargoyle 窗口打开“Interpress”菜单，准备执行“Stuff to Tioga”（填塞至 Tioga）命令。弹出的上下文菜单展现了 Cedar 极具特色的人机交互细节：菜单项并未排成单列，而是严整地分成了左、中、右三列。Bier 细致拆解了这套操作逻辑： - **按键映射列**：点击菜单项时，左列命令对应左键单击触发，中列对应中键，右列对应右键。 - **修饰键组合**：配合键盘上的 `Shift` 或 `Control` 键，前 12 个核心命令均拥有完全无需展开菜单的盲操加速快捷键（Accelerator）。 - **扩展命令**：该菜单包含超过 12 项操作，超出部分可通过直接呼出菜单选取。 ```mermaid flowchart TD accTitle: Gargoyle 菜单加速快捷键体系 accDescr: 展示三键鼠标结合 Shift 与 Control 键触发命令的加速逻辑 subgraph Modifiers["键盘修饰键状态"] None["无修饰键"] WithShift["按住 Shift 键"] WithCtrl["按住 Control 键"] end subgraph MouseButtons["三键鼠标列映射"] Left["左键 (左列命令)"] Middle["中键 (中列命令)"] Right["右键 (右列命令)"] end subgraph Action["目标命令示例"] Stuff["Stuff to Tioga"] end None --> Middle Middle --> Stuff ``` 以“Stuff to Tioga”为例，其对应的快捷键规则是“无 Shift、无 Control、直接中键单击”。Bier 切换到 Tioga 窗口中双击建立节点级选区，随后触发该操作，刚刚绘制的紫色斜体“G”立刻完美无缝地嵌入到了 Tioga 文本节点中。Bier 感慨道，从在绘图软件中绘制矢量图到将其直接引入文档，整个过程极为顺畅迅速。 --- ### [01:04:57](https://www.youtube.com/watch?v=z_dt7NG38V4&t=3897s) “文档即用户界面”概念与带按钮的命令行目录（ButtonLS） Bier 进一步深化了对“文档即用户界面”（Documents as User Interfaces）设计哲学的探讨。在 Gargoyle 中，无论是文本标签还是几何矢量图元，底层都可以附加一段描述其交互行为的脚本或元数据，使其在被点击时表现出按钮一般的控件功能。例如系统内置的字体调整浮动菜单，熟练的用户知道按住 `Control` 键并点击特定按钮就能快速将文本加粗。Bier 当场输入了一段文字，选中文本后按住 `Control` 键右键单击，瞬间将字体切换成了最大号的粗体字：“你使用 Gargoyle 的时间越长，凭借这套菜单的工作机制，你完成这类操作的速度就会越快。” 这项技术不仅局限于矢量图，在任何承载 Tioga 的地方都能生效，包括命令行终端。Bier 呼出了一个 Commander 控制台窗口（其本身即为一个 Tioga 实例），并运行了一个名为 `buttonLS` 的自研命令。该命令具备类似 Unix `ls` 的目录列举功能，但在输出的文件名前方，额外插入了一个小矩形方块。这个方块正是拥有按钮行为的 Tioga 对象——用户只需拿鼠标轻轻一点方块，对应的文件便会立刻在编辑器中打开，实现了命令行与图形化交互的浑然一体。 --- ### [01:07:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4054s) Cedar 的版本控制与包管理：DF 文件、BringOver 与 SModel 随后，Bier 将话题转向了支撑 Cedar 团队高生产力的另一大基石：系统建模与包版本管理工具。Bier 梳理了现代版本控制系统的演进：“当然，现如今有各种各样的软件版本管理工具，经历了一整套发展序列对吧，比如现在非常流行的 Git，过去还有 CVS、Subversion 等等；Cedar 也有自己的版本，而且相当易用。” 在 Cedar 体系中，每个软件模块或组件包都通过一个名为 `.DF`（Description File）的文件来进行描述。Bier 打开了自己为演示编写的 `hello.DF` 进行逐行解析： - **元数据头部**：自动记录文件作者（当前显示为 `EBSU`，即 Eric Bier Super User 的缩写）以及目标存放目录（如 `Cedar 13.0` 顶层目录）。 - **SModel 命令**：相当于现代 Git 体系中的 `commit` 或 `push`。“S 代表 System，也就是你通过将系统模型发送至文件服务器来对其进行建模”。 - **文件清单**：列出属于该包的实现文件（如 `HelloWorld.mesa`）。 - **导入依赖（Imports）**：明确声明该包依赖的底层库，包括 `Atom`、`Basics`、终端命令接入库 `Commander`、底层 I/O，以及 Cedar 特有的字符串库 `Ropes`（Bier 补充道：“那是 Cedar 提供的不可变字符串”）。 ```mermaid flowchart LR accTitle: DF 文件解析与 BringOver 依赖同步机制 accDescr: 展示 DF 文件通过递归解析获取主文件及上游依赖的过程 DF["hello.DF 文件"] BO["BringOver 命令"] LocalDir["本地工作目录"] subgraph DirectPackage["本包文件"] HelloImpl["HelloWorld 实现文件"] end subgraph RemotePackages["外部依赖包 (DF 递归解析)"] Atom["Atom.df"] Basics["Basics.df"] Cmdr["Commander.df"] Ropes["Ropes.df (不可变字符串)"] end DF --> BO BO -->|"下载并复制"| HelloImpl BO -->|"根据 USING 子句按需拉取"| RemotePackages HelloImpl --> LocalDir RemotePackages --> LocalDir ``` 当执行 `BringOver`（提取拉取）命令时，系统首先读取指定的 `.DF` 文件，从远端目录下载核心代码副本，随后递归解析其引用的所有下游 DF 文件。为了避免把依赖包的内容全盘无脑拖回本地，DF 文件提供了 `USING` 子句，精确圈定本地编译所必需的特定接口模块。此外，行尾的语法（如 `~=` 等）还允许开发者灵活指定依赖版本策略：是无条件拉取最新版、锁定特定日期的版本，抑或仅在远端版本更新时才覆盖本地。为了实操检验这套机制，Bier 尝试在本地建立一个名为 `gargoyle` 的 Cedar 13 开发目录，并通过 `FindR` 命寻找 Gargoyle 相关的 DF 文件，准备用 `BringOver` 演示一次完整的项目依赖拉取全过程。 ### [01:11:34](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4294s) DF 文件机制、文件获取与 HelloWorld 编译运行 Eric Bier 继续演示 DF 文件（Description File）的自动化处理机制。在修正了一个命令行的输入错误后，DF 机制开始递归解析 Gargoyle 所需的所有依赖文件，一口气从远程服务器同步并复制了 366 个文件到本地工作区。通过在控制台输入列目录命令（`button LS`），可以看到所有项目组件均已就绪。Eric 随后打开了 `GGCircles.mesa` 及其实现模块 `GGCirclesImpl.mesa` 的本地副本，展示了系统已具备直接编辑修改代码的环境。 ```mermaid flowchart TD accTitle: DF 文件自动化抓取与编译运行流程 accDescr: 描述 Cedar 环境中通过 DF 文件递归拉取依赖、本地编辑、编译与 Commander 注册的完整闭环。 subgraph DependencyFetch["依赖与文件获取"] A["执行 DF 解析命令"] --> B["分析 Gargoyle.df 依赖树"] B --> C["递归拉取 366 个依赖文件至本地"] end subgraph EditAndBuild["代码修改与构建"] C --> D["打开 HelloWorld.mesa / Impl"] D --> E["修改文本并保存 (追加时间戳)"] E --> F["触发单个模块编译 (Compile)"] end subgraph RuntimeExec["运行与命令注册"] F --> G["运行编译后的模块"] G --> H["向 Commander 注册 hello 命令"] H --> I["终端执行 hello 输出运行结果"] end ``` 为了让大家直观了解 Cedar 中的编译与运行流程，Eric 转到一段小型的 `HelloWorld` 示例程序中进行演示。他将代码中的打印信息从“Hello World on January 24, 2019”追加上具体时间（10:30 a.m.），保存文件后发起编译命令。在尝试对整包发起统一构建机制（如 `make`）未果后，他针对单个实现模块（`hello world imple`）执行了编译，随后执行该模块。该模块运行后在系统的命令调度器（Commander）中注册了一个名为 `hello` 的全局命令；Eric 在控制台输入 `hello`，控制台便准确输出了刚才更新的代码逻辑。 - DF 文件机制会自动遍历完整的依赖树，并在本地建立完整且受控的代码工作副本。 - 模块运行并不只是生成一个独立的执行程序，而是可以直接向 Commander 注册新的系统交互指令。 --- ### [01:15:02](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4502s) Chris Jacobi 论“免链接”与 Tioga 统一编辑器的设计哲学 Chris Jacobi 补充指出了 DF 文件带来的另一项巨大便利：在传统开发环境中，开发者必须与极其繁重的链接器（Linker）机制打交道，而“在某些操作系统里，链接器的文档往往有几十甚至上百页”，但在刚才的演示中，Eric 完全没有执行任何显式的链接步骤。Chris 强调：“无论链接逻辑多么复杂，系统都会直接从那份简单的 DF 文件中自动解析出来，用户根本不需要操心如何链接。” 随后，现场讨论转向了 Cedar 的核心设计亮点：Tioga 既充当代码编辑器，又担当文档排版工具。被问及这一架构背后的动机时，Eric Bier 阐述了“在所有场景下保持一致的文本编辑交互”所带来的深远优势：无论是修改一行表单数据、编写数万行代码，还是撰写一篇排版考究的学术论文，所有的击键肌肉记忆（快捷键、三键鼠标操作、格式刷、选区操作等）完全通用。这使得工程师可以毫不费力地在学术论文和源代码之间双向复制代码片段、甚至是内嵌图形。如果研究员需要让行政助理协助排版论文，也可以毫无认知障碍地直接指导。 Chris Jacobi 进一步展开了这个哲学的核心逻辑。他指出，在 Cedar 设计的年代，外部世界充斥着割裂的工具，但 Cedar 的选择其实是最自然的：既然开发需要程序编辑器，而且系统已经拥有一个极具表现力的文本编辑器，那何必重复发明轮子？Chris 总结道：“如果非要在当时进行争辩或解释，你需要论证的反而是——你为什么*不想*用这种方式来做。” --- ### [01:18:54](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4734s) 待决删除（Pending Delete）、选区移动与 NLS 思想源流 Eric Bier 回到具体交互细节，解释了 Tioga 中的待决删除（Pending Delete）和快捷文本移动操作。在 Tioga 中，当用户用鼠标跨词框选一段文本后，文字会立即反白显示（Video Reverse）。这种反白状态明确向用户提示当前的待决状态：一旦此时键入任何新字符，被选中的旧内容将立即被新输入的文字覆盖。此外，配合左手的修饰键，鼠标选择可以产生丰富的操作： - 单独按住 `Shift` 并进行选区：将选中内容直接**复制**（Copy）到当前光标插入点。 - 同时按住 `Ctrl` 和 `Shift` 并进行选区：将选中内容从原位置删除并**移动**（Move）至当前插入点。 Paul McJones 对 Cedar 展现出的集成度深表赞叹，并追溯了其思想渊源。他指出 Tioga 依据缩进隐藏或展开代码细节的“裁剪层级”（Clipping Level）功能，其源头可以直接追溯到 Doug Engelbart 的 NLS（oN-Line System）系统；事实上，曾参与 NLS 项目的 Bill Paxton 正是 Tioga 的主要作者之一（Doug Wyatt 也参与了开发）。 Paul 回顾了 1970 年代中期施乐 PARC 的技术演进：当时 Alto 计算机内存非常有限，每个程序几乎都要独占整台机器，代码编写只能使用功能简陋的小编辑器，而写文档则要切换到专门的排版工具；虽然 Alto 上已经孕育了左侧滚动条、选区高亮以及 Smalltalk 倡导的“通用单组件工具”概念，但直到 Cedar 问世，配合 1 兆字节（1 MB）大内存的强大硬件平台，才真正将 NLS 的层级思想、Smalltalk 的高集成度以及现代矢量图形系统彻底熔铸在一起。 Eric 接着现场演示了代码缩进层级的控制：在长达数页、嵌套极深的复杂代码程序中，开发者可以通过鼠标多级点击调整视图层级，将代码逐层折叠成高层结构大纲，从而在阅读时有效控制软件的认知复杂度。 --- ### [01:23:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=4995s) Tioga 的所见即所得性质与 Interpress 文件查看现场有人提出疑问：当 Tioga 切换至显示打印字体时，它是否属于真正的完全“所见即所得”（WYSIWYG）？ Eric Bier 坦率表示，Tioga 并非绝对意义上的 WYSIWYG。他重新打开了此前展示的双栏排版学术论文（关于 Toolglass 与 Magic Lenses 的研究论文）并切至打印视图模式：在编辑器中，虽然字体和排版样式已经逼近真实印品，但它依然是以连续的单栏逻辑流展示，并不会在编辑窗口内直接切分为双栏排版；真正的双栏版面布局，只有在转换生成为 Interpress 打印描述格式或直接发送给打印机渲染时才会呈现。 Chris Jacobi 补充解释了当时的技术限制：在 Cedar 早期，平滑字体（Smooth/Outline Fonts）技术在当时尚未普及甚至属于保密技术，系统普遍依赖点阵字体（Bitmap Fonts）。由于当时的屏幕显示分辨率根本无法匹配高精度的物理打印机分辨率，屏幕显示渲染与最终纸质打印使用的字模必然存在轻微差异；但随着 Cedar 后续版本的演进，这种屏幕与打印之间的鸿沟被逐步弥合。随后，Eric 尝试在 Cedar 13 环境下直接调用内置查看器（如 IP Viewer 或 `IPRegister`）打开本地保存的 `.ip`（Interpress）文件。虽然对具体查看器命令的名称有些生疏，但目录中留存的大量 Interpress 归档文件证明，在当时的研究流程中，将 Tioga 文档编译为 Interpress 格式并在打印前进行软校对或直接发送给施乐网络激光打印机，是 PARC 研究员日常工作的核心标准环节。 ### [01:26:32](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5192s) 文档打印预览与字体排版差异演示现场讨论了 Cedar 环境下打印输出与屏幕显示的差异。当时虽然可以在显示器上查看准备打印的文件，但由于字体映射与渲染的限制，字符显示效果略显怪异。因此用户并不会直接去编辑这类针对打印机生成的文件，而是始终编辑 Tioga 原生格式的文件。此外，Tioga 文本的自动折行取决于当前窗口的宽度，而实际发送到打印机排版时，列宽调整机制完全不同，这种微小的视觉差异在屏幕上常常难以完全对应。现场随后尝试启动名为 `Preview` 的预览包。启动时稍微遇到了一点字体缺失的小插曲，但随后成功在窗口中调出了排版预览，正在逐页翻看一篇会议论文。在默认缩放下字号极小难以辨识，但通过 Cedar Imager 的缩放功能放大后，能够清晰看到高质量的轮廓字体（full outlines），这与最终发送到激光打印机上的效果完全一致。 - Tioga 文件的屏幕自动换行依据视口尺寸动态调整，而打印输出采用独立的分栏与页面布局规则。 - `Preview` 工具基于轮廓字体实现分辨率无关的渲染与缩放显示。 --- ### [01:27:21](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5241s) 面向专家的多键界面与 Cedar 文档文化现场有人提出疑问：Cedar 的用户界面高度一致且经过深思熟虑，但因为它深度依赖三键鼠标的多键组合与操作，看起来非常偏向“高阶用户”（power users）。这种设计对新手来说学习门槛有多高？各类命令是否容易被发现？ Eric Bier 解释道，在 PARC 内部，Cedar 绝非仅供顶尖计算机科学家使用，行政助理和专职美工都会在日常工作中使用它，并且能够迅速上手。这得益于 Cedar 极具规范的工程文化： 1. **统一文档规范**：每个软件包（package）都必须附带格式清晰、命名规范的文档文件，用户极易检索。 2. **严格的发布流程**：每当开发者更新一个包，必须遵循固定的协作约定——使用 `SModel` 保存新版本，并在通过电子邮件发布更新通告时采用标准模板，详尽记录所修改的包名以及所有具体变更点。 3. **文档与代码同步**：只要代码变动涉及功能调整，更新对应文档是硬性约定。 Chris Jacobi 随后补充了关于“易用性”的独到见解。他指出很多功能听起来难，是因为开发者在向别人解释或炫耀时往往过度阐述了背后的复杂设计原理；但当用户真正坐到机器前，肌肉记忆和一致的操作逻辑会让一切变得极其自然： > “When you actually sit on the machine and you are not thinking, you just use your fingers to do the fingering for you, then you will see the logic behind it.” —— Chris Jacobi 很多命令完全可以凭借 Cedar 的核心设计理念直接盲猜出来，“事实证明它就是那样工作的”。不过 Jacobi 也指出，虽然命令设计尽可能沿用 Tioga 的范式，但领域工具依然有其专有命令——比如行政助理可以轻松撰写文档，但不会去写 Tioga 宏程序，也不会去使用芯片设计编辑器；在集成电路版图编辑器中，为了效率，画金属线就按 `M`，放晶体管就按 `T`。 --- ### [01:31:55](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5515s) Gargoyle 图形编辑器的诞生与对齐技术在被问及作为核心开发者参与 Gargoyle 项目的渊源时，Eric Bier 详细回顾了这一工作。Gargoyle 是一款交互式矢量插画工具，其核心灵感与算法源于他在加州大学伯克利分校（UC Berkeley）的博士论文研究，并在 1986 年的 ACM SIGGRAPH 会议上发表了论文。 Bier 在博士期间重点研究的是名为“Snapdragon”的交互几何对齐技术，他将其形象地形容为“打了类固醇的尺规作图”（ruler and compass on steroids）。同时，PARC 有着极其深厚的“吃自己的狗粮”（dogfooding）传统，大家不仅为了写论文做系统，更乐于打造能让周围所有人每天使用的实际工具。在 Cedar 社区中，随着大家对在文档中插入插图的需求日益增长，Bier 联手 Ken Pier 展开了 Gargoyle 的研发，Maureen Stone 等人也参与了协助。 ```mermaid flowchart TD accTitle: Gargoyle 架构与技术栈 accDescr: 展示 Gargoyle 从底层渲染库到交互技术再到终端用户应用的各层架构关系。 subgraph CoreEngine["底层图形库 (Cedar Imager)"] A["Michael Plass 开发的 Cedar Imager"] B["多边形、样条曲线 (Splines) 与裁剪"] C["分辨率无关图形渲染"] A --> B A --> C end subgraph Technique["交互与几何算法 (UC Berkeley 博士研究)"] D["Snapdragon 技术: 尺规交互与对齐扩展"] E["视线投影光线对齐 (2D 到 3D 泛化)"] end subgraph Application["终端工具与用户群体"] F["Gargoyle (2D 插画系统)"] G["Gargoyle 3D (三维几何建模)"] H["PARC 美工人员 (如 Steve Wahlgren)"] I["制作手册、海报、PARC Forum 宣传品"] end CoreEngine --> F Technique --> F Technique --> G F --> H H --> I ``` Gargoyle 的底层依托于 Michael Plass 构建的 Cedar Imager 图形库，该库原生支持复杂多边形、样条曲线（splines）、几何裁剪以及分辨率无关的渲染能力，这确保了屏幕交互所见即打印所得。系统推出后，PARC 的专职美工 Steve Wahlgren 迅速将其作为主力工具，制作了大量的机构手册以及 PARC Forum 的学术讲座海报。 Bier 的博士课题随后进一步拓展到了三维领域，诞生了 Gargoyle 3D。在此项研究中，令人惊喜的是，用于二维精确作图的键盘鼠标交互范式可以直接复用到三维空间：用户不需要专门的三维定位鼠标，而是从视点穿过屏幕二维光标向三维空间投射一条视线光线（ray），该光线能够直接吸附到三维导线、三维对齐平面或球体表面（三维版本的圆规构建）。在当时，Bier 每周都会录制一盘演示录像带，开车穿过海湾大桥送往伯克利 Evans Hall，向他的博士导师 Carlo Séquin（当时 Séquin 与 Brian Barsky 在伯克利共同组建了充满生机的计算机图形学实验室）汇报研究进展。 - 关键人物：Eric Bier、Ken Pier、Maureen Stone、Michael Plass（Cedar Imager 开发者）、Steve Wahlgren（PARC 驻场美工）、Carlo Séquin（博士导师）、Brian Barsky。 - 关键论文与发表：1986 年 ACM SIGGRAPH 会议。 --- ### [01:37:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=5821s) Cedar 语言特性：多返回值与强类型区间约束随后应现场要求，Eric Bier 重新打开 `GGCircleSimple` 模块的代码，深入演示 Cedar 语言的高级语言特性，重点解析了 Cedar 的过程定义与类型系统。以计算两圆相交的例程 `CircleMeetCircle` 为例：该函数判断两个圆是否相交，交点可能为 0 个（同心或远离）、1 个（相切）或 2 个（相交）。在大多数传统编程语言中，函数通常只能返回单个值或指针对象，但 Cedar 原生支持多返回值： ```cedar CircleMeetCircle: PROC [circle1, circle2: Circle] RETURNS [points: ARRAY [1..2] OF Point, count: [0..2], tangent: BOOLEAN] ``` ```mermaid flowchart LR accTitle: Cedar 过程调用与多返回值签名 accDescr: 展示 CircleMeetCircle 接收两个输入圆，并一次性解构返回三个独立变量的流程。 subgraph Inputs["输入参数"] C1["circle1: Circle"] C2["circle2: Circle"] end subgraph Proc["例程执行: CircleMeetCircle"] Logic["相交几何判定"] end subgraph Outputs["命名多返回值 (自动成为局部变量)"] R1["points: ARRAY [1..2] OF Point"] R2["count: [0..2]"] R3["tangent: BOOLEAN"] end Inputs --> Proc Proc --> R1 Proc --> R2 Proc --> R3 ``` Bier 指出了该语言设计中的若干独特细节： 1. **命名返回值即局部变量**：在 `RETURNS` 子句中为返回值命名的瞬间（如 `points`、`count`、`tangent`），系统自动在函数体内创建了同名的局部变量，后续代码可以直接对其赋值（例如使用 Tioga 搜索到的 `points[1] ←...`），无需在函数末尾显式打包构建对象。 2. **自定义数组下标范围**：Cedar 允许明确指定数组下标的上下界。此处数组声明为 `[1..2]`，表明数组包含两个元素且索引从 1 开始计数，打破了常规语言强制从 0 开始的惯例。 3. **显式取值区间约束类型（Subrange Types）**：常规语言通常将相交次数声明为通用 `INTEGER`，而 Cedar 允许直接将类型约束为子区间 `[0..2]`。编译器能够在类型检查阶段强制保证数值在 0 到 2 之间，赋予了类型系统极高的表达力与安全性。 4. **赋值操作符**：Cedar 使用左箭头（`←`）作为赋值符号，而非现代语言中常见的等号（`=`）或冒号等号（`:=`）。 ### [01:40:21](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6021s) 字符集、键盘映射与“Windows by Winter”移植项目在讨论方法头部的等号和返回值默认值设置时，现场有人询问 Cedar 是否使用了大量非 ASCII 标准字符。Eric Bier 解释说并非大量使用，只是有那么几个，其中左箭头（`←`）就是最具代表性的奇特字符之一。当时的硬件键盘上有专门的物理按键来输入这些特殊字符。随着 Xerox 后来在 20 世纪 80 年代末将 Cedar 移植到 Sun 计算机及其操作系统上，开发团队必须进行键盘按键映射，使得原先在 Alto 键盘上习惯的 Cedar 快捷键能在 Sun 工作站附带的各种键盘上找到对应的物理按键。Eric Bier 回忆道，自己正是当年参与键盘映射工作的人员之一。除了键盘映射，Eric Bier 还参与了在 1987 年左右将 Viewers 窗口系统移植到 Sun 操作系统的工程。当时团队内部成立了一个代号为“Windows by Winter”（入冬前搞定视窗）的冲刺项目，目标是在当年的 12 月 21 日之前让 Viewers 在 Sun 机器上正常运行。Eric 笑着表示虽然记不清那天到底赶没赶上，但肯定非常接近成功。随后的讨论指出，所有的 D 系列机器（D-machines，如 Dorado 等）都继承了 Alto 的键盘布局与字符集。Chris Jacobi 补充说，在键盘上真正带来麻烦的只有左箭头字符，后来语言用 `:=`（冒号加等号）替代了它。一旦改用 `:=`，语言内部就再也没有不可或缺的特殊非 ASCII 字符了。谈及赋值与判断语法的哲学，Chris Jacobi 强调说：“考虑到 `:=` 对比单等号 `=`，这比使用两个等号 `==` 或仅用一个等号要直观得多。”即便在离开 Xerox 很多年后的今天，他在编写其他语言时偶尔仍习惯用 `=` 表示比较而非赋值。 - **非 ASCII 特殊字符**：早期主要依赖 Alto 键盘自带的物理特殊键输入（如表示赋值的左箭头 `←`）。 - **赋值符演进**：后续代码标准全面转向由普通 ASCII 字符构成的 `:=`，消除了跨平台输入的硬件依赖。 - **Windows by Winter 项目（约 1987 年）**：PARC 团队为将 Viewers 视窗系统移植到 Sun Microsystems 工作站而设定的年底冲刺攻坚战。 --- ### [01:43:15](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6195s) 面向对象模式、闭包与内置的多线程支持 Chris Jacobi 接着深入剖析了 Cedar 语言的核心特性。尽管 Xerox PARC 凭借 Smalltalk 奠定了面向对象编程（OOP）的基石，但 Cedar 语言本身在诞生初期却完全没有在语法层面提供显式的面向对象支持。然而，由于语言提供了完备的底层原语，面向对象风格在实际开发中反倒成了绝对的规范。Chris 谈到：“我不记得有哪怕一个程序不使用 Cedar 的面向对象特性，但它们完全是通过底层原语构建起来的，基本上就是函数变量、闭包和嵌套函数。”这意味着开发者不需要手册里出现 `lambda` 这个词，便能极其简单地依靠嵌套函数与闭包实现 Lambda 表达式的能力。另一个关键特性是多线程并发机制。Chris Jacobi 指出，Cedar 从一开始就原生支持多线程，据他回忆，整个 Cedar 系统中可能只有编译器这一个程序没有使用多线程，其余组件无一例外都跑在多线程上。Paul McJones 或 Nick Briggs 提醒道，其实在 Cedar 之前的 Mesa 语言中就已经具备了线程支持。对此 Chris 欣然同意，并指出许多革命性概念在 Mesa 中就已成型，但 Cedar 的功劳在于将它们打磨得自然且易用。模块系统同样脱胎于 Mesa，但在 Cedar 中得到了大幅简化，且丝毫不损其模块化封装的威力。与此同时，Eric Bier 在屏幕上的源码中展示了一个利用 Tioga 富文本排版代码的绝佳范例：代码中出现了一个名为 `d²` 的变量，其中的数字 `2` 直接被排版成上标样式。Eric 解释称该变量实际代表距离的平方（distance squared），赋予其上标字形后，读者一眼就能心领神会，清晰直观。此外，Cedar 还拥有极其强大的异常处理机制，从抛出异常、捕获异常到重新抛出异常均有一套严密的支持，并辅以完备的同步原语来应对并发编程。 ```mermaid flowchart TD accTitle: Cedar OOP 与并发实现机制 accDescr: 展示 Cedar 如何在缺乏原生 OOP 关键字的情况下，通过底层原语模拟面向对象并结合多线程与异常处理架构。 subgraph Primitives ["Cedar 语言核心原语"] FV["函数变量 (Function Variables)"] CL["闭包 (Closures)"] NF["嵌套函数 (Nested Functions)"] RA["Ref Any (通用指针类型)"] end subgraph Paradigms ["应用层构建范式"] OOP["面向对象编程范式 (OOP)"] CB["复杂多层回调机制 (Callbacks)"] RT["运行时类型自检 (Type Inspection)"] end subgraph Runtime ["并发与系统机制 (源于 Mesa)"] TH["原生多线程 (Multi-threading)"] EX["异常处理 (Throw / Catch / Rethrow)"] SP["同步原语 (Synchronization Primitives)"] end FV --> OOP CL --> OOP NF --> OOP RA --> RT FV --> CB CL --> CB TH --> SP ``` --- ### [01:46:29](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6389s) 动态类型自检（`ref ANY`）与泛型替代方案关于异常处理与系统内省，Chris Jacobi 强调其意义远超单纯的错误排查。早期 Cedar 的调试器本身就是用 Cedar 语言编写的，调试器必须掌握关于变量的一切信息，这促使 Cedar 原生具备了完备的自我内省（Self-inspection）与运行时类型自检机制（Runtime Type Inspection）。虽然 Cedar 在文本层面上是一门静态强类型语言，但系统引入了一种特殊的指针类型——`ref ANY`。一旦指针被声明为引用（Reference），程序在运行时便能动态查明其所指对象的实际类型，甚至能通过 `SELECT` 分支语句根据运行时的具体类型来执行不同的逻辑分流。现场人员询问 Cedar 是否包含现代编程中的“泛型”（Generics）概念。Chris 解释称 Cedar 语言层面并未直接设计泛型语法，当时的工程师完全是把 `ref ANY` 当作泛型来使用的： - **功能替代**：一个通用容器（如通用数组）可以直接容纳 `ref ANY` 指针，使其指向任意结构的数据。 - **性能开销代价**：现代泛型编译能够为类型特化提供零运行时开销（Zero Overhead），而使用 `ref ANY` 则不可避免地需要经过间接寻址与动态类型查询，带有一定的性能损耗。 - **硬件宽容度**：Chris 风趣地调侃道，在 Dorado 这种强悍的计算机上运行，那点开销人们平时根本察觉不到，大家也就心安理得地不去追求零开销泛型了。结合嵌套函数与 `ref ANY`，当时的开发者经常写出深度嵌套的函数指针回调模式：一个函数接收极度宽泛的参数并调用外部变量，回调自身又触发上层程序的另一个回调。这种模式虽然对于不熟悉上下文的人来说颇为晦涩难懂，但赋予了系统无与伦比的灵活性。Chris Jacobi 总结道，Cedar 虽然允许通过 `ref ANY` 进行类似弱类型的动态操作，但程序代码本身在形式上依旧保持严谨的类型定义，“即使你使用运行时类型，它本质上仍是强类型的，只是在运行时去进行强类型判定而已。” --- ### [01:51:38](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6698s) 对象与引用的解构、Dorado 硬件光标与系统挂起 Eric Bier 在审阅屏幕上的源码时发现了一个曾被遗忘的类型声明细节：代码中定义了一个 `Circle` 类型，它被明确定义为指向 `CircleObject` 的引用（`REF CircleObject`），而底层的 `CircleObject` 则声明于另一个模块中。当创建一个新的圆形实例时，其实际类型是 `Circle`，但调用的分配指令是创建一个全新的 `CircleObject`。这展示了 Cedar 在类型系统上对“实体对象”（The thing）与“指向实体的引用”（The reference to the thing）做出的严格语义区分。Chris Jacobi 解释称，尽管两者在名称和类型自检中是完全独立的类型，但编译器在语法糖上提供了极大的便利——当开发者需要沿着指针链向下解引用时，无需手动书写繁琐的解引用操作符，直接输入一个点号 `.` 即可，该点号既可以表示访问结构体中的字段，也可以自动穿越指针进行链式访问。在演示接近尾声时，Eric Bier 特别花了几分钟分享了关于 Dorado 硬件光标（Cursor）的技术逸事。当前演示虽然是通过远程 Mac 在 X Windows 下运行，使用的是 X11 光标，但 Dorado 本机实现的光标极为独树一帜：Dorado 硬件直接分配了专用的 CPU 周期，每隔极短的周期就会强制刷新屏幕上的光标。这就使得光标成为了整台机器上最可靠、几乎绝不崩溃的视觉元素。即便 Cedar 环境出现严重错误导致整个系统彻底冻结、应用界面严重卡顿滞后几十个事件没处理，光标依然能够以绝对的实时性紧随用户的鼠标手势顺滑移动。 PARC 的工程师们巧妙地利用了硬件光标的这一超高可靠性，将其开发成了极度容灾的状态通信管道： - **光标数字报错**：当操作系统底层崩溃、窗口系统无法绘制错误弹窗时，系统会直接在光标图案内部绘制一个数字代号。 - **暗号文化**：工程师们必须记住这些光标数字的含义，Eric Bier 和现场嘉宾不约而同地提到：“各种各样的错误信息不过就是直接显示在光标里面的数字代码，我们所有人都得学会那些数字代表什么，我记得 815 就是一个非常重要的代码。” - **全系统状态挂起与回滚**：Chris 赞同这是专供专家使用的极致界面设计，而谈及 Cedar 的告别语，他由衷感叹希望现代系统也能保留这些设计。在最后几秒钟，Chris Jacobi 还提到了 Cedar 强大的“挂起”（Suspend）与检查点（Checkpoint）机制，系统允许用户在任意时刻对整个运行环境打快照并随时回滚到先前的状态。 ### [01:55:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=6901s) 回滚趣闻、致谢与最后的命令细节（Open R 与 Find R）现场谈论起 Cedar 系统中的挂起（suspend）与恢复（resume）机制，指出该过程本质上是在保存当前系统的执行状态。由此有人回想起当年实验室里的一则趣事：曾有人借用经典邪典电影《洛基恐怖秀》（Rocky Horror Picture Show）中的名曲《Let's Do the Time Warp Again》，根据其旋律改写了一首恶搞小歌，歌词变成了“咱们再来一次状态回滚吧”。正如发言者笑着回忆道：“As a joke one year someone wrote a little song to the to the tune of Let's Do the Time-Warp Again from Rocky Horror, except it was 'Let's do the roll back again'.” 随着演示接近尾声，现场询问大家是否还有临别的最后发言。参与者们（包括 Nick Briggs、Chris Jacobi、Paul McJones 等）纷纷向主讲人表达感谢，齐声道谢“Thank you, Eric”，Eric Bier 也欣然回应“You are very welcome”。在关闭系统之前，Eric 借机补充了一个刚才一直在操作但未及口头解释的小细节：界面上的 `Open R` 和 `Find R` 命令。他解释说，命令里的字母“R”应当代表“Release”（发布），而“Open”则是指打开某个特定的发布版本文件以供浏览或编辑，由此为这场跨越数十年的 Cedar 系统环境完整演示画上了圆满的句号。 - **挂起与回滚文化**：Cedar 开发者曾创作改编歌曲《Let's do the roll back again》，戏仿《Rocky Horror》的《Time Warp》，调侃频繁存储和回滚系统状态的开发日常。 - **Release 命令前缀**：系统中的 `Open R` 与 `Find R` 工具按钮中，“R”代表 Release（发布库版本），用于在已发布的归档版本中查找和打开文件进行查看或二次编辑。 ## Notable quotes > [06:01](https://www.youtube.com/watch?v=z_dt7NG38V4&t=361s) What Cedar was really strong at was a strongly typed language with separation between interfaces and implementations, which meant... that it was tremendously good at allowing code reuse, and the code that you produced was... likely to, you know, if it compiled, it was probably going to run. — Eric Bier ## Mentioned Eric Bier, Hanson Hsu, Rick Cattell, John Warnock, Charles Geschke, Paul McJones, Chris Jacobi, Nicholas Briggs, Scott McGregor, Warren Teitelman, Bill Paxton, Doug Wyatt, Ken Pier, Maureen Stone, Michael Plass, Steve Wahlgren, Carlo Séquin, Brian Barsky, Doug Engelbart, Cedar, Mesa, Tioga, Gargoyle, Gargoyle 3D, Smalltalk, Interlisp, Solidviews, Pilot, Xerox Star, Interpress, Snap-Dragging, NLS, Alto, Dolphin, Dorado, Sun Microsystems, Solaris, MacBook Pro, X Windows, Xerox PARC, Computer History Museum, MIT, UC Berkeley ## Video description [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. Catalog number:102781041 Lot number: X8888.2019 [Source](https://www.youtube.com/watch?v=z_dt7NG38V4)

Source quotes

[6:01] Eric Bier: What Cedar was really strong at was a strongly typed language with separation between interfaces and implementations, which meant... that it was tremendously good at allowing code reuse, and the code that you produced was... likely to, you know, if it compiled, it was probably going to run.

Source quotes

[75:50] Chris Jacobi: It's actually obvious: you need a program editor, you have a text editor, so why not use that? [103:15] Chris Jacobi: I am not aware of a single program which didn’t use the object features of Cedar, but they were done with the primitives which were basically function variables and closures and nested functions. [26:53] Eric Bier: Tioga is really important in Cedar because it's everywhere.

Original transcript

[0:10] is January 24th [0:11] Hanson soo and here [0:14] so Eric he tell me a little bit about [0:18] how you started at Park and how you got [0:21] involved with the Seeger project sure so [0:24] I first encountered Cedar in 1981 it was [0:29] my second summer pet park as a summer [0:32] intern and I was working that summer [0:35] with my host rick Cattell on databases [0:39] and he wanted them done in the cedar [0:40] programming environment so that was my [0:44] first experience with it my following [0:47] summer I was there for for three summers [0:49] as part of a program with MIT they [0:52] called it the 6a program it was a co-op [0:54] program where you work three summers on [0:57] a fall at a company and then do a [0:59] master's thesis based on about your last [1:02] six months of work so as I say my second [1:06] summer it was using cedar with Rick [1:08] cattell my third summer my host was John [1:12] Warnock and I was in a lab I think was [1:16] the imaging Sciences lab gesh key was [1:18] the lab manager at that time and I was [1:21] working on solid modeling system that I [1:23] called solid B's that then became my [1:27] master's thesis at MIT and so I [1:34] encountered cedar I encountered it [1:37] largely on the Dorado computer which I'm [1:42] sure you know about here at the Computer [1:43] History Museum and I would still [1:47] remember the first time I encountered a [1:48] Dorado at that time they didn't have [1:51] dourados for everyone so you had to sign [1:54] up for them and I signed up for an hour [1:57] slot with a Dorado act actually had to [1:59] take a shuttle bus from my office down [2:01] on Hanover Street to the building on the [2:05] hill [2:06] 3333 coyote Hill Road to get my one hour [2:10] slot with the Dorado and actually that [2:16] was in summer but that was the summer [2:17] before when I was doing the using small [2:19] talk that was my first encounter with [2:20] the door [2:21] and and I had to ride the shuttle bus [2:24] that summer and what I remember was [2:28] almost laughing out loud because I [2:32] wasn't waiting for the computer it was [2:33] waiting for me [2:36] so the Dorado was a sweet machine they [2:40] they were built with emitter-coupled [2:42] logic which meant that they were fast [2:44] but also that they ran really hot so you [2:47] didn't have a Dorado in your office you [2:49] had the Dorado down the hall in an [2:50] air-conditioned room and park had a [2:52] whole lot of cables running in the [2:54] ceiling one of the things that I thought [2:57] was really interesting about cedar was [2:59] that it was environment that was [3:01] intended both for researchers and for [3:05] staff both for programming and for [3:10] making publications so what I've got on [3:14] the screen right now are examples of [3:16] documents that have pictures in them [3:19] that have nicely formatted text and so [3:22] forth the researchers used cedar but [3:25] also the administrative assistants also [3:27] the artist sensitive horse could you [3:31] maybe go back and explain to someone [3:34] who's not familiar with this environment [3:37] what cedar is sure so cedar is a [3:43] combination of things it's both a [3:45] language also called cedar Mesa a [3:48] programming language when people asked [3:51] about it back in the 80s we used to tell [3:53] them it's kind of industrial-strength [3:54] Pascal that kind of gives you a feeling [3:58] for what the syntax is like I will talk [4:01] more about the cedar language later but [4:05] it was also of course a set of [4:08] application as a set of libraries that [4:10] that people could build on and cedar was [4:14] a very successful experiencing code [4:17] reuse the the way that the cedar [4:20] programming language works [4:22] it pretty much forces you to package [4:24] your code in a way that other people can [4:26] use it and other people did there were [4:30] dozens of people in the cedar community [4:32] and we were constantly building software [4:33] on top [4:34] of each other's software mm-hm [4:37] so was a it was a pioneer for the [4:40] modular programming kind of paradigm yes [4:43] I think that's fair to say certainly [4:46] certainly very modular and people built [4:52] a lot of different kinds of applications [4:54] on it we were just talking about some of [4:56] them so there were document processing [5:01] tools there were email readers there was [5:06] all kinds of debugging tools publication [5:13] two-dimensional graphics [5:14] three-dimensional graphics VLSI design [5:17] tools databases the list went on and on [5:21] networking software it was all done in [5:24] cedar and because because it was fairly [5:30] close-knit community and because of the [5:33] way the programming environment itself [5:34] worked you you could constantly be [5:38] building on other people's software and [5:40] even sometimes you would discover a bug [5:42] in someone else's software and rather [5:44] than bother them with it you would just [5:46] fix it and it meant that if you found [5:50] something wrong and you couldn't fix it [5:52] yourself it was easy to find out who was [5:55] responsible for that and get a problem [5:57] fixed quickly okay and what was the goal [6:01] for the the group had developed cedar [6:04] what were they trying to do with with [6:06] the environment right so Park put a [6:11] large investment of time and effort into [6:14] cedar and one of the reasons they did [6:16] that was this feeling that whatever we [6:20] were going to do research on in the [6:23] cedar community that we wanted to be [6:27] able to do it very productively we [6:29] wanted to stay on the cutting edge of [6:31] whatever research topics we were working [6:33] on and in order to do that we needed to [6:35] have a programming environment that was [6:38] very productive to work in [6:40] and cedar was very successful at that [6:43] and there were two other programming [6:49] environments at Park as well right [6:52] direct small talk and inner lists right [6:55] and so how would you compare these with [6:58] with those environments right so [7:03] obviously the languages are very [7:05] different and what they enable is very [7:06] different so small talk very interactive [7:10] you type a line of code straight into [7:14] your your terminal window and [7:17] immediately execute it right so that [7:19] very interpreted interpreted interactive [7:23] way of of working inter Lisp you know [7:29] because of the way the lisp language is [7:31] with the very simple syntax you can be [7:35] generating code and then immediately [7:37] running the code that you generated so [7:40] the the folks who used inner lisp you [7:43] know we're often doing the artificial [7:44] intelligence type of stuff [7:46] what cedar was really strong at was a [7:50] strongly typed language with separation [7:55] between interfaces and implementations [7:57] which meant as I said that it was [8:00] tremendously good at allowing code reuse [8:03] and the code that you produced was you [8:09] know fairly robust and likely to you [8:12] know if it compiled it was probably [8:14] going to run and so it was a good [8:18] environment for building things that [8:21] were easy to productize because you [8:24] already had them implemented in a [8:26] language that that encouraged creating [8:29] fairly robust hardened code what [8:33] machines did you have access to and [8:35] could you compare compare them right so [8:39] my first summer at Parc [8:41] I had an alto at my desk [8:44] and I think it was Andy Daniels was [8:47] working next to me and he had a dolphin [8:51] which was a newer machine so it was [8:56] enough faster I don't know 50% faster [8:58] two times faster or something like that [9:00] that it was worth it when he was out of [9:03] the going to be out of the office he [9:04] would tell me okay you can use my [9:06] dolphin now because I don't need it but [9:09] but the Dorado was then significantly [9:11] faster than the dolphin as I said the [9:16] tirado's wait for you not the other way [9:18] around so oh em by the way that first [9:26] Dorado that I signed up for I mean those [9:28] machines were won 1 million instructions [9:33] per second now that's not quite as slow [9:36] as it sounds because those instructions [9:38] did a lot [9:39] that wasn't just clock cycles they're [9:42] micro codable machines and each Dorado [9:48] on the signup sheet said how much memory [9:50] it came with so most of them I think had [9:53] 768 kilobytes but but if you were lucky [9:57] you could sign up for the big Dorado [9:58] that had a whole megabyte of RAM so then [10:05] cedar ran on the the dolphin and the [10:09] Dorado and other machines in the D [10:11] machine series but not on the Alto I [10:15] don't think cedar ever ran on the alto I [10:18] don't know that it ever ran on the [10:21] dolphin certainly the Mesa language did [10:24] run on the dolphin because I think [10:25] that's what Andy Daniels was coding in [10:27] that summer but I'm not sure that cedar [10:30] ran all the Dolphins okay [10:33] did you want to talk about how Mesa [10:37] developed into cedar the part of it I [10:40] remember was that Xerox developed the [10:43] Mesa language and programming tools for [10:45] the Mesa language and they used it for [10:48] some Xerox products right so when the [10:52] Xerox star came out which I think was a [10:56] and my first summer at Park 1980 there [10:59] was a big party out on the patio to [11:01] celebrate the release of the star that [11:04] summer as I recall so uh that's that [11:09] software was written in Mesa Mesa didn't [11:16] have all the convenience features that [11:18] cedar Mesa eventually had so you didn't [11:21] have the automatic garbage collection [11:22] and of course that has a big impact on [11:25] how you do programming with it so you [11:28] did a lot more programming where you [11:30] explicitly worried about pointers and [11:33] allocating storage and so forth and that [11:37] was one of the big improvements when we [11:39] moved to cedar [11:44] to help us out today we have several [11:48] Park alumni here Paula Jones Chris [11:52] Jacoby and Nicholas Briggs I'm Paul [11:57] mcjones [11:57] I was it actually sort of across the [12:00] street at Xerox STD from 1976 to 1981 I [12:04] was working on the staroffice automation [12:07] system and the pilot operating system [12:09] which became a low-level building block [12:12] for cedar later but I left before cedar [12:15] was really I think I'm Chris Jacoby I [12:18] joined Park in 1983 and been one of the [12:24] customers of cedar first I wrote the [12:28] VLSI design tool in cedar which might [12:32] have been one of the largest in code [12:35] size but later on I got even closer to [12:39] cedar I've wrote parts of the compiler [12:42] and parts of the Window System I'm [12:45] Nicholas Briggs [12:46] I started at Parc in 1984 and at that [12:50] time was working on the inter Lisp [12:52] system but later on I became a customer [12:56] of the cedar imaging code as part of the [13:00] document printing system another couple [13:03] of words about the origins of cedar Mesa [13:06] we were pretty happily using Mesa in the [13:10] mid to late 70s for those product for [13:13] the product development as Eric said it [13:17] didn't have a garbage collection we had [13:19] so little memory we had to preciously [13:21] allocate each little bite [13:23] there was an interesting discussion [13:26] going on at parked across the street I [13:28] wasn't directly involved but I got to [13:30] read sort of the minutes which was to [13:32] come up with there was sort of some [13:35] controversy at Parc about getting [13:37] everyone working together using those [13:39] packages that Erica described and yet [13:42] there were these three different [13:42] languages so some of the people felt it [13:45] would be great to try to unify the [13:47] capabilities of the three different [13:49] programming environments which Eric has [13:52] already described there there [13:54] tributes so there was a effort called [13:57] the experimental programming environment [13:59] research project and it was really [14:02] looking at the three languages and [14:03] trying to decide could one of them [14:05] become sort of the PARCC standard [14:07] language and I think cedar Mesa clearly [14:11] came out of that and by the 80s was you [14:14] know played a dominant role and yet I [14:16] think the people from Smalltalk and [14:18] inner Luce felt not exactly railroaded [14:21] you know they they definitely [14:22] contributed a bunch of ideas to what [14:24] went into cedar but they weren't [14:26] convinced that that was going to replace [14:28] their their own language [14:35] all right so let me say a few words [14:37] about what we're looking at here so if I [14:41] were giving this demo back in the 1980s [14:43] I would be doing it off of the screen of [14:46] a dorado in the early 80s that would [14:49] have been a black and white screen right [14:53] now what we're doing is I have a MacBook [14:56] Pro here at the Computer History Museum [14:59] it's running X Windows we have a VPN [15:06] connection to a Sun Microsystems machine [15:08] at Parc that's running a version of [15:12] cedar that that works on Sun [15:15] Microsystems machines that works on [15:18] Solaris and of course then what yours [15:23] you're seeing on this screen here what [15:26] cedar is producing hmm so to introduce [15:31] you to cedar of course the first thing [15:33] you see with cedar is the Window System [15:35] and we're looking at several windows [15:38] here there were actually several windows [15:40] systems developed for cedar it was one [15:43] that wore entitlement did called Docs [15:46] that had a lot of functionality to it [15:49] but ended up being somewhat slow Scott [15:53] McGregor did in response to that I think [15:56] a a lean and fast Window System that he [16:01] calls viewers and so the the windows [16:04] that you're seeing here we called [16:06] viewers if you kind of look at the [16:09] screen from top to bottom you're seeing [16:12] there's a sort of a status bar up here [16:14] at the top and some buttons if I press [16:17] this button called command we get a new [16:21] terminal window or what in cedar was [16:23] called a commander if I press the new [16:29] button we get a new text editor window [16:31] that's the Tioga text editor and then [16:36] what you're seeing going down the screen [16:38] again these are these are viewers you [16:43] can have many viewers open at the same [16:46] time and see [16:47] was kind of optimized so that you could [16:49] have many many windows open at the same [16:52] time in fact you could make the windows [16:55] very compact so you could even get rid [16:58] of the the small number of menus that [17:01] are are at the top of the of each window [17:04] to make each window very efficiently use [17:07] the screen space available and in fact [17:12] there's another menu on that gives you [17:15] more functionality that that I have [17:17] collapsed by default it was a very [17:20] configurable system there are [17:22] configuration files where the user could [17:25] say what defaults they wanted for [17:28] various things including what what menus [17:31] are visible down at the bottom of the [17:35] screen we have icons so when you take a [17:39] window and close it it then becomes an [17:44] icon at the bottom of the screen and [17:47] later on in cedar development some color [17:50] was added to the icons generally to show [17:54] the kind of application that you are [17:56] working with and as you see the icons [18:01] have different patterns to them which [18:03] also suggest which exact application it [18:06] is you're running and cedar came with a [18:08] fun little tool called the icon editor [18:11] where you could one pixel at a time [18:13] change what your icons look like so one [18:18] thing that strikes you immediately about [18:20] the viewers window system is that it's a [18:23] tiling window system right most of the [18:25] windows systems we use these days or [18:27] what are called overlapping you you have [18:29] a window and then another window on top [18:31] of that and another window on top of [18:33] that and you drag them around and resize [18:35] them and so forth so viewers does tiling [18:41] which means that whenever you open a [18:44] window it goes into one of the two [18:47] columns so there's a left column here [18:49] and a right column here you can switch [18:52] which column a window is in so I've got [18:55] this little right arrow here I can move [18:57] that window over to the right and [18:59] how it's in this column if I'm [19:02] distracted by the other windows in that [19:04] column or I want more space for this [19:05] window I hit the grow button that viewer [19:09] now becomes the whole column and all the [19:13] others become icons you can change where [19:19] the line is between the two columns [19:22] adjusting it like so and there's a lot [19:27] of machinery and cedar for remembering [19:30] which which windows you had opened [19:33] before so if I close this window [19:37] actually I think I have to destroy it [19:39] I'm gonna try that if I destroy this [19:43] window it remembers our well there were [19:46] two other windows in that column when [19:49] you when you you push them out to make [19:51] that window big but now that that window [19:53] doesn't exist anymore let's assume that [19:56] you want them back so there's sort of a [19:58] number of clever little efficient [20:00] features like that so Chris Jacoby and I [20:05] were talking the other day about some of [20:07] the things that we still miss about [20:09] cedar to this day and one of the things [20:12] that we miss is the way that the scroll [20:14] bars work and let me show you that so [20:21] what we're looking at here is actually a [20:24] document written using the Tioga text [20:27] editor that that was written to be a [20:31] conference paper and notice that the [20:37] scroll bar is off to the left hand side [20:39] instead of the right hand side where it [20:41] would be in most systems today cedar [20:44] users you that is a very good thing one [20:48] of the great things about having the [20:50] scroll bar on the left is that when you [20:54] have a text document and went in [20:56] particular when you're working on [20:57] software so let me open a software [21:01] module for a second [21:05] so here's a software module one of the [21:08] things to notice about software is that [21:11] the text is more likely to be on the [21:14] left-hand side of the window then on the [21:17] right-hand side often the right-hand [21:19] side has a lot of white space and since [21:22] what you're doing when you're working on [21:23] a document is you're off and pointing at [21:25] things with your mouse cursor you're not [21:28] going to be pointing at the white space [21:29] you're going to be pointing at the text [21:31] and the text tends to be on the left so [21:34] you're already near the left hand side [21:36] of the window is just a small motion to [21:38] get into the scroll bar and start using [21:40] it mm-hmm [21:43] the scroll bars also had some nice [21:45] features where if I want this particular [21:48] piece of text to go straight to the top [21:50] of the screen it's a single button click [21:53] to do that so there's not a whole lot of [21:56] scroll and see what happens scroll and [21:58] see what happened it's a whole lot of [22:00] clicking the Tioga text editor also has [22:06] levels as I showed you before and there [22:08] are these menus here that say I want to [22:11] see fewer levels so you're basically [22:12] getting an outline view of this document [22:15] now I want to see all levels and it [22:18] expands out and shows you everything but [22:22] you don't actually need that menu [22:23] because those commands are also built [22:26] into the scroll bar so if I let's see [22:32] there we go holding down the ctrl + [22:35] Shift key collapses everything as I [22:38] click and then holding just the ctrl key [22:41] expands things back out and at the same [22:44] time moves what I wanted to go to the [22:46] top of the screen to the top of the [22:47] screen so after you use cedar for a [22:50] while and kind of become an expert user [22:52] a lot of these things become second [22:56] nature and you get really efficient at [22:58] navigating around in documents and as I [23:02] said previously not only is this a good [23:07] system for code but also a good system [23:11] for [23:13] publications so here's that same [23:16] conference paper that we were just [23:18] looking at but I now just collapsed all [23:20] the levels and now we see an outline of [23:23] this conference paper and if I want to [23:27] jump straight to section five and expand [23:29] things out um I can go ahead and do that [23:31] with another click so I'm definitely [23:34] something that cedar users miss about [23:37] cedar by the way if you want to jump to [23:40] a particular position in the document [23:42] like three-quarters of the way down you [23:45] just used the middle mouse button to do [23:47] that the cursor changes to this little [23:50] arrow to show you that you are thumbing [23:52] and you go straight to that part of the [23:54] document so cedar made extensive use of [24:00] all three mouse buttons in the interface [24:01] yes thank you for that prompt exactly so [24:07] a lot of the operations in cedar use [24:10] some combination of the left mouse [24:12] button the middle mouse button the right [24:14] mouse button and and the ctrl key and [24:18] the shift key right so with ctrl + shift [24:21] that gave you four combinations plus [24:23] three mouse buttons basically gave you [24:26] twelve commands in any given context [24:29] that you could trigger just with those [24:32] keys and and the mouse buttons and cedar [24:36] made a lot of use of that as you'll see [24:38] as we go along I wanted to show you [24:41] moving a window to the top there you go [24:44] so again without changing the content of [24:47] one of the columns of the Window System [24:49] you can change what order the windows [24:51] appear in another thing to notice and [24:56] this is particularly true or I [24:59] particularly remember this with respect [25:01] to writing software is that the fonts [25:06] that are used are readable but small and [25:10] as a result one felt there was no [25:16] problem in opening many windows at the [25:18] same time so if you were writing a piece [25:20] of code and you thought well I kind of [25:22] need to copy some bits of code [25:25] from module a and module B and module C [25:28] and move those all into module D then [25:32] you could just open those four modules [25:33] all at the same time and move things [25:36] around so let me give you a feeling for [25:39] that so there's another module and what [25:50] I do so there I've got three modules [26:10] that open at the same time and I've able [26:14] to see quite a number of lines of each [26:16] one if I wanted a piece of content move [26:20] from one window to another I can go [26:22] ahead and do that so maybe I want to [26:25] move a piece of content down here and [26:31] maybe I also need something from this [26:35] module right here and I just pulled that [26:39] all in so one of the things that I was [26:45] just demoing without talking about it [26:47] was this command open are these commands [26:50] open are and find our I believe the R is [26:53] for release and open in the sense I've [26:59] opened something for editing or viewing [27:01] find in the sense of get me a listing of [27:06] everything that matches a pattern and [27:08] the R is means but don't look in the [27:12] current directory look in the release [27:15] directories of seeder itself wherever [27:17] they are on some file server so for [27:21] example if if I remember that there are [27:26] a number of files in the seeder release [27:30] that end in the extension DF [27:33] I can go ahead and ask the system to [27:39] find all those and it's telling me where [27:42] they are in the on some file server [27:45] somewhere so there is a path that begins [27:48] with cedar 13.0 and somewhere else in [27:52] cedar is a mapping from that path to an [27:55] actual file server somewhere and then [27:59] there's a subdirectory inside of that [28:01] called top and that's where all these DF [28:05] files are stored and I'll talk more [28:07] about DF files later but the companion [28:11] command open R means if you find a file [28:16] that matches this pattern that I just [28:18] typed then please open it in the Tioga [28:21] text editor and let me see it so if we [28:25] remember for example that the Tioga text [28:27] editor itself as a documentation file [28:31] the cedar convention says that the [28:33] documentation for a package always ends [28:36] in the letters do C so not hard to [28:38] remember and I said open our Tioga doc [28:43] and it found that for me in the release [28:45] wherever it happens to be and I can now [28:48] go and read the the user manual for the [28:52] Tioga text editor and you know find out [28:55] how Toyota works I wanted to tell you a [29:01] little more about the Tioga text editor [29:03] itself Tioga is really important in [29:06] cedar because it's everywhere so [29:09] obviously it's in windows like this [29:13] Tioga window here and you can see by the [29:16] fact that this document name ends in dot [29:19] Tioga that this is a Tioga file by the [29:24] way i'm notice another efficient use of [29:26] screen space that little bar at the top [29:29] of the window is both used for the path [29:33] name of the file but there are also some [29:35] buttons underneath it [29:38] so Tioga is used in Windows but Tioga is [29:43] also available in many other places in [29:46] Cedars so for example this is a terminal [29:50] window in most modern operating systems [29:53] the the terminal application has a [29:56] fairly stripped down text editor with [30:00] only a small subset of the commands that [30:03] would be available in a full-fledged [30:04] text editor but but this is this has got [30:09] Tioga in it so I can do Tioga shift [30:12] select within that command tool and pull [30:16] bits of text from the command tool [30:19] itself or from other documents on the [30:21] screen I believe I can even change the [30:27] looks of things here so there we go [30:30] right so I just made that text bold [30:34] because well this is the Tioga text [30:37] editor it's even available in the little [30:44] tools that you do to do search and [30:46] replace so this tool here the edit tool [30:50] is kind of a companion to Tioga you [30:53] generally only have one edit tool on the [30:55] screen at a time and then you apply it [31:00] to any windows you happen to have open [31:03] so for example one way to do a search in [31:07] cedar is to say well I think the word [31:11] memos is in this document somewhere [31:13] let's see if I can find it and there [31:17] there that's one way to find it and if I [31:21] want to do a search and replace then of [31:22] course I can put in another piece of [31:24] text here that that I want to replace it [31:29] with [31:31] now I could change the text of course [31:35] that would be the common thing to do but [31:38] I believe it's also possible to change [31:42] the looks so let me let me see if this [31:47] is how you do that I haven't done this [31:48] in a while [31:49] all right so match anywhere match [31:54] literally do replace do operations okay [32:01] obviously I haven't done this in too [32:03] long but you can also use the looks to [32:10] to search for to search for pieces of [32:14] text that have a particular look to them [32:16] so let's see if I can get that to work [32:20] all right and I don't need anything to [32:23] replace it with oh right [32:25] looks that's what I need to do all right [32:29] so what if I just want to find [32:31] everything in the document that's bold [32:32] Wow so we can go ahead and do that yeah [32:39] so the other tool is very powerful and [32:42] now I think we can also do [32:50] do the edit I was planning so let's see [32:53] if I can make that bold do a search [33:02] there's memos and there it's replacing [33:05] both the text and the looks of that [33:08] particular item [33:10] by the way cedar does have undo good old [33:15] shift escape gives you on one level of [33:17] undo in many of the applications in [33:20] cedar and if you want to get rid of all [33:26] of the edits that you've done recently [33:27] you can just hit the reset button and go [33:31] back to the the on disk version of that [33:33] particular file as you can see the edit [33:37] tool has a whole lot of functionality [33:40] and I won't go through all of it for you [33:43] but I will point out some of the [33:45] interesting things so let's um let's go [33:47] to my conference paper again and let's [33:53] find out some things about this document [33:55] so here's some Texas Bowl why is it bold [33:57] well it's bold because it it has the [34:00] letter B associated with the looks well [34:02] B stands for bold so someone just [34:05] applied the bold look directly to those [34:07] characters what about this this is bold [34:12] but it doesn't have the bold look [34:14] applied to it what's happening instead [34:16] is that there are style sheets behind [34:18] Tioga they are even cascading style [34:21] sheets and so if I could get here it [34:26] tells me that that there's a style [34:29] applied to this called Chi 2 column [34:32] reduced chi in the sense of the computer [34:34] human interaction conference the ACM [34:38] conference so we had a style sheet for [34:42] writing publications for that particular [34:46] conference [34:48] and this particular paragraph is a [34:52] heading level one or a head one so kind [34:56] of a lot of the style functionality that [34:59] you would expect one last thing I'll [35:03] show you about the Edit tool is the [35:08] ability to do macros so for example if I [35:13] wanted to select something and then I'm [35:18] going to move the caret to a position [35:22] after that object and then I'm going to [35:27] make it look bold and then I'm going to [35:32] add a few characters to it I can then [35:39] ask Tioga what operations did I just do [35:42] since the last time I selected something [35:44] it remembers all of the operations and [35:50] it will repeat them so in addition to [35:56] undo cedar has redo and that happens [36:02] whether or not you're using the Edit [36:04] tool so if I just let's me close that if [36:12] I just come to an object here do a few [36:15] edits to it maybe I'll make it a italic [36:18] this time I'll add a little punctuation [36:22] at the end maybe put a number now I [36:28] select anything else hit my Escape key [36:30] and I'm redoing that edit so you would [36:35] often find as you were using the Tioga [36:36] text editor that you wanted to do [36:40] something over and over again and often [36:42] it would do just what you were hope what [36:44] you would hope it would do [36:49] one thing about cedar some people liked [36:52] it some people didn't was that a lot of [36:56] the commands required that you make a [36:58] text selection before you did them so [37:02] for example let's see if I can [37:14] so for example say I want to load a new [37:18] file into this window so this window [37:22] knows that it's in the Tioga files [37:24] folder so any other file in that folder [37:29] is available to me so here are all the [37:33] files that are in that folder and if I [37:37] come along and let's see here I will [37:47] select [37:49] a filename that I come and say get and [37:56] there's what was in that file if I want [37:59] to go back to the previous file just hit [38:02] the previous file button and it reloads [38:04] that again and you'll probably see other [38:10] commands in the demo where where we use [38:14] that ability to just select some text [38:16] anywhere on the screen and then apply it [38:18] to one of the seeder applications Eric [38:27] can you say something about the [38:30] different mousing model the insertion [38:36] point and shift select copy selects [38:38] those operations that are quite [38:40] different from what we usually encounter [38:42] today yes I certainly will let's do that [38:47] now and I think I will do it with some [38:52] code [39:00] so when you're using a computer today [39:04] you're probably going to use copy and [39:07] paste copy and paste has become a [39:10] standard way of moving text around [39:13] within applications and across [39:15] applications in seeder there is a more [39:21] efficient method and it's it's enough [39:24] more efficient that I continue to use [39:26] cedar deep into the 1990s just so as not [39:30] to have to give give that up along with [39:33] some other features but that was a big [39:35] one and here's the idea [39:39] instead of selecting something and then [39:45] clicking a copy key or a copy button and [39:50] then moving somewhere else and pressing [39:54] a paste button what you do in cedar is [39:58] you leave your cursor wherever you're [40:00] working at the moment so perhaps we're [40:04] working right here and now we we [40:11] realized that the thing that we're about [40:13] to type is already present somewhere [40:16] else on the screen so rather than type [40:19] it again it would be nice to just copy [40:22] it so what you can do is hold down the [40:26] shift key on the keyboard that tells the [40:28] system that you want to do a copy and [40:32] now all of those mouse buttons commands [40:35] are available in order to do that copy [40:38] and let me talk about those for a second [40:41] so left mouse middle mouse right Mouse [40:44] we use them all the left mouse button [40:47] you select a single character [40:51] any character on the screen the middle [40:55] mouse button selects a word any word on [40:59] the screen the right mouse button [41:02] extends your selection at its current [41:04] level of granularity so if I selected a [41:08] character and I hit the right mouse [41:10] button it selects all the characters [41:13] from the first place to the new place if [41:18] on the other hand I had selected an [41:20] entire word and I hit the right mouse [41:21] button it selects to the level of words [41:24] but we're not done yet because there's [41:28] also double clicks so if I want to [41:33] select this entire node as it's called [41:36] in Tioga I double click panning encoding [41:40] like this a node generally corresponds [41:42] to a line of code so double clicking [41:44] gets the whole line and now I can use [41:48] the right mouse button to extend the [41:50] selection at the line level and finally [41:54] if you double middle click you get the [41:59] node and anything nested under it so an [42:03] entire branch or entire tree and if I [42:07] right click I extend at the level of [42:10] entire trees and in code that generally [42:14] means that I can then select a whole [42:16] number of methods or routines in the [42:20] code and maybe I want to take this whole [42:23] section of code for example and move it [42:25] to some other part of the file in order [42:27] to group it with some other routines [42:28] that I've written so those are the basic [42:34] selection commands and now when you hold [42:36] down the shift key you've still got all [42:40] those commands available to you [42:42] left click middle click right click [42:43] double clicks and so on but now you're [42:46] doing them in the context of wanting to [42:48] copy so if I hold down the shift key and [42:51] say double click double left-click I've [42:55] just pulled in an entire line of code [42:57] from somewhere else in the file [43:01] and more interesting still I'm now setup [43:08] with my cursor in the right position to [43:10] pull in yet other lines from other parts [43:13] of the file so instead of copy move [43:18] click paste [43:20] move back copy and so forth it's shift [43:24] click shift click shift click and you [43:28] can really throw text around in a hurry [43:31] with with that way of doing things [43:37] anything else I should cover Nick yeah I [43:40] think that that got it if you don't mind [43:44] I'd like to add something which is very [43:47] hard to demo that's probably you didn't [43:50] demo it the commands are very orthogonal [43:54] which means if a certain pattern of the [44:00] command works in one place this the same [44:02] pattern of mouse and keyboard and double [44:06] click works in something else and if [44:12] anybody wondered how that Eric after [44:16] having 16 years not you cedar still is [44:20] able to demonstrate the key clicks then [44:23] you see how clever the user interface is [44:29] done so that there is a small number of [44:32] facts to remember it's actually even so [44:36] good that for me it's 18 years since I [44:39] haven't used cedar I still make errors I [44:42] still use cedar key combinations [44:45] sometimes on my PC with the tool which [44:48] absolutely has no idea what to do for [44:51] that and another thing which is hard to [44:56] demonstrate but Eric said that the Tioga [45:00] is everywhere I'd like to come with some [45:04] example for this so that it really [45:09] becomes obvious say for example your [45:12] program [45:13] runs into an error and writes an error [45:16] message guess what you can use this yoga [45:19] Tioga commands to go and edit the error [45:24] message if you want because wherever [45:27] there is text this is Tioga I think I [45:31] know one exception if in a chip design [45:34] you have some metal with the pattern of [45:38] letters that doesn't work with Tioga [45:41] commands thanks Chris oh just a few more [45:50] things about Tioga and then I'll move on [45:53] to some other things so you may be [45:56] curious about some of the buttons up at [45:59] the top of the screen [46:01] for example split this is a feature that [46:07] you would love to have in text editors [46:09] even today but not all of them have it [46:11] it's the ability to look at the file at [46:16] several different Scrolls at the same [46:18] time right so maybe I need some code [46:22] from copy circle but I needed up here at [46:25] the top of the file I can go ahead and [46:28] open that maybe even take that whole [46:34] routine and move it to the other part of [46:37] the file easily done and I believe that [46:40] split works any number of times so you [46:44] can actually see that same code file [46:48] many different parts and pull pull code [46:51] from several parts of it at the same [46:53] time [46:58] there were lots of power tools for you [47:02] know remembering where you'd been to [47:06] recently there's this idea of normalized [47:09] where you have a selection and it gets [47:12] pulled almost to the top of the screen [47:14] leaving a little bit of space for [47:16] context so anytime you select something [47:19] and normalize it that's what happens it [47:25] will remember previous selections and [47:27] and allow you to Reese elect them the [47:31] style kind button switches the fonts of [47:34] the document in order to show you what [47:36] it would look like if you printed it on [47:37] a laser printer instead of looking at it [47:41] on the screen like this obviously those [47:44] fonts are less readable on the screen [47:46] they make you appreciate the bitmap [47:48] fonts that I've been using in the demo [47:50] so far so um I'll go back to using them [47:54] those fonts alright let me talk a little [47:57] bit about the formatting of code so one [48:01] of the clever ideas in the Tioga text [48:03] editor is and the reason that you can [48:07] use it for both software and for [48:09] publications is the documents are split [48:13] into two parts [48:14] as far as their representation behind [48:16] the scenes there's the first part of the [48:19] document which is generally the text [48:21] content then there's a null character [48:24] and then after the null character [48:26] there's some additional data generally [48:29] binary data that tells Tioga things like [48:33] how to format the text above whether to [48:38] use bold or italics and also allows you [48:42] to add illustrations and so forth to the [48:45] code in fact the comments in cedar Mesa [48:49] code are not even seen by the compiler [48:52] because they also are stored at the at [48:55] the document past the null character so [49:00] and let me let me demonstrate that a [49:03] little bit [49:04] so I'm going to reset this and open a [49:10] smaller example I have a little [49:17] HelloWorld program here and one thing to [49:27] notice about this is that is the way [49:29] that it's formatted we have some text in [49:32] italics at the top [49:34] that's how see your format's comments so [49:37] those won't be seen by the compiler at [49:39] all I think key words that are in all [49:44] caps are shown in small caps font which [49:50] has a pleasing appearance to it and then [49:54] the names of procedures are bold and so [49:57] forth now in modern text editors modern [50:01] development environments that kind of [50:04] formatting would probably be generated [50:06] on the fly by a particular editor which [50:09] happens to know the the syntax of that [50:11] particular language but that's not [50:14] what's going on in cedar what's going on [50:16] in cedar is that it's actually [50:18] explicitly adding appearance commands to [50:22] the text and let's see here [50:26] let me see if I can turn off the [50:28] formatting for a second so here's our [50:32] edit tool again and I think I can clear [50:37] all the looks [50:38] let's clear them okay and if I wanted to [50:43] I could also take this text here and [50:46] tell it not to be a comment there we go [50:52] so there's a plain text version of the [50:54] document that we were just looking at [50:56] now I don't actually want the compiler [51:00] to look at this comment so I give a [51:04] command it happens to be controlled [51:05] backslash and that will turn something [51:08] into a comment it's gotten moved after [51:11] the null character so the compiler won't [51:12] see it and there's also a command [51:15] control M that applies the standard [51:20] cedar Mesa fonts to the various parts of [51:24] the document so there's some kind of fun [51:28] things that you can do once that you [51:30] know that that is going on so for [51:34] example if you if you wanted to put some [51:37] Greek characters in your text maybe [51:40] you're doing a little math and you've [51:43] discovered that you're interpolating [51:50] between several points so maybe you want [51:54] you've got a variable alpha and you want [51:58] to take one minus alpha and multiply it [52:01] by say value x0 and then you're going to [52:06] want to add alpha times some other [52:10] variable x1 now of course as I said [52:14] alpha you saw me type the letter A that [52:16] wasn't any fun mm-hm but let's fix that [52:20] so if I hold down the looks key and type [52:23] G for Greek now my a becomes an alpha [52:32] and there's my formula in a more [52:35] mathematical notation now I do have to [52:37] remember that that's really an a behind [52:40] there because the compiler isn't going [52:43] to see the Greek looks on that so I [52:45] can't have another variable named a in [52:48] the same method as that alpha but if I [52:51] like it for the the mathematical purity [52:54] of it I can go ahead and do that another [53:00] thing I really like about being able to [53:03] use Tioga for writing code is that you [53:05] can put pictures in your code and let me [53:10] show you that so when I was developing [53:16] The Gargoyle illustration system I [53:18] needed to do a lot of geometric [53:21] calculations including calculations on [53:24] lines arcs and circles so there's the [53:29] open arc command again and I've opened a [53:31] module called GG circles in pole Mesa [53:35] where Gigi scans for gargoyle Health [53:38] sort of short for gargoyle and I'm gonna [53:42] scroll down this file and their circle [53:45] meet circle and it has a picture in the [53:47] code labeled with some of the the names [53:52] of variables that are going to be used [53:54] in the code in order to give you a [53:56] feeling of what this does and in fact [53:59] there's a there's another picture that [54:02] goes with the code farther down so you [54:06] may wonder how do we put code pictures [54:09] in code and I'll show you that in just a [54:11] few minutes [54:18] it's also worth noting that the Tioga [54:22] text-editor because it is intended to be [54:26] used for code as well as publications [54:29] has some built-in buttons in the menus [54:33] at the top that help you out with code [54:36] one way or another so this module here [54:39] is an interface and let let me stop and [54:41] talk about that a little bit one of the [54:44] reasons why software reuse worked so [54:47] well in the seeder environment was that [54:50] anytime you wrote some library of [54:54] routines that were going to be called by [54:55] another module you had to define an [54:58] interface saying what what the what the [55:02] API was what the definitions were for [55:04] the various the various procedures that [55:08] were going to be available in the [55:10] library and so this module here this is [55:14] a seeder definitions it's an interface [55:19] and each of the the methods that you're [55:23] seeing here are do not have an [55:26] implementation they're only and they're [55:28] only interfaces so when you create a [55:32] circle from a point in a radius you give [55:34] it a point and you give it a real number [55:35] which is a radius really a [55:38] floating-point number but that's what [55:39] they're called in cedar and that it's [55:41] going to return an object called circle [55:43] which is of type circle no [55:46] implementation is provided the [55:49] implementation is always in a separate [55:51] module often with impl imple at the end [55:54] of its name in fact you can have [55:56] multiple implementation modules for a [55:59] single interface sometimes handy if the [56:01] file started to get too large and you [56:06] could even have multiple implementations [56:08] for the same interface so if you wanted [56:11] to have an experimental implementation [56:12] of some of these methods you could go [56:15] ahead and do that in a separate [56:17] implementation and later on when the [56:20] package gets gets put together and ready [56:23] to run you can choose which [56:25] implementation you want to use [56:28] now back to the Tioga commands if I [56:32] select a piece of text and click get [56:34] info that probably happens so fast that [56:38] you could hardly even see it but what [56:41] just happened was that interface the [56:45] cedar definitions was replaced by a [56:47] cedar program which is an implementation [56:50] and I believe it's going to refer to the [56:54] interface so and it's going to export [56:58] the interface so that's how you know [57:00] that this is an implementation of that [57:02] interface that we were just looking at [57:07] and similarly if if you use things like [57:13] the definitions button I believe that [57:16] will help you get to the definition of a [57:18] particular thing let's see if that works [57:22] so I'll select that click death [57:24] and there we are at the definition of [57:27] the procedure that has that particular [57:29] name so all of those things just are [57:31] built right into the menus at the top of [57:33] Tioga and available to you anytime that [57:36] you're programming alright let's change [57:41] gears a little bit and switch to a [57:43] different application I'll just close [57:47] this for now because I'm going to use it [57:49] later [57:54] and I'm going to show you the gargoyle [57:56] graphics tool move it over to the left [58:01] column and get rid of this object so [58:07] what you're looking at here is an [58:10] illustration tool it has a number of [58:15] built-in objects you can play with [58:18] squares and circles and triangles but [58:24] what's really fun about gargoyle is the [58:26] way that you can construct your own [58:28] objects and it has a method built into [58:31] it called snap dragging which I'll show [58:34] you in just a second this is a menu of [58:38] operations up at the top and this menu [58:43] was itself drawn with the gargoyle [58:45] editor using what we call documents as [58:48] user interfaces I'll talk a little bit [58:51] more about that later too and these are [58:54] also menus that help you with drawing [58:58] precise shapes so the idea of the snap [59:02] dragging techniques for drawing precise [59:04] precise shapes is that you can ask the [59:10] system to give you some guidelines it's [59:12] kind of like a ruler and compass [59:15] construction approach except without all [59:18] the tedium that you remember from ruler [59:20] and compass construction in high school [59:22] this is a system that builds all the [59:25] guidelines for you so for example if I [59:29] want to make an equilateral triangle [59:32] that has a horizontal base and is one [59:37] inches on a side I just start drawing [59:40] and the system is automatically giving [59:43] me some guidelines because I have [59:45] automatic mode turned on and there's my [59:48] equilateral triangle and if I want to I [59:53] can also let's see haven't done these [59:57] commands I don't want [59:59] let's see here all right there's drag [60:05] and rotate now let's see if I can figure [60:15] out [60:31] not that one [60:36] all right so that must be scale let me [60:40] try that one more time [61:00] there we go [61:03] all right so you've got your guidelines [61:06] you can make precise shapes and let me [61:11] show you how we would make kind of an [61:14] italic letter G so I say I want [61:17] guidelines at zero degrees which is [61:19] horizontal and also 60 degrees which is [61:22] a little to the right of vertical and I [61:24] start drawing and I don't need my [61:27] circles anymore [61:43] there's my letter G and gargle used some [61:50] of the same ideas that were used in the [61:52] taiga text editor as far as making use [61:55] of the mouse buttons so for example if [62:02] we want to take this part of the G here [62:09] so I I did a middle click to get the [62:14] whole edge just like selecting a word in [62:17] Tioga I do a right click to extend my [62:20] selection to this edge so now I've [62:23] selected all of these segments in [62:25] Gargoyle [62:25] and now I'm going to do the drag [62:28] operation and I'm able to drag just [62:35] those particular objects and if I have [62:38] my cursor here first then I can even [62:41] make use of the guidelines in order to [62:44] precisely hold that part of the G along [62:48] the guidelines as I'm moving it so now [62:54] let's say we wanted to take this G and [62:56] let's make it purple and maybe we feel [63:03] like it's a little too large so I'll [63:05] shrink it down a bit [63:10] and now maybe we want to add that to a [63:12] Tioga document whether it's code or a [63:15] conference paper so I'll move that over [63:20] here and now let's say for some reason [63:25] we want that purple G to be over here I [63:29] just leave the cursor there I come over [63:32] here and go to my I think it's the inter [63:38] press menu and there's an operation [63:41] stuff to Tioga now notice this menu that [63:44] just popped up as a lot of operations in [63:47] it but they're not in a single column [63:49] they're in three columns the left-hand [63:52] column means things that you can do that [63:55] you can accelerate by using the left [63:56] clicking on this but menu with the left [63:59] mouse button the mail calls for the [64:01] middle mouse button the right columns [64:03] for the right mouse button and also if [64:06] you hold down shift or control keys at [64:09] the same time that you're clicking you [64:11] can get to any of these commands here [64:13] and this particular menu has more than [64:16] twelve commands so there's some you can [64:18] only get to by popping the menu up like [64:20] this but the first twelve all have [64:23] accelerators now we can see that the [64:25] accelerator for stuff to Tioga is no [64:29] Shift key no control key and use the [64:32] middle mouse button so let's go ahead [64:34] and do that and I have to have a node [64:40] level selection so I'll double click [64:42] over there and there's our G so very [64:49] quick from drawing a picture in gargoyle [64:51] to getting it into Toyota [64:57] so I talked a little bit about this menu [65:00] up here and how it was drawn with [65:02] gargoyle itself using a system that we [65:05] called documents as user interfaces and [65:07] the idea there is that any of the [65:11] objects here whether they're text [65:13] objects or whether they're bits of [65:14] geometry can have some additional text [65:18] apply to them which describes what their [65:20] behavior should be when you click on [65:22] them and the document says user [65:25] interfaces system had kind of built-in [65:30] functionality for things like the pop-up [65:32] menu that we were just looking at and [65:35] let me show you some others so here's a [65:36] pop-up menu for doing fonts and so again [65:44] after you use gargle for a while you [65:46] know that if you want bold you've got a [65:48] you're going to hit this button using [65:50] the control key and the text is going to [65:52] become bold and actually let me show you [65:55] a bit of text I think I just start [65:58] typing yeah start typing that's great I [66:06] can select that and now if I remember I [66:09] hold down the control key do the [66:12] right-click and I'll get the largest of [66:14] the bold font choices so the more you [66:17] use gargoyle the faster you get at [66:19] operations like this because of the way [66:21] the menus work now this idea of [66:24] documents has user interfaces was used [66:29] in many different places so in addition [66:31] to being able to take objects in the [66:34] gargoyle illustration system and allow [66:36] them to have button behavior you could [66:40] also do that in Tioga including anywhere [66:43] that Tioga is used so here's a commander [66:49] window but of course we know it has [66:51] Tioga in it and there is this command [66:54] that we wrote called button LS which [67:00] does what an ordinary LS command does [67:03] except that in addition to listing all [67:06] the names of the files in that directory [67:08] it's added this extra rectangle before [67:11] each vaio now that rectangle ism is an [67:14] object that you can ask Tioga to put in [67:17] any document but this particular version [67:21] of the rectangle has some button [67:23] behavior behind it so that if you click [67:27] at it it's going to open that particular [67:31] file let me talk a little bit about DF [67:34] files and the commands bring over an S [67:37] model because they were another key to [67:41] why we were so productive in the seeder [67:44] environment so of course these days you [67:48] there are all kinds of version [67:50] management tools for software there was [67:52] been a whole line of them right so it's [67:55] very fairly popular right now there was [67:58] CVS and subversion and and so forth um [68:04] cedar had its own version of those but [68:07] it was quite easy to use so the idea was [68:13] that when you make a package in cedar [68:15] you you write a file for it that [68:19] describes which what is in that package [68:22] both what is directly in that package [68:25] and what it needs to import from the [68:27] cedar releases in order to work and so [68:31] for my little hello world file here I [68:35] created a DF file and you can see what [68:39] DF files look like [68:41] so here's hello dot DF at the top of the [68:46] file it automatically puts in the name [68:49] of the author of the file I happen to be [68:50] running as Eric be your super user so [68:53] that's why it's EBS you up there and [68:55] it's it's going to put itself in the [69:01] cedar 13.0 top directory that's where DF [69:04] files [69:04] go so if I if I use the put command what [69:09] you might call commit or push these days [69:14] that's the s model command in Cedar [69:17] where s is for system so you are [69:19] modeling a system by sending it out to [69:22] the file server then it says what what [69:26] files are directly part of this package [69:28] since this is just a little hello world [69:30] program we've only got one the hello [69:33] world implementation file and then it [69:36] tells you what packages it imports so it [69:39] needs one called atom and one called [69:41] basics and one called commander because [69:43] the hello world is going to involve [69:45] typing a command in the terminal and it [69:49] needs to do some IO and it needs some [69:51] strings which in Cedar were called ropes [69:53] and those are the immutable strings that [69:56] cedar provides and when I use this DF [70:01] file using the bring over command it's [70:04] going to go to this directory get this [70:07] file make me a copy of it and then go in [70:10] turn to each of these other DF files and [70:12] recursively bring over some of their [70:15] contents not all of their contents as [70:17] the using Clause here says which [70:19] particular modules from that package I [70:22] actually need to have locally in order [70:24] to do things like compile my own package [70:28] for example and the syntax at the end [70:31] the tilde equals and so forth a variety [70:34] of different syntax was possible there [70:36] to say always get the latest version of [70:39] that that package or get a version from [70:42] a particular date or only get it get it [70:46] if it's newer than the version that I [70:48] have locally a lot of the version [70:51] oriented commands like that so let me [70:56] see if I can actually do one so since [71:04] since I was one of the creators of The [71:06] Gargoyle illustration system let's see [71:09] if I can make a gargoyle directory looks [71:14] like that may already exists so let's [71:17] try that so a cedar 13 version of [71:22] gargoyle and now I'll use my find our [71:25] command and see where the DF file is [71:28] there it is and now I will say I want to [71:31] bring over that package I'll use my [71:34] shift my shift select to copy that into [71:37] the command looks like I made a typo [71:40] there and let's see if that works [71:46] so the DF file machinery did its magic [71:52] it found the gargoyle DF file and then [71:54] recursively went into any DF files that [71:57] gargoyle needed it copied over 366 files [72:02] and if I now do say a button LS in this [72:07] directory you can see that all of those [72:15] files are available to me to start doing [72:18] my work [72:24] and so in particular we're already we've [72:27] already looked at GG circles Mesa now [72:31] it's getting the local version of that [72:33] and if I wanted to I can get the [72:36] implementation which now gets the local [72:39] version of the implementation and I can [72:40] go ahead and start editing that and make [72:43] changes to the gargoyle system and just [72:50] to get a feeling for what compiling is [72:52] like let me go back to my little [72:55] HelloWorld program [73:03] and I'll open that so right now it's [73:09] gonna say hello world on January 24 2019 [73:13] maybe I'm out of time - that will do [73:18] 10:30 a.m. [73:20] hmm save the file I'll give a compiled [73:25] command now cedar had powerful tools [73:28] built-in for figuring out what needed to [73:30] be compiled so I can probably just say [73:35] Mako anyone figure it out nope not quite [73:46] sure how how you how you trigger it [73:50] against a whole package but drinking [73:52] against a single module worked just fine [73:54] so we just compiled hello world imple [73:57] and now I can run it and that's not what [74:07] I was hoping to see [74:11] let's try this again [74:18] there we go and what this command does [74:22] is it registers a command with the [74:24] commander the command is hello and I [74:29] think I'll give the hell out command and [74:34] there's the code that we just wrote [74:36] working and I think if I give it an [74:39] argument [74:50] forget how to get help I'll get it to [74:55] say what its usage is anyway so we [74:58] compiled and we ran hello world program [75:02] and Eric if you don't mind let me point [75:08] some other users of the DF files if [75:13] there is something specially to be [75:16] compiled or so that's figured out from [75:20] the DF file where have you seen Eric [75:23] ever linking some program you know how [75:27] many lines are sorry pages the linker [75:31] documentation has in certain systems [75:34] here Eric tits and say anything about [75:38] linking because whatever the linking is [75:41] will be read out of that one DF file [75:44] which seems so simple let me talk a [75:50] little bit more about the Cayuga being [75:56] both a publishing tool and a code editor [76:00] and the reasoning or the motivation [76:03] behind creating Tioga in that way I'll [76:09] do my best so as you see cedar gets a [76:13] lot of advantage of having the same text [76:16] editor everywhere right [76:19] so once you've learned the commands how [76:24] you create a paragraph how you make [76:26] something look bold how you apply a [76:29] style to something whatever it happens [76:32] to be then you can use that everywhere [76:35] and your your motor memory of course [76:39] learns when to hold down the ctrl or [76:41] shift key which mouse button to press [76:45] also the the copying mechanisms holding [76:53] down the shift key and then selecting [76:55] something everywhere having that work [76:58] everywhere so whether it's just a [77:02] a filled in a form on your screen or an [77:04] entire conference paper the same command [77:09] is going to work and you're going to be [77:11] able to copy your text from one place to [77:13] another so I don't know how much of that [77:18] was you know explicitly thought of and [77:22] designed in Cedar probably a lot of it [77:24] but I do know from having used it that [77:28] it was very convenient you could pull [77:32] pieces of text out of code and stick [77:34] them into a conference paper if that's [77:36] what you wanted to do take a picture [77:38] from the conference paper and put it in [77:40] the code all of that stuff just worked [77:43] it also meant that if you were trying to [77:46] explain to someone else [77:48] so your administrative assistant was [77:51] helping you with a conference paper you [77:54] could stand next to her while she worked [77:56] and say well you have to hold down the [77:58] ctrl key here and that piece of text is [78:02] going to move over there I would like to [78:05] expand on this answer a tiny little bit [78:08] remember when cedar was done there were [78:12] many other tools to look at how you [78:16] could do it which you could copy so it's [78:21] the wrong thing to ask why are the tools [78:26] done the same tools it's actually [78:29] obvious you you need a program editor [78:33] you have a text editor so why not use [78:37] that so if you ted to argue and to [78:42] reason at that time you would have to [78:45] reason why you would not want to do it [78:48] that way and that reminds me I talked a [78:54] lot about copying but it's also [79:00] interesting to spend a moment or two to [79:02] talk about moving and about pending [79:06] delete right so as I said before the [79:12] selection commands are quite powerful [79:15] and so I can select from a word to a [79:18] word now you probably noticed that when [79:21] I did that that the text that I just [79:22] selected became video reversed and the [79:27] reason for that is that often the reason [79:30] that you're making a selection like that [79:33] is that you're going to replace that [79:35] text with something else and the video [79:39] reverse means that if you start typing [79:41] now all of that text is going to go away [79:44] and something new will appear in its [79:47] place so that just comes for free the [79:51] pending delete but now I'm what if I [79:54] wanted to move text so again all of the [80:00] mouse operations are going to work and [80:03] I'm just going to change the keys that I [80:06] hold down with my left hand so if I hold [80:10] down the shift key as you know what's [80:12] going to happen is whatever I select is [80:15] going to be copied to my current cursor [80:18] position if I wanted to move it instead [80:24] so I don't want this sentence to be here [80:27] anymore I want it to be somewhere else [80:29] hmm then I hold down ctrl and shift and [80:34] it goes ahead and moves it instead of [80:36] copying it I was impressed I've never [80:42] seen cedar before her to see how [80:45] wonderful it is and also to see where [80:48] some of the been thinking about where [80:50] some of the ideas came from somewhere [80:52] very old like I think the setting the [80:54] the so called clipping level in Tioga I [80:57] believe goes clear back to Doug [81:00] Engelbart ALS system and I believe one [81:02] of the NLS people was Bill Paxton who [81:05] was the Tioga editor yes he certainly [81:09] worked on it so did Doug Wyatt and the [81:12] NLF system was much simpler but it was [81:15] very integrated things tended to be [81:18] applicable in in any possible place in [81:20] the when I was at Parc and Xerox in the [81:24] middle 70s [81:26] the alto had a very small memory each [81:28] program took over the entire alto and [81:31] things weren't integrated we had to use [81:32] simple little editors for for code and [81:35] fancier editors for documents often [81:39] cedar is able to but but there were [81:42] silla mentor techniques from the alto [81:45] that they did get into theater like the [81:47] film the left hand left sided scroll bar [81:52] some of the some of the ideas of [81:54] selection and and and finally I think [81:56] the the the sort of integration the fact [81:59] that you're using the the same component [82:02] everywhere definitely was something that [82:04] small talk was pioneering even on the [82:07] tiny tiny alto they were able to just [82:09] let you use a single editing tool a [82:12] single graphics tool in any possible [82:14] environment so finally with cedar with [82:16] the with a big powerful 1 megabyte [82:19] computer I was able to pull together all [82:23] those ideas and then add so much more [82:26] all the graphics really was was way [82:30] beyond what what was ever done on the [82:33] Alltel since Paul just mentioned the [82:37] levels again I thought I'd show that in [82:42] code which has many different levels of [82:44] indentation to it you can actually click [82:49] and click and click and keep getting [82:51] more and more and more detail and so if [82:55] you write long routines even ones that [82:57] are multiple pages long not considered [83:00] great coding practice but it sometimes [83:02] happens you can manage some of the [83:05] complexity of that by using the levels [83:09] each even down into the code itself was [83:15] tired a full WYSIWYG then I mean I guess [83:19] you mentioned like once you switched the [83:21] font to show the the printing fonts then [83:23] did did what to show it on the screen [83:26] match what would be printed [83:27] I don't think it was completely what you [83:32] see is what you get [83:33] opening that conference paper again and [83:38] putting it in print mode you see that [83:43] this is a two column conference paper [83:46] but we're not actually seeing two [83:49] columns here in Tioga that's not going [83:53] to happen until we turn it into inter [83:57] press or something like that or actually [83:59] send it to the printer okay [84:01] so you got a pretty good idea of what it [84:03] was going to look like but my yoga was [84:06] pretty much WYSIWYG but in the very [84:09] early times we did not have smooth [84:16] phones actually a smooth fonts were [84:19] still secret but so we had bitmap phones [84:23] which means when the text goes from the [84:27] screen to the printer it will print with [84:31] a mildly different font and they had to [84:34] be different because screen resolutions [84:37] could never match printer resolutions at [84:41] that time but eventually in in further [84:46] going on with cedar such differences got [84:49] it eliminated so you mentioned inter [84:54] press could you actually view inter [84:56] press files directly in cedar yes let's [85:04] see if we can do that [85:10] don't know if we have it here in Cedar [85:12] 13 but we might so there's a whole bunch [85:16] of inter press files and that's the ones [85:24] for two glasses and magic lenses let's [85:31] see alright so there it opened it in [85:34] Toyota now that that was probably [85:38] something called IP viewer or something [85:40] like that does anyone remember I was a [85:43] special viewer okay so that's inter [85:55] press it so there's IP register yep that [86:04] one I would have to look up but those [86:08] were the files that are sent directly to [86:10] the printer the printer understands [86:11] natively yes as you see I have inter [86:19] pressed files for a lot of the documents [86:21] in this directory so I think what I did [86:25] was make inter press files on them there [86:27] was a printer command to send them to [86:29] the printer it was very common to do to [86:32] look at the file for printing on the [86:35] monitor but again because of the font [86:40] problems the characters looked a little [86:43] bit odd you didn't really want to edit [86:47] printable files you edited Tioga files [86:52] and there is also some small differences [86:57] you might not even notice that the line [87:00] breaking of the files depended on the [87:03] window size and when you print the [87:09] column adjustment is is different [87:21] one thing I notice is that the interface [87:27] is I mean obviously it's it's very [87:29] consistent and very well-thought-out [87:33] it's also you know because of the [87:35] multiple mouse buttons it seems to be [87:38] geared towards powered users so I'm [87:42] wondering about like how easy is this [87:44] for a novice to learn are the various [87:47] commands easily discoverable right so as [87:56] I said it wasn't just researchers using [87:58] it the administrative assistants would [88:01] use it the artists would use it and they [88:04] were able to come up to speed it was [88:06] nice that that you could easily find the [88:09] documentation for each of the packages [88:11] and part of the seeder culture was that [88:17] you would write good documentation and [88:20] as I said there was conventions for what [88:22] you would call the documentation file if [88:25] you updated a package then there was a [88:28] convention for what you did then you [88:30] would use s model in order to save a new [88:34] copy and then you would use a specific [88:37] template in your email message to make [88:40] sure that you described all of the [88:42] things that you want to describe about [88:44] what change you've just made and which [88:45] package it was you changed and and it [88:49] was a convention also to update the [88:51] documentation if you'd made a change [88:53] that should be documented so the [88:56] documentation tended to be pretty usable [89:03] all right there is a package called [89:05] preview now let's see if it works [89:20] looks like I don't have the fonts I need [89:23] wait did you give me a window okay well [89:29] you know that the ease of use for [89:34] non-expert is something kind of funny if [89:38] you'd read the documentation or if you [89:41] listen to somebody explaining how it [89:45] works it sounds difficult and one of the [89:50] reason it's difficult is because we be [89:53] proud of it and we sometimes even [89:56] explain why something is in a particular [90:00] way it is but when you actually sit on [90:03] the machine and you are not thinking you [90:05] just use your fingers to do the [90:08] fingering for you then you will see the [90:12] the logic behind it so many commands you [90:17] can just come with the design ideas of [90:22] cedar and you will come out guess how it [90:26] works and yes it works that way [90:31] so here we are paging through a [90:33] conference paper using the yeah the [90:36] preview tool hmm of course the fonts are [90:39] not very readable at that size but we [90:42] can Wow scale them up there so those are [90:46] the full outlines of course if you sent [90:54] that to a laser printer the [90:56] administrator could easily write a text [91:00] document but the administrator would not [91:03] write a Tioga program and the [91:06] administrator would not design a chip [91:08] with the chip design editor we're given [91:12] the very technical nature the commands [91:15] might have been more technical but they [91:18] still used as much as possible the same [91:21] pattern as the [91:25] Tioga stuff but kind of obvious if you [91:29] wanted a metal line you pressed em and [91:32] if you wanted a transistor you press T [91:35] you know it came up with some other set [91:39] of commands which were application [91:42] specific so not absolutely everything [91:46] was completely integrated but a lot [91:50] right could you talk a little bit of [91:55] them out since you were the one of the [91:58] developers of gargoyle could talk about [92:01] your involvement in that how that [92:03] project started and the other people [92:08] that you work with sure gargoyle was a [92:12] lot of fun so gargoyle as I said is an [92:16] illustration tool and you saw a little [92:19] demo of it earlier and it grew out of my [92:23] dissertation at UC Berkeley it we had a [92:32] conference paper about it at the [92:34] SIGGRAPH conference in 1986 I think it [92:37] was so that's about when we were working [92:40] on and as far as my dissertation was [92:45] concerned I was really interested in the [92:48] the Snapdragon technique the kind of [92:50] ruler encompass on steroids technique [92:53] but I also really enjoyed building [92:58] software that other people were used [93:00] would use and we definitely have a long [93:04] tradition at Parc of using the tools we [93:07] build in a way cedar is one of the [93:10] glowing examples of that because this [93:15] was not just in a programming [93:17] environment where you you did something [93:20] that you would write a conference paper [93:21] about when someone built a new database [93:24] or a new text editor or a new graphics [93:26] editor or whatever it was everyone in [93:29] the community would start to use it [93:32] and so we noticed that people who were [93:36] using cedar wanted to put pictures in [93:39] things and that it would be great to [93:41] have a way to draw them and so Ken [93:46] Pierre in particular worked on Garr go [93:49] with me I think I probably got some help [93:51] from Maureen stone and and others as [93:54] well of course we were we were standing [93:58] on the shoulders of people like Michael [94:00] PLAs who built the cedar imager and so [94:04] there's a really powerful library that [94:06] has built into it [94:09] polygons and spline curves and and [94:12] clipping and resolution-independent [94:16] graphics so that once you got it to look [94:19] right on the screen you probably be able [94:21] to get it to print too and all that kind [94:22] of stuff [94:24] so adding an interactive end on top of [94:27] all of that graphical rendering power [94:31] made a lot of sense and folks like Steve [94:38] wahlgren who was a staff artist at the [94:41] time picked up gargoyle and used it for [94:44] lots of the things he needed for [94:47] graphics at Parc whether he was making [94:49] brochures or posters for the park forum [94:53] or whatever it happened to be so we had [94:59] a lot of fun seeing what what the [95:01] artists were able to do with gargoyle [95:04] now my dissertation was actually on [95:09] using the Snapdragon technique in both [95:11] three dimensions and two dimensions so [95:13] that was eventually a gargoyle 3d and [95:18] one of the delightful surprises of that [95:21] work was that some of the same mouse [95:25] button and keyboard button commands that [95:28] you can use to precisely draw objects in [95:30] two dimensions work in three dimensions [95:33] as well once you have the guidelines you [95:36] don't actually need to have a [95:38] three-dimensional cursor or moving or [95:41] in the world you can instead see [95:43] yourself as pointing a line from your [95:47] eye through your cursor into [95:49] three-dimensional space that then you [95:53] then snap to a three-dimensional [95:55] guideline or the surface of a sphere [95:58] which is the three dimensional analog of [96:01] the circles and ruler and compass [96:03] construction or onto the surface of a of [96:07] a plane and so just by beefing up the [96:11] alignment objects so that they were [96:14] three-dimensional you could quickly make [96:17] make precise shapes in three dimensions [96:20] and when I was working on that project I [96:23] would I would make a video once a week [96:26] and drive it across the bay bridge to UC [96:28] Berkeley where my thesis advisor at UC [96:31] Berkeley was was waiting to see what I'd [96:34] done that week who was just a surprise [96:38] man Carlos say can he and Brian Barsky [96:45] kind of how to assemble the a graphic [96:49] slab with lots of graduate students [96:52] there in Heaven's Hall easy Berkeley did [97:01] you say earlier that you wanted to show [97:03] some more features of the language ah [97:07] yes let's do that such as multiple [97:12] return values sure so let's um let's [97:16] look a little more closely at GG Circle [97:19] simple [97:26] so some interesting things about the [97:28] seeder language one interesting thing as [97:34] as you say you can have multiple return [97:38] values so here's a routine that we were [97:42] looking at before circle meat/meat [97:45] circle and the purpose of this routine [97:47] is to take two circles and see if they [97:51] intersect and if so at how many points [97:54] write and circles can intercept at a [97:57] intercept at a single point if they're [97:59] tangent they can intersect at two points [98:01] if they overlap and they can intersect [98:04] it no points if they're concentric or [98:06] far from each other and so forth so this [98:10] routine is going to return some [98:13] information about that intersection now [98:14] in many languages you're you're only [98:17] able to return a single object but [98:19] that's not true in cedar as you can see [98:22] here we've got the returns keyword here [98:26] are the input arguments we're going to [98:28] take a circle named circle one in a [98:30] circle named circle two here's the type [98:32] of those objects and then we're going to [98:35] return three different objects we're [98:39] going to return an array of point [98:41] objects we're going to return the number [98:45] of times that the two circles intersect [98:48] which will be a number between zero and [98:50] two and we'll return a boolean which [98:53] will be true or false saying whether or [98:55] not the the system thinks the circles [98:57] are tangent and the way this actually [99:02] happens is that just by naming these [99:06] return values you've created a variable [99:09] that's local to this procedure that you [99:12] can begin to use so let's use the fine [99:16] machinery here there we go already [99:18] starting to assign a value to point sub [99:23] one now another interesting thing to [99:26] notice here is these this syntax for [99:28] ranges right so we know that this is an [99:31] array not only do we know that it has [99:34] two things but we're going to call the [99:36] first one one and [99:37] second one - right so whereas most [99:40] arrays and encode start counting at zero [99:43] for whatever reason we decided to start [99:46] counting at one here and we made that [99:47] explicit in the in the declaration there [99:52] even a little otter is you know in most [99:56] programming languages you just say hit [99:58] counts an integer right but it's so easy [100:01] in seeder to say well actually there's a [100:04] constraint on this integer we can tell [100:05] you right now it's going to be 0 1 or 2 [100:09] so so that was actually explicitly put [100:13] in the declaration there and the funny [100:17] little left arrow here is the assignment [100:19] character in seeder instead of a regular [100:21] equal sign and we we were able to give [100:27] the return value a default value right [100:31] there in the in the header of this [100:33] method as well did see to use a lot of [100:37] non ASCII standard characters not a lot [100:43] just a few and and yeah the left arrow [100:48] is one of the strange ones so there [100:50] would be there were special keys on the [100:52] keyboard to type those characters yes I [100:57] believe so [100:59] when we ported seeder to the Sun [101:03] computers to the Sun operating systems [101:06] which happened in the late 80s obviously [101:11] we had to do some key mappings so that [101:15] the the keys that we would expect on the [101:17] seedier keyboard which was the alto [101:20] keyboard would have analogs on whatever [101:25] keyboard you were going to have with [101:27] your Sun workstation and I actually was [101:31] one of the people who did that keyboard [101:33] mapping ok I also helped to port the [101:37] viewers window system to to the Sun [101:41] operating systems back around 1987 we [101:45] had this project called windows by [101:46] winter where we were trying to get [101:49] viewers working on the side [101:50] microsystems you know before December 20 [101:53] 21st I don't remember whether or not we [101:56] succeeded but I'm sure we came close so [102:00] then the d machines all inherited the [102:03] alto keyboard and the character set as [102:05] well that's what I remember the way I [102:12] remember it the the left error was the [102:16] only character which was problematic on [102:18] keyboard and that got replaced by Cole [102:21] and equals and once you write colon [102:28] equals you don't have any special [102:30] characters which are important to the [102:33] language and when I left Xerox I did for [102:42] years to come still occasionally today [102:45] I've write equals and I mean with equals [102:52] that we do a comparison and not an [102:56] assignment but considered colon equals [103:02] vs. and single equals is so much more [103:05] intuitive than having two equals or just [103:08] one equal and I can add a few more [103:15] feature on the seedier language if [103:18] that's okay with you Eric please do one [103:23] Xerox might have been inventing [103:27] object-oriented languages with small [103:31] talk when Cedar come out there is no [103:35] object-oriented feature on the language [103:38] at all however there is enough [103:40] primitives that object-oriented [103:44] programming has been the norm I am not [103:48] aware of a single program which didn't [103:51] use the object features of cedar but [103:56] they were done with the primitives which [103:58] were basically function variables and [104:03] closures and nested functions so lambda [104:11] expressions something which occurs [104:14] without having lambda mentioned in the [104:16] manual it's very simple you make [104:19] closures in nested functions and do you [104:22] heaven [104:24] another thing see their head from the [104:28] beginning where multi-threading I am [104:32] aware of one programming theory which [104:35] does not use multi-threading it's [104:38] possible there are more but the one I do [104:40] remember that's the compiler itself [104:45] actually threads were even in Mesa [104:47] before see here oh you're absolutely [104:50] right a lot of things where even in Mesa [104:53] before they were in cedar cedar made [104:57] them easy to use and it's so natural but [105:09] it's it's hard to point out the [105:15] individual little features like the [105:20] module eric was mentioning that is also [105:24] coming down from Mesa but it has been a [105:28] lot of simplified in theater I think [105:32] without losing power by the way I found [105:36] another nice example of adding font [105:41] appearances in code so here's a variable [105:45] d2 but it actually represents a distance [105:49] squared so by I'm giving it superscript [105:53] looks you make it queer clear that oh [105:56] well that's of course that's a distance [105:59] squared what else would deep T squared [106:03] be [106:06] but yeah there was a powerful error [106:10] handling mechanism just lots of support [106:14] for throwing exceptions catching them [106:17] again re throwing them again that was [106:20] all in cedar and then the [106:23] synchronization primitives for for [106:26] dealing with multi-threading it's [106:29] interesting you mentioned the error [106:30] handling because that's more than just [106:36] error handling since in early cedar the [106:40] debugger was written in cedar and the [106:42] debugger figured out about everything [106:45] about variables so the cedar language [106:48] allowed self inspection and this was a [106:54] frequently used what what's now very [107:00] modern like runtime type inspection that [107:05] has been in cedar all the time instead [107:09] of having objects there was a a type [107:13] which was called R if any so that was [107:17] bound to pointers and if a pointer was [107:21] called a reference that meant that at [107:24] runtime you could figure out what the [107:28] type of that point of russ and your [107:30] program could run select statements [107:33] according to what type a variable really [107:37] is so you mentioned the cedar is [107:40] strongly typed did was there word was [107:46] there concept of generics or was that [107:51] something that you were able to live [107:53] without in the cedar language there's [107:57] one feature of generics which really [108:02] make them useful beyond what you do in [108:05] cedar in cedar you do not program with [108:09] generics what you did is you were [108:11] programming with the ref any so that [108:14] thing could be whatever it had to be it [108:18] did [108:18] do the function of generics with one [108:21] little exception and that was the [108:23] performance because if you use generics [108:27] like you do them today you would have [108:30] zero overhead for some extensions and [108:35] that little detail was not in theater [108:38] but having had a Dorado computer one was [108:42] missing that right so if so say you [108:46] wanted you would just have an array that [108:49] would have ref any's two other other [108:52] things [108:53] tiny something one could do yeah [109:01] so you also mentioned that people tended [109:05] to program in an object-oriented style [109:08] by building up from the primitives that [109:12] were already in the language even though [109:14] it did not explicitly support [109:16] object-oriented programming in the [109:19] language definition so you mentioned [109:21] that that was done with a combination of [109:22] closures and nested functions there is a [109:28] pattern which is found in many many [109:31] programs that the function has a with [109:36] any argument so what you did is you [109:41] wrote your code by calling a function [109:45] which is a very generic argument like [109:48] Ruffini and could give in to that [109:51] function whatever you wanted to give in [109:53] to that function and also the fact that [109:57] functions were nested allows you to use [110:00] the outer variables of your functions so [110:05] by using function variables you could [110:11] create pretty tough to read patterns [110:14] where a holdback used a callback back [110:20] into the original program which might [110:22] use a different callback back into the [110:25] pro-- the function which was originally [110:27] called and these patterns you kind of [110:32] had to [110:32] and how they they look like but they had [110:37] the power one needed yes it sounds like [110:42] the even though mace mace is cedar Mesa [110:44] was explicitly a strongly typed language [110:49] with ref any you could actually program [110:52] in a more loosely typed fashion this is [110:56] absolutely true and it is an explicitly [111:00] typed language in the sense that [111:03] everything has its type if any also has [111:07] a type with any it's just at run time [111:11] it can be a whatever other type pointer [111:16] you want to assign to that Rivini but [111:20] the program text is strongly typed and [111:24] if you use the run time typing it was [111:27] still strongly typed but it was then [111:30] typed at run time so I just noticed [111:38] something interesting in the code that [111:40] I'd forgotten about so we have this type [111:43] circle it's defined to be a reference to [111:46] a circle object I have a circle object [111:49] and it's defined to be defined in [111:53] another another module and when we make [111:56] a new circle it's of type circle but [111:59] we're making a new circle object so [112:02] there was this kind of distinction [112:04] between the thing and the reference to [112:07] the thing that shows up in the type [112:09] declarations [112:15] so is the reference to the thing treated [112:17] as a different type or is there sort of [112:20] a notion of a type and a reference to [112:23] that type there's always a reference to [112:26] you that you can make a reference to [112:27] that type it's a separate type in the [112:30] sense that it has its own name you can [112:32] refer to it you can ask if this variable [112:34] is a circle you could ask if it's a [112:36] circle object right okay that in spite [112:39] of being a separate type the language [112:42] allowed to shortcut when you have you [112:48] want to follow a chain of pointers you [112:51] didn't have to explicitly follow the [112:53] change so in that sense you could type a [112:56] dot which could either follow a pointer [113:00] or be a field of a structure I wanted to [113:04] say just a few words about um the Dorado [113:07] cursor oh sure that's because I remember [113:10] that follow this is not a Dorado cursor [113:11] obviously this is the next Windows [113:13] cursor but one of the interesting things [113:16] about the Dorado was that it dedicated [113:18] some of its CPU time to drawing the [113:22] cursor on the screen every few cycles [113:25] the the cursor would be updated and what [113:29] that meant was that the cursor was one [113:31] of the most reliable objects on the [113:33] screen even if there was a problem and [113:36] the rest of cedar had frozen the cursor [113:39] would still move around track your mouse [113:41] nicely know your application may have [113:45] fallen behind and and have ten events [113:48] that it hasn't processed yet but [113:50] nonetheless the cursor would rigidly [113:53] track your hand what that also meant was [113:57] that if you wanted a really reliable way [113:59] to communicate with the user that's [114:02] going to work even when some things have [114:05] gone wrong you could do that by putting [114:07] a number in the cursor so you know [114:11] various kinds of error messages were [114:13] just numbers that appeared in the cursor [114:16] and we all learned what those numbers [114:17] meant and I think 815 was a really [114:24] important one yeah [114:26] so here you have it some little in [114:29] user-interface detail only experts could [114:33] use but you can add more on your last [114:39] words but my last word would be I wish I [114:42] had it yes and cedar had a suspend [114:48] mechanism so you could go back to a [114:51] previous state you could check point and [114:55] you could roll back the entire [114:58] environment or it was essentially you [115:01] were suspending and resuming right you [115:05] were storing your state and as a as a [115:10] joke one year someone wrote a little [115:12] song to the to the tune of let's do the [115:16] time-warp again from Rocky Horror except [115:19] it was let's do the roll back again [115:22] anyway anyone else have any last words [115:26] thank you Eric [115:27] yes thank you very much for thank you [115:30] you are very welcome [115:35] so one of the things that I was just [115:39] demoing without talking about it was [115:41] this command open are these commands [115:43] open are and find our I believe the R is [115:47] for release and open in the sense I've [115:52] opened something for editing or viewing [116:01] you