You can tell a lot about a person from the Fortran they write.
Inconsistent line numbering: “I’ll fix it later.”
Illogical variable names: “It works, so why bother?”
Untidy indentation: “This isn’t a beauty contest.”
Poor commenting: “I understand it now, so everyone should understand it."
Good code reads like poetry.
***
There is a subtle irony in modern engineering.
We create layers of abstraction, only to spend days figuring out where our data is located.
Fortran never had that problem.
You always knew where things were stored. Arrays were just arrays. If a variable was important across the model, you placed it in a COMMON block and moved on.
Yes, COMMON blocks are considered outdated. Critics label them as a global state.
But in real numerical computing—neutronics, thermal-hydraulics, CFD—the issue is not about philosophical purity. The challenge lies in maintaining a consistent state throughout a large, coupled model without losing track of it.
COMMON blocks made this explicit.
You had one designated spot for kinetics parameters, one for thermal state, and one for hydraulics.
There were no hidden layers, no frameworks silently copying data behind your back, and no debates over “who owns this variable.”
You could open the code and clearly see the model.
The compiler could perform its job effectively: predictable memory usage, no aliasing surprises, and tight loops that executed quickly.
Of course, COMMON blocks can be misused.
However, anything can be abused.
When used correctly, they enforced clarity in the physical model that many modern codes struggle with.
The goal is not to impress others with sophisticated software architecture but to solve the equations accurately and efficiently.
COMMON blocks accomplished that quite well.
***
I chose Perl as my scripting language because I don’t think in terms of “programs”; I think in patterns.
Not in objects or hierarchies, but in fragments of text that almost—but not quite—follow rules. Logs, tables, half-broken formats. Perl fits that way of thinking. You match, extract, reshape, and move on. It is not always pretty, but it is direct.
This is essentially the mindset behind regular expressions (regex). You look at a line of text and instantly recognize what is important and what isn’t—anchors, optional parts, repetitions, edge cases. It’s not just an academic theory; it becomes instinctual. Once you view problems this way, Perl feels less like a traditional programming language and more like a natural extension of how you intuitively interpret the world.
Other languages can indeed use regex, but in Perl, it’s not something you reach for as an afterthought; it’s the default mode. The language is designed around the notion that text is fluid, inconsistent, and still manageable without unnecessary complexity.
There is also a certain discipline inherent in this approach. Regex does not allow for ambiguity. Either you understand the structure, or you don’t; it either matches or it doesn’t. This necessitates precision in handling messy data, a valuable habit that extends far beyond the realm of scripting.
Like any sharp tool, regex can be misused. You can create unreadable one-liners that only you will understand, and maybe only for a brief period. However, this is not a flaw of the tool itself; it follows the same principle as any other area of work: if you leave a mess behind, it will come back to haunt you.
So yes, I use Perl because I think in regex—not because it’s elegant, and certainly not because it’s trendy.
I choose it because when the problem is finding structure within chaos, it aligns perfectly with how I naturally think.
***
When you cannot fall back on printouts, margins full of notes, or a second sheet where the logic is laid out in peace, coding becomes less forgiving. There is only the screen, and the screen forgets quickly. What is not made explicit is simply lost.
Under those conditions, discipline is no longer a virtue but a necessity.
You learn to name things properly, because you cannot rely on a scribble in the margin to remind you what a variable meant. You structure code so that it can be read in small windows, because you cannot spread it out across a desk and take it in at once. Functions become shorter, interfaces cleaner—not out of aesthetic preference but because anything else becomes unmanageable.
Errors, too, change character. A loose thought, a half-formed assumption—these cannot be parked on paper and resolved later. They must be settled immediately, or they will dissolve into confusion. The code either carries the idea fully or not at all.
Iteration sharpens. Without the comfort of external scaffolding, you are forced to maintain a coherent working state at every step. Small, complete increments replace large, speculative leaps. You test sooner, because you must.
In that sense, the absence of hard copies removes a layer of forgiveness. It narrows the space in which sloppy thinking can hide. What remains is a more direct relationship between thought and implementation—stricter, sometimes slower, but also cleaner.
And even for those who have no need to—no constraint forcing the change—it is worth trying. Working this way exposes how much of one’s process depends on deferring clarity to the margins. Take those margins away, and you begin to hold more of the structure in your head. You name things with greater care. You close loops earlier. The code becomes less a record of thinking and more its resolved form.
It is a useful kind of friction. Not something to impose forever, but something to experience deliberately. Even healthy people should give it a try, if only to see what remains when there is nowhere left to hide unfinished thoughts.
***
Tidy source code doesn’t seem urgent when everything is functioning properly. The model runs, the numbers appear reasonable, and there's always something more “important” demanding attention.
When I was younger, I thought this way. As long as I knew where everything was, and the logic made sense in my mind, that was good enough for me. And it was—until the moment it wasn’t.
Messy code doesn’t fail dramatically; it bides its time. Issues arise when you revisit something months later or when you need to change one small detail and discover that three slightly different versions of the same parameter are buried in various locations. Problems can also occur when a result seems off, and you can’t easily trace where things went wrong.
Tidy code isn’t just about aesthetics; it’s about being able to trust what you’ve built. A clear structure, consistent naming, and having a single, obvious location for each piece of logic all reduce the chances of hidden errors.
In the end, coding is no different from any other form of engineering. You shouldn’t leave things in a state that only you can understand or where correctness relies on memory. Instead, you should make your code robust, transparent, and repeatable.