Abstraction
There are two phases at which constraints are imposed upon software:
- At run-time (i.e. when the software is executing on a machine) the constraints are imposed by the limits of physical hardware resources:
CPU cycles, memory, storage, I/O bandwidth & latency.
- Earlier, at design-time (i.e. while the software is being written by programmers),
the constraints are imposed by the maximum amount of complexity a human mind is capable of holding:
most people can hold items in chunks of at most three within their working memory;
in any useful software the number of both instructions & data elements is very likely to exceed three;
therefore our only hope for being able to reason about non-trivial software is by using abstraction
to encapsulate software into self-contained modules that interact with each other.
There are two broad categories of abstraction possible: representational (data) & operational (instructions).
The fundamental theorem of software engineering: any problem can be solved by adding another layer of indirection,
except the problem of having too many layers of indirection.
When you get the humour behind that aphorism, you will truly understand how to build software.
For now, just keep in mind that a very common approach to solving problems involves decomposing them into a set of simpler problems.
Next: read about operations on data.