the psychology of computer programming

is an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
I've read this book twice before, once here, and again here.

We must deal with one other problem, which is important because of a seldom questioned view of programming - a view which this book will spend a great deal of time questioning. That view is that programming is an individual activity.

Now that hardware has grown cheaper whilst labor has grown more expensive, group members are much less likely to share a machine and system than there were years ago.

The requirement to develop capability cannot be met adequately by a single person. We learn much faster and much better with the active cooperation of others.

Has anyone ever thought of asking appplicants whether or not they like programmming?

With adults, however, the barriers to learning have usually become internalized, and the average adult learns very little of left to his own devices.

It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing.

Such companies are sitting ducks for anyone who comes along with a fancy package of promises - and with lots of sitting ducks, can the hunters be far behind?

An increase in salary only motivates for a short time it is the raise, not the salary level which is a symbol of current value.

To a surprising degree, the only time we fail to learn is when there are negative forces set up against it.

Because the machines are rigid, the people who use them must, if they are to be successful, supply more than their share of flexibility.

We are trying to make the machine help people take advantage of the immense psychological resources they have in overcoming their immense psychological shortcomings.

the universal computer

is an excellent book by Martin Davis (isbn 978-1-4665-0519-3). As usual I'm going to quote from a few pages:

Liebnitz's involvement with the Harz Mountain mining project ultimately proved to be a fiasco. In his optimism, he had not forseen the natural hostility of the expert mining engineers towards a novice proposing to teach them their trade. Nor had he allowed for the inevitable break-in period a novel piece of machinery requires or for the unreliability of the winds.

Unlike the usual experience with a new untried gadget, Turing's Bombes, built from his design, worked correctly as soon as they were made.

"There are several theorems which say almost exactly that ... if a machine is expected to be infallible, it cannot also be intelligent... But these theorems say nothing about how much intelligence may be displayed if a machine makes no pretence at infallibility." [Turing]

There is nothing in Godel's theorem to preclude the mathematical powers of a human mind being equivalent to an algorithmic process that produces false as well as true statements.

It is interesting to contrast von Neumann's view of computer programming as an activity with Turing's; von Neumann called it "coding" and made it clear that he thought of it as a clerical task requiring little intellect. A revealing anecdote tells of a practice at the Institute for Advanced Study computer facility of using students to translate by hand, computer instructions written using human-readable mnemonics into machine language. A young hot-shot programmer proposed to write an assembler that would do this conversion automatically. Von Neumann is said to have responded angrily that it would be wasteful to use a valuable scientific tool to do a mere clerical job. In his ACE report, Turing said that the process of computer programming "should be very fascinating. There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself."

There is no reason to think that a full scale ACE-style computer would not have worked well if the organization and resources to build one had been there. The issue is best understood in the more general context of the question of which computer functions should be supplied by the hardware and which by software. Turing had proposed a relatively simple machine in which a lot was left to be supplied by software, but where, in compensation, the programmer had very substantial control of underlying machine operations.

"I expect that digital computing machines will eventually stimulate a considerable interest in symbolic logic... The language in which on communicates with these machines ... forms a sort of symbolic logic." [Turing]

Searle tells us that Deep Blue "has a bunch of meaningless symbols." Well, if you could look inside Deep Blue when it was in operation, you wouldn't see any symbols, meaningful or not. At the level of circuits, electrons are moving around. Just as, if you look inside Kasparov's skull while he is playing, you wouldn't see any chess pieces, you'd see neurons firing.

Our consciousness is a principal way in which each of us experiences his or her unique individuality. But we know it only from the inside. We experience our own consciousness but not that of anyone else.

print "squashed-circle" diamond

There's been a bit of a buzz about the Print-Diamond practice recently. I recall doing this a couple of years ago with Johannes Brodwall. In cyber-dojo naturally. We took a wrong turn and were making a thorough mess of it. I vividly recall Johannes saying:

This is too difficult. We're doing it wrong.

I love that. If it's difficult you're probably doing it wrong. We gave up and took a break. We got a really nice Indian take away. Then we went back to Print-Diamond. Very quickly we came up with a new idea. We imagined the diamond lying in the center of an x,y axis. The Print-Diamond of 'C' would therefore look like this:

       -2 -1  0 +1 +2

  -2    -  -  A  -  -    
  -1    -  B  -  B  -
   0    C  -  -  -  C
  +1    -  B  -  B  -
  +2    -  -  A  -  -

Viewed like this you can think of the Diamond as a sort of squashed circle with the A,B,C characters all lying on the circumference. From here it was a short step to this (Ruby):

(-2..+2).map{|row| 
  (-2..+2).map{|col| 
    row.abs + col.abs == 2 ? 'X' : '-'
  }.join
}

which, when puts'd gives:

--X--
-X-X-
X---X
-X-X-
--X--

And we knew we were on our way.
Let's hear it for Curry Driven Development!

yet another interesting TDD episode

In the previous episode I described how a custom assert function declared a local array which I did not initialize.

static void assert_fizz_buzz(const char * expected, int n)
{
    char actual[16];
    ...
}

The effect of not initializing the array was that state from one test leaked into another test and I got an unexpectedly passing test. I fixed the problem by initializing the array.

static void assert_fizz_buzz(const char * expected, int n)
{
    char actual[16] = "";
    ...
}

The most recent episode (in cyber-dojo naturally) revolved around this same issue. This time I was redoing the roman numerals exercise (1 → "I", 2 → "II", etc) in C. My custom assert function started like this.

...
#define PRINT(s) print_string(#s, s)

static void print_string(const char * name, const char * s)
{
    printf("%10s: \"%s\"\n", name, s);
}

static void assert_to_roman(const char * expected, int n)
{
    char actual[32];
    to_roman(actual, sizeof actual, n);
    if (strcmp(expected, actual) != 0)
    {
        printf("to_roman(%d) FAILED\n", n);
        PRINT(expected);
        PRINT(actual);
        assert(false);
    }
}

Once again I failed to initialize the array. I'm a slow learner. This time the test failed unexpectedly! And the diagnostic was even more unexpected:

to_roman(1) FAILED
  expected: "I"
    actual: "I"

This is a less than ideal diagnostic! It seemed that strcmp and printf had differing opinions on what a string is! I fixed it by adding initialization.

...
static void assert_to_roman(const char * expected, int n)
{
    char actual[32] = "";
    to_roman(actual, sizeof actual, n);
    if (strcmp(expected, actual) != 0)
    {
        printf("to_roman(%d) FAILED\n", n);
        PRINT(expected);
        PRINT(actual);
        assert(false);
    }
}

After this the tests passed. This addressed the immediate problem but it did not address to the root cause. So I removed the initialization and (with a hat tip to Mr Jonathon Wakely) I reworked print_string to display the length of the string as well as an indication of the (un)printability of each character:

static void print_string(const char * name, const char * s)
{
    printf("%10s: \"%s\" %d ", name, s, (int)strlen(s));
    for (size_t i = 0; i != strlen(s); i++)
    {
         putchar(isprint(s[i]) ? 'P' : 'U');   
    }
    putchar('\n');
}

With this change the diagnostic became:

to_roman(1) FAILED
  expected: "I" 1 P
    actual: "I" 4 UUUP

Much better. Then I thought about initializing the array a bit more. I realized that initializing the array to the empty string was a poor choice since it masked a fault in the implementation of to_roman which did not start like this:

void to_roman(char buffer[], size_t size, int n)
{
    buffer[0] = '\0';
    ...
}

So I added that and reworked print_string as follows:

static void assert_to_roman(const char * expected, int n)
{
    char actual[32];
    memset(actual, '!', sizeof actual);
    to_roman(actual, sizeof actual, n);
    ...
}

And I was back to green :-)