Re: Great SWT Program

In article <ccbbcc33-ad3a-4634-b6dc-15ebbc6dd15a@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Jan 2, 4:55 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
[snip]

Your post is too long. Do not write a post longer than 100 lines
again.

Bah. I laugh in the face of your reading disability.

I am not required to demonstrate my abilities to you whenever you
demand such a demonstration.

Of course not

Glad that's settled, then.

Writing my responses for me again?

Perhaps it is now starting to dawn upon you why I can so easily shoot
down your claims: it's you writing them! :-)

(If you say "Frog!" and I don't jump, and you then conclude that I'm
incapable of jumping, which is more likely -- I'm incapable of jumping
or I'm simply unwilling to do so whenever some random arsehole demands
that I do so?)

What irrelevancy are you on to this time?

Did you even bother to read what I wrote, idiot?

[insult deleted]

I'll take that as a "no".

[insult deleted]

An insulting rather than a serious and intelligently-written response
is certainly a "no" in a case like this.

It might have been, I suppose, if that was what I wrote.

Ahh, xargs, sed, all the same to normal users: nothing they want to
have to mess around with.

[nonsense deleted]

Normal computer users do not, of course, use any of those things.

Normal CLI users certainly do.

Which there isn't, of course.

If there isn't, then so much for sorting the data by anything other
than file name, of course.

That will already have been done

Of course not.

Then it's because you made a mistake: try again.

When you actually have a point to make, get back to me. Until then,
I'm busy; leave me alone.

Sure, here I am :-)

You're early. Go away, and only come back *when you have a point to
make*.

Yay! I'm back!

Of course not. It's much simpler. Ordinary users have no trouble doing
*that*.

Nor do ordinary Unix users have any trouble doing simple CLI
operations.

But ordinary users (no qualifier) have trouble doing complex CLI
operations.

But ordinary Unix users do not, which is, again, the central point.

*** you.

If you're very new at it, possibly.

IF IT IS AT ALL COMPLEX!

The problem is that what you consider "at all complex" includes the
sort of stuff they teach in kindergarten.

That's a damn lie. They emphatically do NOT teach complex piped
command chains in CLIs in fucking kindergarten!

They do not, nor did I say that they did.

Or do you now clear that *experienced*
programmers have no need of such things as "debugging"?

[puts words in my mouth and insults me]

I consider *writing scripts* to be programming, and to require
debugging.

Moreover, you consider writing a command line tantamount to writing
scripts. You seem rather unique in this.

Excuse me? We were talking about wanting to delete them all.

No

YES, WE WERE.

Certainly not.

Well, you may have been, certainly, once you realized you were on thin
ice - /again/.

If I want
to spare a few, obviously I use C-a and then deselect one or two
manually. If it's about a 50/50 mix, a case not previously under
discussion, I'll use a search or some other method to narrow it down,
or I'll just delete them one by one without bothering to make a large
selection.

Except, again, Explorer's search functionality is much too limited

*cough**sputter*it's SUPERIOR to the search functionality YOU have.

Certainly not. It onsly supports a few very basic search
criteria. Much too limited by far.

What have you got? Search by file name pattern and search by text
within file?

Heh. "find" alone supports:

- file system depth
- last access time
- last status change time
- emptiness
- file system type
- group name/id
- name
- inode number
- # of links
- last modify time
- path
- permissions
- size
- type
- user name/id

And a couple more advanced ones.

Add in other tools and you can match on far more than this, of course.

I can search by file name pattern, text within file, modification
time, and a buttload of other things, and I can even search by A
COMBINATION of these.

Wow. A /combination/ even. With my tools, it would be noteworthy if I
could /not/ search on a combination of different terms.

And get a nice, directly-manipulable set of results as UI objects,
instead of just an inert textual listing, supporting far more
operations than said textual listing would.

You generally don't get a textual listing as a result since you feed
the result directly into the next tool. Hence, what you want to happen
just happens.

...I can
re-present the same data in many different ways with a click or three
and no need to go looking things up or anything similarly clunky and
awkward.

Except your tools cannot even hope to support the same set of options

I suppose you could say that -- they support a LARGER set of options,
by and large.

In practice, they do not, no.

For example, sorting on two criteria (e.g. image width
and then name, so equal-width images are alphabetized; can you even
sort on image width at all?

Of course. Haven't you been paying attention?

Without fiddling around in the manual
first and perhaps even installing additional software first? Could a
*normal* computer user using your stuff?)

A normal CLI user certainly can.

Not to mention such very basic ones as "just point to a search result
and hit delete to delete it".

| rm

You really think this is like brain surgery?

Note for the record: Bent's still failed to address it.

Since you deleted my response, we can only presume that it was
embarrassing to your position. Your pretending otherwise isn't very
convincing.

No, we are talking about ordinary computer users.

Sure, ordinary trained CLI users.

NO. ORDINARY USERS, PERIOD.

So long as they are trained in a CLI, of course.

They are all of the operations a normal user will need.

Because you say so.

No. It's an observed fact.

Ok, because you say that it's an observed fact. What's with all the
hair-splitting?

Including
sorting, searching by file name, searching by text inside the file,
deleting, renaming, and the like.

Yes, simple operations that are insufficient for an IT professional.

Insufficient as decided by who? You?

No, by the people who feel the limitations. You know, the users. But
far be it from you to let these users choose for themselves what tool
better suits their needs.

The above list is just about
everything you get with ls, grep, and other such clunky and ancient
tools.

Or, at least, you wish that it was.

Including at least two operations *missing* from your crummy old CLI
tools: editing a file name (instead of renaming it atomically, typing
out the full new name)

Ah, yes, /exactly/ what I want: an inefficient way of renaming files.

You have an extraneous "in" in there.

You are imagining things again.

(Obviously it's more efficient
to change foobarfiddlyfaddlyquux.jpg to foobarfiddlyfaddlybaz.jpg by
changing only the end of it instead of writing the whole thing
*twice*. OK, once and a half with autocomplete to fill in the name
that's that of an already-existent file. And you can even do a total
change of name more efficiently -- instead of mv sometyping
newname<enter> you have just <f2>newname<enter>;

Of course, you also first have to navigate so that your focus is on
this particular UI element.

f2 selects the old
name so immediately typing a new name will replace it if you don't hit
a navigation key first. The worst case is if selecting the file to
rename is dicky enough because it's in a large dir; you can jump to it
by typing part of the name

But since you have pointed out time and again how inefficient i-search
is for such things, this is hardly a viable option in Twisted-world,
is it?

and searching by a *combination* of criteria
such as modified between this date and that, with this wildcard
pattern in the filename, AND this text inside the file ...

Of course it can do this.

Nonsense. You can search by file name and you can search by text in
the file.

And by a large number of other criteria.

Worse, you do these with TWO SEPARATE TOOLS.

I can largely do it with one single tool, of course. For more esoteric
searches, I may have to involve some other tool.

I have a single
integrated search tool with both of those and much more besides. You'd
have to do multiple searches and cross-reference them somehow, likely
involving a script, or at least sed or xargs. Yuck!

Perhaps in your own imagined Unix (VanillaUnix?), but not in
real-world Unixes.

Any general filesystem manipulations *your* tools provide that *mine*
don't, on the other hand, are obviously not needed even for some
techie uses, let alone for just normal-user uses, because I don't find
myself missing them.

There is a lot that is not /needed/ but that nevertheless increases
productivity once it becomes available.

By "needed" I meant "I find myself missing it" or otherwise aware of
its nagging absence.

There are also a great many things that you do not miss but which you
nevertheless cannot do without once you've seen it.

and worse, you
keep launching personal attacks, insulting me and harassing me. You
seem to believe that the ultimate surefire way to win an argument is
with ad hominem methods, for some insane reason.

I am not trying to win this argument.

He says, while striving mightily to do exactly that. And failing.

You are the one with the overpowering desire to win something here.
You're not doing yourself any favours by imagining similar motivations
for the rest of us.

No, we're discussing what one intends to do in general. You're
inventing hypothetical specifics again, out of thin air, this time "do
a lot for some limited time period". :P

If you are /not/ doing it a lot then typing the entire "convert"
command is trivial anyway and not worthy of mention. The only case in
which the length of the command is of interest is when you intend to
invoke it a lot.

But, of course, you pulled the "some limited time period" part
directly out of your ***.

Meaning that you agree with the rest that I wrote? Good, then.

An unrepresentative example.

Not at all - I do it all the time.

And YOU are unrepresentative of computer users in general!

I don't need to be, of course, since we're talking about Unix CLI
users anyway.

Irrelevant to the issue of excessive typing.

[irrelevancies deleted]

This is the CLI inefficiency subthread. The typing-system subthread is
--> THATaway.

Awww, embarrassed again?

Your previous complaints about how you need to look at the keyboard
and complete disbelief that this need not be necessary betrays
otherwise

If I'd actually said these things, instead of you putting the words in
my mouth, then you might have had a point here.

But, of course, I never said those things. I did say I need to look at
*either* the keyboard or the *screen*.

You also said you need to look at the keyboard, if only infrequently.

as do your statements
concerning how many letters are "many" and take a long time to type.

Time is relative. If you type at 100CPM, then 5 characters will take
you a few seconds and 25 will take a quarter-minute. If you type at
500CPM, then 5 characters will take a bit less than a second and 25
will take three seconds. Either way, 25 will take longer than 5,
although at 500CPM it will only take a couple of seconds longer
instead of about 10 seconds longer. It follows that typing system and
character-counting are orthogonal issues, which is why typing system
is irrelevant here, and why my begrudging a few extra seconds does not
say anything about my typing speed.

Having an efficient typing system changes very many factors that may
not be obvious to you. Most importantly, it causes anything that moves
a hand away from the keyboard to become wasteful in the extreme since
keeping the hand put would let you input a command by typing much much
faster than using the mouse etc. would do for you.

They certainly were -- you keep replying to my replies

No, no, we were discussing those replies of yours in which you
successfully defend your position. /Those/ are the ones I've been
failing to see, not the ones I've been replying to.

So can I. But "very little effort" != "zero effort", and cutting down
on the amount is still a further increase in efficiency.

[quibbling, but no actual disagreement with the above, deleted]

OK, I'm glad that's settled then.

Inventing my response for me again? Makes it all the much easier,
doesn't it?

Basically, "it's a dirty job, but somebody's got to do it". And it's a
job you are causing.

Hey - I'm your employer?

You are? Then I want about three months' back pay. Even at minimum
wage, that's ... lessee ... carry the three ... spent three hours on
your spew this day ... four that day ... clicky-clicky ...

Ah.

You owe me $4746.83.

Pay up.

I already covered this. But you obviously missed it in your overeager
snippage.

Piss off.

He'd rather get $12 an hour and spend it mostly sitting on
his can than get $12 an hour and spend it mostly actually working. :P

Of course, but then, he probably also realizes that if he never needs
to do anything it's only a matter of time before he's downsized.

(You see, unlike you, he is likely to be a mental savant and so he
will be able to deduce this connection quite easily.)

I'm referring to your own earlier posts, particularly when you
recommended emacs to "everyone who edits text a lot".

This doesn't, of course, cover "the world".

No, just a substantial fraction of it; hundreds of millions of people
in the developed world alone.

Certainly not. Just because you think you edit text a lot doesn't mean
that you actually do, and the hundreds of millions of other people who
edit as little text as you do also do not edit text a lot.

Nonsense. That terseness just contributes to the unix CLI being
cryptic and awkward.

So now you'd rather be typing /more/. [implied insult deleted]

I'd rather not be *typing* the commands *at all*, other than to write
a script to automate something, whereupon it's a one-time cost for
many invocations of the command in the future, and then? Yeah, I want
self-documenting names, just as I do with Java library class and
method names.

Right, so you'd rather not type at all but if you /were/ to have to
type, you'd rather have to type as much as possible?

Again, it's a good thing you never had a hand in designing a CLI.

(And, of course, this has nothing to do with self-documenting names in
Java since auto-completion - a foreign term to you I know - nicely
handles this.)

Unfortunately. But there are more concise ways for a user to specify
an object than by typing even two or three characters, and that DON'T
create a tension between speed of specifying versus self-explanatory
naming.

More concise, perhaps, but by and large far less efficient.

When picking an
ordinal

No ordinal is picked.

Ridiculous. There are N items with a natural ordering and it is
picking one of the N.

No, it is not.

There is an ordinal picking going on, if
implicitly.

No.

5. No ordinal is picked.

Nonsense. See above.

Indeed.

Now I will repeat the example: If it is transmitting at only 3cps for
whatever reason

Unless you are in a submarine on ELF, this isn't going to happen.

In other words, in general it may actually happen.

Not really since ELF is a one-way communication system.

The situation you brought up originally, however, happens with some
frequency and is caused by latency

The situation YOU are now bringing up.

It was the original situation: a non-responsive modem connection. This
is caused by latency, not poor bandwidth.

With latency, it becomes more
complex to decide how far to type ahead. Too far and you spend longer
backing up to typos than you save.

If you use an inefficient typing system, sure.

No, my position is that situations where there's an arguable benefit
to typing BLIND have become largely avoidable.

Avoidable, perhaps, but still desirable in a number of cases.

But then you have a very poor track record of interpreting my
positions correctly, even when I state them quite plainly, so I
suppose I shouldn't be surprised that you got another one wrong. :P

Perhaps you need to learn how to write more clearly, then?

It's the mini-script that *invokes* xargs that she'd be implementing.

You don't need a script to invoke xargs, you only need a command line.

A complex one worthy of being called a "mini-script". A little one-
line computer program.

To you perhaps, but then, the simplest things are difficult to you.

Piss off.

People generally don't need complications, but that isn't the point
either. The point is that many could make good use of the power.

But the only real "power" they get that nicer tools can't give them
and that they can make good use of is shell automation via scripting.

As well as more powerful tools, of course.

And using that requires programming-type skills.

Not really, no. If you start involving loops and conditionals, then,
yes, perhaps.

I never said that efficiency requires emacs.

You implied it, right there in the material I just quoted above. To
paraphrase:

You've been inferring things again.

Me: They could just use modern tools instead of emacs.
You: Sure, and remain inefficient.

This was in a discussion about inefficient modern tools, in which case
the above doesn't at all imply what you have imagined that it implies.

Ordinary-Joe computer users don't actually write text a lot.

In Bent-world. In the real world, of course, they do. Working with
written English, particularly, comprises a substantial fraction of
most peoples' school-related and work-related computer use.

And yet, they do not spend a lot of time on this.

Of course they do.

You grossly overestimate how much time people use on school work.

Changing the subject again, Bent?

I am sure you will, yes.

The right o would be the one on the switch on the side of your modem
labeled "|/o"; flip it to "o" and save us all the bother of any more
of your postings.

I don't actually have one here, so that wouldn't help you much I'm
afraid.

Ah -- RFC1149 again, Bent?

Again? Have you been imagining things again?

Must have gotten disconnected for posting
too much off-topic drivel to cljp, and become *really* desperate. ;)

Ah, you /did/ change the subject, didn't you?

Predictable, but at least you did give us advance warning.

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.