The Last Bug

I spent much of yesterday working on a computer program. A friend of mine wrote it in Visual Basic .NET and I was converting it to C# so that it could be used as a sample solution. To save time (famous last words) I had run most of it through a conversion program. The conversion program had done a very good job but things were still not working. That was my fault of course. There were things missing which is pretty typical when one takes shortcuts. I should know better I guess. So what I was doing was trying to find what was missing so I could get a clean compile. I was pretty sure that was all I needed to do. So at one point early in the process I thought “one last bug and I’m all set.” Wrong!

There were a couple of logical problems that were completely hidden by the “last bug” in the way of compiling. I ran into some problems of idiom. Visual Basic .NET and C# have a lot of things in common and they are both true OOP languages. It turns out that there are some differences. One of them I had dealt with manually. I’m so smart. More famous last words. My “fix” was off a little. I had changed an assignment that took advantage of how C# handles some conversions implicitly to an If statement. In my hurry I had only accounted for the "if true” case and ignored the “else if false” case. Whoops.

Most of my problems turned out to be problems of idiom. My friend is old school BASIC which means that a lot of his code assumes arrays start their index at 1. C# is all about indexes that start at 0. So I had a couple of off by one errors. Most of them because I hurriedly “corrected things” without first taking the time to understand what was going on. But it’s all done now and it runs great.

It seems like some lessons have to be re-learned from time to time. One is make haste slowly. As the saying goes “hours of debugging can save minutes of planning.” I’d have been a lot better off spending more time understanding the original program and planning the conversion. The shortcuts I took were not all bad but they came along with some shortcuts that cost me time in the long run. The other is beware the idiom. Learning a new programming language or as in this case translating/converting a program from one language to another means more than just one to one syntax changes. There are styles and best practices that are influences by variations in how the language does different things.

We used to say that “a good FORTRAN programmer can write a good FORTRAN program in any language.” But in this day and age doing so is far from a good idea. We need to learn the differences in philosophy and the differences in how things that look alike may not perform alike. I think that having students learn more than one language is a great idea. In the long run the benefit is not learning different syntax but learning different ways of thinking about concepts. This is something that will help students learn the third language more easily. And they will have to learn a third language (and more) at some point if they are going to work any length of time in computer science. It may also help them become more aware of what they are doing and how others may interpret (or misinterpret) it. That’s got to be a good thing.