Program Structure
Editorial Programming has come a long way since the early days of programs written in assembly. Most notably, programs are much larger today. The size of current programs makes them prohibitive to understand all at once. The obvious question then is how to divide the programs into pieces that are easier to understand. As code grew, we needed better and better answers to that question.
The answers were not always obvious. While today we take for granted lexical scoping, it was not always the most common scoping mechanism. Many programs used only global variables for state. Structured programming (using subroutines, ifs, and loop constructs instead of gotos and other jumps) was not common until the 1970s. And the idea of module or object boundaries which would hide implementation details was not obvious when it was invented. The history is rich with missteps and controversies.
But this history is still unfolding. It is important to keep that in mind as we face an ever-growing codebase. What structures will help us build more powerful software more easily? Can we find new ways to group and separate pieces of software so that we can compose them later? From where we stand today, libraries and APIs seem to be the largest structures that are still recomposable. What is next?
Clojure is exploring this space at many levels. At the level of the let statement, it has non-rebindable names for values. It is pioneering the use of small interfaces not merely for implementation hiding but for composability. And at the largest level, how systems can communicate with structured and extensible data.
Enjoy
Eric Normand <ericwnormand@gmail.com>
P.S. Feel free to email me any time. I love hearing from readers. | 
