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.