[dpkonofa]

>Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.

I would consider myself an Apple evangelist, for the most part, and even I can recognize what's been lost by Apple breaking backwards compatibility every time they need to shift direction. While the philosophy is great for making sure that things are modern and maintained, there is definitely a non-insignificant amount of value that is lost, even just historically but also in general, by the paradigm of constantly moving forward without regard for maintaining compatibility with the past.

[scarface_74]

What was the alternative? Sticking with 65x02, 68K, or PPC?

They could have stuck with x86 I guess. But was moving to ARM really a bad idea?

They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time. When 32 bit code ran it had to load 32 bit version of the shared linked library and 64 bit code had to have its own versions.

[dpkonofa]

>What was the alternative? Sticking with 65x02, 68K, or PPC?

No, including an interpreter like they did (Rosetta) was an alternative. The "alternative" really depends on what the goals were. For Apple, their goal is modern software and hardware that works together. That's antithetical to backwards compatibility.

>They could have stuck with x86 I guess. But was moving to ARM really a bad idea?

I don't think I ever suggested that it was or that they couldn't have...

>They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time.

Yes, and, in doing so, they killed any software that wasn't created for a 64-bit system. Again, for even a purely historical perspective, the amount of software that didn't survive each of the instanced transitions is non-negligible. Steam now has an entire library of old Mac games that can't run on modern systems anymore because of the abandonment of 32-bit without any consideration for backwards compatibility. Yes, there are emulators and apps like Wine and CrossOver than can somewhat get these things working again but there's also a whole subsection of software that just doesn't work anymore. Again, that's just a byproduct of Apple's focus on modern codebases that are currently maintained but it's still a general detriment that so much useable software was simply lost immediately because of these changes when there could have been some focus on maintaining compatibility.

[scarface_74]

> No, including an interpreter like they did (Rosetta) was an alternative.

The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.

That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.

But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.

Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.

Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?

[kelnos]

> The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.

I don't see that as a downside; I see it as a strength. Why should everyone have to get on the library-of-the-year train, constantly rewriting code -- working code! -- to use a new API?

It's just a huge waste of time. The forced-upgrade treadmill only helps Apple, not anyone else. Users don't care what underlying system APIs an app uses. They just care that it works, and does what they need it to do. App developers could be spending time adding new features or fixing bugs, but instead they have to port to new library APIs. Lame.

> Someone has to maintain the old compatibility layers and patch them for vulnerabilities.

It's almost certainly less work to do that than to require everyone else rewrite their code. But Apple doesn't want to spend the money and time, so they force others to spend it.

[caspper69]

This may come as a surprise to you, but the vast majority of users absolutely hate it when their software changes.

They don't want all new interfaces with all new buttons and options and menus.

People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).

I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".

[dpkonofa]

I'm not sure why you're responding to me. Nothing that you're saying is anything that I've mentioned or brought up. I know what the downsides are. I'm just saying that the goals that Apple has optimized for have resulted in a loss of things that many would consider valuable.

[scarface_74]

You said No, including an interpreter like they did (Rosetta) was an alternative

[fpoling]

If Apple users really appreciated backward-compatibility, the would be a significant market for 3-rd party emulators and VMs to run old software using no longer supported hardware or software API. It is not there. There are VMs, but they are mostly used by developers or by people who want to run Windows software on Mac, not old Mac software. So from Apple perspective if their users do not want to pay for backward compatibility, why should Apple provide it?

[LegionMammal978]

I wonder how much of that is just lack of awareness. E.g., the whole story at [0] needn't have occurred if anyone involved were aware of VM emulation for older OS versions. But there's no money in selling old software, and Apple would probably open themselves up to lawsuits ("you told me to use a VM, and then it got hacked!") if they openly advertised it.

[0] https://news.ycombinator.com/item?id=35401895

[BuyMyBitcoins]

Plus, the reduced power consumption and battery life extension is insanely good now. Whereas I could only get an hour and a half from an Intel MacBook Pro, I can now get over a days use out of the M4. I have not been affected by the lack of “legacy” software support and I am more than happy to have this tradeoff.

[dpkonofa]

I think most people, me included, are more than happy with the trade-off. That doesn't mean that nothing of value was lost in each transition.

[scarface_74]

Engineering is always about trade offs. Microsoft could never make the trade offs that Apple has made and while it has suffered because of it in new markets, it’s gained the trust of Big Enterprise. Microsoft should not be trying to act like Apple.

There is room for both. But if you are a gamer, the Mac isn’t where you want to be anyway. Computers have been cheap enough for decades to have both a Windows PC and a Mac. Usually a desktop and a laptop.

[dpkonofa]

I never suggested that they should, in either case. I'm just saying that there are things that are lost by completely ignoring backwards compatibility. There are plenty of Mac-only applications that aren't games that are now obsolete and unusable because of architecture changes.