4 ms·
It is always a trade off. Prioritizing backwards compatibility does not come for free. One result I see from this is that MS keep creating new APIs whole old o
by socialdemocrat 6y ago
It is always a trade off. Prioritizing backwards compatibility does not come for free.
One result I see from this is that MS keep creating new APIs whole old ones languish in obscurity.
On Macs in contrast Cocoa is part of a lineage all the way back to the 1980s. I can still use Objective-C skills I learned even before macOS X was released.
The same cannot be said for Windows. Nobody in their right mind writes Win16 or Win32 apps today.
So ironically the backwards compatibility MS offers it users come at the expense of backwards compatibility for developer skills.
When you ban breaking changes in an API you also stop that API from modernizing and staying relevant.
- andrekandre 6y ago> So ironically the backwards compatibility MS offers it users come at the expense of backwards compatibility for developer skills. im not sure this follows necessarily: whats to prevent ms from say, writing a wrapper that packages up said legacy apps and supplies the libraries they need, so they can keep running and ms can still dump thier old frameworks and stop supportimg them in newer os's? basically, what im saying is, for legacy apps, they can be "bottled up" and still run on newer systems without harming developer compatibility and modernizing (wine proves this imo) but maybe im missing some important detail...
- pjmlp 6y agoWe surely do write Win32 applications, which is one of the reasons why UWP failed and now Project Reunion is bringing the best parts of UWP into Win32. .NET 5 was also only released for Win32, Linux and macOS, UWP will get an update only later next year, if ever.