Each service handles data from a handful of physical of physical knobs.
At least that way you don't have the UI as a single point of failure.
They are, by very definition, an additional point of failure as you're always adding an additional interface. They're good for scaling, not for redundancy, and even that's wishful thinking for most applications.
EDIT: You could argue that microservices might free up the UI thread from locking mistakes, but if your team is going to make locking mistakes, you're also going to make mistakes in the microservice interfaces, so what's the point?
It's pretty much the only empirical thing we have in software engineering, more code = more bugs.
Lots of little microservices means lots of extra code means lots of extra bugs.
Plus you've got to manage how they all interact. Which microservice has priotity? Did you even think of that? The breaking microservice? Or the volume microservice? Did you even think of that or try and test that? Your breaks get disabled every time you turn up the volume?
Whoops, you just killed a thousand people with your "redundant" microservices.
Even so, a program for processing a switch or dial can be really short and simple. You can print it out on a sheet and check and double check every line of code for to make sure it's correct and all possibilities are accounted for.
A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions. The best you can hope for is empirically verifying it's mostly correct most of the time.
I do some. And the last device we built, we still fight with a simple rotary switch. You have to do things like debounce inputs that seem like obvious binary switches. Getting the debounce windowing right can be just as "guessy". And guess what the highest point of failure on said device is. That selector switch. Had similar experience with buttons. I think the software part is just two forms of the Law of Conservation of Ugly.
I do like tactile better, but more for affordance/discoverability (e.g. ergonomic) issues than what you're driving at above.
It's a very common (and lazy) way of programming games (and other more mission-critical apps): naively polling the input device state in the main simulation or rendering loop, instead of actually responding to each and every queued operating system event like mouse clicks.
It's entirely possible to get multiple mouse down/move/up/click events per render frame, if the system has frozen or stalled for any reason (which happens all the time in the real world). But polling just can't deal with that, so it sometimes ignores legitimate user input (often at a critical time, when other things are happening).
So it's still unfortunately quite common for many apps to sometimes miss quick mouse clicks or screen touches, just because the system freezes up for an instant or lags behind (like when the CPU overheats and the fan turns on madly and SpeedStep clocks the CPU waaaay down, or even the web browser opens up another tab, or anything else blocks the user interface thread), and it just doesn't notice the quick down/up mouse button transition that it would have known about if it were actually tracking operating system events instead of polling.
"It’s surprising how many of those derelicts hanging out at the waterfront bars pick an almost random time constant. “The boys ‘n me, we jest figger sumpin like 5 msec”. Shortchanging a real analysis starts even a clean-cut engineer down the slippery slope to the wastrel vagabond’s life."
I'm not sure I buy touchscreens ever being simpler to handle. (or even in the similar range - they're strictly harder)
Hardware debouncing works well for most applications but may not be financially rewarding at scale. With time and effort software debouncing can render sometimes better/good or good enough results as hardware..
Remember the saying, "When all you have is a hammer, everything starts to look like a nail..."
I think you're off by a few orders of magnitude.
I would expect a car to have tons of code.
Think of all the functions...
Engine management, Engine monitoring, Powertrain control, Emissions, Diagnostics, Infotainment, Satnav, Climate Control, Traction Control, ABS, Anti-collision radar, Cruise control, Lane keeping, Backup camera, Parking sensors...
Now keep in mind that these hundreds of components exist in many many possible configurations so the system needs to handle having certain hardware available or not, and also handle a multitude of failure modes gracefully.
With cars, there are certainly many things where it did improve things: satnav, reverse camera, traction control etc, but also some where it made a perfectly working system worse (ie the “fixed” something that wasn’t broken): touchscreen dashboards.
Are there any programs that approach a billion lines of code?
a quick search brought up https://www.freecodecamp.org/news/the-biggest-codebases-in-h... which reports google's codebase is around 2 billion LOC. MS Office comes in close to 50 million, for example.
Not sure how accurate these are, but seem to give some rough comparisons, and yeah, not too many things are billions of LOC.
I can 100% tell from your comment that you've never had to work with one.
It's less science than black magic to avoid double presses or missed presses.
It's the kinda problem that will tend to bite you in the butt if you aren't aware of all the gotchas. Difficulty is they are application specific. But I wouldn't describe the code as particularly complicated.
Most of this stuff a crusty old neckbeard embedded programmer can do half drunk on Friday afternoon.
OP was saying that mechanical switches could be deterministic, which is something that I haven't experienced.
I do agree that there is less to go wrong than a complicated touchscreen interface however.
A modern touch screen is superbly reliable because it has no moving parts, and it can be tested. The (consumer grade) iPad touchscreen is very reliable.
A cheap phone or tablet hardly represent best of breed for the technology as a whole.
Not if it is in an airplane. Think of all the QC steps required to track the production, storage, shipping, installation, testing, etcetera for the replacement of a single switch. If a switch has failed it needs to be inspected to understand the reason for failure (no switch should fail; tracked to understand if it is a batch failure, plus other steps). I am only making an educated guess here.
> A switch can usually be cleaned easily, to restore its function.
Ummm, you think they put known failed parts back in planes? I think not. They do fix major parts, but the QC for that would be insane. You would make a switch to be hermetic and add anti-tampering - a manufacturer of any safety related device doesn’t want it to be “fixed”. Items are designed to be maintained (with proper schedules), or replaced.
> And proper quality switches can be actuated millions of times before failure.
On average? Or does it have a bathtub curve? Yes, quality switches are insanely reliable, but so are touchscreens.
If you have a variety of 50 switches and knobs, then the reliability is worse than 50x worse, because every item has it’s own reliability curve, and it only takes one failure to muck up your day.
Even less so if it's on the space station. Or on a Mars rover. But we're talking about cars. Something a lot of people like to mend for themselves.
I can say that an intermittent switch failure is hard to diagnose and potentially costly. The dash on a 2007 Ford I got cheaply had an intermittent fault where the whole dash would shutdown, and headlights would go off, while driving. Switching ignition off and on would fix it, so I presumed it just needed a reset. It was actually the barrel switch of the key - intermittent enough to cause a lot of dangerous trouble but hard to diagnose.
I don't remember any physical light switch that ever switch on or off by itself.
In an aircraft flying through turbulences I'd feel a lot more comfortable knowing that all switches are pyhsical. Try to use your smartphone while jogging...
Yeah they’re both switches, but size is incredibly important, and small mechanical devices are finicky and don’t produce nice clean digital output (that’s a lie that electronic engineers tell software engineers to keep things simple).
So yeah I’m sure you’ve never seen a light switch fail, but I bet you’ve seen a keyboard fail (especially if you’ve spent any time around a recent MacBook).
But I do agree with your point on using a touchscreen in turbulence. A counter point is that there are probably hundreds of controls or settings on a plane that you never touch during turbulence, possibly that you never touch in flight (like telling the flight computer how much cargo you’re carrying). Stuff like that is ideal for a touchscreen.
In airplanes it's different. Here, outside of takeoff and landing, it's OK to look at a screen for 10 seconds while interacting with it with a hand.
Back to the topic - in car, unless specifically intended for other passengers, driver should never stare on some stupid screen in a place way off the line of sight for driving. Whenever I do that even for a split second in my 15-year old bmw (checking if that knob is really for what I want), there can be an atomic blast in front of me and I wouldn't see it.
Deaths and injuries per mile traveled supports the idea that flying is MUCH MUCH safer.
Worth noting that a significant amount of the information pilots use in the cockpit (at major US carriers, at least), things like flight plans, are on an iPad.
In critical systems, you want to make sure inputs are easy to use in the worst case scenario.
Even the best of touchscreens can't compare to physical controls in tough times.
Part of pilot training (at least in my dad's day in the AF) was blindfolding the pilot and the instructor names a control, and the student must put his hands on it. Or he flunks.
Just because it's on a touchscreen doesn't mean it has to be tiny and hard to touch. A 17" touchscreen could have fewer controls than the same hardware panel. And the controls could be bigger on the touchscreen.
Imagine trying to find the right switch on this by feel, without hitting the wrong one by accident.
https://live.staticflickr.com/6150/5990351987_fb9c159ea5_b.j...
That said, usually you make a short look at the panel to benefit from that hardcoded visual-motion coordination hw in your head.
This raises a question: how many times do an average pilot actually flip a switch over their carrier?
Worth mentioning that these days GPS units seem to be getting touchscreens but usually still aren't losing the physical buttons.
A car is very often fractions of a second away from a serious accident.
A plane at cruise altitude is rarely less than minutes away (unless, in some planes, you are actively trying to crash the plane/make the wings fall off)
Unless you're flying a Boeing 737 MAX that is.
Not really. Pilots are supposed to be visually looking for traffic 90% of the time, and the rest scanning instruments.
So to be heads-down for 10 seconds, the non-flying pilot would have to arrange that with the flying pilot.
It would be madness if pilots had to rely solely on their eyes to locate other planes nearby. There is thankfully instruments which do this as well.
Radar coverage has become ubiquitous in most places, but there's not universal coverage. Heads-up time is very important unless you're flying in actual IMC.
Well designed physical UI allows pilots to use touch and haptic feedback independent of sight. Whether the switch/dial/whatever is analog behind the scenes or is a digital input to the control infra is not the important thing.
"The US Navy will replace its touchscreen controls with mechanical ones on its destroyers
After a deadly 2017 crash between a destroyer and an oil tanker"
https://www.theverge.com/2019/8/11/20800111/us-navy-uss-john...
I also imagine that there are other reasons for both airliners and cars to replace buttons with touchscreens, namely that of cost instead of prioritizing safety and stability, and in general I am not a fan of that trade-off. But I'm also not claiming to be representative of the automobile market in general.
It's not just Boeing, who you accused of being backwards who are doing this, Airbus is too, along with every other manufacturer. Garmin and BendixKing now offer touch screens and it's clearly the future of GA as well not just commercial aviation.
Everyone believes that this will increase safety. That showing only the relevant information in a tunable and interactive way will decrease distractions and help focus on what matters.
The idea that this is to save money is totally absurd! A 777X is $350 million dollars. Any accident would cost an astronomical amount compared to the cost of switches. Even leaving that aside. The touchscreens are actually far more expensive than the old instruments.
This is just a way for Honda to cover up the fact that they can't write software, can't design a reasonable UX, don't want to spend money on it, and want to live as if it's 1999 forever.
Furthermore, tactile feedback is safety. The fact that each switch has a feel, a size, a position - that let's your brain know what you are doing without having to take eyes off the road.
Still, if you’re borrowing your wife’s car it’s easy to realize you don’t have great blindspot visibility at which point looking at a touch screen is very distracting.
Not saying it's right or wrong but your original post is 100% incorrect.
Many recreational pilots fly with uncertified gear (GPS in particular), and even regular smartphone/tablet apps. They also have the required paper documentation and certified instrument but that's just to cover themselves, and as a backup.
Also, some airlines now have officially certified iPads as EFBs, meaning pilots no longer need to carry paper backups.
Touch screen looks awesome on Star Trek, but in actual use it's an inaccurate, attention-magnet, nightmare.
Those are “most” of the controls... none of which require touchscreens.
What controls are you referring to specifically?
Airplanes have keypads that control complex functions on a screen, going from that kind of keypad to a touchscreen is logical.
In the case of cars, a touchpad is overkill for controlling the cabin temperature, stereo volume, etc.
I can imagine people would need to tune a radio panel more often, so at least basic functionality would be good to have as physical inputs. But even then basic radio functions are usually accessible via steering wheel buttons.
New isn't always better.
Flight plans is one thing but controls are all together a different sort of thing.
Why ask for trouble?
The theory I thought was reasonable for why the OP had troubles, was that Mac touch pads are sensitive enough to treat the separate pads of the paws as multitouch.
Testable: try with individual pad of paw on a Mac touchpad.
Usable inputs save lives.
(That's not to say that OP is wrong, of course, just that their argument isn't really a valid one. My belief is that touch screens would suck for flying a plane, but I'm not a pilot.)
You can say the civilian oversight groups that seek to regulate the industry are risk averse, but the companies that build the planes themselves, if they had their say, we'd be flying mach 3 upside down all day.
Re-designing systems introduces risk and uncertainty. Being able to leverage existing pilot training reduces risk (because crashes have resulted from pilots forgetting they were flying X and applied training for Y). Buying new equipment introduces risk of manufacturing defects that wasn't present in the working one.
That's not most people on most subjects. If someone appeals to authority and says "climate change is real, here's 100 scientists with PhDs who agree" I accept that. I am not willing to become an expert on the subject to be able to spend the time to review the facts for myself. Citing sources in a paper is essentially appealing to authority (I understand I could read those papers and the ones they cite, all the way down, but for most things, I'm not going to do that).