Don't forget the other side of that question, though: how much time/money did it save?
Best practice today is to waste computer time to save programmer time. It's absolutely right, too. In 99% of cases, computer time is plentiful and programmer time is scarce.
But that's the result of decades of hardware advances. Mel's computer had a clock speed measured in kilohertz and a memory access time measured in milliseconds. It might be literally a million times slower than what we're using today. The dirty tricks we shy away from today can be the only way to get some things done on hardware like that.
Finally, we're talking about the 1950s. The profession was pretty much brand new. Where do you think modern best practices came from? They're what came out of people finding out, by experience, what works and what doesn't.
Mel was simply pushing the envelope, doing things that other people couldn't using the exact same hardware. Just look at the machine (linked elsewhere in the thread) and imagine creating a poker game for it.
I remember making 'games' (for some definition of the word game that you probably would laugh at today) on a KIM-1 in 6502 machine language (no, I did not have an assembler yet, that was a luxury) and that was a very advanced environment compared to what Mel was working with.
Computer time is only plentiful when you're not pushing the boundaries.
> Where do you think modern best practices came from? They're what came out of people finding out, by experience, what works and what doesn't.
Definitely. But I think this is a pretty clear example of what doesn't work. "What, make a change? Sorry, nobody can figure out how to do that." So yay for Mel for doing what people thought couldn't be done, but let's never do it again.
According to Gordon Bell's Computer Structures: Reading and Examples, the best-case memory access time of the LGP-30 was 2.34 milliseconds†. Most instructions required two memory accesses (the instruction itself, and an operand), which gives you around 200 instructions per second.
The machine had only two registers: the accumulator, and the program counter. The only place you could use a pointer was in the address field of an instruction. In order to increment a pointer, you would load an instruction into the accumulator, add to it, and store it back. Best case, you could increment 67 pointers per second. Worst case, nine.
Mel's job, in this instance, was not to write beautiful maintainable code. It was to write a demo that would sell the machine to potential customers, rather than boring them to death.
Why do you say this? I mean, it's true, but do you think there are people who disagree, who think that writing that kind of code on a modern computer is a good idea, and further that they are participating in this discussion?
I find this reaction confusing. Nobody is holding Mel up as an example for us to emulate in the specifics of how he worked.
It's like telling the story of Tex Johnson doing a barrel roll in the 707 prototype filled with VIPs, and someone comes along and interrupts with, "I'm surprised that people react positively. Doing clever tricks like these is NOT what a good pilot is supposed to do." He'd be right; airline pilots shouldn't be doing barrel rolls. But it's a pointless thing to say, because nobody is telling that story to convince airline pilots that they should be doing barrel rolls.
I think you're right. How much time/money did that clever loop trick waste?