Analysis and Synthesis in programming
Fri Dec 4 19:15:17 2015
The ancients developed the notion of "Analysis", which is breaking things apart to understand them better, and "Synthesis" which is putting things together to make something new. Several pages on ProjectRho make note of this, "[Within] the realm of thought there are only two operations possible: Analysis and Synthesis. That is, cutting something into pieces and merging two pieces into one. http://www.projectrho.com/elemental.html.
This isn't a bad start, and is even self-documenting, in that it analyzes thinking by breaking it into two parts.
Programming is essentially a process of analysis of a problem. Before you can write a program, you have to know how to solve the problem, and you have to have decomposed the problem into simple enough pieces that it is easy to write computer code to solve each piece. If you can't do this, either because you can't solve the original problem, or because you can't break the problem down far enough for the parts to be expressible in a way the computer can understand, you will not be successful at programming.
Where does synthesis come in? Synthesis is related to the notion of code-reuse.
The unix philosophy makes things easier, much easier in fact, to build and rebuild systems in two ways that complement each other.
First unix encourages making each analytic chunk a separarable piece of code, and in particular, a separate executable that can be run all by itself. So if you've analyzed a problem into three components A, B, and C, the unix way of doing things is to actually write three programs A, B, and C that solve the components independently.
However, this leaves the problem of how do you combine A, B, and C into something that solves the original problem, or to use the terminology above, how do you synthesize them into a whole? What unix does to make this easy is the clever and simple solution of having (essentially) all programs communicate in the same way. A program accepts input via a mechanism called, logically enough, "standard input", and writes its results to, as you might guess, "standard output". Standard input and output are then usually just simple streams of text. By using this mechanism, and by having the interface between components be simple streams of text, it becomes possible to use a given piece of code in new ways very simply by inserting it into the middle of the stream.
So, suppose you are solving some other problem which happens to break down into components X, Y, and Z. If component B happens to match component Y (or X, or Z, it doesn't matter), you don't have to then spend any time on solving Y, because you can just re-use B. But you couldn't do that directly if you hadn't written B as a completely separate component, at best you might look at the first problem and try to extract the code for B out to use. A lot of times this is harder than just re-writing from scratch. Even extracting the code to for your component Y assumes that you recognize that some part of the original program matches your Y and can be used as such, which is less likely if B isn't a separate component to begin with.
It's not just the synthesis part that doing things the unix way allows, it's the analysis part too. Normally a problem doesn't break down (i.e. analyze) into just one level of sub-problems. Instead, you have some problem, that you analyze into parts A, B, and C, but then when you go to solve B, you discover that you need to break down B into B1, B2, and B3, and tackling B3 you may find you need to solve B3a, B3b, and B3c. B3b may then break down further, and so on. (I don't mean to imply that all problems decompose into three parts, these are just examples.)
Unix makes even the analysis part easier, because you may, and frequently do, find that problem B3 has already been solved and there's a standard or pre-existing tool for solving B3. By using that tool for B3, you don't need to go break B3 down any further, no matter how complex B3 actually is. Indeed, the history and consistency of unix is such that a lot of the truly hard problems are already solved and a lot of time indeed is saved by just re-using standard tools.
Posted in / software