Hacker News Reader

He can be a genius to be admired while also being one of the worst programmers you could hire, at the same time. Someone to appreciate, but not to emulate. A highly optimized human being, optimized for the "wrong" thing. More in the realm of art than anything else.

Ok, take your up-vote. I think I can agree on that perspective.

Maybe that's even the point that makes me like the story as such very much.

Nah, those were different times when bits and bytes mattered. Everything was written in assembly/,machine code. Mel's tricks were just how things were done back then. There was no repo, code didn't need to be maintained or added onto. The lifecycle of software was much much shorter.

> Nah, those were different times when bits and bytes mattered.

Obviously not. We're talking about mundane business software.

Also the "optimizing compiler" that couldn't reach such levels of "perfection" wouldn't be a thing if this would really matter.

> Mel's tricks were just how things were done back then.

Obviously not. Otherwise there wouldn't be any point in this story.

It points out, with a lot emphasis, how exceptional Mel's code was!

> There was no repo, code didn't need to be maintained or added onto.

VCS dates back quite some time…

Also maintaining code was of course not any less important for a company as it is today. Simply as companies back than also relayed on their software to operate.

> The lifecycle of software was much much shorter.

No, of course not, as nobody would throw away some very expensive asset for no reason.

If anything, lifecycles of software were much longer than today (when you can deploy changes every few minutes if you please). Stuff written in the 70's is still running on some mainframes today!

As changing software was much more dangerous with much higher risk of breakage, less experts around, and everything much more difficult in general, it was more usual to try to not touch an already running system. (Maybe you even heard some quite similar proverb coined back than ;-)).

But "not touching" it does not work, as there is only one truly constant thing: Change.

What are you smoking? :-P

I won't tell you.

But it's quite strong. B-)

>VCS dates back quite some time…

Let's see. From the story:

>I first met Mel when I went to work for Royal McBee Computer Corp... [The firm] had just started to manufacture the RPC-4000

https://en.wikipedia.org/wiki/LGP-30#RPC_4000

> the General Precision RPC 4000, announced in 1960

https://en.wikipedia.org/wiki/Version_control#History

>IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version control system tools. A full system designed for source code control was started in 1972, Source Code Control System for the same system (OS/360).

The events of the story predate the precursors of VCSs by two years, and the earliest true VCS by a decade.

As you like to discuss this detail:

I can't find any definitive info when this computer got actually manufactured ("announced in 1960" doesn't mean strictly the same). But this was the time Mel was met first time by the author.

The story plays likely some time thereafter.

I guess some significant time, because it takes time even for a genius to become familiar enough with a machine to do all this kind of trickery described in the story.

I think it may make sense to assume even some years passed between when the author met Mel the first time and Mel's departure form said company.

So I wouldn't be even so much off with the VCS statement—which actually doesn't state any relation between the usage of VCS and the story. I've only said that "VCS dates back quite some time". Which is obviously true. ;-)

But, all this actually doesn't matter.

The more important statement was the following. Which is a direct reply to "code didn't need to be maintained", which is in my opinion just not true.

I did not say VCS was used back than for that purpose.

I guess they preferred more a sort of solid hard copy. :-)

My guess is that the earliest Code Versioning systems were completely manual, "Duplicate your tape, mark it 1.2, store it in drawer". And these manual processes were brought to and duplicated on computers when code began to be stored on the computers themselves, instead of through cards and paper tape.

Certainly if you were a business, you had an extreme business interest in keeping your "known good" stack of cards in a place, and every revision in code required a new stack of cards.

"Hey, the machine just ate 10 cards from the payroll software, can we get duplicates made?"

"No, those were the originals, guess we're SOL no one gets paid" never happened.

Most likely "Ok, version 1.34 of the payroll software that was updated last week? Cards 1032 to 1042? Duplicate cards will be up to you within the hour"

or "We have to revert to the old payroll processing software, can you create a new fresh copy of 1.33, 1.34 has some bugs and we need to get tonights run in?"

nah, when you're constrained enough, you rarely to never sacrifice anything in the name of future changes. You figure out what needs to be done, then you write a program that does it. If it needs to change, you write a new program. Part of why that's not as bad as it sound is exactly because of those constraints, you're not dealing with megabytes of source code.

There are lots of problems that are specific and simple enough to solve, that it's easier to write a C program from scratch, than it is to find, install and then learn how to do it with some existing package... The same concept goes for programs.. At a certain scale, it's not worth the extra infrastructure/overhead/rigidity/complexity that it takes to write software that's optimized for change.

That said, today, in 2022, it's more or less the opposite, codebases are huge enough that most of software "engineering" is about plumbing together existing libraries, and at that scale, it's an entirely different thing.

No, not even given the historic context this makes any sense.

We're not talking about embedded software with special constrains here!

This story is about mundane enterprise software.

Nothing in the story justified this insane level of over-engineering and premature optimization.

Just using the "optimizing compiler" was deemed "good enough" for all other needs of the company, likely…

Also nobody asked for that over-"optimized" throw-it-away-and-start-over-if-you-need-to-amend-anything-crap.

I have still this warmth nostalgia feeling when looking at this story, but when thinking about it with quite some experience in real world software engineering I'm very sure that this kind of programmer would be one of the worst hires you could probably run into.

Finding any valid excuses for "write-only" code is hard, very hard. This was also true back in the days this story plays.

Sorry for destroying your nostalgia feeling, but please try to look at it from a professional perspective.

I'm pretty sure a card dealing game is rarely considered mundane enterprise software..

Wasn't it a marketing gimmick? At least that's my understanding.

Otherwise it makes no sens. Computers back than where very expensive. You wouldn't use them for anything that wouldn't yield income in some way.

It quite clearly wasn't a "computer game" in today's meaning.

I would call "marketing support software" indeed "mundane enterprise software".

> Your software is going to need to change over time!

Not so for anything shipped on ROM.

The software running on a specific ROM might not be able to change (assuming we're talking for devices using mask ROM and not EEPROM) but it doesn't mean the code itself is supposed to be disposable. Different devices or revisions of the same device can benefit from code changes. Even on the same device unit, they might want to replace the ROM chip to include some fix if it's important enough and makes financial sense. The software itself transcends the constraints of any particular delivery medium.

Ha, perhaps. I work in game dev, and previously had a stint in integrated display controllers for feature phones. Anecdotally, most of my code is effectively thrown away once shipped.