4 ms·

I understand the logic here, and I'm aware Microsoft has a large number of convoluted backward-compatibility requirements, but this seems like drinking to solve

I understand the logic here, and I'm aware Microsoft has a large number of convoluted backward-compatibility requirements, but this seems like drinking to solve your problems and just putting off the inevitable hangover. To be clear: what you're doing here is lying to the user and the developer. Maybe that's justified in isolation, but now this lie is one more bit of "hidden state" you have to keep track of in further development and integration testing. And just like in the real world, lies have a tendency to compound on themselves until you're completely lost in them and have no idea what reality is. I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose. UX designers made themselves terrified of ever showing an error code to a user, but they took that and replaced it with a world where your shit just doesn't work, and when you try to figure out why, all the OS does is shrug.

ace2358 3y ago
This resonates with me. My computers used to crash at the app level, OS level or hardware level. Now when something goes wrong the system just kinda gets lazy and stops working. But it won’t crash. I’ve had my mac pinwheel on the login screen. I can still access the shell and file shares remotely, and even screen share to a logged in user. But login.app refuses to crash so it’ll just pinwheel. I’m glad I never forgot to turn things off and on for troubleshooting :(
- Analemma_ 3y ago
  I have a suspicion that "number of crashes" got badly Goodharted inside major OS vendors. After all, you can "prevent" most crashes by just having a top-level "catch(Exception e) {}" handler, which of course just leads to the program doing nothing instead in an un-debuggable way, but hey: crashes went down! KPI achieved!
- bombcar 3y ago
  My experience is that macOS especially really REALLY absolutely hates when the Internet goes sideways - not actually down, but really bad packet loss; DNS starts being slow and failing sometimes but not completely ... then you enter hell. Next time it happens try turning network connections all the way off.
acheron 3y ago
To be fair, sometimes you get "Oops, an error occurred, LOL!"
FreeFull 3y ago
As far as alternatives to what the article suggested go, I think the ideal solution would be to have a compile-time error, so the developers never even get as far as having their printing code try to run on the Xbox. And since it's a compile-time error, there doesn't need to be any kind of runtime error handling or cost either.
- paxys 3y ago
  Except now you have lost the ability to run all the software that cannot be fixed and recompiled for whatever reason.
  - FreeFull 3y ago
    You could still offer the mocked APIs, but have them be opt-in. Also, having the compiler throw an error doesn't mean that an older, already compiled executable won't work.
    - jonas21 3y ago
      > Also, having the compiler throw an error doesn't mean that an older, already compiled executable won't work. And when the older, already compiled executable calls the API, how do you make things "work"? That's exactly what the article is about.
- Arainach 3y ago
  Apps aren't being compiled here. Apps already exist and new platforms and platform functionalities are being made available. Launching platforms is an eternal chicken and egg problem: You want to launch a new platform. Users want apps before they buy into the platform. Developers want users and a guarantee they will spend money before investing time and money building apps for the platform. If you're really really rich, you can literally pay developers to write apps for you, but ask Microsoft how that went with Windows Phone. Instead, the most reliable way (I said most reliable, not reliable) is to leverage an existing group of apps onto your platform. Maybe you have a phone ecosystem and want to get into tablets. So you take the already existing phone apps in your store and let them run on your new platform. There is no recompiling. There is no build. There is no "build" because the source code was lost when all of the company's assets were sold off in 2002. There is no "build" because the developer made a game, put it on your app store, moved on to the next game and has no interest in supporting this game that isn't providing any significant new revenue. There is no "build" because this is FooManager 6.0, the company that makes FooManger wants everyone to buy FooManager 7.0 and isn't making any further changes to 6.0. etc. etc. etc. Binary compatibility is what matters. Nothing else is of particular significance. In addition, if recompiling an app for your new platform yields compile errors and requires work (as opposed to targeting a new platform version in a manifest and just hitting build), developers on your platform are significantly less likely to spend the time to do so.
notatoad 3y ago
as the article says, the correct solution is to provide an API that applications can access to check if the functionality is offered at all. functions that return correct null responses isn't the ideal behaviour, it's the fallback for when you're already off the happy path.
- crabmusket 3y ago
  I think there's a difference between an API that can be used to check if functionality is available, and an API that must be used before that functionality is offered to the application. E.g. CheckForPrinting : () -> Maybe PrintToken ShowPrintDialog : PrintToken -> Dialog
mike_hock 3y ago
So what's your solution then? Break all apps simultaneously that do not have extensive tests for gracefully handling cases that were impossible when they were created? This is not weird "hidden state" on the implementer's side. It's a straightforward dummy API and all you need to do to test it are a few straightforward asserts that it returns the correct dummy values and doesn't crash. > I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose. That's precisely not what this is. The whole point of the article is to do nothing correctly. Presenting an empty list of printers is consistent with a PC that simply doesn't have any printers installed. A wrong thing to do would be, for example, presenting a dummy printer that accepts jobs but of course never prints anything. You don't break the users of your API, period. That shouldn't be controversial. Unfortunately, too many people seem to think they need to do everything over every couple of years only to produce a solution that is no more extensible and resistant to bitrot than the one they're replacing.
- chrisjj 3y ago
  > So what's your solution then? Break all apps simultaneously that do not have extensive tests No test required. Just try... catch. > for gracefully handling cases that were impossible when they were created? You can never know they are impossible. That is why you have a top-level try...catch.
  - buttercraft 3y ago
    This is about 3rd party apps that Microsoft has no control over.
  - filleduchaos 3y ago
    > No test required. Just try... catch. That doesn't even make any sense. Where on earth would you insert a try...catch? So many people commenting on this article seem to have fundamentally misunderstood what the situation/scenario even is, which is made more jarring by the fact that so many others seem to have gotten it just fine.

ace2358 3y ago

This resonates with me. My computers used to crash at the app level, OS level or hardware level. Now when something goes wrong the system just kinda gets lazy and stops working. But it won’t crash. I’ve had my mac pinwheel on the login screen. I can still access the shell and file shares remotely, and even screen share to a logged in user. But login.app refuses to crash so it’ll just pinwheel. I’m glad I never forgot to turn things off and on for troubleshooting :(

Analemma_ 3y ago
I have a suspicion that "number of crashes" got badly Goodharted inside major OS vendors. After all, you can "prevent" most crashes by just having a top-level "catch(Exception e) {}" handler, which of course just leads to the program doing nothing instead in an un-debuggable way, but hey: crashes went down! KPI achieved!
bombcar 3y ago
My experience is that macOS especially really REALLY absolutely hates when the Internet goes sideways - not actually down, but really bad packet loss; DNS starts being slow and failing sometimes but not completely ... then you enter hell. Next time it happens try turning network connections all the way off.

acheron 3y ago

To be fair, sometimes you get "Oops, an error occurred, LOL!"

FreeFull 3y ago

As far as alternatives to what the article suggested go, I think the ideal solution would be to have a compile-time error, so the developers never even get as far as having their printing code try to run on the Xbox. And since it's a compile-time error, there doesn't need to be any kind of runtime error handling or cost either.

paxys 3y ago
Except now you have lost the ability to run all the software that cannot be fixed and recompiled for whatever reason.
- FreeFull 3y ago
  You could still offer the mocked APIs, but have them be opt-in. Also, having the compiler throw an error doesn't mean that an older, already compiled executable won't work.
  - jonas21 3y ago
    > Also, having the compiler throw an error doesn't mean that an older, already compiled executable won't work. And when the older, already compiled executable calls the API, how do you make things "work"? That's exactly what the article is about.
Arainach 3y ago
Apps aren't being compiled here. Apps already exist and new platforms and platform functionalities are being made available. Launching platforms is an eternal chicken and egg problem: You want to launch a new platform. Users want apps before they buy into the platform. Developers want users and a guarantee they will spend money before investing time and money building apps for the platform. If you're really really rich, you can literally pay developers to write apps for you, but ask Microsoft how that went with Windows Phone. Instead, the most reliable way (I said most reliable, not reliable) is to leverage an existing group of apps onto your platform. Maybe you have a phone ecosystem and want to get into tablets. So you take the already existing phone apps in your store and let them run on your new platform. There is no recompiling. There is no build. There is no "build" because the source code was lost when all of the company's assets were sold off in 2002. There is no "build" because the developer made a game, put it on your app store, moved on to the next game and has no interest in supporting this game that isn't providing any significant new revenue. There is no "build" because this is FooManager 6.0, the company that makes FooManger wants everyone to buy FooManager 7.0 and isn't making any further changes to 6.0. etc. etc. etc. Binary compatibility is what matters. Nothing else is of particular significance. In addition, if recompiling an app for your new platform yields compile errors and requires work (as opposed to targeting a new platform version in a manifest and just hitting build), developers on your platform are significantly less likely to spend the time to do so.

notatoad 3y ago

as the article says, the correct solution is to provide an API that applications can access to check if the functionality is offered at all. functions that return correct null responses isn't the ideal behaviour, it's the fallback for when you're already off the happy path.

crabmusket 3y ago
I think there's a difference between an API that can be used to check if functionality is available, and an API that must be used before that functionality is offered to the application. E.g. CheckForPrinting : () -> Maybe PrintToken ShowPrintDialog : PrintToken -> Dialog

mike_hock 3y ago

So what's your solution then? Break all apps simultaneously that do not have extensive tests for gracefully handling cases that were impossible when they were created? This is not weird "hidden state" on the implementer's side. It's a straightforward dummy API and all you need to do to test it are a few straightforward asserts that it returns the correct dummy values and doesn't crash. > I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose. That's precisely not what this is. The whole point of the article is to do nothing correctly. Presenting an empty list of printers is consistent with a PC that simply doesn't have any printers installed. A wrong thing to do would be, for example, presenting a dummy printer that accepts jobs but of course never prints anything. You don't break the users of your API, period. That shouldn't be controversial. Unfortunately, too many people seem to think they need to do everything over every couple of years only to produce a solution that is no more extensible and resistant to bitrot than the one they're replacing.

chrisjj 3y ago
> So what's your solution then? Break all apps simultaneously that do not have extensive tests No test required. Just try... catch. > for gracefully handling cases that were impossible when they were created? You can never know they are impossible. That is why you have a top-level try...catch.
- buttercraft 3y ago
  This is about 3rd party apps that Microsoft has no control over.
- filleduchaos 3y ago
  > No test required. Just try... catch. That doesn't even make any sense. Where on earth would you insert a try...catch? So many people commenting on this article seem to have fundamentally misunderstood what the situation/scenario even is, which is made more jarring by the fact that so many others seem to have gotten it just fine.