Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.
many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings
For example, the Army found that using glass cockpits doubled or quadrupled the accident rates in UH-60 and OH-58 aircraft respectively, increased it by ~30% in the AH-64, and reduced it by ~40% in the CH-47.
http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=ht...
http://www.usaarl.army.mil/TechReports/2001-12.PDF
A five-year NTSB study found that although glass cockpits had twice the incidence rate of fatal accidents. The study concluded that glass cockpits do not show a safety benefit. This remains the position of the NTSB.
http://www.ntsb.gov/safety/safety-studies/Documents/SS1001.p...
http://www.ntsb.gov/news/events/Documents/2010_Glass_Cockpit...
http://www.ntsb.gov/safety/safety-recs/recletters/A-10-036-0...
The reality is that simpler is sometimes better. Mechanical instruments each do one thing and they do it well. Vacuum-driven systems are simple and extremely reliable. You cannot fly a 100% glass cockpit, period.
What glass cockpits really do well is information integration. That makes it easier to surface relevant information for the pilot but it also means that pilots have to handle more complex systems that are throwing more information at them, and yet also may not be throwing the right information at them.
This is an inherently one-way street, the reason we have the instruments we do is because they're relevant, you can't go hiding relevant information from the pilot. As such, NASA recgonizes that glass cockpits and cockpit automation impose a higher cognitive load on pilots. It's very simple and straightforward to interact with a traditional cockpit, but with a more advanced cockpit you also need to have a correct mental model of what's happening in the background, otherwise "cognitive mismatch" will result.
Just like any other abstraction - it's nice when they work but all abstractions are "leaky" to some degree or other and you need to know how it works and be able to route around the problem to fix the cases where it fails.
The long and short here is that experience and frequent training are the key factors in aviation safety and glass cockpits actually increase the requirements in this area. They're nice when they work but they certainly are no panacea.
http://human-factors.arc.nasa.gov/flightcognition/research/s...
https://www.thinkmind.org/download.php?articleid=achi_2012_1...
GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork).
I agree with you, but although CLIs are explicitly automatable, they are almost never are because most operations are one time deals. If you have evet set up a Linux server I think you'll understand what I mean. The CLI is also a usability nightmare with no discoverability.
Except for helping the 6 or so billion people in their daily lives, but hey, the iPhone would be 'better' if it just had 'bash'?
Read your email lately from bash?
Didn't think so!
Now, I use pythonista as a python-shell. Being able to chain a couple of commands and fix a good-enough solution saves a lot of time in many cases such as web scraping on-the-go.
I know this may be an extreme use case, but if iPad is going to be a laptop replacement we need to be able to get a way to speak with it without immidiate access to a laptop.
It's not a false equivalence at all.
The necessity of lower-level technology in the creation of higher-level technology does not imply that the lower-level technology is somehow 'better' or 'superior'.
You are using a UX right now to read and respond to this.
It's crazy to posit that 'UXs are inferior'. Positively wrong.
In the vast majority of cases, UX's are superior to shells. Maps, news, social media, browsing/buying things, listening to music, making music, photo editing - there are actually very few use-cases wherein the shell is advantageous. Even emacs is a UX of sorts.
GUI:s are superior for the specific (limited) use cases they are designed for, inherently since they were designed to excel at those use cases. They are however less optimal when you want to diverge from those use cases and create something new. This is where malleability/modability comes in, and where CLI:s, bash, scripting, programming comes in, and you can't use limited-scope apps for that.
All tools are best at what they were designed for, I agree with you there. I'm however not sure how I in your mind was wrong before. The two are intrinsically bound, but it's undeniable that apps can't exist without tools, but tools sure can exist without apps.
With all the security concerns and regulation regarding flight, it's easy to imagine how hard it is to move forward and innovate in usability.
I'm not saying upending git for something better would be trivial, but I don't want to constrain my imagination by thinking it's not possible.
If you can coherently explain what you need [git replacement] to do, and explain it simpler than you would explain git itself, then you have an outline of a superior tool.