3 ms·
I thought your comparison w/ Emacs was apt. When analysed as an interactive application Oberon makes me think the most Acme, then Emacs. I'm struggling with de
by enqk 10y ago
I thought your comparison w/ Emacs was apt.
When analysed as an interactive application Oberon makes me think the most Acme, then Emacs. I'm struggling with defining the genuine distinctions between operating system, application server and applications.
It seems the distinction has to do with boundaries and how they are enforced, and by whom (I.e. the amount of user control one has on factors such as security, isolation in contrast to the application writer)
- sedachv 10y ago> When analysed as an interactive application Oberon makes me think the most Acme, then Emacs. Rob Pike borrowed the UI/UX of Acme from Oberon: http://plan9.bell-labs.com/sys/doc/acme/acme.html http://plan9.bell-labs.com/sys/doc/acme/acme.html IMO the Oberon/Acme text-based command approach suffers all of the problems of Unix shells, which are caused by lack of type information. Symbolics Genera's Dynamic Windows used the mouse in a similar way to Oberon but with actions guided by type information, concepts which can be found today in the Common Lisp Interface Manager (https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager). There are Emacs modes like SLIME that do similar things and are widely used.
- ricksplat 10y ago>I'm struggling with defining the genuine distinctions between operating system, application server and applications. Two important concepts are abstraction as you go up the stack (towards the application) and generalisation of functionality as you go down (towards the OS).