To us, here and now, it appears thus

Enter F#, the ideal middle ground that I’ve always wanted. F# is a functional programming language from Microsoft Research which sits on top of the .NET framework and as all other .NET languages are, can easily integrate with its other less functional cousins. The best feature of F# for me has been it’s a gentle yet intellectually stimulating introduction to the world of .NET programming that I’ve so cautiously eschewed so far.  The thing with learning a new language is not learning new syntax. Anyone can do that over a weekend. The hard part is learning its idiosyncrasies – the libraries that let you do real things, the idiomatic usage of language constructs and the external peculiarities that go with the language be it make files or the umpteen build systems that go with C++ or ant and maven with java or the comfortable world of visual studio which makes you believe building is just one keystroke away.

Learning F#, as obscure as it is, means that I will not be spending a lot of time learning the massive libraries that go with the .NET world again and again, but just once. I can just as easily use them in a different world. Code Reuse is a big deal, but something that’s much bigger is the knowledge reuse you get with platforms like .NET.

So, how does one get started with F#? Well, thanks to Microsoft, it has been made absurdly simple. The first thing for anyone programming within the windows environment is Visual Studio. You can get the free Visual Studio Integrated shell here and F# here.

Once that’s setup, then you can hack away.

Signing off,
Vishnu Vyas

Emacs, for those who know me, I am an big fan of, almost to the point of being religious. And and recently I’ve found another one - Eclipse. Emacs, as most would know is the ultimate editor that is written in a dialect of lisp called elisp (which predates attempts to standardize lisp and common lisp) - was the result of a time and a place where almost every programmer wrote lisp, AI was a buzzword and Symbolics was a household name.

Thus, emacs, naturally was written in the language of its time - lisp. With over 3o years behind its belt, emacs is now a mature multipurpose software application that most people go to the extent of calling it an operating system. The things that made emacs such a huge success story was not only was it written in lisp, the language of the day, it was also extensible in lisp, the language that most programmers who first used emacs knew. Thus, every pet-peeve of almost every programmer was solvable with just a few lines of elisp. Extensibility - Thats what made emacs a huge success. With packages for everything from terminal emulation, remote editing, newsreaders and even a web browser - Emacs is one multipurpose software application.

With, the coming of the AI winter, lisp lost ground and eventually gave way to Java. Java, being severely used in the past 10-20 years has become the lingua franca of the time. And, with Java we have another emacs incarnate, something that’s not only written in Java, also extensible in Java - eclipse. It has the same extensibility as emacs has , though not as mature in terms of extensions as emacs. So, Is Eclipse the next emacs?

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