Curiosity and the Computing Profession

Alan Kay said that computing professionals are not curious, especially about the past. How obvious!

Let's start from the top, the CTOs. Laugh now, laugh. I think most of us know that even if they are curious, they won't know enough to understand both the question and answer.

The middle managers? Well, if it is not about resources and deadlines, they don't know what it is. And how important would it be anyway?

The development manager? Lack of curiosity is almost a badge of honour for them. For that is why they are managing and not programming.

Project managers? Laugh some more.

The programmers? Well, since you must know all the fashionable buzzwords, why would you want to know anything that has nothing to do with the buzzwords? Let's see what is fashionable right now, and learn as little as possible about it, as long as it is enough to fool the interviewer, all is good.

I knew about this lack of curiosity since the beginning of my career. Initially, I attributed it to my mostly electrical engineering educated colleagues. I did not think they thought much about computer science. They programmed for a living. That is all, nothing more than that. Then I talked to a person who was advocating design patterns, and realized he was not a bit curious about where design patterns came from. Christopher Alexander? Who? After explaining who he is, his reaction was a shrug. I knew enough to change the topic.

But then, the author of the article made an obvious mistake too: he said Alan Kay invented object-oriented programming. Alan Kay is one of the Gods in computer science. But, he invented an object oriented programming language. Not object-oriented programming itself.

Oh well.

Update: In case it is not clear, this is only a very general observation. I don't mean every CTO is clueless. Some obviously are not. The same for other roles.

Java Versus C, part 2

In my previous post on C versus Java, I talked about the reluctance to re-factor for me. It is much harder to convince myself to change any part of the C program, especially far-reaching changes, or those that change the structure of the program.

The application has been in pilot for a few weeks now. So far, I have one reboot-inducing bug, and some minor issues. The reboot-inducing bug was due to freeing memory that has already been freed.

I am quite satisfied with the application. And once in a while, I would find myself admiring the code I wrote. That never happened before.

This morning, when I was reading an article on TheServerSide.com about C++ versus Java, something just hit me. Even though the 'one small problem and Palm is going to reboot' is certainly not good for the health of the heart, the necessity to be ultra-organized to ensure that does not happen makes the code much better.

I avoided C++ because I was really worried about using too much memory. I also avoided it because hunting memory leaks is not exactly my cup of tea. Making the matter worse is of course the amount of hassle to debug a Palm app on the device. It is also because C++ is more opaque than C. Even in C, I found myself making everything as simple as possible. If a statement can't be understood in one glance, I change it so that it can be.

So, that is the advantage of using C versus Java for me: it forces me to think of the simplest solution to a problem, to organize well, to code defensively, and to be paranoid about what each statement would do to the system. So, if a C program works well, it is inevitably well-crafted. It will have to be for it to work well.

Still, I have many ideas to make the application much better, but I am scared to re-factor the application to use these ideas.

So, as usual, nothing is perfect.

Java Versus C

I just finished, more or less, a Palm OS application in C. Strictly speaking, it is not C, rather, it is using C++ to write a C program. In other words, I am not using any object-oriented features of C++.

Programming in that style of C is actually the only way to control exactly what is going on in terms of memory for Palm OS. You see, Palm OS has no memory protection; an error that causes a segmentation fault on Unix will cause a Palm OS device to reboot. Because of that, I became careful about where every byte is. With C++, it is tougher to account of the bytes, as the virtue of encapsulation also means opacity some times.

After the application is done, I started thinking about the experience I had, and the experience I had for the last few years, when I programmed in Java almost exclusively, other than some Javascript, and Perl. All of these languages handle memory for the programmer.

In terms of programming, all of the languages are fine. They have different styles. But I am not a language bigot; I use a language when it is the right language to use, or it is the best language to use. In a particular context.

I can now say that an incredibly big advantage of using Java (or Javascript, or Perl...) is that refactoring is easy for these languages and very practical especially with an IDE like Eclipse.

For C, especially for an operating system like Palm OS, refactoring is a hairy thing. Instead of trying to find code to refactor, I found myself making sure every change is a necessary change. After a few reboots that took forever to figure out, I became a lot more defensive in my programming, and I also became very defensive in terms of changing anything.

I believe that is the true cost of not having automatic memory management in a language: it make programmer not to have the courage to perform major re-factoring.

Maybe Palm OS is an exception, as it does not have very good debugging facilities, and the simulator is one version down, the emulator two versions down, and device debugging is not fun, to say the least. But still, the disadvantage is real, if quality is concerned. Refactoring is the only way to increase quality of an application, especially if it changes frequently.