Hacker News Reader

To me, it feels like adding a booby trap in one of emergency rooms in the hospital.

When nurses complain about the injuries and the inconvenience, you berate them because "if they can't remember that in room 4 there is a booby trap, are they really intelligent enough to be nurses?"

This exact argument was made about pilots. If they can't figure out <counter-intuitive nonsense design>, then they shouldn't be pilots!

For a recent example, the MCAS design is nonsense, yet people were blaming the pilots, stating something along the lines of: "On page 837 paragraph 7, there's half a sentence that explains how to resolve the issue."

Forgetting to mention that the cause of the issue was purposefully omitted, and that the issue of unexpected trim change typically has a familiar and resolvable cause, not one that physically overpowers pilots... repeatedly. With delays. With no warning signal.

Even other pilots were blaming the dead pilots for making mistakes that were not humanly possible to avoid or recover from.

Why stop at bad design? The cause for that design decision had (as often) monetary/managment reasons.

So the bad design decision resulted from a bad business decision, which was the result of the whole incentive structure within the company, which was the result of the way that corporation operates (has to operate?) within a capitalist environment.

On another layer the regulators did not prevent the MCAS because they themselves have been influenced by economic incentives, lobbying and lack of expertise. In short: capitalism again.

If we wanna live in a capitalist society that is driven by such incentives, we need to be aware that the huge resources and big incentives for corps to take shortcuts and prevent effective regulatory overssight need a powerful counterplayer that is capable of keeping these entities in check.

How we go about that is a different thing, but anybody labouring under the illusion that a next MCAS could be prevented by market forces alone should go see a doctor.

> The cause for that design decision had (as often) monetary/managment reasons.

In the particular case of MCAS that's true, but so often it's simply thoughtless.

Management aren't often given a menu of options with "Really terrible idea that might be profitable" picked from the list. People down in the trenches don't know why you should do X rather than Y and so 50-50 chance you get either, despite the differences. If you told them, "Oh, don't do Y if you can do X, here's why" they'd make better choices and we'd only be talking about cases where management actually said "Yeah, do the terrible idea, we think that would be profitable".

Here's a link to P2000R4 https://www.open-std.org/JTC1/sc22/wg21/docs/papers/2022/p20...

That's a paper for WG21, the C++ Committee to read, but don't worry about what it means, look at how it was rendered. A big section from pages 8 and 9 is "highlighted" by changing the text background to angry red. In the process for many people this text is rendered unreadable due to contrast problems.

Nobody in "The Direction Group" is a rogue artist, here to confront us with black-on-red text as a metaphor for why it's wrong to worry about programming language safety or whatever -- just somebody clicked red in their word processor without really thinking about it and likely with no understanding of why it might be a bad idea.

The old Frank Borman quote is: "A superior pilot uses his superior judgment to avoid situations which require the use of his superior skill."

Maybe we need to add: "A superior aircraft designer uses their superior design skills to avoid situations which require a superior pilot".

There really are apparently "trivial" things in even vaguely modern (like maybe 50+ years old) aircraft that were not like that in 1940s or sometimes 1950s planes because even though we know they killed people the attitude was "You should just know about that". No, fix the plane.

Certainly for programming languages we need to be clear that bad error messages aren't a lack of knowledge by the programmer, they reflect poorly on the quality of the software.

But this applies generally across the design of everyday things. That push door with the word "PULL" written backwards? That's a bad design. Yes, I understand, I am reading a sign meant for people on the other side of the door, but you should have designed the door differently.

Or a thing that periodically annoys me: USB A plugs have the USB trident logo on them. The USB compliance rules say to put the logo on the "top" of the plug. So e.g. if you plug six USB A things into a typical laptop, the logo faces up on every port, the ports are all oriented the same way. So it ought to be very easy to insert USB A plugs when you can see what you're doing. Not perfect, but hey - except even some fairly decent brands decide their brand logo is more important than compliance, so e.g. this XBox controller plugged into a Windows laptop is "upside down" because they just couldn't bear to put the trident logo where the compliance rules said it needs to be...

> That's just, wrong on so many levels. Anyway, I'm just happy they didn't say anything like "people who screw up colons shouldn't be coding"

A lot of those arguments read like they have a lack of empathy and desire to make things easier for new programmers who want to learn or use the language. To me, it comes across as if coming from a position of arrogance, especially the latter claim - a perspective that I've sadly have encountered often, with many people unapologetically being happy about their solutions or the status quo being being unapproachable or needlessly complex - be in regards to system design, code structure, or even how entire libraries (or languages) work.

Then again, even people like Richard Stallman and Linus Torvalds have been known to be difficult in certain regards. I'm not sure whether our industry seems to attract people who have strong feelings about certain things, or whether those beliefs are simply more apparent. Either way, you'll have to deal with that, either because of technologies that you need to use and don't have control over, or because of having to work on certain projects together with developers like that.

Best you can do is probably be as nice as you can towards others yourself.

Also, web archive link, in case the site is down (rate limited) for anyone else: https://web.archive.org/web/20221204044109/https://phil.tech...

> And if you can’t remember the meaning of something like that, I hardly doubt you’d be a decent programmer anyway.

Ah, the elitest assholery that made PHP a wonderful place to be /s

If seen PHP called a lot of things but “elitist” is new to me.

Read through old-ish posts on their maintainer mailing lists. There’s so much snobbery, elitism, and straight-out hostility to anyone from the outside, it reads like 8chan.

This has changed by now, but the PHP maintainer community before version 7 was a circle jerk of hyper anal trolls.

> I hardly doubt you’d be a decent programmer anyway.

I would like for somebody to hardly doubt that I was a decent programmer. Unfortunately most people belong to the "highly" faction

> "people who screw up colons shouldn't be coding"

If you can’t get something as simple as a colonoscopy right, you shouldn’t be anywhere near a terminal.

This remind me a discussion about making Wordpress natively compatible with Sqlite. Somebody put on the the table that Sqlite is using the rule of St. Benedict (adapted I would say) as they code of conduct and that should be a no-go for such development.