The Story of Mel Explained | Hacker News Reader

The Story of Mel Explained

jamesseibel.com

68 pointsseibelj25 comments

Something I've long been curious about:

    Mel finally gave in and wrote the code,
    but he got the test backwards,
    and, when the sense switch was turned on,
    the program would cheat, winning every time.

This doesn't sound like the sort of bug that occurs because you get a test backwards. Making a blackjack program that wins every time, and one that loses every time, seem like very different beasts. So what mistake did Mel make?

The manual for the game says:

  If SENSE SWITCH 32 is depressed, there is a better than normal chance
  of an ace being dealt as the player's first card.

Presumably the story didn't get that quite right. Sadly the code hasn't turned up.

It seems pretty identical to me. In Blackjack, the easiest way to make someone win is to give them 21, and make sure no one else gets 21.

So if the pseudocode is something like:

    if cheat_switch:
        if active_player == "COMPUTER": #this should be "HUMAN"
            make_current_player_get_21()
        else:
            make_current_player_get_20_or_busts()

Then the computer will always get 21, and the human player will get 20. Assume for the moment that it deals with dealing multiple cards for both the human and computer; this can be done, but isn't worth getting into.

And this could all be switched in the `active_player` check.

I always understood it as intentional on Mel's part.

Along the same lines as some of the other responses, it's possible that the "test" in question was testing whether the affected player was the human or the computer; getting that particular test backwards would certainly have the described effect.

Deliberately ignoring the instructions :)

Woz also coded the first Apple I in binary as he had no assembler. Of course the 6502 was a beautifully simple design with a minimal set of opcodes.

Mel's story is nuts but from the perspective of today (or even when I started in 1981) but you have to start somewhere and you can't judge what people did in the early days except in the context of the times.

Didn't the story go that Paul Allen wrote a loader for Altair Basic this way on pen and paper on an airplane?

> To summarize, Mel enabled the index register bit (despite not using the index register) to cause an integer overflow, and because the instruction was at the very top of memory, it had the side-effect of also incrementing the instruction’s opcode, modifying the instruction to change into a JUMP command, in order to exit an infinite loop.

Reading this made me thing of some of the crazy tricks I've pulled in TIS-100. And while it worked well in a game, it would be a nightmare for that to be my day job.

I read this interesting story once before and still don't understand why the author insists on typecasting Mel as a "Real Programmer".

It sounds to me like he should have been writing optimizing assemblers instead of wasting his talents doing one-off blackjack programs.

Additionally, Real Programmers write comprehensible code.

That is the point - the term 'Real Programmer' is meaningless and is merely used to disparage languages / tools / platforms and boost egos. You can look at Mel, a 'Real Programmer', and realize that you can't make value judgements of what true programming is. Programming is using logic to solve problems, regardless of the tools and language.

From the Jargon File: http://www.catb.org/jargon/html/R/Real-Programmer.html

"Real Programmer" is derived from the name of Real Programmers Don't Use Pascal [0], which describes "Real Programmers" as being those who use FORTRAN or assembly or something similarly painful to write software in versus someone who used high-level languages. Nowadays it's generally understood to mean anyone who writes code either directly on "bare metal" or very close to it despite the use of higher-level tools; nowadays, the term's used more-or-less ironically (since modern compilers have gotten much better about proper optimizations), but Mel Kaye - the "Mel" of "The Story of Mel" - was (is?) the archetypal definition of a true "Real Programmer".

The term "Real Programmer" predates "The Story of Mel" by about a year; "The Story of Mel" was written as a direct response to "Real Programmers Don't Use Pascal" (namely, its claim that "Real Programmers write in FORTRAN"). Mel makes FORTRAN programmers look like quiche-eating Pascal programmers in comparison.

[0]: https://en.wikipedia.org/wiki/Real_Programmers_Don%27t_Use_P...

In that context, "Real Programmer" means something like "someone who understands every minute detail about every part of the systems he's programming to the point that they can keep track of every variable, every system state, and every operation to make it do whatever they want". It's not about programming style or finesse. It's about raw mastery of the system to deeper levels than those not called "real programmers" could fathom.

Was the difference in speed between Mel's super-optimized blackjack program and a less optimized equivalent actually noticeable to the user? Or was this level of optimization crazy even back then?

The machine's main memory was a physically rotating drum. If you think of how slow that must have been, odds are very good that his optimizations made a noticeable difference.

how many RPMs for one of those drums?

3600 rpm, with 64 words per track, so reading a word took 260 µs. Minimum cycle time (the address is up next) was 9 × 260 µs = 2.34 ms. Worst case then (just missed it) was (9 + 63) × 260 = 18.75 ms.

I am finding the explanation distracts from the prose of the original and is a jarring contrast. Perhaps this would be better as footnotes.

I think the assumption is that The Story of Mel has been circulated enough that finding a copy of it isn't a problem.

For everyone else, though, it's part of the Jargon File: http://www.catb.org/jargon/html/story-of-mel.html

This is a great link. I read this story a while ago, but missed a lot of meaning behind it. This explanation hits the spot explaining all of that.

Those were the days, when self-modifying code was inevitable.

You should think that self-modifying code has died out by today, but far from it. Each time you open a web site, you could watch this old trick at work. How often do you `document.write` on a web site? To put it without diplomacy, our webware today is at the level of programming an IBM 650 with magnetic drum memory, where self-modifying code is practically mandatory. And Mel is nowhere to be found.

By and large we know better than to output javascript with document.write. We have structured templating languages even for use in a web page. Not everyone uses them yet, but the better technologies do exist.

I wish! Using document.write to inject script tags is the most reliable way to insert code to run before another script tag. Here's an example where we might load some scripts then run some code before finally calling some main function.

  <script>
    // Load optimized or debug code.
    if (debugMode) {
      document.write('<script src="build-debug.js"></script>');
    } else {
      document.write('<script src="build-opt.js"></script>');
    }

    // Enable some runtime debug flags.
    if (enableTracing) {
      // This runs *after* loading the script above and
      // before main() is called below.
      document.write('<script>ENABLE_TRACING = true;</script>');
    }
  </script>
  <script>
    // This runs *after* the script tags injected in the section above.
    main();
  </script>

document.write isn't self modifying code - it's self-generating code at best.

What Mel was doing is the equivalent of document.edit.

> The Story of Mel is a story about a ‘Real Programmer’ that came out in the early 1980′s on Usenet

I read this as a story of "coming out" on Usenet... thought it was going to be about sexual/gender identity or something.

Reply on news.ycombinator.com