Thoughts on SICP 1.1
Section 1.1 of SICP starts of with some simple, straight forward basics of programming languages, but at the same time provided some deep food for thought.
Judging for this limited exposure, Scheme has a very minimal syntax and is incredibly regular. We learn how to use expressions and names. Names are similar to variable names from a language like Java, but are more general in that they also serve the purpose of naming data or functions, by placing them into the current environment.
Next we see that we can combine expressions and that a grouping of operator followed by operands is called a combination. Again very simple and regular. The postfix notation doesn't bother me since I have spent some time playing with Common Lisp for doing generative graphics.
The section on substitution models is really fascinating and I am having a hard time keeping the two notions straight. The two notions being applicative order and normal order. I have created a mnemonic "nORmal order is ||". This means most substitution follows the textual pattern, except some things are conditionally or lazily computed, just like || in Java. If we say
if( foo() || bar() ){ baz() } in Java, it is poosible that bar() may never be computed.
I had rarely considered this formally as a first class notion. I have created a template language in the past and when implementing looping and conditional logic I had to implement a normal order substitution model, but just kind of stumbled through it, without the formal perspective.
Scheme seems to run in applicative order normally, except for when you declare that you want to step out into normal order.
The chapter moves on to look at Newton's Method for approximating square roots. These mathematical passages are challenging to me, and I better buck up if I am going to finish this book. Perhaps I will learn a fair amount of math along the way. It would be great to rewrite the domain aspect of this text using the domain of web programming instead of math :) Of course you would have to dive into input output very early, which isn't desirable from a pedagogical point of view.
Lastly this chapter defines several functions in a nested fashion within an overall function. This left me in awe for a few minutes. Wowsers. This is so simple, regular, and powerful! This immediately reminded me of Java classes and how they must be implemented under the covers. Except that Java has many more restrictions and semantics on top of the class keyword. Here we are left with the raw power and goodness of nested function definition. Parameters to the top-most function are visible within the scope of the nested function. The nested function isn't defined in the global environment, and thus doesn't pollute it's namespace. The is something really interesting going on here, which I think will become clearer as I gain more experience with these constructs, but all ready it sets my mind alight.
The ability to name functions and nest functions allows us to build powerful black box abstractions. No notion of interface or documentation has been introduced yet, but the idea is that you can tell someone if you calll operator X with arguments y and z then you can expect foo as a result.
This allows construction of programs in a layered fashion, whereby each piece follows contracts between interfaces and the overall complexity of the system is broken down into manageable chunks that can be
- tested
- thought about
- reused
Exercises 1.5 and 1.6 were great. Working them out on paper, as well as exploring some possibilities from Scheme REPL really helps to understand the substitution model.