4 ms·

In the early days of a field or subfield there is such an explosion of creativity, but this is followed by a series of consolidations and we tend to forget the

In the early days of a field or subfield there is such an explosion of creativity, but this is followed by a series of consolidations and we tend to forget the “losers” of the initial competition and the beautiful paths they illuminated. See C/Unix vs Lisp/Lisp Machines vs Smalltalk/Alto. Or NeWS vs X. Alan Kay shows the beauty of HyperCard (the “loser” in networked hypertext) vs Web. We had in HyperCard a visual hypertext app dev and reading environment that was trivially programmable / writeable in some very powerful ways for any determined user, using a GUI authoring tool. Now what do we have? Yet another Algol like programming language whose capabilities are severely constrained — and more importantly which is is not remotely a realistic user authoring environment, hell even paid professional programmers have trouble keeping up with JavaScript, the browsers as dev platforms, and the surrounding tooling/libs. More broadly, it’s dismaying how rapidly and seemingly permanently our collective expectations as developers have fallen. Kay is right: What we have in the web stack is not enough and we should not settle. A quote from Kay I enjoyed: “You have to include all media that computers can give rise to, and you have to do it in a form that allows both “reading” and “writing” and the “equivalent of literature” for all users. “Examples of how to do some of this existed before the web and the web browser, so what has happened is that a critically weak subset has managed to dominate the imaginations of most people — including computer people — to the point that what is possible and what is needed has for all intents and purposes disappeared.” It’s also amazing what we settled for in networked computing when I read his notes in this system from 40 years ago: “ perhaps the best early structuring and next stage design of Unix was Locus by Gerry Popek and his researchers at UCLA in the early 80s. Locus allowed live Unix processes to migrate not just from one machine to another on a network, but to a variety of machine types. This was done by combining the safety required for interrupts with multiple code hooks in each process, so an “interrupt” could allow the process to be moved to a different machine and resumed with different (equivalent) code. ”

deleted 4y ago
[deleted]
josephg 4y ago
> Locus allowed live Unix processes to migrate not just from one machine to another on a network, but to a variety of machine types. My personal take on this is that need to make the data layer in computers transparent. Files are currently opaque sets of bytes which need an application specific parser to interact with them. And when you have programs that can interact with a file, the only operations are read and write. Realistically, you can only have one program editing a file at once. Even having multiple programs reading a file at the same time is often a bit broken. Instead, what if files were structured (think JSON or SQL). And instead of overwriting the file when you hit save, the application could send granular updates to the files’ content as edits happened. (Eg update Foo.bar.baz = 22, or the sql equivalent). And applications listen for changes in the data model, so another application (maybe on a different computer)! Can edit something in the file, and the changes get propagated live. There’s all sorts of benefits to this: - We can enable collaborative editing in all applications for free - It’s super easy to make plugins for applications - just make another program which interacts with the data. No plug-in api needed. - The Unix philosophy is strengthened because multiple small programs can work with the same data at once. We can split out IDEs into a lot more small tools. - Users have lots of devices. This sort of thing would make data able to move between their devices in a way that’s transparent to the application. Like live collaborative editing Dropbox. We need CRDTs to do it properly. But the technology behind that is more or less solved at this point. Honestly I think the hardest thing will be getting OS people on board. I think it’s about time we shook up how the filesystem works. open/read/write basically haven’t changed in 50 years.
- pavlov 4y ago
  Microsoft made a huge bet on this exact idea in the mid-1990s as part of their Cairo OS project. When Cairo fizzled, the database file system became a separate component called WinFS but didn’t result in any end-user product: https://en.wikipedia.org/wiki/WinFS https://en.wikipedia.org/wiki/WinFS
  - josephg 4y ago
    What went wrong? Was it just a failure to deliver?

deleted 4y ago

[deleted]

josephg 4y ago

> Locus allowed live Unix processes to migrate not just from one machine to another on a network, but to a variety of machine types. My personal take on this is that need to make the data layer in computers transparent. Files are currently opaque sets of bytes which need an application specific parser to interact with them. And when you have programs that can interact with a file, the only operations are read and write. Realistically, you can only have one program editing a file at once. Even having multiple programs reading a file at the same time is often a bit broken. Instead, what if files were structured (think JSON or SQL). And instead of overwriting the file when you hit save, the application could send granular updates to the files’ content as edits happened. (Eg update Foo.bar.baz = 22, or the sql equivalent). And applications listen for changes in the data model, so another application (maybe on a different computer)! Can edit something in the file, and the changes get propagated live. There’s all sorts of benefits to this: - We can enable collaborative editing in all applications for free - It’s super easy to make plugins for applications - just make another program which interacts with the data. No plug-in api needed. - The Unix philosophy is strengthened because multiple small programs can work with the same data at once. We can split out IDEs into a lot more small tools. - Users have lots of devices. This sort of thing would make data able to move between their devices in a way that’s transparent to the application. Like live collaborative editing Dropbox. We need CRDTs to do it properly. But the technology behind that is more or less solved at this point. Honestly I think the hardest thing will be getting OS people on board. I think it’s about time we shook up how the filesystem works. open/read/write basically haven’t changed in 50 years.

pavlov 4y ago
Microsoft made a huge bet on this exact idea in the mid-1990s as part of their Cairo OS project. When Cairo fizzled, the database file system became a separate component called WinFS but didn’t result in any end-user product: https://en.wikipedia.org/wiki/WinFS https://en.wikipedia.org/wiki/WinFS
- josephg 4y ago
  What went wrong? Was it just a failure to deliver?