🔥 The DB Grill 🔥

Well now, isn't this just precious. I had to squint at my green-screen terminal to read this one, thought my VT100 was on the fritz. Some new philosophy for making sure your little programs don't fall over. It’s a real page-turner.

I have to hand it to you, this idea to "Model minimalistically" is a stroke of genius. Truly. Back in my day, we called that "running out of memory." You didn't choose omission as a design philosophy; you omitted things because the entire mainframe had 640K of RAM and you had to share it with the payroll batch job. Deleting absolutely sparked joy, especially when it was the only way to free up enough space on the disk pack to let the CICS transaction clear. But calling it an "art"? That's a nice way to describe desperation.

And this part about writing declaratively, to "model specification, not implementation"... fascinating. You're telling me that instead of writing a whole COBOL procedure, you can just state the conditions you want the data to meet? And the system figures it out? It's like you kids just invented SQL, fifty years late.

For example, you do not need to maintain a WholeSet variable if you can define it as a state function of existing variables: WholeSet == provisionalItems \union nonProvisionalItems.

Groundbreaking. We called that a "view" in System R back in '79. It wasn't a "state function," it was just a way to not store the same damn data twice. Saved us a whole box of punch cards.

I did get a good chuckle out of the warning to "review the model for illegal knowledge." The idea that one part of your system might magically know something it shouldn't. We solved that in 1985 with a little concept called "locking." If a process tried to read another process's state "atomically," it just... waited. Or it got a deadlock error and the whole transaction rolled back. We didn't need a "dedicated pass" to check for it; the system just blew up in our faces at 3 AM. You learn real quick about illegal knowledge when you're the one who has to restore the master file from last night's tape backup.

This focus on "atomicity granularity" is also quite forward-thinking. Pushing actions to be "as fine-grained as correctness allows" to expose races. It's adorable. We had a simpler metric: make the transaction as short as possible so it didn't lock the customer master file for more than three seconds and bring the entire order entry system to its knees. You didn't need a fancy modeling tool to find the flaw; you just needed an angry sales manager on the phone.

But this is my favorite bit of modern wisdom: "Think in guarded commands, not procedures." So, an IF statement. You've invented a new way to write an IF statement. Bravo. The guard holds, the action may fire. It's got that "event-driven" flair. You know what was event-driven for us? The operator hitting the 'Enter' key. That was the event. The guard was whether his coffee was still hot. You say PlusCal is easier but "nudges you toward sequential implementation-shaped thinking." Son, everything is sequential when you're feeding cards into a reader one at a time.

And the advice just keeps on giving:

• "Write TypeOK invariants." Because your fancy new language isn't typed. We had the COBOL Data Division. PIC 9(7)V99. You didn't hope it was a number with two decimal places; it was a number with two decimal places, or the compiler threw a fit. You're writing documentation to make up for a weak language. Brilliant.
• "Write as many invariants as you can." We called those "business rules." Or "CHECK constraints." They weren't a discovery process; they were on page 300 of a binder full of requirements handed to you by a man who smoked cigars in the data center.
• "Be suspicious of success." Now that's the first thing you've said that I agree with. If a JCL job ran successfully on the first try, it meant you'd pointed it at the wrong dataset.

Look, this is all very clever. All this TLA-whatever, Spectacle, model checkers... it's a beautiful, intricate cathedral of abstraction you're building. It's going to be magnificent. And when it all comes crashing down under the weight of its own complexity, when your "invariants" fail to account for a power flicker in the server room or a fat-fingered entry, you know what will still be running? A 40-year-old DB2 database, chugging away on a mainframe, processing transactions one at a time.

You kids have fun with your "state spaces." I've got a tape library to rotate.