The Story of Mel (1983)

So, the RPC-4000 version of blackjack seems lost, but the LGP-30 version exists (and can be run on simh). I've disassembled and partly annotated it, and found that it too has a sort of cheat switch.

The LGP-30 has no source of randomness to use as a seed. From loading the program, if the player plays optimally, the games will all be the same. Over the first few dozen games, the player ends up in the hole (IIRC, noticeably more than the long-run house edge).

The LGP-30 has one conditional branch instruction, that tests the sign bit of the accumulator. But if the sign bit on the instruction is set, and the TRANSFER CONTROL switch on the front panel is set, then the branch is always taken. This appears once in the program. On startup, if the switch is set, it marks two of the aces as already dealt. This perturbs the sequence enough so that, over the first few dozen games, the player has the advantage.

But the formatting

is part, I think

of the charm.

Abuse of side effects to save code is just a reality of working in limited or embedded systems once you have run into their limits. On one of my current projects, the target has only 8K of program memory. I had to do some things I'm not proud of to get the required functionality to fit because the alternative was to say "It can't be done, scrap everything." The target is an embedded hard-realtime processor core, so there's no way to add more memory to it. It's a component integrated into a larger system so I can't demand a larger or more capable device without incurring significant redesign costs. Quite frankly, I won't be considered worth those costs. Nobody's doing to take on the expense and effort simply because I can't hack it. I'd have a hard time blaming someone for doing the painful to keep a project alive, considering I'm doing exactly that. We can always agitate for better conditions next time around, but this time we must go to war with the army we have, and sometimes that necessitates fighting dirty.

The rest of the stuff is entirely valid though. A programmer that cannot be managed is worthless, and someone who is unwilling to accept correction is a liability. I wouldn't refuse to work with him because unless I'm his superior I don't get to make that call, but I would probably go out of my way to avoid interaction. (And if I were his superior, unless he's got political juice or something, I'd have him shown to the door if he won't work with the team instead of against it.)

When I was faced with that task, I rapidly got fed up with hand-assembling and relocating my code and went off to write an assembler to run on a computer with somewhat less anaemic IO. I doubt I actually used it more than once or twice, but it was fun to write.

Upvoted for the effort of responding in verse, very nice.

That rubbed me the wrong way too. Even the hackers at MIT documented their hacks, they even wrote up a memo explaining a bunch of them so others could understand and build on them - see HAKMEM.

Documentation was much more extensive and available back then. Systems frequently came with full schematics, and you could call the design team on the phone if you wanted. DEC would get phone calls about the PDP-10's RIM10B bootloader right up until the retirement of the 36-bit processor line, and they did their best to explain its tricks.

The loader was made to fit entirely in the processor registers so it didn't touch the memory it was loading. To do this it made use of a specific and documented aspect of the processor - that being that the first thing it did when executing an instruction is to determine its effective address, and nothing the instruction can do will have any effect on its own effective address calculation.

They had two bold-print warnings about this in the processor manual, both before and after the RIM10B source code, but some people still required more explanation. For those people, the explanation was given.

In Mel's story, he grinds out a very well optimized program, and while I can appreciate the skill it takes to do that, he documented none of it. This was customer-facing code. That's unacceptable even by their standards, and even his own co-workers of the era would have thought he was an asshole. A skilled asshole, with skill worthy of respect, but an asshole nonetheless.