Re: GUI vs: CLI (was: Shell command in VB6)

From: Programmer Dude (Chris_at_Sonnack.com)
Date: 04/05/04 

Date: Mon, 05 Apr 2004 14:54:34 -0500

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 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.

> 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 :-).

>> 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).

> 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.

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.)

> [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]

> 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'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.

> 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.

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.

> 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.)

> 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.

> 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. (-: 

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Relevant Pages

  • Re: GUI vs: CLI (was: Shell command in VB6)
    ... >> Using only existing GUI applications could not duplicate ... > If the point is that, therefore CLI apps are better, I've not ... this aspect of cli apps, but it does not apply to me" ?). ...
    (comp.programming)
  • Re: GUI vs: CLI (was: Shell command in VB6)
    ... > this aspect of cli apps, but it does not apply to me" ?). ... between GUI and CLI is actually fairly slight. ... how many of us programmers would ...
    (comp.programming)
  • Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
    ... Microsoft tools are not cheap for lack of spending on them. ... > For the most demanding programmers, ... apps I know aren't thin data covers. ... >> FORTRAN code in any language, including Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: [SLE] NetBeans 5.5 Released
    ... it wasn't until I started playing with Eclipse that I even ... apps are Win32 or Win64 and don't run on Linux or Macintosh. ... I couldn't do the GUI wanted without having to resort to ... nesting layouts like in straight Java. ...
    (SuSE)
  • Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
    ... For the most demanding programmers, ... > in any language, including Delphi. ... I actually have a little routine in some apps where the user can add ... going to shift out to Delphi in numbers significant to Microsoft. ...
    (borland.public.delphi.non-technical)