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

From: Chris Sonnack (Chris_at_Sonnack.com)
Date: 04/16/04 

Date: Fri, 16 Apr 2004 12:34:05 -0500

goose wrote:

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

It's dead, Jim. (-:

>>> 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 guess that's a fair assessment. It doesn't apply to the entire
*environment* in which I work. There are very few text documents
(lots of binary) and very few occasions for batch processing of
documents, text or otherwise.

The bulk of the work is interactive in nature, and I think after
thinking about this thread for a while, it really boils down to
just that:

        CLI == batch
        GUI == interactive

**Programmers** live in a world where batch processes aren't too
unusual. And there are certainly any number of "IT" or "IS" jobs
that are batch in nature. In these situations, the difference
between GUI and CLI is actually fairly slight. A GUI is often
just a "kickoff" screen (either integrated with or wrapped around
a batch process core).

As we've discussed, about the only value for a GUI here is with
rarely used, or infrequently-used-but-hard-to-remember, CLI apps
where is serves as a friendly wrapper.

However, I think most ordinary PC users most often work in an
interactive mode. Consider this: how many of us programmers would
want to write and edit text via CLI (think sed!). I'd bet every
editor we use is GUI (character-based or bitmap). I doubt anyone
does CLI editing!

The reason is simple. Editing is interactive, not batch.

And so are *most* common user-level applications. (Hence, what I've
been saying all along: GUI is superior (not just a matter of choice)
for those users and for those interactive applications.)

> How many programmers aim for reusable /programs/? hmm?

By my count, 14,305. (-:

(Of course, my count could be off.)

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

Maybe it's not as important as it seems? How many *users* do much
Unice plumbing to do their work (non-programmer users, I mean)?

I think you greatly over-estimate the value of this WITH REGARD TO
ordinary desktop users.

Even I, a long time programmer working in a Windows world, haven't
had a demand for these tools. I truly don't miss them at all. On
the rare occasions I can use something like that, perl works very
well on my Win2K box!

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

Let's compare bad GUI apps to bad CLI apps, though.
Or let's compare good GUI to good CLI.

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

Hmm. I just highlight the ones I want, drop them in the GUI tool
and click "Record". Don't need to write any scripts...

>> My car [UI] 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.
>
> 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).

There is a big difference in using a tool for different purposes
(hammers can both insert and remove nails) and having a tool with
a *configurable* User Interface.

When you can alter the position and behavior of the car's controls,
get back to me! (-:

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

[shrug] I'm just not sure I agree the difference is significant.

I have a number of CLI (batch) apps I've written. One converts
C/C++/Java[Script] to colorized HTML, another processes webpages
for me and inserts common text sections (kind of a preprocessor).

I don't see either of these being "reusable" for some purpose other
than what they do right now. Likewise most of my apps, CLI or GUI.

An app can be *useful* in a variety of places--that depends on the
app. For example, sed and awk are hugely useful in many places,
whereas man pretty much has a single use. Likewise, Excel and Word
are hugely useful in a variety of places, whereas a CD-burner GUI
app just makes CDs.

I just don't buy this "reusability of apps" argument. Sorry! :-(

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

Be an uphill battle!

> 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 agree with every word without reservation!

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

I would agree with that (and I think it's not a CLI/GUI issue).

> It just so happens that most CLI apps are designed to run to
> completion without user intervention and most GUI apps are not.

Of course not. CLI == batch. GUI == interactive.

I agree largely with most of what you wrote from this point on. 

-- 
|_ 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 ... > users are not programmers; even most sysads are not programmers. ...
    (comp.programming)
  • Re: new to usenet, some slrn questions
    ... I much prefer CLI and ncurses based apps over GUIs for most ... I use GUI apps for multimedia production, ... GNU tools which save so much time like cp, rm, du, cat... ...
    (news.software.readers)
  • 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: [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: setting PATH for GUI to provide to apps?
    ... How does one control the search path that is passed to apps by the GUI ... This is on top of the usual shell init scripts e.g. ... The trick to get the 'root' things to use your $PATH etc. is to ...
    (comp.sys.mac.apps)