Live data from Hacker News

Honda bucks industry trend by removing touchscreen controls

autocar.co.uk

591–600 of 770 posts

Re: Honda bucks industry trend by removing touchscreen controls

#591
post #583

Earlier quoted context omitted.

> A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions. I think you're off by a few orders of magnitude. https://www.visualcapitalist.com/millions-lines-of-code/

Interesting link. Can anyone explain why a car needs so much code?

Instead of having a single computer that stores all the code, automobiles have lots of embedded systems with their own code and hardware, and lots of systems designed for validating safety critical functionality. When I say lots, I mean it's usually several dozen and can be over 100. Since many of these need to meet special regulations and oftentimes require hard real-time characteristics, this tends to add to the complexity significantly.

Re: Honda bucks industry trend by removing touchscreen controls

#592
post #583

Earlier quoted context omitted.

> A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions. I think you're off by a few orders of magnitude. https://www.visualcapitalist.com/millions-lines-of-code/

Interesting link. Can anyone explain why a car needs so much code?

I mean ... we all know a car does not need that much code

Re: Honda bucks industry trend by removing touchscreen controls

#593
If my blood is on the touchscreen, it shouldn't break my car or prevent me from getting to the hospital. Who needs more controls? I want physical levers and switches on the dash. Case in point, Ford Mustangs have electronic controls to pull heat off the engine, but the valve only opens when the thermostat says it okay so when it breaks (and costs $250 to fix, and breaks regularly) you're stuck with cold air in the winter until you exceed 50MPH. Just give me a freaking lever that manually/physically opens the valve to and pull the heat off the engine. If it ain't broke, don't fix it.

Re: Honda bucks industry trend by removing touchscreen controls

#595
post #530

Earlier quoted context omitted.

> In many of the newer systems, all those physical dials and switches are just inputs to the computer system which ultimately decides to do what the user is requesting. 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…

You've done a lot of programming for hardware switches and such then? 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…

Even modern AAA computer games sometimes miss mouse clicks, because they foolishly poll for transitions of the button up/down state in the main loop, for each frame they render, instead of properly tracking the OS event queue.

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.

Re: Honda bucks industry trend by removing touchscreen controls

#597
post #30
post #15

I will never understand how this trend started in the first place. If you look at e.g. digital cameras, they all have touch screens these days, but they also still have buttons and dials everywhere. The one in front of me has eight physical buttons, seven dials and a power switch. The reason is obvious: when you're taking photos, you don't want to be looking down at a screen; you want to be focused on the task at han…

I can only conclude from the situation you describe, as well as the fact that most cameras (as cameras, not phones) still lack GPS and sometimes Wi-Fi, that a great many industrial designers are trend-following, uncreative bores. Most modern car interior controls are horrible (Tesla’s giant laggy touchscreen included).

> Tesla’s giant laggy touchscreen included

This is false, full stop.

Re: Honda bucks industry trend by removing touchscreen controls

#600

Earlier quoted context omitted.

> A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions. I think you're off by a few orders of magnitude. https://www.visualcapitalist.com/millions-lines-of-code/

The phone switch for Nortel's Meridian PBX system circa 1994, which supported SONET and IP, had about 16 million lines of code. The complexity of a touchscreen is less than 1%, maybe less than 0.1% of that. Lines of code, however an absurd metric, in this case does say something. I'm just not sure exactly what, though.

Isnt code just vastly different... abstracted from 94’ era lingo?
Post reply on HN