Live data from Hacker News

The Story of Mel (1983)

cs.utah.edu

81–90 of 175 posts

Re: The Story of Mel (1983)

#81
post #35

Earlier quoted context omitted.

> It really feels like being an end user of modern tech is like being in an abusive relationship. I've come to realize that a lot of modern developers consider users of their tech to be little more than cattle. The tech is cattle feed, meant to fatten and ensnare the user, so they can be sold off and slaughtered. There's really only one party in that kind of relationship that benefits.

+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 would ask for anything from small tweaks to complete rewrites. He was completely unafraid of throwing away work, and would change his opinions on a dime if they didn’t work out.

Re: The Story of Mel (1983)

#82
post #28

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

EDIT:

OP made a response indicating that his objection to Mel was that he left zero documentation.

To this, I agree 100% !!

Leaving no documentation is doing your future self a huge disservice (even a few weeks from now it'll be helpful if you've left yourself some good breadcrumbs to follow), and is pretty much a hostile act towards the team.

----- initial comment -----

Sure, if he's doing that kind of highly idiosyncratic stuff in the modern software & hardware environment, he'd be a hindrance to any team.

But this was not that situation, and sadly, this comment reveals a deep cluelessness about the technology underlying the computing industry.

The article shows a real genius at work, fully understanding that what he is doing is programming a computing machine, and using every available advantage to get to to yield a program that performs well.

Sadly, software now is optimized entirely for the convenience of the developer, and with literally billions to trillions of multiples of the computing power available to Mel, most software today is utter crap, taking tens of seconds to even load because it barely floats in an ocean of bloated abstraction and 'frameworks'.

The fact that you cannot at even recognize the obvious genius in that story indicates that you should really learn a lot more and seriously rethink your approach to computing. Learn how the hardware and software actually work. Work hard to strip out unnecessary dependencies, middleware, frameworks, etc., and make your applications snappy. With today's hardware, there is literally no excuse for software that does not respond faster than any human perception. But sadly, today, if you can make it work that way, you'll be the exception — so be that exception.

Re: The Story of Mel (1983)

#83
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…

Agreed.

My #1 annoyance these days, because it is so egregious, is Electron apps.

I guess because the only language some programmers know is Javascript, of which I know little but what little I know places it marginally above PHP in intrinsic horror.

So people write standalone apps in a language intended for tweaking web pages, meaning that to deploy those apps requires embedding an entire web browser into every app.

And entire popular businesses, for example Slack, do not as far as I can tell have an actual native client. The only way to access the service is via a glorified web page, running inside an embedded browser. Despite which, it can't actually authenticate on its own and needs ANOTHER web browser to be available to do that.

Electron apps make Java ones look lean and mean and efficient.

Apparently, expecting a language that can compile to native machine code that executes directly on a CPU, and which makes API calls to the host OS in order to display a UI, is quaint and retro now.

And it's perfectly acceptable to have a multi-billion-dollar business that requires a local client, but which does not in fact offer native clients of any form for any OS on the market.

It's enough to make me want to go back to DOS, it really is. Never mind "nobody will ever need more than 640kB"... if you can't do it in 640kB and still have enough room for the user's data, maybe you should reconsider what you are doing and how you are doing it.

Re: The Story of Mel (1983)

#84
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…

A lot of that ethos I think is just Generation X plus computers. A rebellious generation that came of age during a time when digital technology had just granted kids the power to wardial norad. I think tinkerers have always been timeless, but that kind of cyberpunk culture is something we're unlikely to see again.

Re: The Story of Mel (1983)

#85
post #82
post #28

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

EDIT: OP made a response indicating that his objection to Mel was that he left zero documentation. To this, I agree 100% !! Leaving no documentation is doing your future self a huge disservice (even a few weeks from now it'll be helpful if you've left yourself some good breadcrumbs to follow), and is pretty much a hostile act towards the team. ----- initial comment ----- Sure, if he's doing that kind of highly idiosy…

Please read his response of about 30 minutes ago, it's a few replies up. It's not what you think.

Re: The Story of Mel (1983)

#86

I think I found Melvin Kaye's obituary a few years ago but I couldn't find it anymore. A pity that both him and Ed Nather passed away :(

There's this comment long ago about getting in contact with him that has always made me curious, but no information was proffered: https://news.ycombinator.com/item?id=7871260

And, of course, there's this picture that was found of him:

https://zappa.brainiac.com/MelKaye.png

Re: The Story of Mel (1983)

#87
post #37

Bonus trivia: those "Raw, unadorned, inscrutable hexadecimal numbers"? Those would not have been the 0-9a-f we're familiar with today, but 0-9fgjkqw[1]! [1]: http://ed-thelen.org/comp-hist/lgp-30-man.html#R4.13

The reason for FGJKQW is simple: Look at the list of single-letter mnemonics for the 16 opcodes (called “orders” in the manual you cite). Sort them alphabetically, and look for the first six letters that are unused. Viola! (Of course, the problematic letter O is skipped, and for some reason, V as well.) That’s how it was explained to me in 1973 by Mr. Willoughby, a math teacher who also taught Computer Programming in…

> And his reason for starting with machine language? “Well, you can’t expect anyone to understand what’s really going on in higher-level languages if you don’t know what’s happening underneath, right?” Worked for me.

I teach a middle school class called "Computer Organization and Design". It's basically from gates and truth tables, up to implementing ALU functions, to understanding bits of sequential logic... then some handwavy computer architecture stuff to save time, and finally on to handing out a simplified, reduced-instruction ARMv7 THUMB machine language reference, and students writing their own programs on paper and assembling them.

There's a couple digital logic labs in there, and finally they get their own little computers with a simple monitor program that lets them enter programs, single step, and view registers.

I wasn't sure how reaction would be. Many of the students love it. Middle school students seem to do pretty good at this stuff, too-- their memory of learning arithmetic is recent enough that learning a bunch of new similar rules (combinatorial operations, multiplexing, hexadecimal, instruction encodings, etc) seems simple. And, well, no one told them this stuff is often considered "hard."

Re: The Story of Mel (1983)

#88
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…

Neat! I'm curious if you remember anything about this or the materials. I have developed something very similar that I teach to middle schoolers:

https://github.com/mlyle/armtrainer

Re: The Story of Mel (1983)

#89

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.

But it became industrialized by business-types. The BOFH thing was personal. They considered (still do, sometimes), users of their systems to be "the great unwashed." Basically, pests. Business types look at users as a resource to be exploited to make money. Basically, livestock. Different outlook. We try to discourage pests, but we breed and incubate livestock. In neither case, are we particularly interested in the…

The only way I see that happening is if it becomes easier to crowdsource donations. When your users are the ones putting bread on your table, they're the boss. Whatever they want they get. But sadly it's hard to crowdsource from programmers because there's so few of us. I love building and sharing software that delights my peers. Not because it's a smart thing to do. If money was the thing I cared about, then it'd be more rational to play video games on Twitch and blog about culture conflict on Substack. Rather coding is something I feel compelled to do and I won't stop even if it destroys me.

Re: The Story of Mel (1983)

#90
post #88
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…

Neat! I'm curious if you remember anything about this or the materials. I have developed something very similar that I teach to middle schoolers: https://github.com/mlyle/armtrainer

That looks very identical ;) just so much more modern. A lot smaller and the screen is so much more fancy.

Think that with old style boards, old-style chips, old-style number screen.

Post reply on HN