Structure and interpretation of Computer Programs
As I delved down the rabbit role of writing code, particularly looking to delve more into functional programming, a number of folks I respected and asked for advice mentioned the book Structure and Interpretation of Computer Programs. I was also recommended The Little Schemer as I was writing some recursive programs. What follows are quotes, musings and examples from those books and various other sources.
Programming as art, as a way of expressing thought
In order to be creative one must first gain control of the medium. One can not even begin to think about organizing a great photograph without having the skills to make it happen. In engineering, as in other creative arts, we must learn to do analysis to support our efforts in synthesis. One cannot build a beautiful and functional bridge without a knowledge of steel and dirt and considerable mathematical technique for using this knowledge to compute the properties of structures. Similarly, one cannot build a beautiful computer system without a deep understanding of how to “previsualise” the process generated by the procedures one writes. – Daniel P. Friedman
Every computer program is a mode, hatched in the mind, of a real or mental process. These processes, arising from human experience and though, are huge in number, intricate in detail, and at any time only partially understood. Thus even though our programs are carefully hand-crafted discrete collections of symbols, mosaics of interlocking functions, they continually evolve: we change them as our perception of the model deepens, enlarges, generalises until the model ultimately attains a metastable (stable state of a dynamical system) place within still another model with which we struggle.
The source of exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms expressed as programs and the explosion of perception they generate. If art interprets our dreams, the computer executes them in the guise of programs!
Each breakthrough in hardware technology leads to more massive programming enterprises, new organisational principles, and an enrichment of abstract models. Every reader should aks themselves periodically “Toward what end, toward what end?” - but do not ask it too often lest you pass up the fun pf programming for the constipation of bitter-sweet philosophy.
- We control complexity by building abstractions that hide details when appropriate.
- We control complexity by establishing conventional interfaces that enable us to construct systems by combining standard, well-understood pieces in a “mix and match” way.
- We control complexity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and de-emphasises others.
Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology the study of the structure of knowledge from an imperative point of view (describe the steps to take, like a recipe), as opposed to the more declarative (describe the desired state) point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.” – Alan J. Perlis
A programmer should acquire good algorithms and idioms.