Numerical modeling and computer programming are different jobs, sort of

I write in Fortran. Fortran is basically not taught in schools anymore, nor should it be. It's an ugly, outdated, backwards programming language. My code has a two-dimensional array called number (hint: everything in my code is a number). It's barely commented. There are redundant subroutines that do subtly different things that should probably be combined.

There are no buttons or widgets or dialog boxes. There isn't a prompt you can type things into. It doesn't even have a command-line interface. To run the code with a different set of values involves editing Fortran source code and recompiling. The code is its own user interface.

My friends in computer science hear about this and shudder and moan and gnash their teeth. I did, too, when I started my job, because, unlike most mechanical engineers, I have read a lot of books on how to program properly. I read a lot of articles about coding standards. I've gotten red in the face over how curly braces should be used in C. According to Good Programming Practice, my code I use for my research is backwards, barbaric, and ugly. It's like your racist uncle.

The code is exactly how it should be.

Research code is completely different from commercial code. I scrawl out notes to my roommate telling him yes-I-know-I-left-a-pile-of-dishes-in-the-kitchen-I'll-get-to-them-soon-honest-I-promise, but spend weeks revising material to be published. Research code, designed for a small handful of technical, intelligent, skilled people who want data right now, I mean now! Commercial code, used by thousands, needs to be less buggy, run on different systems, and be maintainable. It at least needs an interface.

At least, that's what I was told after I started doing graduate research in numerical modeling. That's what everyone tells you to do. I have one professor who joked about how you never read manuals, you just copy-and-paste your old code. There are places in my code where I have a list of if statements where I should use a select case instead, and didn't, because it was easier to write a few extra lines of code than to turn around and pick up the manual.

I'm starting to reconsider this school of thought, though. I started to think that research code should meet a higher standard when I got frustrated, recently.

In my code, I simulate fluid-structure interaction. For my research, I look at capsule dynamics, that is, the physics of elastic membranes in fluid flows—think balloons. I had been looking at test cases involving one capsule, and for me to look at two, that would mean copy-and-pasting the initialization for the first capsule, changing the code that tells the second capsule where to go. I also need to change array sizes everywhere in the code.

I'm fed up with code that's obnoxiously difficult to work with. It stifles creativity and innovation. Even if I'm the only person who will ever see my code, I'm going to start writing good code. I have a rigid testing protocol, starting now. I'm using version control several times a day, rather than a couple of times a month. I'm writing documentation. I'm making a total overhaul to the code.

I think I might write a version of the code in C++ because Fortran sucks and. I haven't written C++ since I was seventeen, and I work on Fortran every day. Last week, I decided to play with some old code and in minutes I fixed a seven year old bug in some linked list code I'd written for practice. C++ just makes a lot of sense, and Fortran doesn't.