3 ms·

I have been thinking about some user-configurable UI systems like Smalltalk, Plan9, Emacs, Factor language and so on. I think we need a name for this, it's lik

by js8 5y ago

I have been thinking about some user-configurable UI systems like Smalltalk, Plan9, Emacs, Factor language and so on. I think we need a name for this, it's like an operating system but "backwards". The operating system is a common API/abstraction for programs/applications to access hardware devices, and control access to resources. But this is different, these UI systems are a common abstraction for human interacting with different programs/applications. So it is human (not a device) who is being abstracted by them, and the applications written to that abstraction can be run under the UI.

TeMPOraL 5y ago
> user-configurable UI systems like Smalltalk, Plan9, Emacs, Factor language and so on The way I think about them, these are not "UI systems". These are operating systems. That's how I see my Emacs. It's an operating system I work in, running as a guest in whatever traditional OS I happen to have on the machine. It provides a common API/abstraction to access resources and interface with the user[0]. It coordinates applications running on top of it. The magic of Emacs comes from a slightly different approach: it's more focused, less restrictive, and deeply introspectable. By focused I mean, the core paradigm is that applications communicate with users through means of "buffers" containing rich text. Less restrictive - everything can talk to everything else, including poking at its internal state if it so desires. Because Emacs embraces this level of deep interoperability, it provides tools and culture[1] that help manage what would be otherwise ridiculously large interaction surface. And almost everything is thoroughly documented, you can quickly discover what code is being run to make something happen, jump to the definition of anything (including Emacs' C core, if you built from source), and potentially modify it and have the changes applied without restarting. Being able to easily modify the UI you work with is a nice side effect of these features, but it's nowhere near the whole reason they're there. -- [0] - More of the latter than of the former by default, but you can expand the API surface to cover more of the responsibilities of a typical OS if you need to. [1] - For example, defadvice is a tool you can use to extend, modify and suppress any individual function in any Elisp executing in Emacs. It allows users to do things that would otherwise be bug-prone hacks, but it's still too much power for most use cases. This is where the culture comes in - both Emacs and third-party packages typically expose great many hooks around various activities, in anticipation of things people may want to override or extend. In practice, these hooks cover 90% of the things anyone may ever want, so defadvice is a rare sight.
- js8 5y ago
  I am making a case we should not call these environments "operating systems", they are more like "shells". Because the integration of applications (common API) in the OS happens towards the hardware, while here, it happens towards the user. So it's different from an OS, and ideally, you should be able to mix and match the environment and the OS as you wish (as you do, you said you run on a "guest" OS). Then we wouldn't care so much whether the applications are on the desktop or in the cloud.
  - TeMPOraL 5y ago
    Ok, I see what you mean now. You're right, there are two separate concerns here that could be considered orthogonal.

by js8 5y ago

TeMPOraL 5y ago

> user-configurable UI systems like Smalltalk, Plan9, Emacs, Factor language and so on The way I think about them, these are not "UI systems". These are operating systems. That's how I see my Emacs. It's an operating system I work in, running as a guest in whatever traditional OS I happen to have on the machine. It provides a common API/abstraction to access resources and interface with the user[0]. It coordinates applications running on top of it. The magic of Emacs comes from a slightly different approach: it's more focused, less restrictive, and deeply introspectable. By focused I mean, the core paradigm is that applications communicate with users through means of "buffers" containing rich text. Less restrictive - everything can talk to everything else, including poking at its internal state if it so desires. Because Emacs embraces this level of deep interoperability, it provides tools and culture[1] that help manage what would be otherwise ridiculously large interaction surface. And almost everything is thoroughly documented, you can quickly discover what code is being run to make something happen, jump to the definition of anything (including Emacs' C core, if you built from source), and potentially modify it and have the changes applied without restarting. Being able to easily modify the UI you work with is a nice side effect of these features, but it's nowhere near the whole reason they're there. -- [0] - More of the latter than of the former by default, but you can expand the API surface to cover more of the responsibilities of a typical OS if you need to. [1] - For example, defadvice is a tool you can use to extend, modify and suppress any individual function in any Elisp executing in Emacs. It allows users to do things that would otherwise be bug-prone hacks, but it's still too much power for most use cases. This is where the culture comes in - both Emacs and third-party packages typically expose great many hooks around various activities, in anticipation of things people may want to override or extend. In practice, these hooks cover 90% of the things anyone may ever want, so defadvice is a rare sight.

js8 5y ago
I am making a case we should not call these environments "operating systems", they are more like "shells". Because the integration of applications (common API) in the OS happens towards the hardware, while here, it happens towards the user. So it's different from an OS, and ideally, you should be able to mix and match the environment and the OS as you wish (as you do, you said you run on a "guest" OS). Then we wouldn't care so much whether the applications are on the desktop or in the cloud.
- TeMPOraL 5y ago
  Ok, I see what you mean now. You're right, there are two separate concerns here that could be considered orthogonal.