3 ms·

I think you're maybe framing it the wrong way around. It often takes more energy to write portable code than non-portable code. "This isn't something I want to

I think you're maybe framing it the wrong way around. It often takes more energy to write portable code than non-portable code. "This isn't something I want to spend my time on" isn't a rationalization, it's a simple statement of preference. I personally feel absolutely no cognitive dissonance or regret about all the hand-coded PPC I wrote a couple decades ago, nor do I accept someone else wanting me to feel bad about it. It was (and needed to be) optimized for the machine I was working on at the time, and if I were moving it to a new platform, I probably would have wanted to do the same for it, too. As it turns out, though, the need never arose. The code was abandoned before the platform was. In short, YAGNI. Similarly, "This isn't a worthwhile expenditure of our company's resources," isn't a rationalization, it may be a simple statement of business reality. To take a simple example, a video game studio producing an exclusive title has very different incentives around code portability than an indie studio that plans to release on 5 different platforms. What's the point of developing your game to work on iOS if you have no plans to - and may even be contractually not allowed to - release it on that platform?

hinkley 5y ago
Long ago I discovered that people don't get emotionally invested in your little perf- or platform-specific hacks if they don't have to look at them. With function inlining, you can often move your little weirdo bit of code into a function that is off the main call path and if people don't like it, they don't have to look at it. Also the fact that your change is in a single commit means they can always revert it if they don't like it (a bluff almost nobody calls). More importantly, when it comes time to port the code, the intent of your weird little code is both known and self-contained. They can decide what to do about it and have a path to do it. When your clever tweaks are peppered throughout your data architecture and half of the code base, then porting is a costly affair. And in some cases just updating your tools is hampered as well.
- mumblemumble 5y ago
  It's true. Though I suspect that the proportion of code whose portability is hampered by clever code like this is vanishingly small compared to the volume of code whose portability is hampered by things like, "assumes POSIX-style file handling", "makes lots of DOS syscalls", or "targets AVR microcontrollers."

hinkley 5y ago

Long ago I discovered that people don't get emotionally invested in your little perf- or platform-specific hacks if they don't have to look at them. With function inlining, you can often move your little weirdo bit of code into a function that is off the main call path and if people don't like it, they don't have to look at it. Also the fact that your change is in a single commit means they can always revert it if they don't like it (a bluff almost nobody calls). More importantly, when it comes time to port the code, the intent of your weird little code is both known and self-contained. They can decide what to do about it and have a path to do it. When your clever tweaks are peppered throughout your data architecture and half of the code base, then porting is a costly affair. And in some cases just updating your tools is hampered as well.

mumblemumble 5y ago
It's true. Though I suspect that the proportion of code whose portability is hampered by clever code like this is vanishingly small compared to the volume of code whose portability is hampered by things like, "assumes POSIX-style file handling", "makes lots of DOS syscalls", or "targets AVR microcontrollers."