Re: GUI vs: CLI (was: Shell command in VB6)
From: goose (ruse_at_webmail.co.za)
Date: 04/16/04
- Next message: Edward G. Nilges: "Re: Basic programming Question?"
- Previous message: Paul Franklin: "Truth Table approach"
- In reply to: Programmer Dude: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Next in thread: Chris Sonnack: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Reply: Chris Sonnack: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 16 Apr 2004 03:37:51 -0700
I started this reply ages ago, but have not had time to
finish it. I hope that this thread is not yet so dead that
the ideas I express here go ignored (flames welcome :-)
My time is, as always, limited; I may not get back to this thread
for some time.
Programmer Dude <Chris@Sonnack.com> wrote in message news:<4071B97A.87B7F41A@Sonnack.com>...
> goose wrote:
>
> >> Here's a counter case: I have 100+ CAD/CAM files that all need
> >> to be updated. I'll skip to the bottom line: CL can't do that
> >> **at** **all**.
> >
> > how do you know? what are the updates needed?
>
> Implement the most recent ECO. Typically this involves moving,
> adding or removing lines, changing specifications (dimensions and
> tolerances) and adding an ECO notice.
>
> > what format does you cad/cam app save the files in?
>
> Their format. (-:
>
> (Assume proprietary binary. IME, that is the case for most big
> professional CAD/CAM apps.)
>
> > If the files are saved as non-binary (xml, or suchlike),
> > then it is almost certain that if you needed to make
> > an /automatic/ change to all those files a set of CLI
> > applications would easily do it.
>
> ECOs wouldn't be automatic. IME, most changes aren't.
>
> > Why not try to do what I did?
> > Use a bunch of *existing* GUI applications to
> > achieve something considerable.
>
> That doesn't apply to this situation. Professional (expensive)
> CAD/CAM package. Kludges simply aren't appropriate.
>
> > you've missed the point. The functionality was needed.
> > Using only existing GUI applications could not duplicate
> > the functionality, but using existing CLI applications
> > did (and could do a whole lot more).
>
> If the point is that, therefore CLI apps are better, I've not
> only missed it, I've waved bye-bye to it. (-:
I'm not too sure what you mean by this ("I've already seen
this aspect of cli apps, but it does not apply to me" ?).
>
> >> I wasn't aware that being a GUI *prevented* a program from having
> >> certain capabilities (like arbitrary file manipulation). (In fact,
> >> I *have* a couple GUI apps I wrote that do exactly that.)
> >
> > exactly my point: you need to *write* the application. Your
> > gui tool that can do arbitrary file manipulation can be
> > used by my program, hmmm?
>
> If I wanted it to be, sure.
How many programmers aim for reusable /programs/? hmm?
>
> > if I want to use that code, i've got to link it in, right?
>
> Nope. I could make it a DLL. I could make it a COM server. I
> could make it a DDE server. I could make it take text command
> files (oh, already did that :-).
All of those options but the last one assumes rewriting, not reusing.
>
> >> And provide all possible options in front of the user's face.
> >> And support online help (with pictures and diagrams! :-).
> >
> > HEY!!! Your smileys are the right way round now!
>
> Only when used as a closing paren. (-:
>
> > You are right in this respect. GUI's *do* *indeed*
> > maek it easier for a user to get up to speed on
> > a new application. This is a hands-down win for GUI's.
>
> I'd claim the other hands-down win is with regard to the ability
> to present data (see other posts).
Very true. The ability to view a scalable/zoomable scattergraph
is indeed a very big win. Although, I have seen very many
gui apps that dont really need to present complex data, and a few
that are very able to use a pure text-output to marvelous effect
(gnuplot -> set your xterm to its smallest size so that each character
displayed is about 3 pixels and maximise that screen. The effect looks
like a gui :-)
>
> > A GUI may have lots of other wins. But they fail in one big
> > area; reusability by non-programmers.
>
> But I think we've covered that--while that may be de facto now--
> nothing *requires* it be so.
No, nothing really requires it to be so, but with the current
argument (X vs Y), the gui proponents seem to be ignoring this
very important aspect. I dont really want to start up my
development machine each time I want to reuse a particular
program.
Many end-users dont even *have* a development machine (box with
compiler, linker, whatever), so for them a given program that
does only one thing (and does it well enough that they want to
reuse that functionality) cannot be simply reused.
>
> There is NO (ZERO, NADA :) technical reason I GUI app can't do
> Every Single Thing a CLI does. (That most don't probably means
> the need isn't as important to most users as it might be to us.)
No there isn't. In practice, however, most GUI apps cannot
be even /batched/ ... even the gui apps that I like and depend
on are seemingly crippled. There is, as you say, no technical
reason that gui apps cannot do everything that a cli app does,
but many dont even do a *few* of the things I expect from an
application. Most gui apps /need/ you to babysit it from start
to end. I'm sure there are some that dont, but they are few
and far between.
>
> > [GUIs] cannot be reused by a fairly advanced user. period.
> > You need to be a programmer to reuse a GUI-only app. Most
> > users are not programmers; even most sysads are not programmers.
>
> In the sense of unice-style piping, I agree without reservation.
>
> But here's the thing. Piping is uniquely unice *because* of the
> unice philosophy of Very Sharp Little Tools (VSLTs) that (advanced)
> users use to build Bigger Tools.
>
> Quite honestly--even speaking as a programmer--I haven't felt the
> need for--nor the lack of!--that plumbing in Windows. Nothing I
> do in the Windows world seems to require it or even suggest it
> would be handy.
>
> I think the only type of that sort of thing I've done in a VERY
> long time is dropping into Console and doing "dir > files.txt"
> or something.
>
> Which works as well in Winders as unice. [shrug]
It depends on your use of the machine, I suppose. For example,
I hate waiting in front of the pc for anything, so generating
an audio cd of my favourite songs from mp3 (no, I dont pirate:-)
is, with my cli apps, a simple matter of writing a script
that will convert and copy tracks. Any cd-copying program,
no matter how good or reliable, will quickly annoy me if it
cannot take all mp3[0] files from a certain directory and copy them
as audio data to a cd (and leave me a note in a temp directory
on the success/failure of the operation).
>
> > I have considered it, and *all* my gui applications
> > are just gui wrappers around my c/line application.
>
> That's great if it works for you. It absolutely wouldn't for me,
> but I suspect I live in a more graphical world.
>
I suspect that you do :-)
> > I've got a utility library for C (done long ago), that
> > reduces the effort needed for *any* C (or C++) application
> > to use which redirects input, output, errors, etc, so my
> > gui applications can easily be used by each other, even
> > with pipes :-)
>
> Well there ya go! Just like I said!! (-:
>
> >> Consider also an aspect not yet discussed: the ability of the
> >> GUI to *present* information in a **much** more humanly
> >> digestible way. Good use of graphics and color and font
> >> seriously extend the information content of well-presented
> >> data.
> >
> > That is very true; it also leads on to a serious problem
> > of most GUI programs -> the selection of graphics, colours
> > and fonts annoy some users and distract others, while helping
> > the remaining.
>
> Apps should be designed to (a) use Windows color settings, NOT
> some programmer-selected color scheme, and (2) be user settable.
> Also, (iii) the defaults should be as *inoffensive* as possible.
>
> Yes, creating a Good GUI is harder.
> But then, doing something Better usually is. :-P
>
> > OTOH, a CLI program can wrapped by as many different GUIs
> > as there are people willing to write wrappers.
>
> I think that's one of those unicy things that ordinary users
> couldn't care less about. Maybe I'm wrong, but I can't say
> anything about that lights *my* fire. I couldn't care less,
> in fact, about a dozen GUI wrappers. I only need one, and--to
> be honest--I'm really not all that picky about how it works so
> long as it does work.
>
> >> I'd place a straight CLI (i.e. NO GUI at all) right down there
> >> with the buggy whip. Useful and great in its day, but that day
> >> has **long** passed.
> >
> > but luckily, still much more usefull than a UI which cannot
> > be changed *at* *all*.
>
> Disagree. My car can't be changed *at* *all* (in the sense under
> discussion here: the UI), but I don't see that as being any sort
> of disadvantage whatsoever. The same is true for just about every
> physical tool I own.
This is a more usefull analogy than you probably thought it would
be :-). I am in the process of getting a car for the wifey-type.
I already have a car for myself (an ancient bmw, older than most
script-kiddies:). Of course, I want a car (for the wife-type) that
can be reused for more than just travel of 4 people + luggage
(I already have a car that does that), the wifey-type wants just
transport to/from work; she also stipulates that she is *not* driving
a huge bakkie ("truck" for you USA people :).
You say your car cannot be changed at all, but I disagree. I find
myself sometimes looking for a car to transport my dog in comfort
600 to 1300 km when I go on vacation(stationwagon?), a car to
transport the occasional piece of furniture (bakkie?), a car to
sometimes go on vacation with siblings family as well - about
8 people total + dog (kombi/caravelle), somthing to use to work
and back for wifey-type and something with 4x4 capabilities
(I sometimes go for vacations on roads that aren't).
And, of course, it has to be cheap :-). For lots of people, a simple
4 seater passenger car would do. To do anything else with it (transport
a bed, a dog, etc) would be impossible. For most people a gui app that
forces them to babysit a program from start to end is livable. For me
it isn't, my "car" must be as usefull as possible to me, not just once
but again and again ...
>
> > and that was the point of my previous post!
> > *you* have to *build the gui app* to do what
> > a set of existing CLI apps can already do.
>
> I don't see why this is a point. Somewhere someone had to write
> the CLI apps. Once written, there ya go.
Of course, once written, the cli app can then be reused in ways
the programmer never even thought about. Very few gui programs
can claim to be reusable. I applaud those that can be reused.
>
> I mean, fine, you work in an environment where existing tools
> apparently meet your needs. I'm quite familiar with those tools,
> and--in my work--they have no real value. (Not because they
> intrinsically are valueless--far from it--but because they just
> don't apply to my world.)
>
> > The GUI fails miserably in the reusability stakes.
>
> In the sense you mean, I'll grant that, but I just don't see that
> as being such as big issue as you seem to.
>
It is a fairly important issue. We, as developers, spend much of
our "new project" time re-inventing perfectly good wheels. When
will we have time to progress to the new and exciting stuff if we
are spending time writing a new application that might have been,
with a little foresight, avoided.
If the writer of the gui-based windows cd player had thought
of at the very least *documenting* the c/line arguments that
cdplayer.exe recognises then I would not have to download
sqcmd.exe to play a single track repeatedly ...
> > Your argument is that whatever a CLI app can do, a GUI app can
> > also be built to do.
>
> Part of my argument, anyway. The other part is that a GUI is (to
> me) a hands-down winner in information presentation. (Further,
> for most consumer programming, it's probably the way of the world.)
Presentation of information is indeed a hands-down win for gui
apps. I will not dispute that.
>
> > My argument is that using existing CLI applications negate
> > the need to even build a new CLI app.
>
> IF you have apps that meet your need. MY counter point is that,
> IME, in the business world, you often don't.
No, you often dont. However, when the programmer decides to
*write* the app that does not yet exist, why should he cripple
it? Of course it is nice to have a gui application. Its even nicer
to not have to write new software all the time.
If the programmer /designed/ his new business application to be
reused, it would not be long before the statement "In the business
world you often dont have existing apps that meet your need" would
be wrong. Its /because/ we dont have an application that meets
our need that we write new ones. When writing, we should make
sure that someone else can say "This application meets some of
my needs, so I can use it in conjunction with these other apps
that meet the rest of my needs", and not "This application meets
some of my needs, but I cannot use it in conjunction with any
other applications".
>
> > With the GUI, you are generally up the creek without a paddle,
> > should you actually want to use it for anything else.
>
> Well, yes. If I ever needed to port my business app to a digital
> watch, you're right. I'd be SOL. (-:
IMveryHO, we need programmers who care about reusability. I like
applications that are easy to use, that give me help whenever I want
it during the programs execution. I also like to be able to tell
a program "make it so" and then merely come back later to check on its
progress.
I think the crux of my argument centers around the ability to
let a program run its course with as little intervention as possible,
and not whether a GUI is better than a CLI; It just so happens that
most CLI apps are designed to run to completion without user
intervention and most GUI apps are not.
I am the programmer; I am also a user, so when I go on my rant
against "noisy"[1] applications I am not necessarily declaring
that GUI applications are all evil, but that they usually require
too much attention. If your gui application can take *all* the
information it needs to complete its task once at the beginning
of the program, then I think I have a good chance to use that
program of yours.
Most gui programs are *only* interactive, even when there is no
need to be; why needlessly cripple a program. Some programs
are interactive-only, when there are parts of them that need not
be interactive-only (why not allow "open" and "save as" as c/line
args so that one can change the format of hundreds of files with
a single script? Even your CAD/CAM package can allow this without
losing its gui functionality).
The reason, I think, for a gui program having these deficiencies
if because the programmer has been indoctrinated with "GUI is good,
CLI is bad". Even *you* have written above that a gui can technically
do everything a cli can do; however /most/ gui programs fail
miserably on the *one* thing that cli programs are /designed/
to do -> be non-interactive.
Unfortunately, it seems that many programmers write code without
a care about whether or not it can be reused elsewhere. Just because
it has a GUI does not mean that the application MUST ignore
c/line arguments or the users who want to reuse functionality.
The sad truth is that GUI applications developed by programmers
of the mindset "CLI is obsolete" are always going to be a failure
as far as reusability goes. The developer that understands the
strength of reusable tools will develop great GUI apps, that also
happen to be great CLI apps.
btw: search for and download dopewars (for windows) for what I
consider to be the epitome of UI choice. In addition, I find it
a very enjoyable way to waste ten minutes :-)
notes:
[0] for "mp3", read "any format I desire".
[1] A term I just invented now to refer to those applications that
need attention.
- Next message: Edward G. Nilges: "Re: Basic programming Question?"
- Previous message: Paul Franklin: "Truth Table approach"
- In reply to: Programmer Dude: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Next in thread: Chris Sonnack: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Reply: Chris Sonnack: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
