"This approach to coding is far from extinct. One often finds it in software teams, among some highly regarded – though less valued – members. If you've spent several years in the industry or in Computer Science academia, you surely know this subspecies: the developer that replaces a straightforward loop with a series of auto-resolving promises, capped by a cryptic reducer, then revels in their teammates' bewilderment at the sight of the new code. Hardly the personality that you'd select for a coding legend." (ibid)
>> Instead of running a test, Mel kept incrementing the value of the (A) field, as described in the story. This eventually led to an overflow of the entire register, provided the index register bit (X) was on – exactly as Nather remembered. Using 101 as the TBC opcode yields the following sequence:
>> The overflow would toggle the BCU on, causing the heretofore ineffective TBC to transfer control to the address in the (A) field, which was 0.
Wow. I kind of waved my hands at that solution, but you worked it out almost in full (short of actually coding it ... I guess there's no emulator for the RPC-4000 around? Someone should go and write one seeing as the architecture is mostly in the manuals and all. Someone... else >_>). Good stuff!
Btw, if you're looking for translations to more languages, there is a Greek one here:
https://greektrans.blogspot.com/2010/06/mel.html
Complete with Greek-language annotations.
We're totally into more translations. I'll contact the author and see if we can add it. Thanks!
Firstly, there is a false premise here which is that the story is about a great programmer who worked hard to do nothing but add real value to a program. Obviously, this is not so. The story makes it clear by including detail like '"Even the initializer is optimized", [Mel] said proudly', where is it clear that Mel understands that the initializer runs only once, but he optimized it anyway. Some of what Mel did added value, and some of it was just done for Mel's own benefit of learning and self-actualization.
Secondly, it is not necessarily true that the testless loop isn't an optimization. We cannot assume that Mel was always optimizing for time. He probably optimized for code size in cases when optimizing for speed wouldn't make a difference.
If a program obeys the 80/20 rule, where 80% of its time is in 20% of its code, then you can make the biggest speed improvementsin 20% of the code. But then what do you do with the 80% of the code that doesn't execute often enough to make a difference? You can optimize that for size to end up with a small program that is still blazingly fast.
Size doesn't follow any 80/20 rule: 100% of the size of the program is evenly spread into 100% of the code. Shaving an instruction from anywhere makes it one instruction shorter, whether that instruction is in three levels of loop nesting, or initialization code that executes once.
Still, if the machine runs only one program, such as doing nothing else but providing that blackjack game, and if that program fits, there is no value in making it any smaller.
The story of Mel revolves around an entertainment program. This was back when entertainment programs weren't products; there was no game industry.
Mel could have had a completely different attitude toward production programs used for business.
Mel might have been no different from today's regular software engineer, who writes somemthing for an obfuscated contest on the weekend.
The Story of Mel does try to convey the idea that Mel had certain general attitudes. Mel frowned on optimizing assemblers and compilers: "If a program can't rewrite its own code", he asked, "what good is it?". However, any programmer could say things like that. It's par for the course in any water cooler discussion. (Mel would likely have known that an optimizing assembler can rewrite its own code, in a way: it can be run on itself.)
The RPC-4000 was a goofy machine that had extremely variable IPC depending on machine code layout. It could get as bad as 60 instructions every second if they were on the wrong parts of the drum. I'd expect the initializer to be optimized as well even though it's going to run once, since not optimizing would land you with a very long wait for it to get ready.
Unless the program won't fit without the size optimizations.
Anyways, people delight in making the smallest executables that do useful things. Maybe Mel also did.
I thought the original story implied that the primary purpose of the alleged hack was to make the program (a blackjack game) difficult for anyone else to understand and edit, because Mel himself had refused to alter the program to allow the company's staff to cheat?
(edit: blackjack, not backgammon, thank you cassiepaper)
Nah the essay implies it was just Mel's style, due to coding on very resource-constrained systems. So Mel had a habit of data reuse, self-modifying code, and self-constraining timings (from the drum).
The idea behind it was to annoy the marketing people, disregard their request, and help the machine win every game, instead of the other way around.
We don't know his motives, or if the clever 'hack' was added before or after his disagreement with the marketing people.
But it sounds like more than a coincidence
(author of the missing bits piece)
The Jargon file is the source of all sources. I've read it there. We've created Mel's Loop to dive deep into the story, translate it into multiple languages (Hebrew edition is available on the site) and give room to the historical and folklore research that we did around the story.
More on that in the Preface article on the site: https://melsloop.com/docs/preface
It also happens to be one of the (possibly the actual one) primordial HN evergreens so there's probably a large cohort of people who first came across it here. Part of The Story of The Story of Mel, I suppose.
Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. Make a regular submission instead.
(Page is not scrollable for me)
On desktop, I could reproduce the same issue in both Firefox- and Chrome-derived browsers.
