Continuing that thought, I feel that the tools we use are very much disconnected from each other. Of course that is the basic tenet, tools which do one thing well. However, tools serve a specific purpose, which in itself can be characterised as providing a specific service. It seems strange that basically the only widely applicable way to connect very different tools is the shell, respectively calling out to other programs.
I would argue that using some another paradigms could rather help to make the interplay between services in this sense much easier. For example, if we were to use not only a message bus, line in Plan9, but also a shared blackboard-like database to exchange messages in a common format, then having different daemons react on state changes would be much easier.
Of course, this would already be possible if the one point, a common exchange format, was satisfied. In that case, using file system notifications together with files, pipes, fifos etc. would probably be enough to have largely the same system, but based on the file system abstraction.
Imagine now, that programs actually were actually reusing functionality from
other services. My favourite pet-peeve would be a shared bookmark list, cookie
store, whatever browsers typically reimplement. It should be no surprise that
very focused browsers like uzbl actually do just that, allowing for the
combination of different programs rather then the reimplementation of basic
components.
It's unfortunate that tools like mailcap and xdg-open aren't very
integrated into shell workflow. Even though names like vim, or feh are
muscle-memory for me, having unified generic nomenclature for actions like
open, edit would be very helpful as a first step into a more programmable
environment. Plan9-like decision-making for how to respond to these requests,
or like the aforementioned blackboard/messaging architecture all go into the
same direction.
If we now compare how command-line tools respond to queries, so for an abstract
command like help it would naturally be foo --help (and shame on you if
your tool then outputs "Use man foo."; git does it right fortunately), then
we can see how we can procede from here. Not only should we adapt these kind
of queries, but reflectivity is absolutely necessary to provide a more
organised system.
Even though "worse is better", it hinders the tighter linking of tools, as everything first goes to serialised form, then back through the OS layers. Despite dreaming of a more civilised age (you know, Lisp Machines), a compromise based on light-weight message-passing in a service-based approach, relying on deamons as the implementation detail to provide functionality could be viable. Essentially, what can't be done in a single global memory space we emulate.
Sounds awfully like CORBA and DBUS, right? Well I think an important consideration is the complexity of the protocol versus the effort spent on integration. If it is very easy to link existing applications up to the message bus and if that system allows not only message passing, but also provides styleguides and an implementation of the basic interaction schemes (RPC call, two-way communication, ...), then what sounds otherwise like a lot of reimplementation might actually be more like leveraging existing infrastructure instead.
