With a scattering of honorable exceptions, the overwhelming mass of contemporary software is mysterious and fragile: Almost any unexpected event or circumstance results in complete failure, and in general there is no systematic way of discovering what a program is doing or why it has failed to perform as sexpected.
Dealing with the unexpected and helping the user understand the state and problems of the computation are at best dealt with as minor afterthoughs, and typically simply not dealt with at all: The standard explanation for failure is basically "Segment violation".
This is no longer necessary, and is rapidly ceasing to become tolerable.
We are rapidly entering an era where everyday users perform network-driven computations involving dozens of machines and millions of lines of code. Completey failure must become dramatically less frequent, and when automated success is not possible, the software must be able to involve the user constructively in resolving the problem.
Muq is an excellent platform on which to explore these requirements and work out programming methologies for meeting them:
With a little thought and work, we can have a software environment in which short-lived computations are robust and unmysterious, and in which long-lived computations can be actively steered by the user as easily and naturally as a boat or car.
Go to the first, previous, next, last section, table of contents.