This is probably a joke, but tbe halting problem is way overused and doesn't apply in situations where a non-Turing-complete computer is running a known (not arbitrary) program.
The wifi isn't there for the firmware, it's there for the wifi functionality (Don't ask why it needs wifi functoinality, I can't answer).
But once you do have wifi functionality so you have wifi hardware, then the thing needs patching and upgrades too. Maybe some server address has changed, maybe a security fix, etc. And obviously if you have wifi hardware, it's the easy way to upgrade the software.
So the question I think isn't "Why does the firmware need to be updated at all"? It likely wouldn't, if the firmware just made the machine clean dishes. The question one should ask is, why does it have network features at all? What possible use case can exist?
Precisely. The reason it needs a firmware upgrade is that the manufacturer made the choice to make it so needlessly complicated that it ... needs a firmware upgrade.
And the UX should be a lot better on various white goods too: simple, intuitive and unobtrusive. I love my Miele dishwasher (not WiFi enabled!) but my Zanusi washer/dryer is utterly terrible in this respect.
Despite plenty of great physical abilities of the washer/dryer, it's almost ruined by a useless UX that obsessively locks one out of all sorts of perfectly legitimate transitions, meaning one has to frequently turn it off and back on to force the change of activity, adding frustration for something that could easily be handled if only they'd not crippled the device and made you wait while you cycle it.
Do you often create provably error free software? I'd love to hear more about it.
A quick google suggests the updates mostly tweak rinse times and temperature settings, presumably based on data that wasn't available before the model shipped.
It can be cheaper to do things in software so in the past you may have been able to tell the water inlet "fill machine" now you have to watch a water level sensor to control a dumb solenoid valve.
From what I can see, there's only two types of processes running inside a dishwasher:
- control loops. These can (and must) be fully articulated during the design phase, can be accurately modeled using a Mealy FSM, and can be coded and verified with 100% coverage.
- input processing. These take input from various sensors inside the machine, clamp and/or process the measurements, and pass on the data to some control system. The processes can be designed to be completely stateless (or maybe with hysteresis), which means that the only verification they need is that they always output valid data, even when confronted with spurious inputs. Since it's a feed-forward process and the inputs are bounded, 100% coverage is again possible.
The only other system is the UI, and its only job is to provide valid configuration data to the master control process. As long as that part is extensively tested, the rest of the UI can crash and reboot at any time, and it won't affect the operation of the fully-tested control process.
Why not? Or rather, why do we accept this as the norm? A dishwasher isn't that complex, it should be possible to prove the firmware error-free.