Reading note of SICP (4)

Aug. 10th. Complete the 1st chapter of sicp.

I really appreciate the exercises within each subsections, because I can feel that they are well designed. I used to have the same feeling when I did the homework from Dan's course of programming languages. The exercises make the general concepts concrete and doable.

The abstraction is far from merely making the code more structured and readable. It is a design choice. Sometimes, it takes experience to find out where should be abstracted. And sometimes, it takes much more endeavors than simply mix everything together. But once the choice of abstraction is right, the program becomes clearer, and it increases many degrees of freedom for the design afterwards.

Reading note of SICP (3)

 
At the end of the 1st chapter, it enumerates the basic reason for the powerful lisp: first-order procedure.

The major "privileges" of the first-order elements are:
1) They may be named by variables.
2) They may be passed as arguments to procedures.
3) They may be returned as the results of procedures.
4) They may be included in data structures.
They can be crucial abstraction mechanism permitting to express the general methods of computing as explicit elements in programming language, so that they can be handled just like other computational elements. The expression power is enormous.

I have already been used to use the first two kinds of procedures, but the last two actually make the program even more expressive and powerful. Those are also the attractive properties sharing among functional programming languages.

Reading note of SICP (2)

While I am reading, I always try to distinguish which part of thoughts I used to learn from here when I read it for the first time, and which part I learned from Dan's course. And, surprisingly enough, I learned almost all basic factors from Dan, though I always felt I learned a lot of things last year when I began to read it.

The name of this book is perfect for the content -- Structure and Interpretation of Computer Programs. It does not teach about how to program, nor a specific programming language. Of course it is a legacy book. But it seems to me that I cannot get enough from this book unless I have mastered quite a few programming languages. After Dan taught me everything about basic aspects of programming languages and I played with Ruby and Racket for a long time, even after I leaned all those "nontrivial" trivial things about C++, when I read it now, I am able to distinguish which part is the essence and which part is written just for the ease of learning, and I can fully focus on how to put different abstractions into different layers-- in other words, learning the structure and interpretation of computer programs.

I read a comment, saying that Chapter 4 and 5 are the essence of the book. Hopefully, I can finish reading it before September, and leave enough time for Design Patterns.

Reading note of SICP

P59. I still don't think it is necessary to use "square" instead of (* x x) everywhere we perform this operation, but I appreciate the idea of "abstraction". It is really a good idea (and practice) to abstract concepts in different levels and use them accordingly.

Most of the examples I read are in a top-down design manner: firstly use the abstract concepts, and then implement it in a lower level. The concerns for specific lower-level modules is similar to the way I did using unit test. But I am a little bit confuse how to perform the unit test in this manner. Especially for the closure using in LISP--implementing local helper functions right after building major function-- how can I make sure the helper functions are right before I run the program as a whole? If I separate a helper function as an independent one, it seems that quite a little redundant work has to perform when I move it back to the major function.

Anyway, SICP just makes me love Racket even more =D

cheers,