Hey, thanks for the shout out. I laughed out loud at being called a "Mel enthusiast" but it's totally true :)
>> 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:
In this case, how would you feel about adding it to ML project? I can do it for you, and you're more than welcome to add a PR here: https://github.com/tomerlichtash/mels-loop
Oh, the blog where the translation was published is all under a copyleft license. You can see it on its main page. You can do with the text what you will and no questions asked. Happy to make a PR though, if needed :)
A more recent example of an finite loop with no exit condition can be found in the credits section of the 2015 demoscene production "8088 MPH". The loop (which can be found at https://www.reenigne.org/blog/8088-pc-speaker-mod-player-how... under "v:") has two jumps (one conditional, one unconditional) both backwards, and runs with interrupts disabled. The CPU's instruction pointer stays within that block until the end of the routine - there's no wraparound to make a forward jump from a backward one.
There's a POP instruction in the loop that pops to a memory location addressed by a register. When that register contains the address of the final JMP instruction, the latter gets overwritten by a forward JMP.
> Rather, it stems from the obvious lack of real value that the hack added to the program. It's very unlikely that a standard loop would have degraded the program's performance in any noticeable way. Mel's testless loop was clearly a vain addition of complexity.
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.
One thing we don't know is: anything else about Mel and his other work, whatsoever.
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.)
> 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.
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.
> 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.
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’m not sure I buy the conclusion. The point in the original story (at least the version I’ve read) was that Mel’s main job was to write code that could make the computer appear as fast as possible to potential customers. Of course one hack isn’t going to noticeably improve performance, but a collection of hacks can significantly improve performance.
>If this analysis can cast a shadow on the myth of Mel Kaye ... it stems from the obvious lack of real value that the hack added to the program. It's very unlikely that a standard loop would have degraded the program's performance in any noticeable way.
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)
> 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
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).
That's all true, but: a gifted coder is ordered to make a change he feels is wrong, he refuses, and he also writes ingeniously obfuscated code which nobody else can alter?
We don't know his motives, or if the clever 'hack' was added before or after his disagreement with the marketing people.
The story says "Mel finally gave in and wrote the code, but he got the test backwards". Maybe this included further obfuscation, but imho it's not implied in the text.
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.
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.
Reading material like articles can't be Show HN's (they are totally fine posts, of course) so if you're still in the edit window you should take that out the title.
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.
We'll consider a fix. Right now the scroll area is implemented via RadixUI, which seems to be very good, but your point is clear. If you have any practical tips/ideas/links to a good, solid, cross-browser scrollarea component - please let me know :)
Just, uh... don't have a custom cross-platform scrollarea? This is a feature the browser provides already.
Your page is perfectly usable by just removing `overflow: hidden scroll;` of div.data-radix-scroll-area-viewport`, and `overflow: hidden;` from .s24.
So you'll probably achieve intended behavior of having a scroll area that works on all browsers by just not using any custom scroll area plugin, but a plain <div> instead.
I don't think I've ever had a good experience with a custom scrollbar. If it behaves any differently from every other scrollbar on my system, it's going to be inferior. And scrollbars work differently from system to system.
What are you trying to achieve beyond the default scrolling behaviour?
Ironic, considering that TFA is judgmental about exactly that:
> 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.
And then the site uses JS to implement a feature that every browser has!
I have a different issue with the custom scrollbar, although it's no less annoying - when I press anywhere near it (android), it auto-jumps, losing my place.
On iOS you can trick the page into scrolling horizontally by selecting some text and dragging the selection marker beyond the right edge of the screen. Still an annoying workaround though, because the page snaps back to the left as soon as you try to scroll vertically again.
On Firefox for Android the page suddenly jumped halfway down when I tried to scroll. Looks like you've implemented your own scrollbar which overrides the browser?
>> 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.