4 ms·

Every age, this age not excepted, has programmers who somehow find the energy to go out of their way to advocate for writing non-portable code. "Who cares if i

Every age, this age not excepted, has programmers who somehow find the energy to go out of their way to advocate for writing non-portable code. "Who cares if it doesn't run on 80386?" "Who cares if it doesn't run on PowerPC?" "Who cares if it doesn't run on 64 bit?" "Who cares if it doesn't run on ARM?" And now: "Who cares if it doesn't run on 32 bit?" They write code that makes assumptions about endianness, about sizes of pointers, about floating point formats, and then come up with rationalizations about why it shouldn't matter if their code only compiles and runs on one architecture. If we had taken all of them at their word, every architectural upgrade would require a rewriting of a majority of software instead of a recompile, and the open source world would be vastly different, and not in a good way. Old technology is a way to teach people about our roots, how our current path was informed by those roots, the lessons learned from mistakes, and the lessons learned from the successes.

h2odragon 5y ago
Not disagreeing at all with your well expressed point, but: I wrote code to fully utilize the machines I had at the time. When new systems became available, the code needed to be re-written to fully exploit the new just as much as it needed to be de-crufted from the obsolete. Code that has been functional, untouched, for decades has a nobility; but a job that has been worth re-coding the solution every few years is actually important.
mumblemumble 5y ago
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."
Retric 5y ago
Most software doesn’t live very long, and opportunity costs can be huge. For every Minecraft ported to every platform there are several Atari 2600 games that nobody cared about. Creating emulators today is vastly better use of resources than anyone writing ancient console games considering long term portability issues.
gwbas1c 5y ago
Well, do you really care if your web application or mobile application runs on an 80386? But, to get more practical: The wider your compatibility surface is, the harder and more time consuming your software is to write. I once worked on a C# desktop product in the early 2010s where we had a requirement to support Windows XP. This prevented us from using newer features in C#, like the task API, which added a lot of complexity to our UI code. (It's much easier to write UI code in C# when you can "await" in one line instead of dealing with callbacks.) Another drawback (of remaining compatible with Windows XP) was that we had to stick with an old version of .Net, which had bugs. Specifically, we were making a XAML UI, but XAML support in .Net for Windows XP was buggy. Furthermore, we had to test our product on Windows XP, in addition to both 32-bit and 64-bit versions of Vista, 7, and 8. Eventually product management realized that it cost more to support Windows XP than the additional sales it would make, so they dropped the requirement. So, yes, "Who cases if it doesn't run on XYZ." Supporting "everything" often has real consequences and real costs.

h2odragon 5y ago

Not disagreeing at all with your well expressed point, but: I wrote code to fully utilize the machines I had at the time. When new systems became available, the code needed to be re-written to fully exploit the new just as much as it needed to be de-crufted from the obsolete. Code that has been functional, untouched, for decades has a nobility; but a job that has been worth re-coding the solution every few years is actually important.

mumblemumble 5y ago

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."

Retric 5y ago

Most software doesn’t live very long, and opportunity costs can be huge. For every Minecraft ported to every platform there are several Atari 2600 games that nobody cared about. Creating emulators today is vastly better use of resources than anyone writing ancient console games considering long term portability issues.

gwbas1c 5y ago

Well, do you really care if your web application or mobile application runs on an 80386? But, to get more practical: The wider your compatibility surface is, the harder and more time consuming your software is to write. I once worked on a C# desktop product in the early 2010s where we had a requirement to support Windows XP. This prevented us from using newer features in C#, like the task API, which added a lot of complexity to our UI code. (It's much easier to write UI code in C# when you can "await" in one line instead of dealing with callbacks.) Another drawback (of remaining compatible with Windows XP) was that we had to stick with an old version of .Net, which had bugs. Specifically, we were making a XAML UI, but XAML support in .Net for Windows XP was buggy. Furthermore, we had to test our product on Windows XP, in addition to both 32-bit and 64-bit versions of Vista, 7, and 8. Eventually product management realized that it cost more to support Windows XP than the additional sales it would make, so they dropped the requirement. So, yes, "Who cases if it doesn't run on XYZ." Supporting "everything" often has real consequences and real costs.