[po1nt]

Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives.

While we talk about maintainability, we all admire Fast Inverse Square algorithm.

Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety. If you ship audio gear, optimize for latency.

[account42]

> If you have high team fluctuation, optimize for readability.

Or better: If you have high team fluctuation, optimize that first so your team is actually effective.

[po1nt]

You can't fix faulty management as a developer. You can structure a code base around it.

[AlotOfReading]

A traditional engineer can't force purchasing to buy the right parts, but that doesn't mean they should make do by ducttaping sheet metal onto the reactor as a substitute. Technical workarounds are a poor solution to social programs.

[0123456789ABCDE]

but do we care, if management doesn't?

[po1nt]

I do take pride in my work. Keeps me from going insane and switching careers to take on leatherworking. Even if I have to fight the uphill battle with incompetency.

[0123456789ABCDE]

not to dunk on you, but you're following "Keeps me from going insane" with "Even if I have to fight the uphill battle with incompetency"

[bunderbunder]

I do wonder if sometimes these things are set up as false dilemmas, though.

I skimmed through NASA’s coding manual a while back, and one of the things that I took away from it was that optimizing for readability is optimizing for safety.

It’s just that it’s hard for me to see it as readability because I’m not familiar with the problem domain. For example, their ban on reentrancy would definitely require me to rewire my brain a bit. But, for what they are doing, that is a readability decision: they needed to be able to guarantee that a spacecraft’s firmware couldn’t experience a stack overflow, and reentrant code makes it much harder to reason about stack growth.

[po1nt]

Removing null pointer guards would improve readability, not safety. Removing hashing on passwords would also improve readability and made the program easier to debug.

[bunderbunder]

That feels like a strawman to me? Both of those are examples of simply not implementing functional requirements, which is never ok.

For storing passwords in the clear, that should be obvious.

For null checks it may be more subtle, but consider the case of languages like Rust and Kotlin that let you eliminate null checks and replace them with static guarantees that a reference won’t be null. In noth cases that’s celebrated as a win for both safety and readability. So I’m inferring an unstated major premise that we’re talking about skipping null checks in functions where null cannot be formally eliminated from the function’s input domain. (Maybe we’re working in Java instead.) In which case I must insist that null checks are good for readability because they explicitly communicate important information about what arguments the function is willing to accept. It’s leaving that important information unstated and implicit that would be bad for readability.

[po1nt]

Safety is almost never functional requirement (unless for OpenSSL and such projects). You can always focus just on the happy path expecting users will behave. Even in Rust you can unwrap on unexpected value instead of handling it properly. It will lower the LoC, thus increasing readability but possibly crashing the program on unexpected inputs. Possibly leaving open doors for DoS where attacker would just spam invalid input and crashing the server.

[doctorpangloss]

> we all admire Fast Inverse Square algorithm.

i don't. that guy basically made the same game over and over again, while nearly everyone else was innovating in game design, reaching new audiences, etc. that's what change is about!

and then, he blows up the next thing he's put in charge of (VR), and blames everyone but himself. how many billions did he get and he couldn't figure it out? every bit of ethos from that guy was bad, it's not just the one little ethos of the hardcore little optimization algorithm, it's every ethos.

[po1nt]

Quake III was widely successful. John Carmack (probably not author of the algo anyway) later open sourced the game 6 years later which is admirable. Regarding his VR achievements, he made VR viable and not just a military project. I actually like John Carmack and I see him as one of the OG garage programmer.

I personally think he was enormously successful in VR, just not in a market sense but in a technology and UX sense. In my opinion VR is still yet to come to a mass adoption, just not in the "second life" fantasy, but in the "replacement for workspace monitors" kind of way.

[lo1tuma]

Very true. I think the authors area settles more in the webdev area, where you can make releases multiple times per day.

> Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety. If you ship audio gear, optimize for latency.

I fully agree with that.

[KptMarchewa]

> ultrasonic knives

Wow, TIL.