Xerox Star User Interface (1982) 1 of 2

Except the original Lisp and Smalltalk environments are much more than a simple REPL. Sometimes I wish people would learn about computing history. Presentation from Kalman Reti about Lisp Machines, check the interactivity starting at 00:44:00 and how to introduce mouse sensitive images at 01:00:00 link Xerox presentations about Smalltalk-80 link this video link

Mainly videos Self link Xerox Star User Interface this video link Tektronix 4404 Smalltalk link The Smalltalk-80 Programming System link The Final Demonstration of the Xerox 'Star' computer link Symbolics Hypertext Document link

Self link Xerox Star User Interface this video link Tektronix 4404 Smalltalk link The Smalltalk-80 Programming System link The Final Demonstration of the Xerox 'Star' computer link Symbolics Hypertext Document link Warren Teitelman work at Xerox PARC link The Mesa/Cedar programming environment link Steve Jobs internal demo of NeXTSTEP 3, link Alan Kay on Xerox PARC work link link link

Faire enough, so prepare for an history lesson. :) Mesa/Cedar was created at Xerox PARC, as an extension of the Xerox Star 8010 system, which was programmed in Mesa, the language that inspired Niklaus Wirth to create Modula-2. link this video link Mesa evolved to Mesa/Cedar, which allowed for automatic memory management via reference counting and a tracing collector for the cycles. link The environment had a REPL and debugger inspired by the Smalltalk and Lisp systems at Xerox. Think of Swift Playgrounds, kind of. This system inspired Niklaus Wirth to create Oberon, which you can read about in his book, about how the OS was built. link In 2013, Niklaus Wirth revised the language and updated the book for a FPGA based computer. link There were several generations of the Oberon OS, the last one before it stop being relevant, the Bluebottle OS coded in Active Oberon variant. link It had a strange mix of UI, using a mix of text and mouse input. Basically all applications were dynamic modules and the procedures/functions with a special signature could be used from the UI. So you could select text or objects from applications, and invoke such operations on the selection. The Oberon System 3 and Oberon V4 with their Gadgets framework were the best experience, before AOS was designed. Most relevant OS in Modula-3 was SPIN OS, link There were a few others, this is just a small sample.

Way too much to cover in depth. In short, it's all terrible. We're mostly using tools from the 70s, and we're still to this day plagued by use-after-free and out-of-bounds errors, nullpointer exceptions, awful debuggers, race conditions, slow compilation times, bad primitives for multithreaded work, just to name a few. We've known for decades that we can do better and ways to do better have been studied in depth by academia. That's just the basics. Then there is futuristic things: Why can't we move running processes from one physical machine to another? Where are the debuggers that allow you to go back and forward in time? Why can't we visualize the data structures in our program and trivially change the data layout to see how that affects performance? When I look at the demo of the Xerox Sparc interface (1982) and compare that to where we are today it's pretty clear to me we messed up big time somewhere along the road: this video

The thing that horrifies me about all of this is that instead of criticizing or fixing issues most people adapt what they do and even how they think to match all the deficiencies in software. Often, users simply can't imagine systems that work fundamentally differently and better. Often, when deficiencies are pointed out people start defending the mess and pointing out all the clever (half-assed, really) workaround and hacks they came up with. They are proud of all the time they spent (wasted) learning about obscure and counter-intuitive software functionality. They are proud that barely-working plugin/extensions/add-on they found and set up. All of that to do thing that should be trivial to begin with. One counter-point, though. > I make no secret of hating the mouse. If you look at the original uses of the mouse it was great. Especially in systems like Xerox Star. Star allowed people to perform complex tasks with almost no learning curve. this video (Note how they weren't shy of using keyboard either. There are dedicated hardware buttons for standard commands like copy, find, repeat, "properties" and even for common text editing actions. Meanwhile, our keyboards don't have dedicated keys for undo, redo, cut, copy and paste - operations that are used in almost every application today.) Trouble is, we lost most of the driving ideas behind Xerox-style interfaces. Using a predefined set generic, powerful commands. Object-oriented UI. Uniformity of representations. Modern system ha

> At the time, it was a huge leap forward in desktop computing. After seeing some old demos of Xerox Star, I'd question that. this video

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded. (The following paragraph is not directed at the author of the parent post. It's fully rhetorical.) Did you know that icons were supposed to be live representations of in-memory objects? That objects were more fundamental for the OS than files? Did you know that windows were views onto those objects? Did you know that interactions to and between icons were synonymous with OOP polymorphism? this video And this isn't the best UI, it's simply the first modern UI.

Worth remembering: the original windowed interface on Xerox machines was a view into underlying system objects . It was designed around a unified vocabulary of interactions that allowed user to message those objects and also direct inter-object communication: this video Xerox -> Apple -> Microsoft interface transfer preserved nothing of those core concepts. UI became a crutch developers grudgingly added to the system for "those stupid users". Thus, most software engineers today are still convinced that a teletype emulation is the best possible interface to the underlying OS that can possibly exist. Also, normal users are treated as second-class citizens in their own systems.

> How did IBM and Apple take over and Xerox end up as a has-been also ran? They were too far ahead of their time. The component costs needed to come down first. In 1981, the "starter kit" for their office system consisted of one Xerox Star for a user, a second Star to act as a file and print server, and a laser printer for about a quarter of a million dollars in today's money. Each additional networked Star that you added was about $50,000 in today's money. Even at those prices, the system wasn't exactly snappy. I do wonder what would have happened if they had kept iterating on the product until faster, cheaper components arrived. this video

FYI if interested in visuals for the earlier system OS System .85! - link (December 4, 1983) System 1 - link System 2 - link System 3 - link System 4 - link System 5 - link System 6 - link (April 1988) Bonus round - Xerox Star UX (1982) - this video