5 ms·

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 s

by ginko 12y ago

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.

djcapelis 12y ago
Bending the limits of the machine and doing the unexpected may not necessarily be great engineering, but it's amazing art. It's not uncommon for the best programs to have a bit of art inside them that make them work. Especially in high performance timing critical operations close to the hardware. Very few people work in those realms these days and these types of things aren't often necessary, but they're still beautiful and occasionally outright necessary.
burkaman 12y ago
"I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster." I think that's a big part of why people like the story so much.
- Crito 12y ago
  It's a very "John Henry" story. A man fights the machine, and wins, but the victory is shallow because the machine continues to improve with every passing year. Eventually, people like the man are made obsolete. http://en.wikipedia.org/wiki/John_Henry_%28folklore%29#Legend http://en.wikipedia.org/wiki/John_Henry_%28folklore%29#Legen...
bagels 12y ago
"I found an innocent loop that had no test in it... It took me two weeks to figure it out." I think you're right. How much time/money did that clever loop trick waste?
- mikeash 12y ago
  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.
  - jacquesm 12y ago
    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.
  - mcphage 12y ago
    > 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.
    - kps 12y ago
      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. † http://research.microsoft.com/en-us/um/people/gbell/computer_structures__readings_and_examples/00000237.htm http://research.microsoft.com/en-us/um/people/gbell/computer...
dllthomas 12y ago
It's great to be able to handle stuff like this, when it actually does prove necessary (and the degree to which Mel could apparently handle it is impressive). I agree that it is not what you should be doing if there's any way around it (as there more often is, these days), and that the apparent lack of documentation is appalling (though depressingly common).
jacquesm 12y ago
I don't think I can enumerate the number of ways in which I disagree with you. - It's only obfuscation if you have the luxury of solving it in another way. - the times have changed (1956), but the methods have not - sure, it may be obscure but it shows perfect control of the machine and the issue at hand - agreed, it is not maintainable, but back then feature changes usually meant re-writes and people thought longer about what they wanted before they started building. Machine time was more expensive than programmer time. - being clever is (to me at least) exactly what hacking is all about, finding a solution to a problem where you thought none existed. Ask yourself this: if Mel's code was so useless how come some hotshot didn't re-write it using 'best practices' and zero 'clever tricks'? The answer: likely because it could not be done. Mel delivered. - the rebel in me likes Mels attitude towards management. Sure, if you're in management you'd hate him twice weekly but I note that Mel did not get fired, instead moved on to greener pastures - I compare this with the way a jeweler would make his little works of art versus the way a production welder connects pieces of pipe. Mel is the jeweler, you'd rather we all just join pieces of pipe. - I've gone through some of the assembly code for 80's video games and that stuff was full of tricks like this (and without it would never have gotten of the ground). Making a computer output the right results within the margin of error visible to the user when lacking the 'proper' resources is where creativity comes in. And in that case I'd much rather have a guy like Mel by my side than any number of {insert high level language of choice here} pushers because if it is at all possible guys like Mel will find a way. Anyway, as you can see, we're likely not going to agree on this one.
- JoeAltmaier 12y ago
  My professor said it this way: Engineering begins when the problem constraints admit of no solution.
  - atmosx 12y ago
    Really nice quote, what is the name of your professor? :-)
    - JoeAltmaier 12y ago
hibbelig 12y ago
People like to watch James Bond even though they don't jump off a cliff with a wingsuit. So I love this story of optimizing and pessimizing machine code even though I don't write machine code.
coldtea 12y ago
>is NOT what a good programmer is supposed to do Doing what you're "supposed to be doing" is not always what life is about. People also love anti-heroes.
saucetenuto 12y ago
It's the story of a man who did a beautiful thing. It wasn't the _right_ thing, but it was still beautiful. Also, it helps that the stakes are so low. Mel's optimized program cheats at Blackjack, and the protagonist is trying to make it cheat in a different way. We're not invested in his success, so we can enjoy his failure, and maybe even root for it. If the same story were set in the context of the Therac-25, it would be received very differently.
wirrbel 12y ago
Considering that this was the 50s and the first compiler was written by Grace Hopper in 1952 I think judging that guy is a little unfair. We are at the moment at a point where Hardware is (to a degree) cheaper than manpower. You might want to think that one cost can be traded in for the other, which often is the case, yet there are those moments were the assembler programmer might miss the asymptotically more efficient solution that saves magnitudes of time and situations were that Cache-Miss in one of the inner loops just kills performance (and maybe kills that startup because the Application just stalls). While I would never ever want to work like Mel, I share the admiration for Mel's work and propose that "Best Practices" be renamed "Somewhat-Optimal Practices" in his honor.
csours 12y ago
This makes me think of demoscene code. Squeeze the most out of a tiny amount of code. http://en.wikipedia.org/wiki/Demoscene http://en.wikipedia.org/wiki/Demoscene
njharman 12y ago
I agree that doing clever tricks is not good software development. But that does not diminish at all the delightfulness of this story nor Mel's awesome mastery.
mcphage 12y ago
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 12y ago
  Please do. I'll know not to work with you or your company.
- patrickmay 12y ago
  Send them to me.
the_af 12y ago
I sort of agree with you. Mel's story is colorful and I definitely love it as a piece of hacker culture. But we should be thankful we do NOT have to work with Mel in the same team. He could probably out-program us all (at least back in the day), but I doubt his trick would be the most effective use of time in today's application programming. Mel was a real programmer because he did the best with the limited tools of the day, but nowadays... "it was hard to write; it should be hard to read", while funny, is something to be avoided.
deleted 12y ago
[deleted]
xxs 12y ago
Back in the late 80s and early 90s it was still possible to regularly beat the stock compilers with hand written assembler (could that personally). The story used to produce a lot of awe but now it's getting doubted by those pesky best practices.

by ginko 12y ago

djcapelis 12y ago

Bending the limits of the machine and doing the unexpected may not necessarily be great engineering, but it's amazing art. It's not uncommon for the best programs to have a bit of art inside them that make them work. Especially in high performance timing critical operations close to the hardware. Very few people work in those realms these days and these types of things aren't often necessary, but they're still beautiful and occasionally outright necessary.

burkaman 12y ago

"I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster." I think that's a big part of why people like the story so much.

Crito 12y ago
It's a very "John Henry" story. A man fights the machine, and wins, but the victory is shallow because the machine continues to improve with every passing year. Eventually, people like the man are made obsolete. http://en.wikipedia.org/wiki/John_Henry_%28folklore%29#Legend http://en.wikipedia.org/wiki/John_Henry_%28folklore%29#Legen...

bagels 12y ago

"I found an innocent loop that had no test in it... It took me two weeks to figure it out." I think you're right. How much time/money did that clever loop trick waste?

mikeash 12y ago
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.
- jacquesm 12y ago
  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.
- mcphage 12y ago
  > 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.
  - kps 12y ago
    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. † http://research.microsoft.com/en-us/um/people/gbell/computer_structures__readings_and_examples/00000237.htm http://research.microsoft.com/en-us/um/people/gbell/computer...

dllthomas 12y ago

It's great to be able to handle stuff like this, when it actually does prove necessary (and the degree to which Mel could apparently handle it is impressive). I agree that it is not what you should be doing if there's any way around it (as there more often is, these days), and that the apparent lack of documentation is appalling (though depressingly common).

jacquesm 12y ago

I don't think I can enumerate the number of ways in which I disagree with you. - It's only obfuscation if you have the luxury of solving it in another way. - the times have changed (1956), but the methods have not - sure, it may be obscure but it shows perfect control of the machine and the issue at hand - agreed, it is not maintainable, but back then feature changes usually meant re-writes and people thought longer about what they wanted before they started building. Machine time was more expensive than programmer time. - being clever is (to me at least) exactly what hacking is all about, finding a solution to a problem where you thought none existed. Ask yourself this: if Mel's code was so useless how come some hotshot didn't re-write it using 'best practices' and zero 'clever tricks'? The answer: likely because it could not be done. Mel delivered. - the rebel in me likes Mels attitude towards management. Sure, if you're in management you'd hate him twice weekly but I note that Mel did not get fired, instead moved on to greener pastures - I compare this with the way a jeweler would make his little works of art versus the way a production welder connects pieces of pipe. Mel is the jeweler, you'd rather we all just join pieces of pipe. - I've gone through some of the assembly code for 80's video games and that stuff was full of tricks like this (and without it would never have gotten of the ground). Making a computer output the right results within the margin of error visible to the user when lacking the 'proper' resources is where creativity comes in. And in that case I'd much rather have a guy like Mel by my side than any number of {insert high level language of choice here} pushers because if it is at all possible guys like Mel will find a way. Anyway, as you can see, we're likely not going to agree on this one.

JoeAltmaier 12y ago
My professor said it this way: Engineering begins when the problem constraints admit of no solution.
- atmosx 12y ago
  Really nice quote, what is the name of your professor? :-)
  - JoeAltmaier 12y ago

hibbelig 12y ago

People like to watch James Bond even though they don't jump off a cliff with a wingsuit. So I love this story of optimizing and pessimizing machine code even though I don't write machine code.

coldtea 12y ago

>is NOT what a good programmer is supposed to do Doing what you're "supposed to be doing" is not always what life is about. People also love anti-heroes.

saucetenuto 12y ago

It's the story of a man who did a beautiful thing. It wasn't the _right_ thing, but it was still beautiful. Also, it helps that the stakes are so low. Mel's optimized program cheats at Blackjack, and the protagonist is trying to make it cheat in a different way. We're not invested in his success, so we can enjoy his failure, and maybe even root for it. If the same story were set in the context of the Therac-25, it would be received very differently.

wirrbel 12y ago

Considering that this was the 50s and the first compiler was written by Grace Hopper in 1952 I think judging that guy is a little unfair. We are at the moment at a point where Hardware is (to a degree) cheaper than manpower. You might want to think that one cost can be traded in for the other, which often is the case, yet there are those moments were the assembler programmer might miss the asymptotically more efficient solution that saves magnitudes of time and situations were that Cache-Miss in one of the inner loops just kills performance (and maybe kills that startup because the Application just stalls). While I would never ever want to work like Mel, I share the admiration for Mel's work and propose that "Best Practices" be renamed "Somewhat-Optimal Practices" in his honor.

csours 12y ago

This makes me think of demoscene code. Squeeze the most out of a tiny amount of code. http://en.wikipedia.org/wiki/Demoscene http://en.wikipedia.org/wiki/Demoscene

njharman 12y ago

I agree that doing clever tricks is not good software development. But that does not diminish at all the delightfulness of this story nor Mel's awesome mastery.

mcphage 12y ago

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 12y ago
Please do. I'll know not to work with you or your company.
patrickmay 12y ago
Send them to me.

the_af 12y ago

I sort of agree with you. Mel's story is colorful and I definitely love it as a piece of hacker culture. But we should be thankful we do NOT have to work with Mel in the same team. He could probably out-program us all (at least back in the day), but I doubt his trick would be the most effective use of time in today's application programming. Mel was a real programmer because he did the best with the limited tools of the day, but nowadays... "it was hard to write; it should be hard to read", while funny, is something to be avoided.

deleted 12y ago

[deleted]

xxs 12y ago

Back in the late 80s and early 90s it was still possible to regularly beat the stock compilers with hand written assembler (could that personally). The story used to produce a lot of awe but now it's getting doubted by those pesky best practices.