Átila on Code

There seemed to be a theme going at DConf 2014. Or a few. Lots of “metaprogramming is great but hard” (including my talk) and also lots of “the GC got in the way somehow”.

After watching a few of the CppCon videos from this year, it seems to me that it also has a few recurrent themes. Quite a few talks mentioned using custom allocators but completely doing away with exceptions and/or templates. It seems these practices are more widespread than I thought. It still troubles me that nobody seems interested in measuring what the effects would be. I hear a lot of “exceptions would slow this down”, but no measurements. “Template bloat” shows up a lot but I don’t understand how the code woudn’t be just as large if doing them by hand, bar pathological instances of generating code for int/uint and the like. Besides, isn’t that premature optimisation anyway? Write it neat, then cut down on memory usage if using too much.

Really interesting talks, I recommend everyone to check it out.

Once upon time I wrote code using Turbo Pascal and Borland C. Then I discovered protected mode and heard of a compiler called DJGPP that could emit 32-bit code that could access more than 640k of memory. I had to have it. Unfortunately I was used to my text-based IDEs and had no idea how to use a compiler from the command-line. RHIDE and its near perfect imitation of the Borland interface won me over.

At some point that I don’t quite remember (probably when I went to CERN) I started using Linux and Emacs. Emacs was weird. None of the keystroke conventions of other programs worked. It did its own thing. It took a while but I got used to it and even modified my .emacs file, although never so much as to be in a foreign place on a new installation. I’d only really copy elisp from the internet. I ended up using Emacs to write pretty much any code, except for Java. I wrote that in Eclipse.

When I joined Cisco, everyone in my team was using Eclipse in a Linux VM running on Window to write C and C++. I joined the team and started resenting Eclipse more and more each day. At one point I managed to configure a Windows XP VM running Visual Studio that used up less RAM than Eclipse on Linux! But I had to give it to the IDE: it made many things easier when working on a shared codebase. I longed for Emacs but I didn’t want to give up the IDE features that I now relied on, in order of importance:

1. Jump to definition.
2. Autocompletion.
3. On-the-fly syntax checking
4. Finding a file in the project
5. Macro expansion
6. Rename refactoring

If only I could find a way of having this in Emacs… I knew there must be a way, but I also knew it wasn’t going to be easy. So I procrastinated for years. Until last year.

Last year I went into a mad flurry of optimising my productivity. I tried different Linux distros, desktop environments, the works. I changed a lot of the way that I work. My Linux distro went from Kubuntu to Arch Linux. My shell, from bash to zsh. My favourite language was C++, now it’s D. And my “IDE” is now Emacs.

I use auto-complete-clang and flycheck for items 2 and 3 above, and until a few days ago, cscope for item 1. But there were problems since the compiler flags used to build the project must be known for all of this to actually work. But my build system knows the compiler flags, so how do I get it to pass those flags on?

Well, this is an Emacs post so the answer is of course, to write a new elisp package which I called cmake-ide, because that’s what I always use for C and C++ development. But cscope was still annoying me with its fake matches. What if I could use clang for not only autocompletion and on-the-fly highlighting but also for finding definitions? Turns out I can with rtags! I integrated this into cmake-ide and now life is good.

I’m never leaving Emacs now. I have everything I had with Eclipse, and the features I missed even work better than they did there. I version control my .emacs.d directory. I write unit tests in elisp to make sure that my packages don’t break. And I’m more productive for it. Life is good.

I see this a lot:

testMyAwesomeCode() {
    //create object
    obj = factory();

    //set things up
    obj.setup();

    //ask for authorisation
    obj.getAuth();
    //....
}

There’s nothing inherently bad with this, it’s just that it could be a lot more useful if instead if were this:

testMyAwesomeCode() {
    log.debug("create object");
    obj = factory();

    log.debug("set things up");
    obj.setup();

    log.debug("ask for authorisation");
    obj.getAuth();
    //....
 }

The logs serve the same purpose as the comments in the original code, and now when one of the tests starts failing the logs are there to help see what’s going on and why.

I find this works better with a logging and testing system that is usually silent (i.e. the above logs aren’t printed) by default and can then be enabled with a run-time option. That way the noise isn’t there when it’s not needed.

I like to finish what I start. It feels like a failure to me to not see a project to completion, which is mostly the reason why I persevered with my PhD thesis despite not particularly liking what I was doing every day, having no money and living with my parents at age 30. So it’s with a heavy heart that I decided to stop working on my videogame.

This thing goes back a while. Once upon a time in 1995 I think, I went to a friend’s house to play some games on his Amiga. One of them was Gravity Power, which was so cool that I wanted a version of it for the PC so I could play it at home. Since there wasn’t one, I decided I’d write it. And so I did.

The version I wrote back then was in C and x86 assembly, 320×200 graphics on one screen and crude but playable. It wasn’t particularly good though. At some point I decided I’d write a better version, from scratch, with what were then high definition graphics (640×480). I did but soon enough my lack of experience with a larger software project showed and it was hard to keep adding modifications to the gameplay. So I rewrote it in C++.

This was my 2nd project in C++, and it showed as well. I can’t remember much about this version, I’d have to go look it up, but at some point I decided to rewrite the whole thing from scratch again. I’d toyed with enabling networking in the game, and once I realised how much work that would entail, I made an executive decision: no networking. That way I’d implement everything else I’d wanted in the game but at least at last finish it.

And I did, the result of which can be found at sourceforge. It turned out alright, I think. But I’d come back to it yet.

A few years later the C++11 standard came out and I wanted to know it. My background is mainly C++ so I thought it would be inexcusable for me to not know the new standard of the language I know the best. The only way to properly learn programming is to write code, so in that in mind my plan was to write the networking code for Gravastar in C++11 and bolt it on the existing codebase. It was a lot harder than I had anticipated. I’d painted myself into a non-networking corner and decoupling everything was taking an enormous amount of time. C++ itself wasn’t helping, and the new standard had given me oh so much more rope to hang myself. I kept putting off working on it since it was so hard, getting distracted by other projects. Then I learned D, and my desire to write any more C++ dwindled to nothing.

I’d written enough of C++11 to get a good feel for it though, and I just didn’t want to work on networked Gravastar anymore. It just wasn’t fun. And since I was doing this in my leisure time, what was the point? So… I quit. I learned C++11, I learned that I still make a lot of design mistakes in code that’s not that old, and I learned that this time it’s just better to let it go. And once I’d done that, it felt like a weight off my shoulders.

I still want to write a game with a networking component. I just don’t want to do it in C++, or to adapt a codebase that had been designed in such a way to never accomodate networking to do it. It might just be time for a new project.