SICP Initial Thoughts

After installing Racket I opened my browser to MIT's excellent book, Structure and Interpretation of Computer Programs. I have been through a four year engineering course, but never in all my time have I come across a textbook quite as impressive as this. I only had to get as far as the foreword to be amazed by the level of thought and clarity of writing observed in this text.

It opens with a strong and declarative first paragraph.

Educators, generals, dieticians, psychologists, and parents program. Armies, students, and some societies are programmed. An assault on large problems employs a succession of programs, most of which spring into existence en route. These programs are rife with issues that appear to be particular to the problem at hand. To appreciate programming as an intellectual activity in its own right you must turn to computer programming; you must read and write computer programs -- many of them. It doesn't matter much what the programs are about or what applications they serve. What does matter is how well they perform and how smoothly they fit with other programs in the creation of still greater programs. The programmer must seek both perfection of part and adequacy of collection.

To me, this first paragraph for the entire book gets to the real heart of programming. What it is, why we do it, and how. It invokes the mystical and powerful nature of programming that has entrapped many a young technologist.  It describes the difficulties faced on the road to learning this dark art; and hints that the road will be a long one. Programming is an art; perfected through practice and discipline.

Every computer program is a model, hatched in the mind, of a real or mental process. These processes, arising from human experience and thought, are huge in number, intricate in detail, and at any time only partially understood. They are modeled to our permanent satisfaction rarely by our computer programs. Thus even though our programs are carefully handcrafted discrete collections of symbols, mosaics of interlocking functions, they continually evolve: we change them as our perception of the model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle. The source of the 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!

This is such a beautiful description of our art form. It lays plain that the real product of a programmers' work is not code; it is a model. This model dictates how we interface between the real world and the logic of a computer. This model may be but a part of a larger model, an actor in a greater world. As programmers we wrestle with these models; we seek to understand and optimise the model, until we can finally fit it within the constraints of a computer program.

Unfortunately, as programs get large and complicated, as they almost always do, the adequacy, consistency, and correctness of the specifications themselves become open to doubt, so that complete formal arguments of correctness seldom accompany large programs. Since large programs grow from small ones, it is crucial that we develop an arsenal of standard program structures of whose correctness we have become sure -- we call them idioms -- and learn to combine them into larger structures using organizational techniques of proven value.

Now the writer speaks about the content of this book, and its purpose. Computer programs always start small. Large computer programs are often made of many smaller programs. Unfortunately, as larger programs form, it becomes harder to manage the agreement of specifications and implementations. This is where computer science can help. By forming standard techniques in the form of idioms and algorithms, we can ensure consistency and quality in the approach taken no matter what problem is at hand.

Next, the language used in this text is considered.

Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises.

I think this is actually a reasonable approximation of the difference between the widespread modern languages such as C# and Java in comparison to some more academic or experimental languages. The former often strive to build structures and machines that may be very static and uninteresting in nature, but will stand the test of time. The latter type of languages seem to be very much more dynamic and unstable in nature, often trying new and outlandish ideas in particular areas of the language for a potentially positive gain. The writer finishes by adding:

As a result the pyramid must stand unchanged for a millennium; the organism must evolve or perish.

This is also a great description of modern businesses; the current hive of innovation in silicon valley is all about this "fail fast, evolve or perish" type of environment; meanwhile many much larger companies (and industries) that have long stood the test of time are starting to crumble in the face of such opposition.

To me, this book has already stirred deep thoughts on the nature of computer programming, and of the technology industry at large, and I have yet to write a line of code. It will be interesting to see whether the rest of the book is as enlightening.

All quotes are sourced from the Foreword of the book Structure and Interpretation of Computer Programs by Alan J. Perlis.