Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you're just going to sit there doing nothing, at least do nothing correctly

devblogs.microsoft.com

Post reply on HN
Print view View original

171–180 of 356 posts

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#171

Post by mardef »

pjerem wrote: post #140
gruez wrote: post #102

Earlier quoted context omitted.

>It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) Right, but if you read the article, the author is talking less about the developer experience and more about the user experience. "blare loud sirens" is great if you're a tester/developer, not so much if you're an end user. When it c…

I’m sorry, maybe the article used the wrong example but the main issue comes from the fact that an Xbox app is trying to print something. It should fail, not for the developer experience, but because to start, there is no way the user would want to print something on an Xbox. Something is already really wrong with your app if it tries to do things like this. Also he says that apps are developed and tested on PCs and…

Part of the context here is that UWP (universal windows platform), is a target to write-once and run on any windows platform situation.

This made much more sense when Microsoft had multiple platforms running windows with just different sets of apis activated.

At it's peak, this was: PC, phone, hololens, Xbox.

SMS apis may only work on phone, spatial APIs may only work on hololens, printing may work on several, but not all targets. There are ways for developers to check which APIs are supported at runtime, but you can still call these APIs since they are part of the UWP surface.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#172

Post by Arainach »

o11c wrote: post #147

Making it a linker error doesn't even seem to be considered. Xbox is a separate target so a recompile is needed anyway ...

No, it's not - that's the point of the Universal Windows Platform - compile once, put in store, run everywhere.

This also isn't just about new platforms. If you have a desktop operating system and want to change the behavior of an API in a future version, you have to do this same process.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#173

Post by wvenable »

maerF0x0 wrote: post #91

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing…

> I've learned this as "swallowing errors" and IMO it's a poor practice

This is not swallowing errors. This, in the Linux parlance, is not breaking user-space.

There are two ways to handle the situation presented: error out because the machine can never have printers or return an empty list of printers because the machine can never have printers. They're both valid but only one of them doesn't break user-space.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#174

Post by buttercraft »

chrisjj wrote: post #160
mike_hock wrote: post #42

Earlier quoted context omitted.

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 "soluti…

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

This is about 3rd party apps that Microsoft has no control over.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#175

Post by wvenable »

delta_p_delta_x wrote: post #163
PaulHoule wrote: post #115

Earlier quoted context omitted.

It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Recently I had to read an old Access file and where I work we still keep Office '97 around for this purpose and it is quite amazing that it installs and works just fine on Win 11, Clippy works just fine, in fact all the other lame-ass things Office '97 does to take over your desktop all still work even if they don't quite visual…

> It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Here's a pretty detailed list: - It is possible to target Windows XP SP3 (released 2008, EOL 2014, 10 years ago) from Windows 11 and Visual Studio 2022[1] using C++23. Windows 2000 can be targeted with a little more setup[2]. Windows 2000 is 24 years old this year. - It is possible to run a binary written for and compiled in W…

The most stable API/ABI for the Linux desktop is provided by Wine.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#176

Post by crabmusket »

notatoad wrote: post #37
Analemma_ wrote: post #3

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 furthe…

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.

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

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#177

Post by Arainach »

chrisjj wrote: post #157
gruez wrote: post #46

Earlier quoted context omitted.

How about an app originally designed for iPhone but is running on an iPad? iPhones can make calls, but iPads can't. Sure, a properly designed iPad app wouldn't try to use the phone functionality, but what if the developer is too lazy to develop a dedicated iPad app? Surely a crappy iPhone app running on iPad is better than no app at all?

> Surely a crappy iPhone app running on iPad is better than no app at all? Bogus comparison. Non-crappy apps are a thing.

There are many forms of "crappy". Developer hygiene is one bar; user functionality is another.

"Crappy" here refers entirely to developer hygiene, which the user does not care about at all.

If the platform changed and Angry Birds crashed, the customer would not accept "but look at all of these other Angry Birds clone games still available" as an answer, they want the app they are familiar with.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#178

Post by Arainach »

chrisjj wrote: post #161
Arainach wrote: post #54

Earlier quoted context omitted.

What do you mean by "ethical" here, and why is it unethical to preserve ABI compatability?

> why is it unethical to preserve ABI compatability? Straw man. What's unethical here is deceiving the user.

There is no deception. There are no printers, and that's what the API returns.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#179

Post by toss1 »

chrisjj wrote: post #156
xp84 wrote: post #133

Earlier quoted context omitted.

User spends two hours creating content. User hits print. 1. App crashes back to the desktop/Home Screen/etc 2. App can’t find any printers. User cancels and saves the document, prints elsewhere. You really think option 1 is better? Also, none of this precludes the ability to display a message. He’s talking about the system calls themselves and how they should respond. I suppose if the call for the “Add Printer Wizard…

> 1. App crashes back to the desktop/Home Screen/etc Why do think it would crash, rather that simply return to main loop?

So it 'simply returns to main loop'. I.e., the user hits [Print] and then it maybe flickers and goes back to the home screen.

How in heck is that more useful than App reporting that "I can’t find any printers"?

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#180

Post by miki123211 »

delta_p_delta_x wrote: post #163
PaulHoule wrote: post #115

Earlier quoted context omitted.

It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Recently I had to read an old Access file and where I work we still keep Office '97 around for this purpose and it is quite amazing that it installs and works just fine on Win 11, Clippy works just fine, in fact all the other lame-ass things Office '97 does to take over your desktop all still work even if they don't quite visual…

> It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Here's a pretty detailed list: - It is possible to target Windows XP SP3 (released 2008, EOL 2014, 10 years ago) from Windows 11 and Visual Studio 2022[1] using C++23. Windows 2000 can be targeted with a little more setup[2]. Windows 2000 is 24 years old this year. - It is possible to run a binary written for and compiled in W…

I wish they included an 8086 emulator so that old software compiled for DOS would still run. It worked on 32 bit systems until 32 bit support was dropped, which only happened a few years ago. That was due to Intel's virtual 8086 mode, which is not available if your CPU is running in 64 bit (long) mode. Modern computers are fast enough for the emulation overhead to be negligible, even if you don't do any fancy JIT tricks and just go with a switch/case inside a while(true).

I would personally make use of this, I know of a 16-bit program whose latest version was released in the late XP days, so it's not even that old. The idea there was that it was always compatible with DOS, some users might presumably still want to run it on DOS, and there's no point in breaking that compatibility if modern Windows can run it just fine. Then development stopped, 64 bit systems got more popular, and a recompiled version was never released.

I guess the lesson there is that if you're keeping an API for backwards compatibility, some programmers will refuse to switch to a replacement to make their software work on older systems, making the API impossible to remove down the line without breaking modern programs.

Post reply on HN