Wildly off-topic, but I wonder if people like Sutter get tired of saying "c plus plus". It's a very wordy name, and words that start with "p" has got a certain punching quality that I don't know what is called.
If I was a daily C++ programmer, I'd rather call it "c p p".
I believe I normally hear "c p p" when referencing C++ files (including in aggregate possibly referencing headers), but "c plus plus" when talking about the language proper, the standard, compilers, etc.
Daily reminder that anybody who, in C/C++ application code, doesn't hide their atomic ops, integer sizes, and simd directives behind compiler- and system-agnostic defines deserves to die in a motherfucking fire.
EDIT: Downvote away...if you've ever had to migrate over a codebase that did this, you know exactly what I'm talking about.
So, for certain categories of problems, I disagree.
There's way too little acknowledgement in our industry of just how much suffering and anguish one or two chucklefucks on a codebase can inflict on their teammates. Using only the matter at hand as an example:
"Rude" is waking somebody up to stand watch over a buggy system because it wasn't written properly and will seize up.
"Rude" is wasting senior developer time on a refactor because the last person who touched the code used system calls and primitives only available on one specific compiler and one specific OS, and now the system has to change.
"Rude" is injuring somebody because your embedded controller is using the wrong sized int for something, because it slipped through code review because somebody decided to use a #define that got changed between architecture upgrades and never fixed it.
"Rude" is wasting a tester's day having them try to hop up and down over the same three feet of virtual space while trying to tap the attack key just right to repro a race-condition bug caused by some permutation of the above. 8. Hours. Of. Hopping.
~
When you write shitty software, you are hurting everyone else who might ever have to interact with it--so, uh, yeah, I get to be rude.
No, you don't. Let me rephrase: I think it would be appreciated here, and for the sake of politeness and basic respect towards others, that you do not get rude. There are a thousands of other ways to write down how you feel about something without being rude, and people will still perfectly understand it. Moreover they are even more likely to pay proper attention to it if you are not rude.
> Moreover they are even more likely to pay proper attention to it if you are not rude.
It's funny how some people don't learn this.
Years of internet commenting has taught me the uselessness of posting in anger, and the value of a well-argued, well-written point. Strong emotions one way or another diminish the authority and impact of what you say.
It's easier said than done, of course: strong emotions are often specifically what lead you to make the effort of commenting.
If "strong emotions" were enough to diminish impact and authority, the ad business would simply be placards of bullet points. Even on HN, well-written and cool posts routinely are ignored or actively downvoted.
In the grand scheme of things, politeness is a good idea--but there are a few places where being nice simply won't get you as far as calling somebody out passionately on their wrongness. Low-level systems programming on large codebases with smart and stubborn and harried people is one of those cases.
I know what you're talking about, but honestly none of your items enter into my top tiers of porting pains. They tend to generate nice little compiler errors (and warnings you can upgrade to errors), and the refactoring tends to be a straightforward 1:1 replacement affair. Noticing the "lock free" code is just plain broken and testing the fixes tends to eat more time than the actual porting.
The "abstractions" written by those who don't have multiplatform experience (aka the ones writing platform specific code in the first place) tend to have broken designs that require refactoring even if they do exist. Very little difference in work between fixing a broken abstraction and implementing a missing abstraction for those items, IMO.
Unabstracted or poorly abstracted rendering, input, user management, matchmaking, leaderboards, achievements, save systems, async I/O, and platform specific serialization (image loaders, varying-size bytewise copied structs)... all without unit tests or an assertion between them... I find all much worse! You get to refactor, redesign, and retest all at the same time, leaving behind a trail of breadcrumbs: backwards compatability hacks and compromises...
(Also fun: When you discover existing abstractions were discarded instead of cleaned up, in favor of new abstractions, and you get to re-fix all the re-introduced TCR violations and corner cases.)
23 comments
[ 4.3 ms ] story [ 62.9 ms ] threadIf I was a daily C++ programmer, I'd rather call it "c p p".
It's only three syllables. And faster than "javascript". :-)
EDIT: Downvote away...if you've ever had to migrate over a codebase that did this, you know exactly what I'm talking about.
There's way too little acknowledgement in our industry of just how much suffering and anguish one or two chucklefucks on a codebase can inflict on their teammates. Using only the matter at hand as an example:
"Rude" is waking somebody up to stand watch over a buggy system because it wasn't written properly and will seize up.
"Rude" is wasting senior developer time on a refactor because the last person who touched the code used system calls and primitives only available on one specific compiler and one specific OS, and now the system has to change.
"Rude" is injuring somebody because your embedded controller is using the wrong sized int for something, because it slipped through code review because somebody decided to use a #define that got changed between architecture upgrades and never fixed it.
"Rude" is wasting a tester's day having them try to hop up and down over the same three feet of virtual space while trying to tap the attack key just right to repro a race-condition bug caused by some permutation of the above. 8. Hours. Of. Hopping.
~
When you write shitty software, you are hurting everyone else who might ever have to interact with it--so, uh, yeah, I get to be rude.
No, you don't. Let me rephrase: I think it would be appreciated here, and for the sake of politeness and basic respect towards others, that you do not get rude. There are a thousands of other ways to write down how you feel about something without being rude, and people will still perfectly understand it. Moreover they are even more likely to pay proper attention to it if you are not rude.
It's funny how some people don't learn this.
Years of internet commenting has taught me the uselessness of posting in anger, and the value of a well-argued, well-written point. Strong emotions one way or another diminish the authority and impact of what you say.
It's easier said than done, of course: strong emotions are often specifically what lead you to make the effort of commenting.
If "strong emotions" were enough to diminish impact and authority, the ad business would simply be placards of bullet points. Even on HN, well-written and cool posts routinely are ignored or actively downvoted.
In the grand scheme of things, politeness is a good idea--but there are a few places where being nice simply won't get you as far as calling somebody out passionately on their wrongness. Low-level systems programming on large codebases with smart and stubborn and harried people is one of those cases.
The "abstractions" written by those who don't have multiplatform experience (aka the ones writing platform specific code in the first place) tend to have broken designs that require refactoring even if they do exist. Very little difference in work between fixing a broken abstraction and implementing a missing abstraction for those items, IMO.
Unabstracted or poorly abstracted rendering, input, user management, matchmaking, leaderboards, achievements, save systems, async I/O, and platform specific serialization (image loaders, varying-size bytewise copied structs)... all without unit tests or an assertion between them... I find all much worse! You get to refactor, redesign, and retest all at the same time, leaving behind a trail of breadcrumbs: backwards compatability hacks and compromises...
(Also fun: When you discover existing abstractions were discarded instead of cleaned up, in favor of new abstractions, and you get to re-fix all the re-introduced TCR violations and corner cases.)