The traditional model for administrative automation is powerful and successful. It consists of:
A programmatic shell (e.g. sh, csh, ksh, bash)
A set of administrative commands (e.g. ifconfig, ps, chmod, kill)
A set of text manipulation utilities (e.g. awk, grep, sed).
Administrative GUIs layered on top of commands and utilities
This model's philosophy is that every executable should do a narrow set of functions and complex functions should be composed by pipelining or sequencing executables together. This model has been extremely successful despite serious drawbacks. Upon inspection, what is widely considered a UNIX stronghold is in fact a flawed implementation of this model.
When you step back and examine what is really going on when someone uses a pipelined command like "$ a | b | c", you conclude that the first command "a" did not accomplish what the admin wanted to do. If it had, the admin would have just type "a" and been done with it. So then the question is why didn't "a" do what the admin wanted? The answer is that in this traditional model, the stand-alone executables tightly bind three operations together: 1) getting objects; 2) processing objects; 3) outputting results as text. One of those operations does not do what the admin needs so the rest of the pipeline is an attempt to fix that.
Because the executable outputs text, the downstream elements must use text manipulation utilities to try to get back to the original objects to do additional work. While the basic model is extremely powerful, its intrinsic flaw is the tight binding of these operations and the use of unstructured text for integration. This requires clumsy, lossy, imprecise text manipulation utilities.
The traditional model reflects the state of the technology that was available at the time it emerged. .Net provides a new set of capabilities and opens up the possibility of new approaches. These new approaches allow us to replace the traditional model with a decisively superior one. That model is Monad.