Solving SICP

This report is written as a post-mortem of a project that has, perhaps, been the author’s most extensive personal project: creating a complete and comprehensive solution to one of the most famous programming problem sets in the modern computer science curriculum “Structure and Interpretation of Computer Programs”, by Abelson, Sussman, and Sussman (\cite{Abelson1996}).

It measures exactly:

How much effort SICP requires (729 hours 19 minutes (over eight months), 292 sessions).
How many computer languages it involves (6).
How many pieces of software are required (9).
How much communication with peers is needed.

It suggests:

A practical software-supported task management procedure for solving coursework.
Several improvements, on the technical side, to any hard skills teaching process.
Several improvements, on the social side, to any kind of teaching process.

The solution is published online (the source code and pdf file):

http://gitlab.com/Lockywolf/chibi-sicp (\cite{chibi-sicp})

This report (and the data in the appendix) can be applied immediately as:

A single-point estimate of the SICP problem set difficulty.
A class handout aimed at increasing students’ motivation to study.
A data source for a study of learning patterns among adult professionals aiming for continuing education.
An “almost ready” protocol for a convenient problem-set solution procedure, which produces artefacts that can be later used as a student portfolio.
An “almost ready”, and “almost convenient” protocol for measuring time consumption of almost any problem set expressible in a digital form.

Additionally, a time-tracking data analysis can be reproduced interactively in the org-mode version of this report. (See: Appendix: Emacs Lisp code for data analysis)

Read full paper

A Review for GNU Autotools by John Calcote (1st. ed.)

/ I saw a book titled ≪Die GNU Autotools≫ and I thought “My feelings exactly”. Turns out the book was in German. – Tim Martin./

I have read the GNU Autotools: A Practitioner’s Guide by John Calcote.

This is a small review of mine. This time the review is really small, mainly because there already is a good review, written by Flameeyes https://flameeyes.blog/2010/08/20/book-review-autotools-by-john-calcote/, and even though ther review was arranged by the original publisher, No Starch Press , it is technically accurate and psychologically unbiased.

What I do have to add are just a few of my own experiences.

Russian kids are not taught a proper lesson in computer information exchange.

While this statement is a bit radical, most often there is not a single consice introductory lecture which would teach people how to make descent programs, and saying broader, software pakages out of scattered and disperse algorithms, which people are taught to create in high school and in universities.

Most people learn this by either struggling with Microsoft’s documentation, or (even worse) by copying existing Free Software projects, and tweaking the scripts.

This is a very bad approach.

I know, this is a very emotional statement. But my experience says the following: the less structured is the field you are studying, the more structure needs to be present withing the courses given.

As an example: C, C++, HTML, are reasonably well-structured topics. No matter how you approach the studying, there is only one definitive standard of those, and you have almost no chance of completing your tasks successfully unless you comply with the rules.

As an opposite example, creative writing is not that structured. Your literature teacher may give you good grades, or bad grades, but that would quite often be affected by his personal properties rather than his experiences with the audience you are targeting. In case of the high school class essays this doesn’t matter so much, because your target audience IS your teacher, but it gives you little expertise on how to write for other people.

Therefore, creative writing teaching should require much more elaborate courses than computer programming, exactly to overcome this uncertainty.

Making software packages is an ill-defined task.

You cannot ever solve it precisely. You can reach some level of closeness to the original goal, but as life evolves, your projects have no choice but to adapt to the changing world. Therefore creating software packages is a badly structured task

This makes it necessary to have a structured course. Calcote’s book provides such a course.

Indeed, despite being called “A practitioner’s guide.”, it is more of a good theory treatise than a cookbook. And this is good, not bad. Nowadays canned recipies are in abundace, at StackOverflow, for example. But well-narrated explanations are as rare as they have ever been.

Shall this book be studied at school.

No. Of course not. But it would be a very good idea to let university freshmen read this book as a part of their ‘practice of programming’ introductory classes.

Statistics

This book is 315 pages long, and required 29 hours 54 minutes of my time, including doing exersises and writing this review. This makes it roughly 10 pages per hour, 6 minutes per page. Those were produced in 11 study sessions, each session 2 to 4 hours, and was accomplished in one week, with more than one session per day on the weekend. The book was printed out on paper, and I was making annotations with a pencil. For practical text writing I was using GNU Emacs 26.2. In the

Bibliography

GNU Emacs Manual 26.1

I have read the GNU Emacs manual. Before you turn away and switch to a
less propaganda-oriented topic, let me pledge that I’ll try to stick to only
speaking about the book itself, and its influence on me, rather than the
software it describes. This may sound a bit counter-intuitive, but I am
aiming at the audience slightly broader than purely operating systems
enthusiasts or even professional programmers. And as such, the book as a representation of a way of thinking would be more valuable than the actual
software itself.

Continue reading “GNU Emacs Manual 26.1” →