Live data from Hacker News

The Story of Mel (1983)

cs.utah.edu

111–120 of 175 posts

Re: The Story of Mel (1983)

#111
post #98
post #94

Earlier quoted context omitted.

:D I'm just guessing at questions, since I don't have much context. You found him-- did you get to really talk to him? Find out how he looks back on that era? Did he keep programming? What scared him away?

> You found him-- did you get to really talk to him? Yes. Here's the e-mail exchange: http://acuozzo.sdf.org/Mel.pdf (I moved all of my e-mails to Gmail via Thunderbird years ago which is why the sender address is different.) I found him after Bill Bryner mentioned in an e-mail that Mel "was trying to become an expert (Master?) at Bridge and also played flute with the UCLA pep band for basketball games". I figured he…

I guess Mel could have been in the region of 80 years old at the time, and the few 80 year olds I’ve known have been very private individuals.

Re: The Story of Mel (1983)

#112
post #81
post #35

Earlier quoted context omitted.

+1000. But in my experience the trend started not with developers, but with the other people around them: Product Managers, Designers, Engineering Managers, Steve Jobs wannabes. There was an obvious disdain for users, and they were seen as complete dunces that should be shepherded to whatever new functionality happened to pop up their heads. There was also a complete disdain for the medium: designers used to print de…

non-iterative, Steve-Jobsian-gut-feeling-centric development This is a misunderstanding of Jobs. It’s true that he had a disdain for what users would _say_ they wanted, but he was very focused on providing the, with something intuitive and easy to use. He wanted to make their lives better, and to ‘surprise and delight’. He was also very iterative. He regularly saw demos of in-production software (and hardware), and w…

Sorry, let me rephrase: I don't think Steve Jobs was like that at all.

But the copycats that don't believe in iterative development or in user research love to pretend they got all figured out before it's out for development.

Re: The Story of Mel (1983)

#113

Earlier quoted context omitted.

> There was an obvious disdain for users The disdain for "lusers" came from BOFH sysadmin types, well before it was adopted by the non-"tech", business-focused folks.

> The disdain for "lusers" came from BOFH sysadmin types, well before it was adopted by the non-"tech", business-focused folks. Based on the definitions in the thread, I'd say the BOFH attitude is more the inverse: it is contemptuous towards users, whereas the modern practice is more condescending towards users. The latter still has a notional ethos of catering to the user, but the Monkey's Paw corruption caters towa…

Exactly, the modern practice is condescending. The prevalent thinking is that "users don't really know what they want", so there is zero research, zero iteration, zero respect and a lot of corralling in the application to force users into a (lucrative) workflow.

But the treatment itself is first class, unlike with sysadmins of yore.

Re: The Story of Mel (1983)

#114
post #28

I hope I never have to work with someone like him. He sounds awful.

Obviously, not documenting things and writing the most clever code possible makes it difficult for other people to read your code, there’s no doubt about that. And the story acknowledges that. It’s clear that Mel is a very clever programmer but probably a pain to work with. But your comment is just so dismissive of the point of the story, Mel’s cleverness. It comes across like you saying “This person sounds awful bec…

“This person sounds awful because they’re smarter than me.”

I didn't read the comment that way, but then I share the opinion that Mel seems like a difficult person to work with or to manage. Wrote obscure code and apparently failed to document any of it. Took glee when said code worked the opposite of requested. The guy who took over seems to have had to waste countless hours trying to de-obfuscate the code in order to reverse the logic of the test.

I appreciate the cleverness, but there are some red flags here. Also, I got the impression that some of the cleverness was for its own sake, rather than out of necessity.

Re: The Story of Mel (1983)

#115
post #60

I bought the Hackers Dictionary by Eric S. Raymond as a 90s kid and it had this story, as well as a few others. Das Blinkenlights and some AI Koans like the Broken Lisp Machine come to mind. I used to read them over and over, and it really left an imprint on me. The early hacker ethos was such a strong flavor. Sort of a "one part gnostic, one part mechanic, one part counterculture" vibe. Sometimes I wonder if that fl…

> I bought the Hackers Dictionary by Eric S. Raymond That hurts a bit to read. Raymond is/was a huckster who took the original Hackers Dictionary, a communal MIT project, and made some edits. He went on to annoy the Linux community with his CML2 antics around the build system. Lisp/MIT, BSD, and Linux all have their own histories, a mixture of forgettable drama and fundamental difference.

> a communal MIT project, and made some edits

The Jargon File had been dead and dated for nearly a decade when he picked it up. His maintenance and publication was an important part of making this content relevant and accessible to future generations.

Eric Raymond's work is a mix of good and bad-- like you could say about anyone.

Re: The Story of Mel (1983)

#116
post #64
post #18

Sadly 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…

I don't remember the norm being "desktop apps which started in an instant 20 years ago". Or 30, for that matter. Do you have any data for that? E.g., when I think back over launching Photoshop over the decades, I remember loading screens all the way through. My take is that launch times are on average better but still not great. And I think that's because something else that's constant is that programs first get writ…

> I don't remember the norm being "desktop apps which started in an instant 20 years ago".

What keeps happening is-- we get an upgrade, and then have some old applications, and they become "instant" in comparison to our experience with both newer stuff and the application in the past. Then we watch that win clawed away from us.

Of course, it was never instant, even with the old or newer hardware.

My brother spoke a few weeks ago of being awestruck and programs starting "instantly" when he got a hard disk on DOS on the XT. But now I have a better-than-XT-equivalent (9.54MHz V20) with a very fast IO subsystem and I can tell you that it is very much not actually instant.

Re: The Story of Mel (1983)

#117

Earlier quoted context omitted.

I've wondered this too. When my dad was learning to program, this was the culture. When I was learning to program, the culture was no longer fresh and alive, but its spirit was still strongly felt; the torch was being passed to us. Have we preserved that light? If my son learns to program, what will "hacker culture" mean to him?

Maybe being able to figure out strangers' discord passwords. More generally, phishing powers

I think in this context, 'hacker' means more 'one that twiddles bits' than 'one that twiddles others bits'.

Re: The Story of Mel (1983)

#118
"The program used an elegant (optimized) random number generator to shuffle the "cards" and deal from the "deck", and some of the salesmen felt it was too fair, since sometimes the customers lost. They [the Sale Department] wanted Mel to modify the program so, at the setting of a sense switch on the console, they could change the odds and let the customer win. Mel balked. He felt this was patently dishonest, which it was, and that it impinged on his personal integrity as a programmer, which it did, so he refused to do it."

IMO, this story can be a sort of Rorscasch Test that can reveal something about its readers.

For example, when I read this what stands out to me is that Mel brought a sense of ethics to the use of computers.^1

Salespeople at Mel's employer wanted to use computers to manipulate customers. Mel refused to help them.

Others read this story and only focus on Mel's tactics for programming a computer.

"You can learn a lot about an individual just by reading through his code, even in hexadecimal. Mel was, I think, an unsung genius."

In the same way the story's author, who was a Professor of Astronomy at IT Austin, believed that reading Mel's source code could reveal something about Mel, to me, the comments of people who read this story can reveal something about those readers.

"The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it."

To me, "The Story of Mel" is about a person who preferred to think for himself instead of letting others do it for him.

If memory serves me correctly, I recall seeing comments online about this story that "advise" readers, "Do not be like Mel." The question is what do they mean by that. Are they referring to programming tactics, ethics, both, or maybe something else entirely.

1. No only that, but the author was so impressed by Mel's ability that he adopted similar ethics himself.

Re: The Story of Mel (1983)

#119
post #71

So, the RPC-4000 version of blackjack seems lost, but the LGP-30 version exists (and can be run on simh). I've disassembled and partly annotated it, and found that it too has a sort of cheat switch. The LGP-30 has no source of randomness to use as a seed. From loading the program, if the player plays optimally, the games will all be the same. Over the first few dozen games, the player ends up in the hole (IIRC, notic…

Too late to edit, but I misremembered a little: from an earlier comment that I'd forgotten I'd made¹, the program image on paper tape had the aces marked dealt, and the TRANSFER CONTROL test switch merely skipped the part of initialization that cleared it. This means that (with sufficient time and dedication) one could in principle prepare multple tapes with different starting configurations, analogous to editing a binary to change a hardcoded seed.

¹ https://news.ycombinator.com/item?id=20489774

Re: The Story of Mel (1983)

#120
post #30

In 1997 I was doing an apprenticeship. It had a very well organized curriculum and well thought courses. One course was based on 8080/8085 cpu. You know what they gave us: A development board (roughly the size of a modern mainboard) with onboard hex keyboard 0-9a-f and 3-4 function keys (halt, run, write at ... something like that). And a book and templated paper. So the exercises, 3-4 hours every week, were: Impleme…

My CS (or EE?) class did this in 1996 with a Z80 board
Post reply on HN