Ordinarily, when someone is denying an offer or rejecting an idea, they're going to put on the kid gloves and try to make sure you feel good even though they're doing something that, for all intents and purposes, shouldn't make you feel good. Although there is no negative intent when someone is attempting a "sensitive" approach, it can be interpreted as a form of dishonesty and condescension: "why is this person pretending to be doing something good for me when they're so obviously not? do they think I'm so dumb I won't notice?".
Frequent contact with that communication style sometimes triggers a deep-seated resentment for it. By the same token, some people are deeply appreciative of the general concern for the recipient's emotional health and self-worth reflected in such statements and are taken aback when they come in contact with someone who doesn't choose to communicate in that way.
It's hard to find a middle ground that works for everyone, regardless of their background or perspective. I guess that's why we have professionals dedicated to finding the ideal phraseology for corporate communications. Maybe it could be argued that we shouldn't we try to do that.
We'd have less, but much better software.
For an opposing example, look at the world of JavaScript.
But we should abstract away from the language. We've had 35+ years of experience of designing and implementing user interfaces, including their design patterns (MVC, Action/Event based). History is filled with successful designs.
Just consider a sophisticated tool such as your standard IDE: do/undo functionality, separation of concerns, event based, MVC, good standard graphical toolkit, easy deployment and upgrades. These designs are not new, and date back to at least the late 90's (Delphi).
What changed? Well, we've been doing incremental design: throw something at the wall, see what sticks and debug the hell out of it while adding new features. Perhaps that design philosophy is not very tenable in the long run.
That's hardly what I'd rate as "primitive".
That a lot of people carelessly throw together CRUD apps does not contradict what I'm saying. In fact, I'd say most CRUD app development is highly primitive, notwithstanding the complexity of the web platform itself.
Debuggers do tend to sometimes to mask heisenbugs, but this goes the same for just about any tool performing intricate binary analysis. And there's some subtle timing bugs where it's a fact of life that you'll get misleading readings.
Fact is, without debuggers, most highly subtle war story bugs would go unsolved. Logic analyzers, tracers and ICEs are debuggers, too. "Debugger" doesn't just mean gdb. Not that there's anything wrong with it.
There's a ton of programmers who can't code without a debugger because they don't really understand what's going on any other way than line by line. Those people would be filtered out. Debugging doesn't require a debugger, it's just the easy way to do it.
The key to better software is learning from the research literature, not thinking that you're improving because you write nothing but ASM macros in ed(1) in a TTY emulating a VT100 from the 70s.
Sure there, it's been said multiple times; those still writing software would be the smartest around. That alone is reason enough to think the overall quality would be higher; if you don't believe that, then imho you don't know what overall (average) means. You're not listening, you're focusing on outliers and I'm taking about the mean. It's a valid logical inference that if you weed out less intelligent developers by making developing harder, that the average quality goes up; not the absolute quality, the average, mostly because you'd be weeding out tons of bad developers who write tons of bad software. This really isn't debatable, it's logic. Weeding out the bad raises the average quality, there's nothing to argue here, that's just a fact.
Theo de Raadt, on the other hand, has never stopped hacking since his days in NetBSD.