RE: general questions

lol. These rants are priceless!! I talk about a simple wrapper and we
get text stream processing!! Tack on irrelevant things to make your
point sound good!! If you gotta reach that far then that is a clue your
argument lacks merit. I give up trying to explain it.

Sorry I'm not reading anything on unix if I can help it. Text based
operating systems will be obsolete. I know all you text gurus will
argue to your death. But JCL was junk while it was still in use. It
was used only because that had to, not because it was any good. Command
line interfaces, text based oses and the mouse are all going bye-bye.
Its just a matter of time. May be in my lifetime, may not be, I don't
care. I am focusing my attention on the future, not the past otherwise
I could get a high paying job doing cobol since those guys are in
demand. But I don't want to work with a dead language even if it won't
die in my lifetime. I'm looking ahead.

For example:
> If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity.

Wrong. A gui has textboxes. You only need to click some things, not
evey single parmeter for every single command. No wonder you don't like
guis.

> Things based on text stream processing don't
have 'scopes' or associated limits.

Wrong. If a program doesn't have a scope its unlikely to come out well.
And a program can easily accept a text stream and return one. How do
you think your commands work? They are programs.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Sent: Tuesday, September 11, 2012 1:52 PM
To: John Maher
Cc: Andreas Krey; David Chapman; Mark Phippard;
users_at_subversion.apache.org
Subject: Re: general questions

On Tue, Sep 11, 2012 at 12:11 PM, John Maher <JohnM_at_rotair.com> wrote:
>> You're confusing a single application with the whole command line
>> and *everything* it can invoke. In your picture that whole set of all
>> commands available now or in the future is the 'the application' for
>> which you'd need to design a GUI, would you want to have its
> flexibility
>> available in a GUI.
>
> I don't understand this statement at all. I'm talking about a simple
> wrapper. And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.

On the command line, every piece of text, including the base command
to run can be the expansion of shell variables, file wildcards, or the
output of any other program. If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity. The input can be the output of any other
program. If the tool doesn't do the complete job, the output can go
to any other tool.

>> Interaction with *other* applications (the trailer) isn't designed
in,
>> and can't be automated.
>
> Again, if necessary it can be, very easy. However that is not the
point
> of the wrapper. If I want to build a car you can say but it can't
fly.
> And it can't float. You're right. It isn't supposed to. You can
> always pick fault about something if you go beyond its scope.

That's the point here. Things based on text stream processing don't
have 'scopes' or associated limits. Likewise for command lines based
on text expansions.

>> GUI applications are designed to interact with a user, and not with
>> other applications
>
> Again that is not true. Well the first part is. The second part
(("not
> with other applications") may or may not be true. Depends on the app.
> I'm starting to learn who isn't a programmer because they have common
> misconceptions about how programs are designed. I wonder if its from
> watching TV?

Starting here worked out pretty well for me:
http://books.google.com/books/about/The_UNIX_programming_environment.htm
l?id=poFQAAAAMAAJ
The concepts still save me time every day.

-- 
  Les Mikesell
     lesmikesell_at_gmail.com