Dirty Programming Secrets

Bob just confessed that he knew Fortran. That's dangerous, Bob. I confessed to my boss that I knew assembler once, and for the next five years I was the assembler guy and core dump reader for my group!

As for Fortran, I'll confess to not really knowing it -- and taking steps to make sure that I didn't ;-). I did a tiny little bit of work with it in a programming languages class. I also once carried a deck of punch cards from NYU to Dartmouth in order to port a Fortran program that had been written in 1964 so that I could use it in a research project. But I turned down a CS grad school admission at Purdue in 1983 because they wanted me to teach an undergraduate course in Fortran! I have programmed a lot of COBOL though. That's even worse.

I thought I'd take this confessional type of posting in a different direction, though. I think that every programmer, and every technologist period, probably has at least one story about a terrible, terrible kludge they once did to solve a problem. I will admit to having several of those, actually. Self-modifying code and/or branches into data space play prominent roles in several of the really nasty ones that I've done professionally... though not recently ;-) Since Bob's confession relates to something he did long ago, I'll dig back into the far reaches of my memory and do the same.

My first amazingly horrible kludge came when I was a student programmer working on a new module for a statistical package that was widely used by students and faculty at Dartmouth. The package was written in BASIC, and the module I was working on was supposed to allow users to input a formula to do a transformation on a data set. So, I wrote a cool recursive descent parser to validate the syntax of the formula, and then I started thinking about how I was going to actually interpret the formula to execute the transformation. It occurred to me that instead of writing the interpretation code, it would actually be easier to just take the validated formula and transform it into legal syntax for a decent programming language, then surround it with source code for a loop that read through the data set and fed the data into the variables referenced in the code for the formula, then compile and run that source code... so that's what I did. My BASIC code wrote a PL/1 program, then told the OS to compile and run it, and then read the results out of a temporary file.

Of course, code that writes code isn't really all that strange a concept. We do it in the Lotus world with @Eval, Evaluate() and NotesSession.Evaluate() all the time, and we do even crazier things sometimes, like writing a LotusScript agent that writes data that an @formula turns into JavaScript which writes HTML. But it always feels like a kludge to me, and it always reminds me of that BASIC program that wrote the PL/1 program back when I was a 19 year old student.

So, anyone else want to confess their secrets? ;-)