To us, here and now, it appears thus.

Regular expressions, if you are not a perl expert are often a pain in the ass to write, test and debug. Espescially if you are in python where there are a bunch of methods of doing extremely similar things, yet not quite the same. I found this really handly little regular expression testing tool, which runs off a web-browser and can run on your local computer called retest.

It uses ajax to make things simpler and more interactive and really useful if you are trying to parse really weird stuff.

Signing off,
Vishnu Vyas

Today, I had an interesting conversation with a friend of mine, a self-professed Java geek and some one who is a hard sell for dynamic languages like python. And our conversation came back to the same topic, again and again - type safety. From what I know of Java, it seems more or less highly type safe unless there is some sort of ugly reinterpret_cast like construct. But, coming back to my home ground of C++, thinking about it, C++ is not really type-safe, In more cases than others, type-safety is nothing more than an illusion. C++, being a multi-paradigm language has a whole host of powerful and extremely useful features, which also makes shooting oneself in their foot extremely easy.

Here is my top three really useful features, which also are the big type-safety pitfalls.

1. Variadics : Variadics is a really handy feature in C++, but its current syntax is a dark abyss for getting into type-safety hell. The way currently one handles variadics in C++ is this unholy mess of macros all starting with “va_”. These macros not only manipulate the stack directly, but return a memory image of the object. So, unless you are very sure of what type you are getting your hands dirty with, you are going to come up with serious bugs. The case here is even worse than python, where when you do the wrong operation on the wrong type, you get a run time exception. Which in my opinion is more type safe than the current scenario in C++.
2. reinterpret_cast : reinterpret_cast is another potential pitfall that I’ve come across, especially when I am prototyping in C++. Sometimes, its just easy to do a reinterpret_cast and forget it. Its really handy when you are trying to develop with some one else’s code. That damn singleton class which needs one tiny extra bit of functionality that you absolutely definitely require, but you can’t extend it. So, what does one do? An ugly reinterpret_cast. And you’ve given yourself a golden pass to type-safety hell.
3. void * pointers : These are the worst offenders. I am sure, everyone who has programmed in C++ have had enough pains with knowing how bad these little bastards can make your life. I won’t add to the woes, but just let me mourn along in silence here.

Signing Off,
Vishnu Vyas.

It’s been quite a while since I wrote anything of any significance these days. My blog seems to have moved into a more or less vegitative state. Also, since I am in line for quite some writing in the coming days ahead I think Its about time I did some emergency CPR here and get this blog back to life. Anyway, as a start, maybe I should start with a story. No, its not one about damsels in distress and charming princes. Its a more mundane story about programming.

This happened not so long ago, I’ve always been a pretty good C++ programmer, and of late I’ve been doing a lot of my programming in python. Python, if I hadn’t mentioned before, is this amazing dynamic language which is amazingly easy to use and more importantly maintain. Its one great language, except for its speed. For most practical purposes I never had any problems with the speed of python. But, sometimes when you have to wait for an hour to get some output on some data you are processing, it gets irritating. The task here was simple decipherment. I was basically using the EM algorithm (or to be more precise, the forward backward algorithm) for deciphering a piece of text. I managed to write a pretty good implementation of it in python, but it was slow - real slow.

So, I sat down and rewrote the forward backward algorithm in C++ (in the time that my python program was running) and the speed difference was unbelievable. My C++ code went 40 times faster than my hand optimized, psyco-compiled python code. If you have programmed in both C++ and python, you already knew that. C++ is faster than python, atleast 10-fold on the average. But thats not the lesson here.

The most amazing thing was, I actually managed to write, debug and get a working version of the C++ program in less time than I would have expected it to take. That’s the most surprising part. So, I’ve decided to share my experience with you guys. One of the main things that really helped me during my C++ development was not only did I have a very clear goal of what I am doing (which most software projects rarely have), but I also had a very clear goal of how I was going to do it. This was because, I had already implemented my original version in python.

Python, as someone has already said, is executable psuedo-code. Not only did I have a very clear idea of what data structure to use where, How to model the various elements (in this case, the plain text, the cipher text, etc..) and how my models interact with each other. This was all ready done, the only thing remaining was more or less manual translation from python to C++. The whole lesson here is that python is not only a great language for exploratory programming, but its a great language to prototype as well.

I am sure, that if I had started all this in C++ from the beginning, I would have been just too lazy to do all the refactoring that my code would have required. Changing from one type of object-method interface to another is pretty much a pain in C++. On the other hand, by the time I had my python code running, not only was it a correct working version, but a well designed version as well. Any screw-ups in the initial design were promptly corrected without too much effort. Any useless “just in case virtual functions” that would have cropped up in my C++ were not there because, refactoring is so easy in python that you can add them as you go. And most of all, you can test for all the bigger logical errors that occur when you have multiple objects interacting with each other in a complicated program in a python program easier than in a C++ program.

As, an unexpected side effect, I picked up a couple of good habits from python that I would have never bothered to do in C++ for my hobby programming. For example, unit-testing. I do write unit-tests, only if my projects get big enough that I think Its worth the trouble, but with python, you always have this simple if __name__ == '__main__' which serves as a poor man’s unit test. Not too much trouble, yet worth the every second you invest in writing simple tests there. These days, I do it as a matter of habit for all my python modules, and thats one good habit that spontaneously extended to my C++. With a bit of preprocessor magic, you can do pretty much the same type of poor-man’s unit-testing in C++ as well, and this did save me some pain later.

Now, that I’ve rather incoherently rambled on, I would like to summarize my experience. With, python you can not only prototype with great speed and get a clean implementation, you also end up picking up a lot of good habits on the way, that not only makes you a better python programmer, but a better C++ programmer as well!.

Signing off,
Vishnu Vyas