Oleg dreams himself to something like Plan9: > ...
# linking-together
j
Oleg dreams himself to something like Plan9:
This paper is an attempt to imagine what an OS would look like and how it would work if looking for a word 'foo' in something and deleting/closing/stopping this something, -- be it a paragraph of text, a network connection, a subscribed newsgroup, a process -- would all require roughly the same sequence of mouse clicks or keystrokes, and would be understood and interpreted in the same spirit by the operating system.
http://okmij.org/ftp/papers/DreamOSPaper.html
c
This reminds me of Joel Spolsky's blog Don't Let Architecture Astronauts Scare You. The fact that there are three distinct English words "deleting/closing/stopping" suggests to me that users will have no trouble remembering and repeating these different actions. An abstraction is useful when we want to operate at the level of the abstraction, across different implementations. How often are users going to want to delete a line of text at the same time as close a network connection or stop a process? Very, very rarely imo. -------- https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there’s a general pattern: sending files. That’s one level of abstraction already. Then they go up one more level: people send files, but web browsers also “_send_” requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It’s the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it’s getting really vague and nobody really knows what they’re talking about any more. Blah.
When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.
s
That excerpt should end with, “and then they have truly become mathematicians.”
a
Yeah, but our job as programming tool developers is precisely to climb that mountain and stop in the right place. That's how all our programming abstractions got started, starting with lambda. And while programming tool design is very similar to math on one side, it's very similar to OS design on the other, with both focusing on possible actions a user can take, specified in digital form, to accomplish a goal, plus all the overlap in runtime design.
s
There’s time for engineering and there’s time for science. The key is to know when to use which.
j
@Chris Knott I can only surmise from this reply that you did not read the paper. Nonetheless, as a sign of good will, I made you some art inspired by the phrase "architecture astronaut"...
❤️ 1
c
I read it, although perhaps I misunderstood it if you are suggesting this response is not relevant...?
j
You said "How often are users going to want to delete a line of text at the same time as close a network connection or stop a process?" He makes no suggestion that they would. Instead, he talks about using a conceptually similar framework for interacting with the many databases that are maintained by the operating system, which would mean that when one seeks to perform an action they would have less cognitive work to do in order to figure out how to complete their desired task. This is in spirit similar to how Plan9 improves upon the Unix model by using the file API to interact with various system and non-system services.
c
I didn't mean to suggest that the author proposed that, that was my own thoughts on when such abstractions actually have practical use. As in; when tested against my personal rule of thumb for whether an abstraction is a good idea, I don't believe these suggestions pass it.
I am assuming the original namers of, for example, files, folders and pipes, chose these names because they felt their behaviour was naturally analogous to physical files, folders and pipes. In the real world a notepad and a pipe are very different things. Nobody thinks "hmm, writing in this notebook is really the same operation as sending water down this pipe". This is not a useful thought for anyone to have. To be clear, I am an architecture astronaut by nature, the aesthetic attraction of a unifying abstraction is very strong for me, but I don't believe it makes the system more practically useful. It's something I have tried to train myself to fight