4 ms·

It reminds me of "Mel"in 1983 which was in response to "Real Programmers write in FORTRAN." https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.

It reminds me of "Mel"in 1983 which was in response to "Real Programmers write in FORTRAN." https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html

notfish 4y ago
Which is, of course, included as “The story of Mel” in the jargon file: http://www.catb.org/jargon/html/ http://www.catb.org/jargon/html/
- still_grokking 4y ago
  I was fascinated by this story as teenager. But looking back on it, I would say out of my current perspective this Mel guy was not a genius, but one of the worst programmers you could probably hire: He written unmaintainable and even unchangeable "write-once" code that was so complex that nobody else could handle it either. He refused to do what he was payed for and just went away as he lost interest. One of this kind of dudes on your engineering team and your company is in real deep trouble… It's a given that you will need to throw away everything they did and start form scratch should any changes be necessary later on. However there's one fundamental constant in software engineering: Your software is going to need to change over time! No mater whatever somebody told you upfront. So in case you've got software built by some "Mel" you're completely screwed at that point, especially as changes to SW are usually needed the most at some critical period in time for your company.
  - alar44 4y ago
    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.
    - still_grokking 4y ago
      > 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.
      - triknomeister 4y ago
        What are you smoking? :-P
        still_grokking 4y ago
        I won't tell you. But it's quite strong. B-)
      - LordDragonfang 4y ago
        >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 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 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.
  - dusted 4y ago
    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.
    - still_grokking 4y ago
      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.
      - dusted 4y ago
        I'm pretty sure a card dealing game is rarely considered mundane enterprise software..
        4y ago
  - dleslie 4y ago
    > Your software is going to need to change over time! Not so for anything shipped on ROM.
    - nske 4y ago
      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.
      - dleslie 4y ago
        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.
  - IggleSniggle 4y ago
    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.
    - still_grokking 4y ago
      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.
- ExtraE 4y ago
  Direct link: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
- a1pulley 4y ago
  I was a physics major until I stumbled across the jargon file online. It was an, "aha, my people!" moment. It was already showing its age then—nearly 20 years ago!—but sucked me into CS where I was much happier.
drewzero1 4y ago
This comes up on here every few months, and I can't help but read it every time. We had a few Mels in the earlier days of my employer's history and I can't help but be a little bit in awe of the stories I've heard from and about them.
dqpb 4y ago
> the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.

It reminds me of "Mel"in 1983 which was in response to "Real Programmers write in FORTRAN." https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html

notfish 4y ago

Which is, of course, included as “The story of Mel” in the jargon file: http://www.catb.org/jargon/html/ http://www.catb.org/jargon/html/

still_grokking 4y ago
I was fascinated by this story as teenager. But looking back on it, I would say out of my current perspective this Mel guy was not a genius, but one of the worst programmers you could probably hire: He written unmaintainable and even unchangeable "write-once" code that was so complex that nobody else could handle it either. He refused to do what he was payed for and just went away as he lost interest. One of this kind of dudes on your engineering team and your company is in real deep trouble… It's a given that you will need to throw away everything they did and start form scratch should any changes be necessary later on. However there's one fundamental constant in software engineering: Your software is going to need to change over time! No mater whatever somebody told you upfront. So in case you've got software built by some "Mel" you're completely screwed at that point, especially as changes to SW are usually needed the most at some critical period in time for your company.
- alar44 4y ago
  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.
  - still_grokking 4y ago
    > 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.
    - triknomeister 4y ago
      What are you smoking? :-P
      - still_grokking 4y ago
        I won't tell you. But it's quite strong. B-)
    - LordDragonfang 4y ago
      >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 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 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.
- dusted 4y ago
  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.
  - still_grokking 4y ago
    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.
    - dusted 4y ago
      I'm pretty sure a card dealing game is rarely considered mundane enterprise software..
      - 4y ago
- dleslie 4y ago
  > Your software is going to need to change over time! Not so for anything shipped on ROM.
  - nske 4y ago
    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.
    - dleslie 4y ago
      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.
- IggleSniggle 4y ago
  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.
  - still_grokking 4y ago
    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.
ExtraE 4y ago
Direct link: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
a1pulley 4y ago
I was a physics major until I stumbled across the jargon file online. It was an, "aha, my people!" moment. It was already showing its age then—nearly 20 years ago!—but sucked me into CS where I was much happier.

drewzero1 4y ago

This comes up on here every few months, and I can't help but read it every time. We had a few Mels in the earlier days of my employer's history and I can't help but be a little bit in awe of the stories I've heard from and about them.

dqpb 4y ago

> the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.