Quote of the day

"One important detail is that actions that have not yet been tried in a state s are always assumed to lead immediately to the goal with the least possible cost, namely h(s). This optimism under uncertainty encourages the agent to explore new, possibly promising paths.

- Artificial Intelligence: A Modern Approach (Russell&Norwig)

Amusing how theory can guide one's life as well as explain the inevitable disappointments. Of course, Mae West anticipated theory with "Whenever I have to choose between two evils, I always like to try the one I haven't tried before"

A demigod passes

printf("goodbye, world\n");

Programmers vs. System Administrators (or NOT vs.)

I love this post describing the difference between programmers and system administrators:

Programmers are like vampires. They're frequently up all night, paler than death itself, and generally afraid of being exposed to daylight. Oh yes, and they tend think of themselves (or at least their code) as immortal.

System Administrators are like werewolves. They may look outwardly ordinary, but are incredibly strong, mostly invulnerable to stuff that would kill regular people -- and prone to strange transformations during a moon "outage".

Stories from my life

A guy with whom I'm playing an online computer game commented to me: "As a programmer you already know, there is no such thing as a "random" glitch".

There may be a cause, but things can look pretty random. I had to fly down to North Carolina once because a system we had written for a large company (controlling vending machines that took credit cards) started randomly charging customers $0 for some of the purchases (which were NOT $0).

I remember the flight well, because I had a cold and the cabin was unpressurized, and I arrived weak and pale with blood trickling out of my ears after some of the worst pain I've ever experienced. The guy in charge of the computer that was running my program whom I was rushing to see was unable to see me at first because an Ebay auction on some collectible was in the end stages, but finally I got to see the system.

After hours of comparing my input logs to the output we were generating, and trying to figure out HOW my program could possibly produce such nonsense - and running the program in a test mode with the same input to try to reproduce the problem - I was ready to tear my hair out.

I wrote a quick test program that did simple arithmetic and logged the output. It worked fine. I went to my hotel room in despair and left it running.

The next day, I checked the output log of the test program and found that for several minute-long periods the computer would add 1 and 1 and arrive at 0.

The computer they were using to run my program was really a collection of a large set of processing units, and processes could be run by any one of these - when my process was run on a defective unit, it produced defective results.

When I asked them how this could possibly have been going on undetected, they explained that the system ran diagnostics continuously, but the results were sent to a display that was itself no longer working, so they hadn't checked in months. Probably higher priority Ebay auctions.

Our president explained to me that it would be bad for company relations if I killed anybody. In retrospect, it might have been worth it.

Quote of the day

Their rumpled clothes, their unwashed and unshaven faces, and their uncombed hair all testify that they are oblivious to their bodies and to the world in which they move. These are computer bums, compulsive programmers.


Joseph Weizenbaum 1976

Quote of the day

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

- Rich Cook

Quote of the day

A hacker on a roll may be able to produce, in a period of a few months, something that a small development group (say, 7-8 people) would have a hard time getting together over a year. IBM used to report that certain programmers might be as much as 100 times as productive as other workers, or more.
- Peter Seebach

Return to me......

Of the few readers I have, I estimate that approximately zero are going to understand this post - it's mostly for my own reference, about computer programming style.

At work, our coding standards encourage "at most one return statement from a function", and code review showed my code often has more than one. Finding those places in thousands of lines of code so I can "fix" them might be non-trivial, so I was googling to see if I could find an automatic tool (a good thing to do before deciding to write your own).

Unfortunately, this is a particularly controversial "rule", where probably as many people (including me) think of it as unwise as there are that want to enforce it, so pretty much all I found was just philosophical discussion about one or many exits (same as returns).

One comment I found especially apt (at least in part because he agreed with me that it is better to know when to use a tool then to resolve not to use it:

Your argument that sticking with single exits forces you to factor
your code sounds a little like: "I never use my windshield wipers.
That forces me to stop and clean my car more often, and that is a
good thing." ;)