
The Story Of Mel - jacquesm
http://www.catb.org/jargon/html/story-of-mel.html
======
acqq
The wikipedia entry
([http://en.wikipedia.org/wiki/The_Story_of_Mel](http://en.wikipedia.org/wiki/The_Story_of_Mel))
has even the link to the picture of Mel, whose name is discovered from the
preface to the manuals for the Royal McBee LGP-30 ACT 1 (Algebraic Compiler
and Translator) compiler (dated 1959). Then somebody discovered the group
picture in
[http://www.librascopememories.com/Librascope_Memories/1950_-...](http://www.librascopememories.com/Librascope_Memories/1950_-_1959_files/560800%20Librazette.pdf)

and there it is:

[http://zappa.brainiac.com/MelKaye.png](http://zappa.brainiac.com/MelKaye.png)

~~~
acuozzo
I was first to find that image of Mel in the Librazette archives. In fact, the
following post was my first on HN:
[https://news.ycombinator.com/item?id=3110883](https://news.ycombinator.com/item?id=3110883)

More context: [http://librascopememories.blogspot.com/2012/03/59-mel-
kaye-l...](http://librascopememories.blogspot.com/2012/03/59-mel-kaye-
legendary-lgp-30-programmer.html)

I did eventually manage to get in contact with Mel, but I scared him away,
unfortunately. That's a story for another day... :-/

~~~
Stratoscope
> I did eventually manage to get in contact with Mel, but I scared him away,
> unfortunately. That's a story for another day... :-/

Tell us today! Tell us! Please?

------
gtirloni
The most interesting aspect of this story is that it apparently has a property
of yielding infinite posts of itself on HN. I wonder when will be the next one
:)

[https://news.ycombinator.com/item?id=7282617](https://news.ycombinator.com/item?id=7282617)

[https://news.ycombinator.com/item?id=5758225](https://news.ycombinator.com/item?id=5758225)

[https://news.ycombinator.com/item?id=5643818](https://news.ycombinator.com/item?id=5643818)

[https://news.ycombinator.com/item?id=5395931](https://news.ycombinator.com/item?id=5395931)

[https://news.ycombinator.com/item?id=5269815](https://news.ycombinator.com/item?id=5269815)

[https://news.ycombinator.com/item?id=3509450](https://news.ycombinator.com/item?id=3509450)

[https://news.ycombinator.com/item?id=1945288](https://news.ycombinator.com/item?id=1945288)

------
timtadh
I am working on an x86 code generator today for a small language I have been
working on. This story seems very timely to re-read because it is so difficult
to generate really good x86 code. Even though I basically know what I am doing
when writing a code generator at this point, and I have previous ones to
reference, there are so many edge cases it is hard to get it right.[1]

It used to be said that a compiler would never beat a programmer at assembly.
Now we say the compiler is usually going to "do the right thing." I think
there are two things going on here: 1) Our code generators are much better
than they were in the bad old days. 2) Most people don't understand the ins
and outs of their machines like Mel did (I certainly don't). This means that
the compiler has "institutional" knowledge from a few really knowledgeable
people and the rest of us just use that knowledge.

[1] see for simple example `imul` which has 5 different forms
[http://docs.oracle.com/cd/E19455-01/806-3773/instructionset-...](http://docs.oracle.com/cd/E19455-01/806-3773/instructionset-39/index.html)
. According to the intel optimization manual[2] the 16 bit forms suffer from
"false LCP" stalls. The recommendation is to cast to 32 bit before preforming
the `imul`.

[2]
[http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-
optimization-manual.pdf) page 103 in the PDF. See also 506 for timings on the
Atom architecture and 517 for Silvermont.

~~~
NoMoreNicksLeft
> It used to be said that a compiler would never beat a programmer at
> assembly.

Probably still couldn't. But with gigs of ram, terabytes of hard drive space,
and gazillions of flops of cpu time available, no one cares. No one can wait
for Mel to optimize blackjack, your boss wants the new build 5-15 minutes
after you've written the code, and that shouldn't take more than an hour
itself.

It's not that the compiler got better than programmers... it just because
cheaper. Hell, how many Mels are there out there anyway? Surely the number of
people that clever and devoted to the bare metal of a CPU has never exceeded a
few thousand people out of the entire population of Earth. Rarity makes them
expensive, but it also means that shitty software shop in St. Louis or Tampa
could never have such a person.

And since technology drives the economy, everything would crash if we had to
rely on the availability of super-programmers.

Optimizing compilers are slightly better than they were long ago... but this
isn't because they're all that impressive. We've just had thousands of monkeys
pounding away over decades, hammering out one little optimization or another,
and the storage to allow compilers to grow big enough to have a library of
those to rely on.

~~~
dllthomas
It depends greatly on the programmer, and how much time you allot them. GCC
will produce _vastly_ better code than _any_ human programmer, given a
specification in C and a time bound of 1 second. Give them ten minutes? An
hour? A week?

At the extreme a sufficiently adept assembly programmer (which probably still
exist) will still beat the compiler, given enough time, though that can be
helped by the ability to reference the code the compiler is generating.

~~~
wolf550e
Not _any_ human programmer, at least not for some tasks. The handcoded x86
SIMD code in x264 (the software video encoder used by everyone who cares about
video quality per bitrate) beats the output of any compiler trying to compile
the pure-C fallback function. Same for a bunch of other code you use
(indirectly) like memcpy or strlen.

But the optimized handcoded routines take weeks to develop while a compiler
would be done in less than a second. For almost all code, a programmer's time
would be better spent on something else.

~~~
dllthomas
You seem to have misread what I said, and are making basically the same point
I did. I said that _given only a single second in which to work_ (and given a
problem specification in the form of a correct C program) then literally any
human programmer will lose out to GCC. That seems unequivocally the case, and
you seem to agree.

I _also_ said that there still exist programmers who, given enough time, can
probably beat the compiler. Certainly there are tasks where this is easier,
but no one is getting it done in one second.

------
thegeomaster
Stories like this are why I'm inclined to consider programming as much as an
art as it is a science. Artists, too, can use their media (such as brushes or
musical instruments) in a completely novel and unusual way. The end result is
often not pleasant to casual viewers or conventional artists (that would be
coders who write clean, maintainable, kludge-free code) but it can just as
often leave you awestruck by how interestingly and differently a tool or a
feature or a language construct has been used.

For a philosophical discussion on this, see [1] and [2], both from PG, who
actively advocates for a playful, prototype-first approach to coding, which
more resembles a painter painting a picture than, say, a sociologist
conducting systematic research. ([1] is a transcription of a talk by Don
Knuth, [2] is Paul's own essay.)

[1]:
[http://www.paulgraham.com/knuth.html](http://www.paulgraham.com/knuth.html)

[2]: [http://www.paulgraham.com/hp.html](http://www.paulgraham.com/hp.html)

~~~
wfn
As much as I like pg's writings (honestly, I (usually) (kinda) like/appreciate
his writing style, content, etc.), re: hackers&painters, obligatory link to
Maciej's retort/comments "Smushing Paul Graham":

[http://idlewords.com/2005/04/dabblers_and_blowhards.htm](http://idlewords.com/2005/04/dabblers_and_blowhards.htm)

It's a very nice read, actually.

(You might remember Maciej from "The Internet With A Human Face"[1] / as the
dude behind pinboard.in / etc.)

[1]: [http://idlewords.com/bt14.htm](http://idlewords.com/bt14.htm)

~~~
thegeomaster
I'd actually argue that an analogy with architecture is a much stronger one
than the one with painting. In both architecture and hacking, the creative
output has to hold up to some objective standards (to compile, run and solve
the problem/to adhere to the laws of physics and provide a purpose) but it
also allows degrees of freedom not commonly thought about when one thinks of
architecture or coding.

This is, of course, implying that an architect is also capable of
"implementing" his solution (which should, strictly speaking, be an engineer's
job), but you could also argue that you can devise a system where a hacker
would write a functional prototype and then a software engineer would
reimplement it rigorously, with specs, TDD or whatsoever. This is where the
analogy starts being a little far fetched so I admit it's not the best one but
I feel like an architect's thought process follows very closely a hacker's
one.

Maciej's text is very nice, and I must say I'm stretched between PG's original
text and this one right now. I guess I just to need it a little more thought
and reread both of them :)

On a side note, I sometimes think about whether programming is really "just
engineering" and if I'm just being delusional and just eager to call myself an
"artist" because I love hacking. It's an interesting subject to ponder about,
but I can't say I've made up my mind.

------
seryoiupfurds
The computer:

[http://ed-thelen.org/comp-hist/lgp-30.html](http://ed-thelen.org/comp-
hist/lgp-30.html)

The story referenced:

[http://www.pbm.com/~lindahl/real.programmers.html](http://www.pbm.com/~lindahl/real.programmers.html)

~~~
kps
Linked from Ed Thelen's site is
[http://www.bemorehealthy.com/LGP-30Computer/The30.htm](http://www.bemorehealthy.com/LGP-30Computer/The30.htm)
which has a couple photographs of Mel's handwritten code.

------
ginko
This story gets posted every now and I'm always surprised that people react
positively to it. Doing clever tricks like these is NOT what a good programmer
is supposed to do. Especially when they're not documented. This is just
obfuscation for obfuscation's sake.

~~~
mcphage
When I'm in a place to interview programmers again, I should have them read
this story. If they say they like it, I'll know not to hire them...

~~~
djcapelis
Please do. I'll know not to work with you or your company.

------
billpg
Last time this story was posted here, I commented "I hope I never have to work
with this guy, he sounds ghastly!"

This was a new account and I suddenly found myself with -7 karma points. I had
to consider if I should throw that account away or keep it and earn those
points back.

I kept it and now have a little under 3k points. He still sounds ghastly!

------
kps
For anyone interested in how machines like the LGP-30 worked, there's a book
titled _Basics of Digital Computers_ by John S Murphy, nominally in 3 volumes,
though you'll most likely find the combined edition. Though the title sounds
similar to modern yellow-jacketed dross, this book was published in 1958 and
the ‘basics’ go down to vacuum-tube circuits for arithmetic and control.

------
galapago
My favorite quote:

"I have often felt that programming is an art form, whose real value can only
be appreciated by another versed in the same arcane art; there are lovely gems
and brilliant coups hidden from human view and admiration, sometimes forever,
by the very nature of the process."

------
MaggieL
The other funny story about this machine is pretty much the flip side:

Shop practices dictated that when you scheduled debugging time, you couldn't
be bumped off as long as your program was still running.

This led some clever fellow to write a deliberate loop that kept his program
"running" \-- panel lights a-flashing -- while he fashioned a patch for the
most recently noticed bug, which he could then dial in to the memory in-flight
without losing his place in line.

When his ruse was discovered, he was chided for wasting lab resources, to
which his response was: "Wasting resources? Nonsense! I used the optimising
assembler!"

~~~
jacquesm
Do you have a source for that story?

------
carbonmachine
I've seen this story around before, but I'm always curious if anyone has
managed to track him down. Would be a very well read interview if someone
could speak with him. Seems likely he could still be alive.

~~~
jacquesm
[https://spreadsheets.google.com/pub?hl=en&hl=en&key=0Aqz4Zqs...](https://spreadsheets.google.com/pub?hl=en&hl=en&key=0Aqz4Zqs_yZ6vdFNGTFd2eDNWWWU4WnZiaHFVdzRMVlE&output=html)

Lists him as still missing. He might very well still be alive but the clock is
ticking, that librascope archive is full of 'in memoriams'. Tough to see all
these pioneers pass away almost unnoticed.

------
adamgravitis
“If a program can't rewrite its own code”, he asked, “what good is it?”

Amen.

------
webmaven
Needs a [1992] in the title.

------
shmerl
That's a classic.

------
LeoPanthera
A classic, but hard to believe anyone here hasn't seen it before!

~~~
Siecje
There are new developers, like me, that have not been around for a long time.

~~~
shmerl
In such case it's worth reading the whole jargon:
[http://www.catb.org/jargon/](http://www.catb.org/jargon/) (in print version -
The New Hacker's Dictionary).

