Thu Nov 14 07:34:36 EST 2019

Two kinds of code

... that arise when evolving systems over time with radically changing

- Top level system glue

- Self-contained modules

The reason to split them up is that they are fundamentally different.
The latter's point is to LIMIT behavior and make it more mathematical,
i.e. ensure it has properties,

The former then satisfies the fluffly cloud of human interface and
social process requirements, which always seem to boil down to
SPAGHETTIFICATION: connect everything to everything without any real
properties, just a cloud of objects with arbitrary reactive patterns.

In most systems it is possible to move some of the non-modular code
into modular code once it is understood, but this is a slow process.
Once identified, it should be refactored though, because real
spaghetti code will eventually hit a wall.

Typically this boils down to introducing 1. function and procedure
abstraction (write libraries), or 2. object clustering (e.g. Erlang's
supervisor networks that manage clusters of objects as units).

Procedure abstraction is preferred, as it is the only approach that is
reusable.  Object clusters are often too specific to a particular task
or (hardware) architecture.  The need for separate tasks seems to
always be driven by a physical property.

To maintain spaghetti code, aim for discoverability, rapid
(instantaneous?) development cycle, and don't make things too
abstract: stick to objects (services) and message passing.