Xerox Star User Interface (1982) 1 of 2

There are a few demos of the Xerox Star floating around on YouTube. Seeing it in action gives you a much more complete picture of the system. [VIDEO] The "look" was obviously hugely influential, the "feel" not so much. It is quite an odd beast, as the mouse is actually only used for selecting objects. The Lisa GUI prototypes are also and interesting bit of GUI trivia. It's easy to see the Star's influence on the final shipping version of the Lisa GUI compared to its prototypes. [LINK]

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] [VIDEO] [LINK]

Mainly videos Self [LINK] Xerox Star User Interface [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 [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] [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: [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. [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. [VIDEO]