Code Read 2 - Dijkstra on Goto

Edsger W. Dijkstra, a giant of computer science, wrote an article long ago arguing that the "goto" statement was bad for programmers and the programs they wrote. Week 2 of Code Reads covers this article.

The statement "goto is bad" is exactly the kind of attention getting statement that provokes internecine fights between partisans of various languages. Unfortunately, the flame-wars usually miss the most relevant points. I'm definitely in the "no silver bullet" school, in fact I'm in a sub-sect of that school that says "your choice of language in and of itself is almost irrelevant to the success of the project". Obviously, Logo would be an inappropriate choice of language for building a web site, and for parsing log files Perl is a lot easier than Java. But the chief benefits of one language or another are using the skills of the people available, fitting in with a larger organization, and the availability of tools and libraries suitable for the job, not the language constructs.

So if language constructs are less than relevant, what is the point of Dijkstra's article? I found Joel Neely's comments in the Code Reads discussion section particularly insightful: the problem with "goto" is that it breaks the metaphors we develop to organize our code.

Dijkstra himself makes this fairly clear:

"My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications." - EWD

I take this to mean that code is not the end goal here - correct execution is the goal. Or to use modern language - the business logic must solve the business problem. That should be the focus of our activities, not the code itself.

"My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." - EWD

Although Dijkstra is saying a lot more than just this, the key point here is that we should make sure that the way we build a program bears a simple correspondence to the way it works, and more specifically, to a way we can think about it.

Which brings us back to the chief problem with "goto" statements - they tend to obscure the underlying logic of the program, instead of making it more apparent. They may make writing code marginally easer but that make building software much more difficult.
Read more...

Code Read 1 - Frederick Brooks and the Mythical Man Month

Since Scott Rosenberg seemed to have so much worth reading in his book, Dreaming in Code , I've decided to spend a few days catching up on the Code Reads section of his blog. He provides weekly links to various original sources of the field, which are followed by a discussion.

Week 1, discussing The Mythical Man Month by Frederick Brooks, starts the series out with what is undoubtedly one of the most important books in the field. Most famous for Brooks Law: "Adding manpower to a late software project makes it later", the book actually has quite a lot more to say about how to build software without getting caught in the "tar-pit" (his image) of perpetually slipping schedules.

I'm not going to go into too much detail now, because I'm still re-reading it, but I am particularly stuck by "conceptual integrity", something which he argues is very important to a successful software project. I think this is a key point in something that I plan to explore a lot more in the blog - we usually build software using a set of basic abstractions, or a model. Whether the model is appropriate and flexible can make a huge difference in how the project proceeds. Succinctly, what makes a good object model?

More soon...
Read more...

Looking for Skillfulness - Dreaming in Code

Just finished Dreaming in Code by Scott Rosenberg. Fascinating book - well written, with some very interesting things to say.

For those of you who haven't read it - read it. It's a great introduction to both the very difficult problems of building large software systems, and also to a lot of the ideas try to alleviate those difficulties. Moreover, Scott doesn't have an ax to grind, or a vision he's trying to prosteletize - so it seems to provide a reliable, unbiased survey of the best thinking out there.

Frankly, I got very inspired reading it. Not about any particular solution, because I too think that there is no silver bullet, but about the idea that we can come up with an toolbox of approaches for dealing with this issue, and perhaps come up with some common core concerns, that will help guide us down any software project. What it comes down to, I think, is not developing better methodologies or programming languages (although these help) but rather developing better skills. Finding out what those skills are, and honing them.

Skillful software is an exploration of that - and a record of my experiences as I try to test these ideas in the field, so to speak.
Read more...