On Tue, Sep 11, 2012 at 7:22 AM, John Maher <JohnM_at_rotair.com> wrote:
> Interesting discussion. It appears you have not had the chance to work
> with a good wrapper, or maybe you shun guis or something because there
> appears to be a strong bias to your statements.
First, let me remind you that you started the discussion, complaining
about not being able to find the way to do what you wanted in a GUI.
> I have been a
> programmer AND user on both sides, gui and command line, so I am not
> making things up.
I'm more of a system administrator, so used to doing things that
aren't designed into GUIs as everyday operations for most users.
>> I'm not saying GUIs don't work. Just that they are generally a subset
>> of what can be done with commands.
>
> This is simply not true. Expose every function and every parameter and
> there is nothing the gui can not do. Add some automation, and the gui
> can actually do more.
But that's within a single application. Well designed command line
tools and scripting languages include all of each others'
functionality fairly seamlessly. While a GUI 'could' let me run a
program of my choice to supply any option or input, none that I've
seen actually do. So they are limited to what the designer
anticipated where the command line tools gain functionality as new
tools are developed or you add your own helper/wrapper scripts.
>> You are making some assumptions about scale and locality here. I have
>> most of the world at my fingertips in the form of URLs.
>
> Of course I am. I must make some assumptions or there is nothing to
> talk about. Don't forget a gui can have a box where a URL is entered so
> it can do everything you can by just typing in stuff plus anything else
> that gets added.
But, I said I would have a list of URLs in a file. Your GUI 'could'
let me provide the file as input. But that would be a rare choice for
a GUI designer and a common scenario for me. So if forced to use a
gui for a repeated operation, I'd probably end up displaying the file
in one window and cutting/pasting a line at a time as I repeat the
many mouse-clicks it might take for the rest of the work.
>> OK, but if I regularly work with 44 repositories, I'm likely to have
>> their URLs in a file where a script can extract them a lot faster than
>> you can navigate the world in a picklist.
>
> Now you're making assumptions, that's OK though. Makes for a good
> discussion. And you are right. Nothing works best 100% of the time.
> Now think of the reverse of that. What if you wish to do something to
> 44 repositories once? Whats better typing them all in or clicking on
> them. You can type, I'll click.
My assumptions are from past history. Picking 44 names out of 100
might be a win. Picking 44 out of 50,000, I'd rather just type them
in, but if I am creating a new, arbitrary set of names for related
things I'd use a name convention where wildcards or number sequences
make the set script-friendly for operations on the group. If someone
else has given me the names, we are back to already having the list in
a file and the script just has to iterate over it.
>> But it can only be a good design after you already now what I'm going
>> to do. Until then you can only offer the bazillion choices.
>
> Again, not true. With experience comes wisdom.
How does that differ from what I said? If the GUI designer knows
what I'm going to do and wants to spend the time making it easier,
then yes, the GUI approach can be nicer. But if I want to do
something new and different (and what's the point if I don't?) then
combining all of the functionality of existing commands with script
wrappers and a few of my own is going to win.
> Although you can never
> predict a user 100% of the time, you can learn to be spot on 50% (or
> better) of the time. And you seem to be forgetting a gui can do
> anything text can do by offering a textbox.
No, a textbox is not the same at all. Text tools allow running any
program you want to expand the result. I suppose a textbox 'could'
let you put in $(cat wild_card_filename) or $(grep pattern filename)
and accept the result like any bash command line will, but I've never
seen a GUI do that.
> There's a bazillion right
> there.
But that's a bazillion you have to input There's an old saying that
GUI's make 'easy things easier and difficult things impossible'.
> You also have a bazillion at the command line.
Which can be generated by any other tool at my disposal.
> I think what you
> are picturing is nothing like what I am planning. lol. At least I
> would never use the same words to describe it as you do.
OK, but I spent a couple of days 20+ years ago learning how to combine
the work of different tools with simple shell scripting and it has
saved me time pretty much every day since. But, I tend to think that
the best user interface is no interface at all - that is, the machines
should just do your work for you in the cases where it is predictable,
and it should be trivial to repeat complex sequences even when you
have to do it manually. If you have to do some set of operations
across 44 instances of something today, how will your GUI help you
automate that set of operations on the next 44? If you did it on the
command line, you'd just recall the command and edit the target. Or
save it in a file that you can edit easily, or come up with a way
another tool can generate the target list. The 'graphic display' of
the operation isn't particularly useful on its own here - you just
want the underlying work done.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2012-09-11 17:45:58 CEST