My programming history

I started programming with Turbo Pascal when studying for my bachelors degree. Later I switched to Turbo C++, which felt like getting out of a straitjacket, although I mostly stuck to C. I even wrote a simple GUI toolkit for VGA inspired by Al Stevens’ D-flat toolkit that I read about in Dr. Dobb’s Journal. The segmented memory of the DOS era were a bit of a restriction, though. On OS/2 I discovered gcc and the freedom of unsegmented memory, which later led me on my path to Linux and FreeBSD. Whenever speed is of the essence, C is stil my tool of choice. But with the speed of today’s computers, a “scripting language” is usually sufficient. But developing applications in C is not very fast; there is a lot of scaffolding you need to write for every program.

For quick and dirty programs utilizing and combining the myriad of tools available on a UNIX-like system, the Bourne shell is hard to beat. The syntax does have its odd ends though, and the grammar is non-existant. Writing substantial programs in it is a challenge. For one thing, it lacks built-in data storage types.

Perl was the first scripting language that I learned after installing Linux, and I used it for most of my scripting needs for years. But for more complicated programs I still used C. Personally I’ve not had much trouble maintaining my Perl programs, but I never did build very big ones in it. And I generally try not to be too clever, because I’ve had trouble reading some of my earlier programs when revisiting them several months after writing them.

The Lua language I discovered because it is being integrated as an embedded language in newer LuaTeX typesetting engine. There it excels in things that are very hard to do in TeX macros. I’ve done some small (calculation) programs with it, but it doesn’t feel like that is Lua’s strong point. You can make it’s tables into all kinds of data structures, but it feels kind of forced. It could well be used to generate e.g. a spreadsheet-like table in TeX without external dependencies.

Diving into Python

So I finally bit the bullit and started learning Python. So far I like it a lot. It’s not very wordy, and the required indentation make for good readability. It is rich in data storage types, has an extensive standard library and it just feels right. It is also quite fast to develop programs in.

Python vs. C; a case study

To get a good feel for Python, I decided to port my lamprop program (not insignificant by my standards) to Python.

The original C program is 2673 lines of C code and headers, including comments. Of these 753 are a n×n matrix library generated by a Perl script. Ignoring the comment lines and this library leaves 1496 lines.

The Python port is only 811 lines in total, including comments and a setup.py file that is not really part of the program. Ignoring those we are left with 625 lines. Which is only about 2/5 of the equivalent C code! This took me about a weekend, which included reading a significant portion of the on-line documentation, and about a third of Mark Lutz’ “Learning Python”. Wow.

Sure, on a big input file the python version takes 0.1 second while the C version runs in under 0.01 second. But I could hardly care less.

Next, I’m going to do a re-write of stl2pov. This is potentially a much slower program, so I’m going to start from scratch.