Explicating the survival of the Shell as default OSS UI
-
Three words from a comment whose poster has been lost to the sands of time: "Ditch The Dog". No autopilot's going to save you when you snap your elevator cables during the takeoff roll, have to do an all-engines-out landing whether it be on the Hudson or an abandoned airstrip in the Canadian prairie, find out the hard way that your pitot heat's kicked the bucket without telling you about it, or experience what it's like to fly a very, very large J-3 Cub thanks to an unexpected shower in the electronics bay.
As I mentioned above - INAP - but I understand each of those references.
I'm just flogging your analogy. Just because Real Pilots don't need a better A/P GUI, doesn't mean we can't ask what could make an A/P GUI better.
"Ideally", the A/P would catch on to the derp-derp "pilot" who just kept punching things in until his flight plan was accepted. ;)
Because even Real Pilots are sometimes turn out to be just pilots and then - CFIT.
-
"Ideally", the A/P would catch on to the derp-derp "pilot" who just kept punching things in until his flight plan was accepted.
I think ideally the A/P would catch on to the derp-derp "pilot" and disable the plane before he kills himself and his passengers. A simple solution to this is an interface that is just daunting enough that someone with no knowledge won't even try, but that is otherwise not a barrier to anyone who knows what they're doing.
Please don't read that as a defense of Git or Linux.
-
While that's a great question, the problem is that I'm not trying to solve one problem but several. If I had to boil it down to two or three core issues, they would be:
- Make it easy to learn the basic interface for all tools, because there is in fact only a single basic tool with a single basic interface, with variations that you choose to add on as you go along.
- Allowing users to easily have two or more documents or pieces of documents integrated into a third document, without having to worry if the applications that each is created in are compatible.
- Allowing users to pick any tool they need out of a toolbox and just use it, without having to either a) have a monster-all-in-one application with a huge number of tools that you have to look up, b) having to find some external tool that requires you to go outside the original application, or c) rolling your own script to do the job.
True, in some ways my idea is just shifting the problem rather than solving it (for example, in the third case, you still would have find the tool you want to use, and may have to roll your own for it if no one else has done the same job before; but once you've done that, it can be applied to anything you need that works with that type of data, not just the specific file format and application), but I am at least trying to advance the state of the art. It's an experiment, at this stage, and one which, like all experiments, may fail.
- Automating version control in a transparent and universal manner.
I'll work on some use cases for the three issues I mention later today, probably starting with your example of writing a report on fleet fuel economy as a starting point.
-
On the other hand, you might have a better idea......to do about the latter?
(Again, I'm just discussing, I have no horse in this race. AND, you clearly know what you're talking about.)Re: ash cloud - what A/P would prevent you from plotting around it?
(But, yes, a well-informed pilot is better than some noob who wouldn't think to check on conditions)Re: detailed climbing and descent examples: wouldn't a good A/P GUI help to point these issues out quicker? Particularly at the margins?
-
(Again, I'm just discussing, I have no horse in this race. AND, you clearly know what you're talking about.)
Re: ash cloud - what A/P would prevent you from plotting around it? (But, yes, a well-informed pilot is better than some noob who wouldn't think to check on conditions)
Re: detailed climbing and descent examples: wouldn't a good A/P GUI help to point these issues out quicker? Particularly at the margins?
The A/P wouldn't prevent you from plotting around it yourself, but it'd blithely fly through it if it was left to its own devices.
And a good A/P UI would be able to point out that there's a problem, but that's exactly when you need that conceptual understanding of what's going on to understand what the autopilot is saying to you.
-
Here's where the problem with his argument lies; some tools require conceptual understanding of the problem domain to use, no matter how good your UI is.
I don't see how that's a problem with my argument.
Actually it's more the opposite: people with the domain knowledge (lawyers, architects, etc) should be able to write their own software, making use of the domain knowledge they already have, without also having to learn a new software engineering domain.
Not that I'd be in favor of having pilots who aren't qualified to fly manually
Me neither, but the autopilot can (potentially) save lives if an unqualified person does end up behind the yoke. Or if a pilot temporarily passes-out due to a medical condition or in a million other cases.
The problem comes when you command the A/P to do something that makes no sense given the plane's state...(you can trap some of these errors, but not all, given the current state of the art of airplane design).
That's only a problem with Airbus! ziing!
-
Make it easy to learn the basic interface for all tools, because there is in fact only a single basic tool with a single basic interface, with variations that you choose to add on as you go along.
You're saying the interface for an efficient music sequencer is a "variation" of that of an efficient photo editor? Or database administration application? Or non-linear video editor?
I don't think even Apple, in the Classic-est of the Mac Classic era, would make that claim.
Allowing users to easily have two or more documents or pieces of documents integrated into a third document, without having to worry if the applications that each is created in are compatible.
Right; but you've just shut out all software vendors with non-trivial file formats.
True, in some ways my idea is just shifting the problem rather than solving it (for example, in the third case, you still would have find the tool you want to use, and may have to roll your own for it if no one else has done the same job before; but once you've done that, it can be applied to anything you need that works with that type of data, not just the specific file format and application), but I am at least trying to advance the state of the art.
I appreciate trying to advance the state-of-the-art. I do not appreciate giant run-on sentences though.
-
Actually it's more the opposite: people with the domain knowledge (lawyers, architects, etc) should be able to write their own software, making use of the domain knowledge they already have, without also having to learn a new software engineering domain.
No, if they don't know software they should team up with someone who does.
Like it or not, software development is its own knowledge domain. I have software domain knowledge but that doesn't mean I can go be a lawyer or an architect because I happen to have domain knowledge in another domain (software).
-
No, if they don't know software they should team up with someone who does.
They should now. But that is not the way the world should be. That is not the ideal.
And now we enter the point of the conversation where nobody fucking posting here understands what the word "ideal" means. Hold on tight, kiddies, it only gets more dumb from here.
-
It would be ideal if I could build my own car, represent myself in court cases without losing, do my own knee replacements and heart transplant when I get old, do all my own taxes and accounting, fix my own refrigerator, and even write pretty-and-useable GUIs by myself. But that's never going to happen. Such an ideal has no basis in reality. We might as well be arguing about unicorn glitter-farts.
-
It would be ideal if I could build my own car, represent myself in court cases without losing, do my own knee replacements and heart transplant when I get old, do all my own taxes and accounting, fix my own refrigerator, and even write pretty-and-useable GUIs by myself.
Yes it would.
But that's never going to happen.
And yet, it's still an ideal.
(Person who doesn't know what the word "ideal" means count: 1. Let's see how high we get!)
Such an ideal has no basis in reality. We might as well be arguing about unicorn glitter-farts.
Then go away and don't participate, instead of coming in here and shitting ignorance all over.
-
That's only a problem with Airbus!
So is the possibility of the pilot tearing the tail off by jamming the rudder back and forth five times in a row in flight.
Filed under: I wish I were kidding about this one.
-
Yes, but mostly because I'm from the Everett area where most of the Boeing aircraft worth talking about are made, and thus it's in my DNA to mock Airbus for being fucking awful, which they are.
If it ain't Boeing I ain't goin'!
(Reads the link) See our Boeings are so powerful than those wimpy-ass Airbus shitpiles can't even fly behind one without getting roundhouse-kicked back down to the ground.
-
I'm going to let someone else respond to this because I don't even know where to start. You basically just admitted that your thoughts on who should be able to develop software only exist in fantasy-land, and now my head hurts at why you keep saying the system sucks and we need to make it so anybody anywhere can write software.
Filed Under: Yes communism sucks in the real world, but it works good in an ideal world so why aren't we doing communism?
-
Actually it's more the opposite: people with the domain knowledge (lawyers, architects, etc) should be able to write their own software, making use of the domain knowledge they already have, without also having to learn a new software engineering domain.
And we're actually fairly close to where someone who has domain knowledge and a logical head on their shoulders can pick up a scripting language (Python's probably the best choice for this job, I personally would feel comfortable throwing my mom Learn Python the Hard Way) and hack something together to ease their workflow along. Sure, it'll need some TLC (read: "You've put together something that does $nifty_thing_X, cool! Now, lets take care of taking it from jury-rigged prototype to production tool." from you or me down the road, but it's better than making people shovel data into silly pipe-delimited files manually because the IT dept. is a bunch of dumb-dumbs with a 'no automation allowed' policy.
The main challenge comes when all that domain knowledge is locked up in the head of someone who can't, or won't, get past ground zero. Some people would never be interested in even the slightest whit of scripting, no matter how much easier their lives would be made by it.
That's only a problem with Airbus! ziing!
Not really; the 777 and 787 autothrottles have a mode trap in them that wound up contributing to Asiana 214...Me neither, but the autopilot can (potentially) save lives if an unqualified person does end up behind the yoke. Or if a pilot temporarily passes-out due to a medical condition or in a million other cases.
That's why we have two pilots on airline flights; also, when you do wind up in an all-else-fails and somebody who doesn't know what they're doing has to get the plane back to terra firma in one piece, ATC will basically talk them through it with the help of a type-rated pilot/instructor on the ground. (OTOH: most of the time, with the amount of deadheading flight crew roaming around, it'd be pretty darn hard to get into a situation where you had an airliner in the sky with nobody with flying knowledge alive aboard it. The Helios 522 (IIRC on the flight number) mishap was extreme, but the one flight attendant who was able to keep himself conscious until the bitter end using the plane's O2 supplies had a commercial pilot's license, AIUI.)
-
And we're actually fairly close to where someone who has domain knowledge and a logical head on their shoulders can pick up a scripting language (Python's probably the best choice for this job, I personally would feel comfortable throwing my mom Learn Python the Hard Way) and hack something together to ease their workflow along.
I agree that the languages are actually pretty damned good, it's the programming environments and tooling that suck.
The main challenge comes when all that domain knowledge is locked up in the head of someone who can't, or won't, get past ground zero. Some people would never be interested in even the slightest whit of scripting, no matter how much easier their lives would be made by it.
This again...
They don't have to be interested. I'm not saying we hold a gun against people's head and force them to program. I'm saying anybody who's interested in learning should be able to learn with minimal friction.
Please don't bring up points that were already discussed.
-
I'm going to let someone else respond to this because I don't even know where to start
Don't?
and now my head hurts at why you keep saying the system sucks and we need to make it so anybody anywhere can write software.
It is ironic that he's the guy complaining the loudest about how software is shit.
-
They don't have to be interested. I'm not saying we hold a gun against people's head and force them to program. I'm saying anybody who's interested in learning should be able to learn with minimal friction.
I think this is the first time you added the parts I bolded. Previously you made it sound like anybody should be able to learn, and that has a very different meaning from anybody who's interested should be able learn.
-
They don't have to be interested. I'm not saying we hold a gun against people's head and force them to program. I'm saying anybody who's interested in learning should be able to learn with minimal friction.
Sorry if I pointed out something that was already obvious to some people around here. I just think it's a point that needs to be made, because even if you made the environments and tooling frictionless, you'd still have trouble getting beyond the 'its a magic box' phase with a quite significant fraction of the populace. Granted, we're starting to see pushback against the commercial forces that are driving the magic box view...but you do have to admit that there are commercial forces that drive that view, not just simple ignorance by end-users. Magic boxes with walled gardens inside them are far easier for salespeople to pitch, and far more profitable short-term for the companies that make them.
-
anybody should be able to learn
How is "anybody should be able to learn" different from "anybody who's interested in learning should be able to learn"?
-
How is my 90-year old grandma who's never touched a computer in her life any different from a high school freshman who would like to learn some HTML?
-
How is my 90-year old grandma who's never touched a computer in her life any different from a high school freshman who would like to learn some HTML?
I have no idea what that has to do with my question. The grandma's better at baking? I guess? Is that what you're looking for? The high school freshman has a condom in his pocket? I'm lost.
-
Just say your 90 year old grandma is interested then. Doesn't that fix your gap in this argument?
-
Just say your 90 year old grandma is interested then. Doesn't that fix your gap in this argument?
It would. But she would never be interested so it's kind of a moot point trying to come up with a system that allows her to become an effective programmer. Why would someone who doesn't know the meaning of email, Internet, operating system, Start Menu, install, boot, shut down, or even mouse have any interest in software development? She can't even get over the concept that DVD's don't require rewinding.
-
The main challenge comes when all that domain knowledge is locked up in the head of someone who can't, or won't, get past ground zero. Some people would never be interested in even the slightest whit of scripting, no matter how much easier their lives would be made by it.
Wait, it looks to me like you're arguing both sides of the fence??
Anyway, re; autopilots and ashclouds (wasn't that a song by Joni Mitchell?), both an old-school Classic A/P and a newfangled "better*" A/P would route you right through it... doesn't refute that a "better" A/P could help sometimes.
I guess my point is that it's good to dream a little bit about Ideal
- Better, but not completely omniscient about, say, weather.
Yes Blakey I'm agreeing with you - have some free links
-
But she would never be interested so it's kind of a moot point trying to come up with a system that allows her to become an effective programmer.
I don't see how that contributes anything to this discussion at all. If she's not interested, she's not interested. Like I said above, so what? Who cares? Not relevant.
Why would someone who doesn't know the meaning of email, Internet, operating system, Start Menu, install, boot, shut down, or even mouse have any interest in software development? She can't even get over the concept that DVD's don't require rewinding.
You're kind of an asshole towards 90-year-old grandmas everywhere, aren't you?
-
How is my 90-year old grandma who's never touched a computer in her life any different from a high school freshman who would like to learn some HTML?
@blakeyrat:
The high school freshman has some notion of a mental model of how the box works, even if it's incomplete/off-base in many ways. Mott's grandmother doesn't even have that. That mental model of the computer as a logical machine and not a magic box is the 'Ground Zero' I refer to, and is the first leap anyone who seeks to program must make. Without it, you have no hope of becoming anything besides a code monkey, even if you are interested in programming.
-
Ok? Again, I don't see the relevance.
-
Ok? Again, I don't see the relevance.
To your argument that "programming environments should not be sticky wickets": I support that point anyway.
To your argument that "programming environments should not be sticky wickets because the world would be sunshine and rainbows if everyone could program a computer": You've come to the right conclusion for the wrong reason. First: we'd get more WTFs of the code-monkey kind this way, not less. Second, some people never will be able to get past ground zero, no matter how smart they are otherwise, how much they want to create the Next Big Thing, or how much they invest themselves in the problem.
Remember that the brains of most of us were wired to deal with other people and all their illogical quirks, not perfect logicians cast in silicon.
-
Isn't that the entire point of your argument though? That it would be stupid to try make programming so easy that someone with that little computer knowledge could do it?
-
It's like you have the /thread point of the argument but refuse to use it because it would be /thread and might stop the blakeyranti....... oooooooooooooooh
nevermind, ignore everything I've said.
-
Mott's grandmother doesn't even have that.
So what? She's not forced to be interact and be interested, any more than she's being forced to learn Javanese (unless, perhaps, she happens to live on Java).And it doesn't matter that she's a grandmother, either, which is what blakeyrat was getting at - the person who gave me my first shot at commercial programming died a few years back, aged 94.
-
To your argument that "programming environments should not be sticky wickets because the world would be sunshine and rainbows if everyone could program a computer":
I don't recall ever making that argument. Quote me.
-
Isn't that the entire point of your argument though? That it would be stupid to try make programming so easy that someone with that little computer knowledge could do it?
Maybe my point hasn't been clear? I'll try to summarize.
- We should not have barriers to keep interested individuals from trying to learn how to program.
- We also need to acknowledge that some individuals, regardless of other knowledge, will never be able to become effective programmers, and we should not be catering to them because it's a waste of time and effort and will only make things worse.
- Some individuals, while they may have the intelligence to learn programming, will not have the time to become effective at it (think of the doctors and lawyers mentioned earlier) and lowering the bar of entry will mostly be a waste of time because most of these guys simply don't have the time to write a good software product. We do not need to cater to them either.
- Finally (and mostly this was me going pedantic on blakeyrat's use of the word "anybody"), we need to realize that not everybody is interested in programming, and we should not be lowering the entry bar to those people because they don't even care to begin with. Basically "anybody should be able to learn to program" is based on the flawed premise that there are no people who would never want to learn to program.
-
Finally (and mostly this was me going pedantic on blakeyrat's use of the word "anybody"), we need to realize that not everybody is interested in programming, and we should not be lowering the entry bar to those people because they don't even care to begin with. Basically "anybody should be able to learn to program" is based on the flawed premise that there are no people who would never want to learn to program.
What are we risking by lowering the bar for people who aren't interested? Do people who are not interested require the bar to be lower than for people who are interested?
-
What are we risking by lowering the bar for people who aren't interested? Do people who are not interested require the bar to be lower than for people who are interested?
It's an opportunity cost Bort. The time we spend on lowering the bar for people who aren't interested is time we are not spending on other things, like (from a research perspective) coming up with a better algorithm for a certain task, or finding system architectures that are more suited to secure systems.
-
What are we risking by lowering the bar for people who aren't interested?
Probably wasting our time solving problems that don't need to be solved instead of problems that are actually worthwhile. That's the thing about an ideal...at least of the super duper @blakeyrat variety...it doesn't take real world constraints into account.
-
What are we risking by lowering the bar for people who aren't interested? Do people who are not interested require the bar to be lower than for people who are interested?
I would say if someone is not interested because they think it's too difficult, but would be interested if it was easier, then they actually were interested to begin with and don't fall into the non-interested group. And this is a valid case, and a good point on why stuff like the Linux CLI or git are bad. The bar is too high and alienates a lot of otherwise interested individuals.
For the truly non-interested, it's not so much a risk as it is a complete waste of everyone's time. You don't build something for a market that doesn't want/need/care about it. I'm certainly not about to go building spacecraft for the Amish.
-
I'm certainly not about to go building spacecraft for the Amish.
Why not? Horses in horsey-space-suits to pull the space ship along...
...that would be cool!
I'm using that one, somewhere, sometime.
-
Is that an excuse to
sample... ahem... commune with spirits this evening?Already on my third as I type...
-
As I mentioned above - INAP - but I understand each of those references.
I understand the first three, but the "very, very large J-3 Cub" just went "whoosh."
-
I understand the first three, but the "very, very large J-3 Cub" just went "whoosh."
It's a reference to an incident where a Qantas 747 lost nearly all of its electrics due to leaking sink drains.
-
Okay, I'm gonna troll on the autopilot riff a bit, before I get back on topic. Disclaimer: IANAP, but I am a simmer and long-time flight enthusiast, so I have a pretty good idea how planes stay up in the air and how to get them to go where you want.
It seems to me that creating an autopilot that flies the plane autonomously - even adjusting to real-time condition changes, as fed to it by ground control, is not an impossible task these days. For all I know (I haven't been researching the matter), it's already been done. Leaving aside extreme cases (when - even with a qualified and experienced pilot behind the controls - it's brown pants time), such an autopilot could concievably cart complete flight noobs around the country.
Whether that is sensible, is another matter entirely, but if ever we do get flying cars, my money is on that they'll work something like this.
Getting back on topic, I see two issues being conflated: using computer-based tools and creating computer-based tools. The second we call "programming".
As far as the first is concerned, I'm 100% with @blakeyrat - if a user needs to negotiate a steep learning curve to perform trivial tasks, the designer of the tool did a shitty job. Non-trivial tasks should only introduce the minimum amount of additional complexity required. Mind you, simplicity for the user generally means complexity for the designer - but that's what we're paid for.
As for the second, I mostly agree with @blakeyrat - it should be simple to automate trivial tasks and creating more complex solutions should only be as hard as the added level of complexity.
To illustrate the point, I like C (K&R flavour), because it's simple and compact. Unfortunately, it is the wrong kind of simplicity. It's simple in the way simple tools (hammers, saws etc.) are simple - making anything interesting with them requires knowledge and skill. Most computer users need complex tools that are simple to use. Granted, such tools are only going to be simple to use if you're sticking to the narrow range of applications they were designed for. Getting more flexibility comes with the cost of having to learn more, but not everyone will need to be a power user.
-
This is worse than car analogies.
-
>blakeyrat said:
They don't have to be interested. I'm not saying we hold a gun against people's head and force them to program. I'm saying anybody who's interested in learning should be able to learn with minimal friction.I think this is the first time you added the parts I bolded. Previously you made it sound like anybody should be able to learn, and that has a very different meaning from anybody who's interested should be able learn.
My take on this is just a little different. He has said "anybody who's interested" before, at least earlier in this thread, if not elsewhere. However, I've always gotten the impression he thinks no learning should be required. The tools should be so easy to use that someone who has never programmed anything should be able to just sit down and write his or her domain-specific application with no more help needed than (maybe) the tooltips when hovering over the icons. Which might be an ideal, but it is an ideal so far removed from reality that it is of very little value in discussing how software should be improved.
-
Most computer users need complex tools that are simple to use. Granted, such tools are only going to be simple to use if you're sticking to the narrow range of applications they were designed for. Getting more flexibility comes with the cost of having to learn more, but not everyone will need to be a power user.
This is why the CLI has endured. A pure, point-and-click GUI is terrible for tying disparate applications together, which is what a suitable programming language excels at, and one of the criteria for such a language is that it needs to be suitable for discovery and exploration of what a program can do. This, in turn, practically mandates that said language has an interactive interpreter/REPL.
Filed under: Do you want an AppleScript REPL with that, @blakeyrat?
-
Actually, I'm going to go out on a limb here and say that possibly the most intuitive, programmable (and I'm not simply talking macros here) tool for solving a wide range of disparate-domain-specific numerical problems is Microsoft Excel - operated by (mostly) point and click. It has its problems, but it is simple enough for office-monkeys (and PHBs) to use and can do almost any kind of number-crunching you can imagine, requiring very little besides knowledge of domain-specific formulae that the user is supposed to know anyway.
-
This is worse than car analogies.
This is the Skoda of car analogies.
-
It has its problems, but it is simple enough for office-monkeys (and PHBs) to use and can do almost any kind of number-crunching you can imagine, requiring very little besides knowledge of domain-specific formulae that the user is supposed to know anyway.
Now, if it'd only stop getting its maths wrong...
-
Can't have everything.
