What is a perform?
I closed the previous article saying that programming was controlling the flow. I was left wanting to tell you where I learned that. I didn't learn it from a book. I learned it lost.
I started the way we all started: modifying programs others had written. Nobody sat you down to write one from scratch on your first day; they handed you a colleague's and said «now make it print this column too». And that's where the ordeal began.
Because the language was COBOL, and it's worth saying one thing about COBOL for anyone who's never touched it: COBOL is not a structured language. Nor typed, in today's sense. Nor object-oriented, heaven forbid. COBOL is a language, full stop. It lets you jump from anywhere to anywhere. And what came out of that, most of the time, was what we now call spaghetti code: line after line running forwards, backwards, and returning to a point you no longer remembered the reason for.
I don't tell it with arrogance. Nor with smugness, nor even with nostalgia — though I remember with great fondness all the colleagues I shared those machines with. They programmed the way you programmed back then, the way I was taught too. It was simply like that: you got lost. I would spend days trying to fix programs that, in all honesty, I didn't understand. I got lost among their lines. I'd look for where a total was calculated, and the total turned up tampered with in four different places.
And then I found an instruction. Just one. It was called PERFORM.
PERFORM — and its sibling PERFORM THRU — let you do something that seems silly and that changed everything: put a chunk of program into a named «paragraph», call it, and return only to the exact point you'd called it from. Go and come back. Without getting lost.
It seems like little. It was huge. For the first time I could write the body of a program and read it the way you read a sentence:
perform header
perform lines
perform footer
exit.And that's it. There was the whole program, in plain sight. The flow, visible. Anyone reading those four lines knew what the report did without yet understanding how. The how came afterwards, and it came on its own: now I sit down to write the header. Then the lines. Then the footer. And inside the header I look up the data; and inside looking up the data, I open the file. Each thing in its paragraph, each paragraph with its name, each name telling you what it does. The program had stopped being a plate of spaghetti and become an index.
The bad part — there's always a bad part — was the price. That meant rewriting whole programs a different way. And it didn't pay off. It took me longer to tidy up what already worked untidily than to print the column they'd asked me for. For a while I worked twice as hard.
Until it stopped being twice. Because once I had a few written that way, I noticed something: the next program was the same. Another header, other lines, another footer — but the shape, identical. And I only had to rewrite what changed.
And that's when the second magic arrived, greater even than the first: functions.
A function is a perform that's been to school. It doesn't just go and come back: it takes something by the hand and brings something back. You tell it «write me the header, twenty tall and thirty wide», and it returns the header made — today, in my trade, the HTML of that header; back then, whatever had to be printed. You pass it values, it returns you a result. The named paragraph had become a part with sockets. And with that, control of the flow became total: the same thing, in different sizes, without rewriting anything.
This is where someone ought to show up and remind me that that's what classes are for. And they're half right. Classes are very good — others make them, and they save you an enormous amount of time. But I hardly use them. And it's not an old man's pose: I don't want to subordinate my application to what someone else decides, and changes whenever they feel like it.
Because a class, to me, is a function in which you lose track of the flow. You call it believing it's going to do one thing, and it does whatever its variables hold inside at that moment — which isn't always what you think. You ask it to add; it adds, or it doesn't, depending on how half a dozen variables you can't even see are arranged. Of course not all classes are alike, nor are half of them as opaque as I paint them. But I never fully came to understand them, and I think I know why: I never trusted them.
And if on top of that you add namespaces, I lose the thread entirely: Pepe isn't Pepe, he's Pepe from Juan's namespace, not to be confused with Pepe from Raúl's namespace. Anyway.
So classes arrived and I carried on with my functions. Objects I won't even mention — those I never used. Probably for never having even a moment to peek at them: when you're always up to your neck in pending work, you've no time to spare on something whose usefulness, glancing at it, you don't quite see either. For a big team of programmers it surely has its use. For a solitary programmer like me, I never cared to find it.
And I stayed — or rather, I never left — with the old way. Because a function does exactly what that PERFORM I discovered as a young man did: it receives, it does, it returns, and it drops you right where you were. What goes in is visible. What comes out is visible. The flow, once again, visible.
I have nothing against classes. I have something in favour of being able to read a program the way you read a sentence. At sixty-four, after everything I've seen come and go, my favourite program is still that one:
perform header
perform lines
perform footer
exit.Only now the headers are woven by an AI. And here's what I didn't expect: the AI likes my functions. It understands them at first glance, it improves them, and when it has to write a new one it writes it with the same logic I would have. My programs change —it touches them, not me—, but I still understand the code even though I barely read it. I know what I'm going to find before I open the file.
And that's no accident. In the loom there are a handful of programming rules written so that things get programmed the way I like, not the way the AI decides at any given moment. Functions, not classes. An honest if, not a ternary you have to force yourself to decipher. Old-programmer things — that maybe only I like and only work for me. But it's my application, and the one who has to understand it is me.
The perform, I still write it myself.
— an old programmer · 64 · rss