This talk follows a familiar pattern in historiography of computing: the "golden days" of Lisp machines, Smalltalk workstations, Plan 9/Oberon awesomeness, etc. In other words, glorified tales of better days, as told by grey-bearded veterans.
The speaker does not touch at all the details of *why* all of these were superseded by supposedly worse and more complex systems, "What went wrong?"
The systems that are being romanticized in the talk were a coder's delight, a peak of personal productivity, discoverability, malleability. They did have an integrated rich UI, where everything is a programmable action, everything is traceable and introspectable, wrapped by human-usable keyboard/mouse actions and UI presentation.
Still, they handled structuring, versioning and communicating *complex data* badly, something which was solved much better even by Unix/Windows-style filesystems and utilities. Plan 9 was an improvement over Unix in many aspects, but handling data complexity was not one of them.
My suspicion is that what is still very lacking today is well structured and introspectable data, system-wide schemas, rigorously defined ABIs, serialization and IPC mechanisms, transactional guarantees. Mo more raw streams/blobs of bytes everywhere, no more untyped pipes, no more poorly defined structs in C headers that implicitly define ever-changing ABIs, no more file systems without transactional guarantees, no more reimplementation of sorting and filtering in every Unix utility. I hope that the state of the art has advanced far enough to finally have a useful and comprehensive common language for data and interaction (Fuchsia's FIDL + capnproto + a kind of Kaitai Struct on steroids?), including network communication (kind of a global IPFS-like database of schemas?).
So no, moving back to the "good old days" of a magic old programming language is not the answer, in my opinion. There are other pressing issues that have never been solved well before and may be finally solved now.
> The speaker does not touch at all the details of why all of these were superseded by supposedly worse and more complex systems, "What went wrong?"
I did the talk, FWIW.
I didn't much because it would have turned it into a very different talk, and frankly a rather depressing one.
The real answer is very simple:
They were superseded by cheaper systems, which could be built and maintained by less-skilled and therefore cheaper people. And possibly also used by less-skilled people.
Partly. Not just them; in a way, MS was an outgrowth.
MS DOS wasn't written in C. MS BASIC wasn't.
But Windows was. And they didn't have a good direction for Windows until they got OS/2 3 in the divorce from IBM, and hired Dave Cutler et al from DEC to finish it and make it work.
OS/2 and NT were built using tools developed on (and for) UNIX. Mostly, C.
Win NT is the next generation of both DEC VMS and OS/2, and it was built using the language that was being honed on, and for, VMS' rival on the PDP-11 and VAX: UNIX.
The speaker does not touch at all the details of *why* all of these were superseded by supposedly worse and more complex systems, "What went wrong?"
The systems that are being romanticized in the talk were a coder's delight, a peak of personal productivity, discoverability, malleability. They did have an integrated rich UI, where everything is a programmable action, everything is traceable and introspectable, wrapped by human-usable keyboard/mouse actions and UI presentation.
Still, they handled structuring, versioning and communicating *complex data* badly, something which was solved much better even by Unix/Windows-style filesystems and utilities. Plan 9 was an improvement over Unix in many aspects, but handling data complexity was not one of them.
My suspicion is that what is still very lacking today is well structured and introspectable data, system-wide schemas, rigorously defined ABIs, serialization and IPC mechanisms, transactional guarantees. Mo more raw streams/blobs of bytes everywhere, no more untyped pipes, no more poorly defined structs in C headers that implicitly define ever-changing ABIs, no more file systems without transactional guarantees, no more reimplementation of sorting and filtering in every Unix utility. I hope that the state of the art has advanced far enough to finally have a useful and comprehensive common language for data and interaction (Fuchsia's FIDL + capnproto + a kind of Kaitai Struct on steroids?), including network communication (kind of a global IPFS-like database of schemas?).
So no, moving back to the "good old days" of a magic old programming language is not the answer, in my opinion. There are other pressing issues that have never been solved well before and may be finally solved now.