The Story of Mel (1983)
11–20 of 175 posts
Re: The Story of Mel (1983)
#12Re: The Story of Mel (1983)
#13This part in particular, taken from Wikipedia, still reads to me like Necronomicon level black magic:
> But when x was already the highest possible address, not only did the address wrap around to 0, but a 1 was carried into the bits from which the opcode would be read
Re: The Story of Mel (1983)
#14Re: The Story of Mel (1983)
#15Can some way more experienced than me ELI5 why the inner loop part was so clever? I'm the most novice of programmers and have never touch anything remotely like pointers so feel I am missing the lightbulb moment the author clearly got. Many thanks.
Eventually he realized that Kaye was using self-modifying code to process elements of an array, and had coded the loop in such a way as to take advantage of an overflow. Adding 1 to the address field of an instruction that referred to address x normally just changed the address to x+1. But when x was already the highest possible address, not only did the address wrap around to 0, but a 1 was carried into the bits from which the opcode would be read—in this case changing the opcode to "jump to" so that the full instruction became "jump to address 0".
Re: The Story of Mel (1983)
#16[1] is an instruction manual for the blackjack program itself, written by Mel.
Classic story solidly in the “should be reposted every six months or so” cohort.
0: https://www.freecodecamp.org/news/macho-programmers-drum-mem...
1: http://bitsavers.trailing-edge.com/pdf/royalPrecision/RPC-40...
Re: The Story of Mel (1983)
#17Previous discussion where another person tried to replicate this: https://news.ycombinator.com/item?id=20484330
Re: The Story of Mel (1983)
#18Nowadays, desktop apps which started in an instant 20 years ago, seem to take several seconds even before they are even doing anything useful like loading a project or whatever. Even things like Visual Studio looking through the MRU project list can take 10 seconds (probably a threading issue) and VSCode, Teams and others are equally unimpressive - in fact the browser, the one thing that should be slow due to the network, is usually fastest when using a well-written site.
I'm not sure whether the multi-platform desktop app was ever a great idea. How much time have we saved "not writing multiple apps" but have instead ended up with slow, bloated software that doesn't usually run multi-platform, at least not all the time in the same way.
Re: The Story of Mel (1983)
#19Sadly we have strayed to the other extreme. From "every instruction is precious" right over to, "who cares how many instructions I use?" Nowadays, desktop apps which started in an instant 20 years ago, seem to take several seconds even before they are even doing anything useful like loading a project or whatever. Even things like Visual Studio looking through the MRU project list can take 10 seconds (probably a threa…
Seriously, I have to really think about when was the last time there wasn't some degree of unnecessary friction in an application. It really feels like being an end user of modern tech is like being in an abusive relationship.
Re: The Story of Mel (1983)
#20https://en.wikipedia.org/wiki/The_Story_of_Mel
It was nice to see the original write up and to read how about it worked for the user.