Recently in Computing Science Category

I've been thinking about starting a Toronto Free Software group for many many months (since around October 2009) and decided that I finally have enough time to do so.

So here we go, the first meetup of the Toronto Free Software group will take place on the 14th of July (a Wednesday) at the LinuxCaffe, 326 Harbord St, Toronto. Click here to get directions.

It will start at around 5:30pm and I'll have a sign or something that says Free Software on it. Or maybe I'll just hold up a book on C++?

The article, "Trains, Elevators, and Computer Science", begins with a brief history of trains and elevators and specifically their braking systems. The writer, Dick Lipton, a computer science professor at Georgia Tech university, positions his article as practical by first stating that George Westinghouse was "not a theoretician, but was one of the great inventors of the 1800's", then fully explaining the braking problems and adding little comments such as "Pretty neat" and "extremely clever" after some engineering idea.

After 10 paragraphs of history we finally reach the point where Lipton explains the "general principle" behind both and the relation to computing science. This principle is

...do not rely on an action, but on the structure of the system. Make the default, a passive state, a safe state so that when the system fails, it gets to the safe state by default.

The writer of this article, Neal Ford, apparently dislikes any comments and calls them "code smells".

He suggests that inline comments are unnecessary when method/function/procedure names are specific and they have one specific purpose.

Ford may be onto something here but he obsesses over the latest and supposedly greatest software methdologies. Some of the obsessions are dynamic languages, "agile" methodology, and "test/behaviour-driven" development. What I found worse was the re-labeling and mis-crediting of an old software development idea. Ford credits Kent Beck and calls it the "compose method" pattern but everyone else (at least those who know their history) will recognize it as a central idea in structured programming. This apparent pattern, really an old idea given a new name, describes the writing of smaller functions/methods with a clear, specific purpose. The beauty of structured programming is that it gives us a way to convert blocks of code into smaller functions.

A few weeks ago I picked up the books A Discipline in Programming and Structured Programming. The first is by E. W. Dijkstra and the second includes a large section written by him. I became interested in these books after reading a few of Dijkstra's other papers and about Donald Knuth's great works. The computer science field could stand to have a bit more formalism in it and less hand-waving about "real-world" tools and methodologies.

Here are some quotes that I found especially good.