The story of Mel, a real programmer

This post was originally published on Usenet by the author, Ed Nather (utastro! Nather) on May 21, 1983. It is likely that at the time of publication you were not even born yet. We believe this history must be preserved – if only because now we are separated from the real “hardware” by a thick layer of abstractions.

Read on and have fun!

In a recent article [относительно 1983 года — прим. перевод.]devoted to the so-called “programming for cool macho”, the author said without hesitation: “Real programmers write in Fortran.”

Well, it is quite possible that in this era of light beer, portable calculators and “handy” software, this is indeed the case. However, in the good old days, when the very term “software” seemed funny, and computers were stuffed with all kinds of drums and vacuum tubes, everything was completely different. Real programmers knew how to write in machine codes. Yes, yes, you understood correctly: they used the same “crude, incomprehensible, uncouth” 16-bit numbers. Directly.

So that a whole new generation of programmers does not lose knowledge of the glorious past of their “fathers”, I consider it my duty to tell as thoroughly as possible how a “real” programmer wrote code. His name will be Mel – because that was actually his name.

I met Mel when I took a full-time job at Royal McBee Computer Corp, a now defunct subsidiary of a typewriter firm. Royal McBee developed the LGP-30 – a small, relatively cheap (by the standards of those years) computer with drum memory – and was preparing to start production of a new machine, the RPC-4000, a significantly modified and improved model based on (badum-shh!) The same drum memory … However, the new models were prohibitively expensive, and the market rejected them. I suppose it’s for this reason that you’ve never heard of this company or the car itself.

(Actually, the author is being a bit disingenuous here. The Royal typewriter appeared in Stephen King’s novel “Misery.”

Specifically, I was writing a FORTRAN compiler for this wonderful machine, and Mel was my “guide” through his electronic wisdom. So, Mel did not approve of compilers.

“If a program can’t rewrite its own code,” he asked, “what’s the use of it?”

Mel was credited with writing (in hexadecimal machine codes) the most popular program the company owned, blackjack. At computer shows, potential buyers could compete with the LGP-30. Needless to say, the game was a resounding success? At every trade show, the LGP-30 booth was overcrowded, while the IBM machine vendors chatted lazily to each other, devoid of an audience. As for the actual sales of our computers, we tried not to raise this issue.

Now Mel’s job was to rewrite blackjack for RPC-4000. (Porting? What is it?) The new computer had a one-plus-one addressing scheme: each machine instruction, in addition to an opcode and an operand address, had an additional address indicating where the next instruction was located on the spinning reel. In modern terms, each instruction was followed by a GO TO command. How does it feel, huh? Block Pascal’s pipe with this nonsense and take a long drag to comprehend!

Mel liked the RPC-4000. It could be used to optimize the code by placing instructions on the reel in such a way that when one completes, the second could be executed immediately. We had a special program for this purpose, optimizing the assembler, but Mel refused to use it.

“You never know where and what he will push,” he explained, “and you will have to use additional constants.”

It took a long time before I fully understood this remark. Mel knew the numerical value of each opcode and could assign his own addresses on the drum. And every instruction he wrote could be viewed as a numeric constant. For example, he could take the addition instruction (if, of course, it had the desired value) and multiply another number by it. So only Mel himself could work with Mel’s code.

I compared Mel’s hand-optimized programs with the results of an optimizing assembler using the same source code. And Mel’s result has always been better. I think this is due to the fact that the top-down development method has not yet been invented. And if he was, Mel would still refuse to use it.

Mel first wrote the most complex pieces of program loops to be the first to place them on the optimal drum addresses. Our optimizing assembler was not that cunning and far-sighted.

In addition, Mel never used loops to create a delay in code execution – even if the awkward Flexowriter needed a break between output characters to work correctly.

Flexowriter 2201 Programmatic printing device,
Flexowriter 2201 Programmatic printing device,

Mel placed the instructions on the drum in such a way that each of them passed by the read head at exactly the right moment. It took the drum one full turn to find the next one — that’s the delay it needed. I will never forget what term he coined for this procedure. The word “optimum”, despite its absolute nature, is often used in relative terms: “not optimal enough” or, for example, “not at all optimal.” Mel went even further. As part of his approach, he called the maximum possible delay “absolute pessimum.”

When he finished rewriting the blackjack and tested it on a computer (“Even the initializer is optimized” – Mel boasted), he received a request for revision from the sales department all of a sudden. The program used a very elegant (optimized) random number generator for the operations of shuffling cards and dealing hands from the “deck”. Some of the sellers thought it “unfair” that buyers periodically lose. Accordingly, Mel was given the task of finalizing the program so that when the touch button on the computer console was pressed, the program would “play along” with the customers.

Mel was indignant. He felt that this was a dishonest move (and it was so!), The implementation of which, moreover, infringes on his programmer’s immunity. He flatly refused to change the program. The main salesperson, the boss, and some of his colleagues took turns trying to persuade Mel to change the code. In the end, Mel gave up and refined the game. True, in the opposite direction: when the switch was on, the program cheated and won, and when it was turned off, it played the game honestly. Mel was delighted with his decision. He claimed that his subconscious was “uncontrollably ethical” and categorically refused any further corrections.

Perhaps this is one of the few photographs that captures Mel (the rightmost one in the background).  // Source:
Perhaps this is one of the few photographs that captures Mel (the rightmost one in the background). // Source:

After Mel left the company in search of a greener job, Big Boss asked me to look at the code and try to remove Mel’s “conscience” from it. I agreed, but without much desire. Working with Mel’s program threatened to turn into a whole adventure.

I often caught myself thinking of programming as a separate art form, the real value of which can only be appreciated by an initiate. The code may contain magnificent pearls, brilliant finds, hidden from the common eyes, sometimes even forever, due to the nature of the process. You can learn a lot about the author of the program by reading his code, even in hexadecimal numbers. I personally think Mel was an unsung genius.

Probably the biggest shock for me was one innocent unconditional cycle. Seriously, it didn’t have a single exit condition. Common sense told me that the program would run in it indefinitely. However, in reality, the computer entered the loop and exited it without any problems. It took me two weeks to figure out how Mel did it.

Ironically, but true: the LGP-30 computer (pictured above) is known only for the fact that a certain real programmer Mel wrote for it a surprisingly “optimal” program for playing blackjack,

The RPC-4000 had one really modern tool called the index register. It allowed the programmer to organize loops using so-called indexed instructions. Each pass the number in the index register was added to the operand address, which made it possible to get the address of the next data element in the array. All that remained was to increment the contents of the index register by one each time. Mel never used it.

Instead, he put the instruction in the machine register, added one to its address, and saved it. The modified instruction could then be executed directly from the register. The cycle was organized taking into account the additional time for the execution of such an instruction. Once it was “over,” the next one was right under the drum readhead, ready to be read and played. But there was no exit condition in the loop either.

I noticed that the bit indicating the use of the index register (the bit was between the address and the opcode in the instruction word) was set. This was an important hint: Mel never used the index register, leaving it at zero. Mel’s approach literally dazzled me with grace and perfection.

He placed all the data he was working with in the upper memory addresses, so after the last element was processed, incrementing the instruction address led to an overflow. The carry bit added one to the opcode, replacing its value with a branch instruction. Of course, the next program instruction was stored at address zero, and the program successfully continued on its way.

I’m not in touch with Mel, so I don’t know if he has succumbed to the maelstrom of change that has swept the programming world in recent years. I personally want to think that he still works in the old way. I was so impressed with Mel’s work that I stopped looking for the “bug” leading to blackjack cheating. I told the boss that I had not coped – he nodded and seemed not surprised at this outcome.

When I left the company, the blackjack program was still cheating when the button was on. I think I did the right thing. I was ashamed to crack the Real Programmer’s code.

Afterword from 2021

Unfortunately, history has not preserved for us any other references to the “real programmer” Melvin Kaye. The story of Ed Nather (R. Edward Nather, 1947-2014) is a kind of monument to programmers who saw code not as a heap of instructions and functions, but as a whole piece of intellectual art.

Finally, let’s write a few words about Natera himself.

Ed Nater
Ed Nater

In scientific circles, he was known primarily as an astronomer, professor at the University of Texas (Austin) and an expert in astroseismology, white dwarfs and observing the interaction of extinct binary stars. In addition, Nater served as the director of Whole Earth Telescope for 10 years. The Internet popularity of the scientist was brought by the publication of the story about Mel on Usenet.

As for the program for playing blackjack, we suggest that you familiarize yourself with instruction on its application by Mel.

For those for whom the original article was not enough, we give the following link: Mel’s story with technical details explained (in English).

Similar Posts

Leave a Reply