Recently started learning lisp, firstly, I have to admit I really do
love all the paranthesis. But there are other features of my old
language that I do miss.

Is lisp frequently used to develop web pages, if so can I get a easy
to use standalone install to do this? (e.g Wampserver for PHP)

Coming from netbeans I am finding emacs a bit, difficult. I really
don't like having to press the Ctrl button to do almost anything. Is
there a netbeanseque IDE for lisp?

I am really interested in lisp, but when learning a new language
worrying about an IDE should be the least of my worries. Maybe a lisp
plugin for netbeans? xD

On the whole I really like lisp and am eager to learn more.

Thanks for your time

Anti Quark <photonpackets@gmail.com> writes:


> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

Yes. http://www.cliki.net/admin/search?words=web


> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. 

You should map Control the key where Caps Lock usually is. (ie. on the
left of [A]).


> Is there a netbeanseque IDE for lisp?
>
> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries. Maybe a lisp
> plugin for netbeans? xD

You're the netbeans specialist here. (I don't even know what it is).
You're a programmer.  What are you waiting to write a lisp plugin for
netbeans?



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 05/07/2012 12:44 PM, Anti Quark wrote:
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I think most lisp developers prefer to write web-interfaces for their 
software.
The best web server is probably hunchentoot
http://weitz.de/hunchentoot/
Though could download it from there the best way is to use quicklisp 
http://www.quicklisp.org/beta/
In the Lisp REPL write (ql:quickload "hunchentoot")

It's a bit quirky if you are used to PHP, but if you know web 
programming (CGI clients in all forms.. including PHP) then you should 
pick it up pretty quick.

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?
>

There is no netbean, but there is a Eclipse plug-in called Cusp
http://bitfauna.com/projects/cusp/

Most people just use Emacs with SLIME though as it over all has the best 
Lisp interface.

> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I'm not sure what do you mean by 'standalone', but it's very easy to run 
Hunchentoot web server -- it requires like three lines of code.
You can install it with one command if you use quicklisp (and you should).

> Coming from netbeans I am finding emacs a bit, difficult.

LOL. I had to use netbeans today and I find it a bit difficult. Well, 
not so much difficult as slow, verbose and buggy.

E.g. Netbeans 6.8 wasn't able to build project edited in Netbeans 7 
until I manually deleted file and restarted IDE. The fuck?

> I really
> don't like having to press the Ctrl button to do almost anything.

You don't need to. Ctrl is totally unnecessary for writing code and 
using REPL. Emacs isn't different from any other editor when you use CUA 
mode.

You only need Ctrl to do things like compile code. Particularly, C-c 
C-c. But it's really easy to press it, isn't it? C-c is a common 
keybinding for copy/past, BTW.
Anyway, if you're more comfortable with other keybinding you can rebind it.
Or you can use menu. Really, I don't see how it's so much different from 
netbeans.

> Is
> there a netbeanseque IDE for lisp?

No. It's a better idea to configure Emacs up to your taste.

What particular things bug you, aside from "it doesn't look like netbeans"?

Copy/paste? Yes, it is different, and thus inconvenient, but you can fix 
it via CUA mode. Full CUA messes up C-x which is frequently used, but if 
you don't mind using Ctrl-Ins, Shift-Ins, Shift-Del instead of C-c, C-v, 
C-x there is also 'partial CUA' which works just fine.

That said, you can try commercial Lisp IDEs -- Allegro CL, Lispworks. 
For learning, they are fine.

> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries.

REPL is an important part of Common Lisp experience, and you have to use 
somewhat different workflow to utilize it efficiently.
Working with Lisp might be different even if IDE looks like Netbeans.

It's better to embrace it than to fight it.

Alex Mizrahi <alex.mizrahi@gmail.com> writes:

> You don't need to. Ctrl is totally unnecessary for writing code and
> using REPL. Emacs isn't different from any other editor when you use
> CUA mode.
>
> You only need Ctrl to do things like compile code. Particularly, C-c 
> C-c. But it's really easy to press it, isn't it? 

You don't need to use control in emacs.

Type M-x slime-compile-defun RET instead of C-c C-c (or use the menu as
suggested by C-h f slime-compile-defun RET

You don't need to use control for "cut" "copy" and "paste" in emacs.
Use instead:

M-x kill-region RET              ("cut")
M-w or M-x kill-ring-save RET    ("copy")
M-x yank RET                     ("paste")


> C-c is a common keybinding for copy/past, BTW.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 07/05/2012 6:44 AM, Anti Quark wrote:
> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)
>
> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?

Clojure to the rescue then. It's a Lisp that runs on the JVM, has a lot 
of web-dev library support (and how! Server-side, client-side, DB 
interface, you name it. And can be deployed at Hadoop fairly 
painlessly.), and has a netbeans plugin (Enclojure) available.

On the other hand, it's not Common Lisp, so if your Lisp absolutely has 
to be Common Lisp, you're out of luck there.

Anti Quark <photonpackets@gmail.com> writes:

> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I'm currently using Common Lisp to develop a small website interacting
with a PostgreSQL database and so far it's way better than doing it in
PHP.

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?

It could be worse, you could have to click-click-click everywhere to do
anything though you can still do it if you wish to. Moreover, you can
replace the CapsLock key by Control to make your life better.

> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries. Maybe a lisp
> plugin for netbeans? xD

Learning the basic of emacs isn't a big deal at all, you can do the
tutorial (C-h t) in 20min or less and then your on your way. Plus, there
is already two or three tutorials which explains how to install SBCL +
SLIME. Oh, and you should look at paredit - an emacs minor mode - so you
don't have to worry about the parentheses.

> Learning the basic of emacs isn't a big deal at all, you can do the
> tutorial (C-h t) in 20min or less and then your on your way.

One which teaches to use C-p, C-b and so on instead of cursor keys?
Oh please. This *is* why people think that Emacs is old/hard to 
learn/weird/obsolete.

There are only a couple of useful things described there, rest is 
obsolete junk.

>> You only need Ctrl to do things like compile code. Particularly, C-c
>> C-c. But it's really easy to press it, isn't it?

> You don't need to use control in emacs.

Technically speaking, yes.

I was talking about what I use myself, though. Going through 
command/menu each time would be sort of painful.

Although I didn't bother to learn slime-compile-file keybinding for 
quite a while: I do not compile files that often.

People just overestimate how much they need to learn. There is just 
handful of commands which are actually required to do development 
comfortably.

However Emacs tutorial was written in times when cursor keys were not 
common on keyboards and was not updated since. No wonder that newbies 
find emacs difficult.

Alex Mizrahi <alex.mizrahi@gmail.com> writes:

>> Learning the basic of emacs isn't a big deal at all, you can do the
>> tutorial (C-h t) in 20min or less and then your on your way.
>
> One which teaches to use C-p, C-b and so on instead of cursor keys?
> Oh please. This *is* why people think that Emacs is old/hard to
> learn/weird/obsolete.
>
> There are only a couple of useful things described there, rest is
> obsolete junk.

Once you understand that it's painless and faster to use the keys on or
around the home row it makes sense. Using the cursor keys is like using
the mouse, you have to leave your home row.

--=-=-=
Content-Type: text/plain

Alex Mizrahi <alex.mizrahi@gmail.com> writes:
>> Learning the basic of emacs isn't a big deal at all, you can do the
>> tutorial (C-h t) in 20min or less and then your on your way.
>
> One which teaches to use C-p, C-b and so on instead of cursor keys?
> Oh please. This *is* why people think that Emacs is old/hard to
> learn/weird/obsolete.
>
> There are only a couple of useful things described there, rest is
> obsolete junk.

Right, so you move your right hand to the arrow keys every time you need
to move in a buffer? Or maybe the mouse? How cute.

Rupert

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iJwEAQECAAYFAk+pEEcACgkQRtd/pJbYVoZr+gP/X6KW4WZhLqxhuEOSitddulZF
9UR5yF8t9aIu82PvGups+hcNS0piDA+VUtJif1XUTgbqoTBQ+iD0WxC56ua1wCm5
L/63mo0unlt8Yh+6N5Z4yLJyLY9DWr7x21ed5jEwOgN1fu0GThP5/86Vtau7yw5z
LFtEKuvbU8XRhhkNnZ8=
=IFDa
-----END PGP SIGNATURE-----
--=-=-=--

On 2012-05-08 11:27:11 +0000, Alex Mizrahi said:

> One which teaches to use C-p, C-b and so on instead of cursor keys?

Yes, one for people who can type.  Quaint, I know.

On May 8, 2:23=A0pm, Rupert Swarbrick <rswarbr...@gmail.com> wrote:
> Alex Mizrahi <alex.mizr...@gmail.com> writes:
> >> Learning the basic of emacs isn't a big deal at all, you can do the
> >> tutorial (C-h t) in 20min or less and then your on your way.
>
> > One which teaches to use C-p, C-b and so on instead of cursor keys?
> > Oh please. This *is* why people think that Emacs is old/hard to
> > learn/weird/obsolete.
>
> > There are only a couple of useful things described there, rest is
> > obsolete junk.
>
> Right, so you move your right hand to the arrow keys every time you need
> to move in a buffer? Or maybe the mouse? How cute.

I do, for instance. I even use the mouse from time to time (especially
if it's actually my laptop's touchpad). I've been using Emacs for
years, but never invested much time in learning complex commands or
changing my (undoubtedly poor) typing habits. Most of the time I spend
in front of Emacs, anyway, is really spent thinking, so I don't think
improving my typing speed of a few %s will buy me anything. Even if a
pro typist would be faster with C-foo than with arrow keys, I don't
want to spend time becoming a pro typist in the first place, and I
suspect most programmers are like me in that regard - especially those
that, like me, came to Emacs after other editors (Notepad++, Eclipse,
whatever).

So, yes, from the point of view of a little-more-than-newbie with
Emacs, I do think the tutorial is not fit for most Emacs newbies, as
it wasn't for me. I find Aquamacs' choice of using familiar
Command-... shortcuts to be most sensible; even if when I use it I
keep using C-x C-s, C-w, M-w, C-y, C-_ etc., I don't have any trouble
"teaching" a coworker how to use it. On non-Macs, keyboards often have
rarely used keys that can be used in place of Command for a similar
effect, for example there are often two distinct Control keys, Caps
Lock, and a Windows key which is even placed more or less where
Command is on Mac keyboards.

Alessio

Alessio Stalla <alessiostalla@gmail.com> writes:

> I do, for instance. I even use the mouse from time to time (especially
> if it's actually my laptop's touchpad). I've been using Emacs for
> years, but never invested much time in learning complex commands or
> changing my (undoubtedly poor) typing habits. Most of the time I spend
> in front of Emacs, anyway, is really spent thinking, so I don't think
> improving my typing speed of a few %s will buy me anything. Even if a
> pro typist would be faster with C-foo than with arrow keys, I don't
> want to spend time becoming a pro typist in the first place, and I
> suspect most programmers are like me in that regard - especially those
> that, like me, came to Emacs after other editors (Notepad++, Eclipse,
> whatever).

 http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

>> There are only a couple of useful things described there, rest is
>> obsolete junk.

> Once you understand that it's painless and faster to use the keys on or
> around the home row it makes sense.

1. It's actually painful to hold ctrl all the time. Even if it's on caps 
lock. The thing is, you press it with one finger, little finger that is.

2. It's painful to switch between different keybindings. I'm not going 
to spend 100% of my time in Emacs. I also use browser, I use other 
people's computers and so on. I want to use same keybindings even if it 
is a tiny bit inefficient. After all, I don't switch between moving and 
typing all the time.

3. I can go from letter keys to cursor keys without moving a hand on my 
laptop. On a larger keyboard it takes fractions of second.

> Using the cursor keys is like using
> the mouse, you have to leave your home row.

No, it's not. It takes order of magnitude less time.

>> One which teaches to use C-p, C-b and so on instead of cursor keys?
> Yes, one for people who can type. Quaint, I know.

Wow, your programming is bottlenecked by your typing speed?

> Right, so you move your right hand to the arrow keys every time you need
> to move in a buffer?

Yeah, but believe me: when you're used to it hands really do it faster 
than you can think.
I touch type, maybe not as fast as pro typists, but fast enough for my 
purposes. OTOH I don't need to rely on 'home row', I can move my hands 
freely, reaching any keys in and combinations.

> Or maybe the mouse?

Mouse is a completely different story, precise positioning of mouse 
without taking feedback into account is extremely hard. So it switching 
to mouse is order of magnitude slower than reaching some keys. But for 
some things mouse is ok.

> How cute.

What isn't cute is RSI you get from typing too much. Maybe you should 
learn how to organize your workflow in such a way that milliseconds 
spent on moving fingers from home row to cursor keys will be absolutely 
insignificant.

I wonder what do you guys do so that you need to type whole day long.

>   http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html

Maybe if Yegge typed slower his essays would be shorter and more readable.

But, anyway, there isn't really a need to learn touch typing -- in a few 
decades of intensive typing you can pick it up automatically. Not just 
letters but all keys you use.

On 08/05/2012 2:58 PM, Alex Mizrahi wrote:
> 3. I can go from letter keys to cursor keys without moving a hand on my
> laptop. On a larger keyboard it takes fractions of second.
>
>> Using the cursor keys is like using
>> the mouse, you have to leave your home row.
>
> No, it's not. It takes order of magnitude less time.

Where the hell is your mouse? Floating out there among the moons of 
Jupiter? Mine is only about as far beyond the cursor keys as those are 
beyond the alphabetic keys.

On 2012-05-08 18:29:47 +0000, Pascal J. Bourguignon said:

> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html 
> 

When I rule the world[*] one of the first reforms (after all the 
obvious tshooting-every-third-person stuff) is going to be to abolish 
all the stupid "IT" courses that get taught in school and forcing 
people to learn to type, because that's actually a useful skill.

[*] well, of cours, I already technically do, I just made the mistake 
of delegating too much so I now have even more stringing-people-up 
stuff to do.

On 2012-05-08 18:58:29 +0000, Alex Mizrahi said:

> 2. It's painful to switch between different keybindings. I'm not going 
> to spend 100% of my time in Emacs. I also use browser, I use other 
> people's computers and so on. I want to use same keybindings even if it 
> is a tiny bit inefficient. After all, I don't switch between moving and 
> typing all the time.

Your computer doesn't have emacs keybindings everythere?  How quaint.

On 2012-05-08 19:01:37 +0000, Alex Mizrahi said:
> 
> Wow, your programming is bottlenecked by your typing speed?

The same way my ability to do physics would be bottlenecked if I could 
not do arithmetic reliably in my head, yes.

>>> Using the cursor keys is like using
>>> the mouse, you have to leave your home row.

>> No, it's not. It takes order of magnitude less time.

> Where the hell is your mouse? Floating out there among the moons of
> Jupiter? Mine is only about as far beyond the cursor keys as those are
> beyond the alphabetic keys.

It's not so much about distance to mouse as about nature of mouse 
movement -- basically, you cannot position cursor without watching it 
move. (Unless you're a Counter Strike pro who can headshot as soon as he 
sees something.) A process of watching cursor move and coordinating your 
hand is much slower than just sending commands to hands. It takes ~100 
ms just to see something, latency of human sensory input is significant. 
The only way you can do something quickly is to 'buffer' command to 
muscles, but it's not possible with actions which require feedback.

>> 2. It's painful to switch between different keybindings. I'm not going
>> to spend 100% of my time in Emacs. I also use browser, I use other
>> people's computers and so on. I want to use same keybindings even if
>> it is a tiny bit inefficient. After all, I don't switch between moving
>> and typing all the time.

> Your computer doesn't have emacs keybindings everythere? How quaint.

I have more-or-less the same keybindings in all programs, including Emacs.

I wonder what do you do when you have to use somebody else's computer, 
e.g. if they ask you to fix it. Panic?

Alex Mizrahi <alex.mizrahi@gmail.com> writes:

> I wonder what do you do when you have to use somebody else's computer,
> e.g. if they ask you to fix it. Panic?

Each time my wife wants me to proof read something she has written in
Word on her machine, I panic. It's not that I never use anything else
than Emacs and Emacs-alikes, but whenever I use a wysiwig text editor
myself, I use Pages on the mac. Pages is a Cocoa program, and thus
understands the most basic Emacs control-key-bindings, which are hard
wired into my spine. But I still struggle with the fact that I have
assigned meta to the left command key on my mac, and thus frequently
quit programs when I feel like doing a "M-q" to fill a paragraph :-)
-- 
  (espen)

>> Wow, your programming is bottlenecked by your typing speed?

> The same way my ability to do physics would be bottlenecked if I could
> not do arithmetic reliably in my head, yes.

Well, I never was good with arithmetic, but I really excelled in physics 
in school: I won a number of city-wide physics competitions for children 
of my age (and it was a fairly large city full of tech schools, so there 
was some competition).

So I guess you meant that arithmetic is pretty much irrelevant for 
solving physics problems just like typing is irrelevant for programming :)

That said, I agree that being very slow at typing (or not knowing tools) 
might make programming very slow and uncomfortable. (Depending on a kind 
of programming, of course -- some complex algorithms might be developed 
on paper or even in one's head without any typing at all.)
But past some point, returns diminish to the point of becoming totally 
irrelevant.

I even bought IBM Model M keyboard, but I'm afraid the only real effect 
is that it sounds way louder and cooler than rubber dome keyboards.
I can only hope this sound stimulates brain activity or something...

Tim Bradshaw <tfb@tfeb.org> writes:

> On 2012-05-08 18:29:47 +0000, Pascal J. Bourguignon said:
>
>> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html 
>>
>
> When I rule the world[*] one of the first reforms (after all the
> obvious tshooting-every-third-person stuff) is going to be to abolish
> all the stupid "IT" courses that get taught in school and forcing
> people to learn to type, because that's actually a useful skill.

Well soon enough it won't be that useful.

http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 2012-05-09 13:29:31 +0000, Alex Mizrahi said:

> I wonder what do you do when you have to use somebody else's computer, 
> e.g. if they ask you to fix it. Panic?

Espen answered this better than I can.

On 2012-05-09 15:12:59 +0000, Alex Mizrahi said:

> So I guess you meant that arithmetic is pretty much irrelevant for 
> solving physics problems just like typing is irrelevant for programming 
> :)

No.  You might be able to get away at school level without arithmetic 
(by which I really mean "being really fluent with numbers") but you get 
screwed later on.

I know this because at a slightly different level it's what happened to 
me: I was lazy, didn't practice enough boring mathematical methods 
stuff, and that lack of fluency came back and bit me later.

Alex Mizrahi <alex.mizrahi@gmail.com> writes:

>>>> Using the cursor keys is like using
>>>> the mouse, you have to leave your home row.
>
>>> No, it's not. It takes order of magnitude less time.
>
>> Where the hell is your mouse? Floating out there among the moons of
>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>> beyond the alphabetic keys.
>
> It's not so much about distance to mouse as about nature of mouse
> movement -- basically, you cannot position cursor without watching it
> move. (Unless you're a Counter Strike pro who can headshot as soon as
> he sees something.) A process of watching cursor move and coordinating
> your hand is much slower than just sending commands to hands. It takes
> ~100 ms just to see something, latency of human sensory input is
> significant. The only way you can do something quickly is to 'buffer'
> command to muscles, but it's not possible with actions which require
> feedback.

I'd suggest a trackIR to move the mouse and click.
http://www.naturalpoint.com/trackir/

With 6 degrees of freedom, you can use yaw and pitch for mouse
movement, forward for click, left for middle click, right for right
click, and you have roll remaining for your own binding.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 2012-05-09, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> Well soon enough it won't be that useful.
>
> http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html

Not if you're someone who types very fast, but doesn't exhibit brainwaves.

On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>> Using the cursor keys is like using
>>>> the mouse, you have to leave your home row.
>
>>> No, it's not. It takes order of magnitude less time.
>
>> Where the hell is your mouse? Floating out there among the moons of
>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>> beyond the alphabetic keys.
>
> It's not so much about distance to mouse as about nature of mouse
> movement -- basically, you cannot position cursor without watching it
> move. (Unless you're a Counter Strike pro who can headshot as soon as he
> sees something.) A process of watching cursor move and coordinating your
> hand is much slower than just sending commands to hands. It takes ~100
> ms just to see something, latency of human sensory input is significant.
> The only way you can do something quickly is to 'buffer' command to
> muscles, but it's not possible with actions which require feedback.

ALL actions require feedback! I don't want to blindly issue commands to 
my computer while not even looking to see if it's gone into Sorceror's 
Apprentice mode deleting the wrong files or something.

Besides that, aren't you being a bit inconsistent? First, touch typing 
is so great because you can keep your eyes on the screen and see what 
the hell you're doing, in context -- then mousing is awful because you 
must keep your eyes on the screen?

On 2012-05-09, Jumpin' Jehoshaphat <jj1058672395@gmail.com> wrote:
> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>>> Using the cursor keys is like using
>>>>> the mouse, you have to leave your home row.
>>
>>>> No, it's not. It takes order of magnitude less time.
>>
>>> Where the hell is your mouse? Floating out there among the moons of
>>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>>> beyond the alphabetic keys.
>>
>> It's not so much about distance to mouse as about nature of mouse
>> movement -- basically, you cannot position cursor without watching it
>> move. (Unless you're a Counter Strike pro who can headshot as soon as he
>> sees something.) A process of watching cursor move and coordinating your
>> hand is much slower than just sending commands to hands. It takes ~100
>> ms just to see something, latency of human sensory input is significant.
>> The only way you can do something quickly is to 'buffer' command to
>> muscles, but it's not possible with actions which require feedback.
>
> ALL actions require feedback! I don't want to blindly issue commands to 

This may be true, but not all actions have to wait for each piece of feedback
individually before proceeding.

The GUI requires instantaneous real-time feedback, which is different from
*eventual* feedback that the right thing was done as a result of
a sequence of actions.

You cannot queue mouse movements the way you can queue keystrokes.

For instance, if a GUI is lagged, you cannot simply go through the motions
of clicking on something to obtain a context menu, and making a selection
from that menu, and then watch as those actions take place later.

With a keyboard, you can do the equivalent of that, within the limits of your
typing accuracy.

Even if the machine you're working with is sharply responsive, there is still
lag: that in your brain.

Consciousness requires about 500 ms of processing (Benjamin Libet's "Half
Second Delay"). Whatever you think is happening "now" on your computer screen
actually happened about half a second ago.

To conquer the delay, you have to train your subsconscious "device drivers" to
handle events sooner, before consciousness takes place. 

Anything that you can react to faster than 500 ms is done without
consciousness. If you react to something in 50 ms, then 450 ms later, you
become aware of what happened, and of course you convince yourself that you
consciously meant to do that. (In fact, you only meant to do that in the
sense that in the past you trained yourself to respond to that event in that
way; that's when the conscious decision was made.)

You will never eliminate all the delay in an inaccurate procedure that requires
corrective feedback.  Not to the extent that you can eliminate it in a
procedure that is mostly pure output.

On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
> On 2012-05-09, Jumpin' Jehoshaphat<jj1058672395@gmail.com>  wrote:
>> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>>>> Using the cursor keys is like using
>>>>>> the mouse, you have to leave your home row.
>>>
>>>>> No, it's not. It takes order of magnitude less time.
>>>
>>>> Where the hell is your mouse? Floating out there among the moons of
>>>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>>>> beyond the alphabetic keys.
>>>
>>> It's not so much about distance to mouse as about nature of mouse
>>> movement -- basically, you cannot position cursor without watching it
>>> move. (Unless you're a Counter Strike pro who can headshot as soon as he
>>> sees something.) A process of watching cursor move and coordinating your
>>> hand is much slower than just sending commands to hands. It takes ~100
>>> ms just to see something, latency of human sensory input is significant.
>>> The only way you can do something quickly is to 'buffer' command to
>>> muscles, but it's not possible with actions which require feedback.
>>
>> ALL actions require feedback! I don't want to blindly issue commands to
>
> This may be true, but not all actions have to wait for each piece of feedback
> individually before proceeding.

They usually do, if you want to avoid and/or recover from mistakes.

Not only that, when actions can be queued up without feedback in between 
then those actions should probably be automated with a script, not 
entered manually.

> For instance, if a GUI is lagged, you cannot simply go through the motions
> of clicking on something to obtain a context menu, and making a selection
> from that menu, and then watch as those actions take place later.

These aren't the days of 300 baud modem links to 20-hops-away mainframes 
anymore. Your system shouldn't be lagged, especially not if it's one 
that even has a functioning mouse. If it is, you need to nice some 
processes or something.

> With a keyboard, you can do the equivalent of that, within the limits of your
> typing accuracy.

And as likely as not end up with something like "The quick brown fox jlog".

> Even if the machine you're working with is sharply responsive, there is still
> lag: that in your brain.

If that's a problem, the only solution is to automate the task. It will 
impede ANY manual task. If the manual task doesn't really require 
feedback it doesn't really need to be manual does it?

> To conquer the delay, you have to train your subsconscious "device drivers" to
> handle events sooner, before consciousness takes place.

And this, you claim, is only possible with the keyboard? Then explain 
people with much faster reaction times playing first person shooters. 
Better yet, explain why the number one rule for proficiency in those 
that the good players will tell you over and over again, unanimously, is 
"use the mouse and not only the keyboard!".

> You will never eliminate all the delay in an inaccurate procedure that requires
> corrective feedback.  Not to the extent that you can eliminate it in a
> procedure that is mostly pure output.

If it's pure output it's either "naturally" typing something you thought 
up or else it's something that you can automate. If it's data entry it's 
typing. If it's command entry it's scriptable.

Jumpin' Jehoshaphat <jj1058672395@gmail.com> writes:

> On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
>> For instance, if a GUI is lagged, you cannot simply go through the motions
>> of clicking on something to obtain a context menu, and making a selection
>> from that menu, and then watch as those actions take place later.
>
> These aren't the days of 300 baud modem links to 20-hops-away
> mainframes anymore. Your system shouldn't be lagged, especially not if
> it's one that even has a functioning mouse. If it is, you need to nice
> some processes or something.

No indeed.  But we're still at the time when big companies are made by
convincing people that they need to buy a new computer (or phone or pad)
every year, and this is done by providing for "free" "upgrades" of the
system that are more and more bloated, and provide slower and slower
reaction time.  Lag indeed.


>> With a keyboard, you can do the equivalent of that, within the limits of your
>> typing accuracy.
>
> And as likely as not end up with something like "The quick brown fox jlog".

Which is why you use an editor and not just cat(1).



> If it's pure output it's either "naturally" typing something you
> thought up or else it's something that you can automate. If it's data
> entry it's typing. If it's command entry it's scriptable.

And how do you enter the script?  What do you think we're doing all day
long?  We're PROGRAMMERS!



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 2012-05-10, Jumpin' Jehoshaphat <jj1058672395@gmail.com> wrote:
> On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
>> On 2012-05-09, Jumpin' Jehoshaphat<jj1058672395@gmail.com>  wrote:
>>> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>>>>> Using the cursor keys is like using
>>>>>>> the mouse, you have to leave your home row.
>>>>
>>>>>> No, it's not. It takes order of magnitude less time.
>>>>
>>>>> Where the hell is your mouse? Floating out there among the moons of
>>>>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>>>>> beyond the alphabetic keys.
>>>>
>>>> It's not so much about distance to mouse as about nature of mouse
>>>> movement -- basically, you cannot position cursor without watching it
>>>> move. (Unless you're a Counter Strike pro who can headshot as soon as he
>>>> sees something.) A process of watching cursor move and coordinating your
>>>> hand is much slower than just sending commands to hands. It takes ~100
>>>> ms just to see something, latency of human sensory input is significant.
>>>> The only way you can do something quickly is to 'buffer' command to
>>>> muscles, but it's not possible with actions which require feedback.
>>>
>>> ALL actions require feedback! I don't want to blindly issue commands to
>>
>> This may be true, but not all actions have to wait for each piece of feedback
>> individually before proceeding.
>
> They usually do, if you want to avoid and/or recover from mistakes.
>
> Not only that, when actions can be queued up without feedback in between 
> then those actions should probably be automated with a script, not 
> entered manually.

Right, and that script should be written by clicking the mouse on various
locations of picture of a QWERTY keyboard to avoid any queuing prior
to that script being run. :)

>> For instance, if a GUI is lagged, you cannot simply go through the motions
>> of clicking on something to obtain a context menu, and making a selection
>> from that menu, and then watch as those actions take place later.
>
> These aren't the days of 300 baud modem links to 20-hops-away mainframes 
> anymore. Your system shouldn't be lagged, especially not if it's one 
> that even has a functioning mouse. If it is, you need to nice some 
> processes or something.

And then there is networking.

>> With a keyboard, you can do the equivalent of that, within the limits of your
>> typing accuracy.
>
> And as likely as not end up with something like "The quick brown fox jlog".

In mouse terms, the accuracy of this is astronomical.

>> Even if the machine you're working with is sharply responsive, there is still
>> lag: that in your brain.
>
> If that's a problem, the only solution is to automate the task. It will 
> impede ANY manual task. If the manual task doesn't really require 
> feedback it doesn't really need to be manual does it?

Writing a novel is just so much typing; so automate it!

Fixing a bug in code: automate it.

An existence proof would go a long way here.

If what I do could be automated, it would be. :)

>> To conquer the delay, you have to train your subsconscious "device drivers" to
>> handle events sooner, before consciousness takes place.
>
> And this, you claim, is only possible with the keyboard? Then explain 

Absolutely.

> people with much faster reaction times playing first person shooters. 
> Better yet, explain why the number one rule for proficiency in those 
> that the good players will tell you over and over again, unanimously, is 
> "use the mouse and not only the keyboard!".

Because the way the keyboard control behaves in those games is like a very
dumb mouse.

Yes, a mouse is better than using cursor keys to implement a low-level
simulation of a mouse.

Shooter games do not not have an efficient keyboard interface for easy
selection of targets, because ... doh ... that would, like, be cheating?

An efficient keyboard client for a first person shooter would identify the
vulnerable points of several targets in the visual field and simply let you
[Tab] through them. Or show little numbers or letters next to them so you could
select which ever you want: random access. Moreover, only your foes would be
thus flagged, never your friends.

So imagine entering a scene. There are two of your friends and three foes.
Little targets appear on the heads of the foes, labelled A, B, and C.

All you have to do is type A, B, and C to select each one and shoot.

Moreover, suppose you can just type ABC very fast, and the shooting then
happens later: your crosshairs move to A, shoot. Then to B, shoot. Then to C.
Shoot.

You could play this game with your eyes closed. Just position yourself with
your back in a corner, close your eyes, and type ABC ABC ABC ...

Likewise, the mouse interface of these games could be better also, if the goal
was efficient targetting. It could have "snap to target", the way editors
for graphics have "snap to point".

Freehand graphics: that's one area where the mouse is handy. But for actually
drawing a decent shape, it's horrible. You need a tablet with a stylus.  The
mouse is not strictly better for all 2D stuff. Many kinds of CAD tasks work
better with a keyboard, whenever there is a lot of horizontal and vertical
alignment, and a regular grid.  A mouse brings next to nothing to PCB layout
for instance.

On 09/05/2012 9:25 PM, Pascal J. Bourguignon wrote:
> Jumpin' Jehoshaphat<jj1058672395@gmail.com>  writes:
>
>> On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
>>> For instance, if a GUI is lagged, you cannot simply go through the motions
>>> of clicking on something to obtain a context menu, and making a selection
>>> from that menu, and then watch as those actions take place later.
>>
>> These aren't the days of 300 baud modem links to 20-hops-away
>> mainframes anymore. Your system shouldn't be lagged, especially not if
>> it's one that even has a functioning mouse. If it is, you need to nice
>> some processes or something.
>
> No indeed.  But we're still at the time when big companies are made by
> convincing people that they need to buy a new computer (or phone or pad)
> every year, and this is done by providing for "free" "upgrades" of the
> system that are more and more bloated, and provide slower and slower
> reaction time.  Lag indeed.

If you're dumb enough to use Windoze, sure.

>>> With a keyboard, you can do the equivalent of that, within the limits of your
>>> typing accuracy.
>>
>> And as likely as not end up with something like "The quick brown fox jlog".
>
> Which is why you use an editor and not just cat(1).

?? It's not the editor, it's the OS. If more than around 16-32 
keystrokes get backlogged, depending on the OS, some tend to get dropped 
instead of sent to the application.

>> If it's pure output it's either "naturally" typing something you
>> thought up or else it's something that you can automate. If it's data
>> entry it's typing. If it's command entry it's scriptable.
>
> And how do you enter the script?  What do you think we're doing all day
> long?  We're PROGRAMMERS!

Entering a script is something that's naturally done by keyboard rather 
than by mouse. The discussion was manually entering commands, not code 
or data.

On 2012-05-10, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> Jumpin' Jehoshaphat <jj1058672395@gmail.com> writes:
>> If it's pure output it's either "naturally" typing something you
>> thought up or else it's something that you can automate. If it's data
>> entry it's typing. If it's command entry it's scriptable.
>
> And how do you enter the script?  What do you think we're doing all day
> long?  We're PROGRAMMERS!

Why, drag and drop. You have icons on the desktop for all possible characters,
and then you just drag them one by one to the script icon.

-- 
If you ever need any coding done, I'm your goto man!

On 10/05/2012 12:00 AM, Kaz Kylheku wrote:
> On 2012-05-10, Jumpin' Jehoshaphat<jj1058672395@gmail.com>  wrote:
>> Not only that, when actions can be queued up without feedback in between
>> then those actions should probably be automated with a script, not
>> entered manually.
>
> Right, and that script should be written by clicking the mouse on various
> locations of picture of a QWERTY keyboard

Not unless you're stuck developing on a phone or a pad.

>>> For instance, if a GUI is lagged, you cannot simply go through the motions
>>> of clicking on something to obtain a context menu, and making a selection
>>> from that menu, and then watch as those actions take place later.
>>
>> These aren't the days of 300 baud modem links to 20-hops-away mainframes
>> anymore. Your system shouldn't be lagged, especially not if it's one
>> that even has a functioning mouse. If it is, you need to nice some
>> processes or something.
>
> And then there is networking.

What does that have to do with the responsiveness of the local software 
(whether browser, NNTP client, etc. or nonnetworked software) to mouse 
input?

Besides, if the network is slow and that's making a browser web app 
slow, it's going to be impossible to use without waiting whether you use 
the keyboard or the mouse. Until the server response to the previous 
input is received and the browser loads new stuff, it won't respond to a 
keystroke as you'd expect. You can't queue up keystroke commands to web 
apps. (Typing into a form on the webpage, sure, but that's typing into a 
local buffer the entire contents of which are sent to the server in one 
shot when you hit "send" afterward.)

>>> With a keyboard, you can do the equivalent of that, within the limits of your
>>> typing accuracy.
>>
>> And as likely as not end up with something like "The quick brown fox jlog".
>
> In mouse terms, the accuracy of this is astronomical.

I don't care. It's still not good enough; ergo, the smart thing to do 
with an unresponsive system is wait.

>>> Even if the machine you're working with is sharply responsive, there is still
>>> lag: that in your brain.
>>
>> If that's a problem, the only solution is to automate the task. It will
>> impede ANY manual task. If the manual task doesn't really require
>> feedback it doesn't really need to be manual does it?
>
> Writing a novel is just so much typing; so automate it!

That's data entry, not command inputs.

> Fixing a bug in code: automate it.

That's data entry, not (immediately executed) command inputs.

>>> To conquer the delay, you have to train your subsconscious "device drivers" to
>>> handle events sooner, before consciousness takes place.
>>
>> And this, you claim, is only possible with the keyboard? Then explain
>> people with much faster reaction times playing first person shooters.
>> Better yet, explain why the number one rule for proficiency in those
>> that the good players will tell you over and over again, unanimously, is
>> "use the mouse and not only the keyboard!".
>
> Because the way the keyboard control behaves in those games is like a very
> dumb mouse.

Feel free to suggest a superior keyboard interface then. One that 
wouldn't be blatant cheating, of course.

> Likewise, the mouse interface of these games could be better also, if the goal
> was efficient targetting. It could have "snap to target", the way editors
> for graphics have "snap to point".

Some of them do, on the lowest difficulty setting; the crosshair may not 
snap but the shot still might if it's aimed accurately enough.

Of course, only wusses play on those difficulty levels. ;)

> Freehand graphics: that's one area where the mouse is handy. But for actually
> drawing a decent shape, it's horrible. You need a tablet with a stylus.  The
> mouse is not strictly better for all 2D stuff. Many kinds of CAD tasks work
> better with a keyboard, whenever there is a lot of horizontal and vertical
> alignment, and a regular grid.  A mouse brings next to nothing to PCB layout
> for instance.

Wrong again. You need snap-to and similar features, as well as ways to 
procedurally generate exact shapes such as circles, ellipses, and 
regular polygons. On the other hand, it's a lot faster and more 
intuitive to position graphics objects with a mouse than by holding down 
some direction key and watching it crawl across the screen, plus having 
the fun of figuring out how the hell to select something -- 
tab/shift-tab or similar has problems with imposing an arbitrary and 
usually rather unpredictable sequencing on 2D-disseminated things that 
probably aren't neatly arranged in reading order on a grid like dialog 
box controls; whereas some sort of control-arrow-key type deal for 
move-to-next-below, move-to-next-left, etc. has its own problems when 
there's a selected object, a close by object off at a 45 degree angle or 
so, and maybe a more distant one in an adjacent cardinal direction as 
well. The only situation where there's a clear advantage over a mouse is 
to select an object completely covered by another object, or an object 
so thin that it's nigh-impossible to click on it, or so small you can't 
click on it without clicking a control handle that does something other 
than just select it. And then what you want it an alternate selection 
mechanism *in addition to* standard click-selection. Such as a 
(keyboard-and-mouse-enabled) object list you can bring up and choose 
from, or a key command to cycle the selection through everything in 
Z-order that overlaps the pixel beneath the pointer, or something.

* Jumpin' Jehoshaphat <jofenu$3vm$2@speranza.aioe.org> :
Wrote on Thu, 10 May 2012 00:04:14 -0400:

|> No indeed.  But we're still at the time when big companies are made
|> by convincing people that they need to buy a new computer (or phone
|> or pad) every year, and this is done by providing for "free"
|> "upgrades" of the system that are more and more bloated, and provide
|> slower and slower reaction time.  Lag indeed.
|
| If you're dumb enough to use Windoze, sure.

BS. As far as OS/Distro/Software strategies go Linux, Macs, Windows etc.
are indistinguishable in this regard.  Microsoft just happened to
pioneer the revenue model, stanford capital has appropriated, (as with
ajax etc), if you know any exceptions I'd be glad to hear about it.

Most of the time the software is multiplatform, like AOL/Firefox. All
the paychecks in this business are either to breed the next generation
of consumers, or to introduce said bloat and inefficiencies in the
platform that can eventually be monetized. --- Madhu

>> So I guess you meant that arithmetic is pretty much irrelevant for
>> solving physics problems just like typing is irrelevant for
>> programming :)

> No. You might be able to get away at school level without arithmetic (by
> which I really mean "being really fluent with numbers") but you get
> screwed later on.

Huh? At school level people work with concrete numbers, but on more 
advanced level there are barely any numbers in formulas.

I don't know much above physics above school level, but I've got M.Sc. 
applied math degree without being particularly good at arithmetics.
We had only a couple of courses which actually involved arithmetics, and 
teachers admitted that they are not just computerized enough.
(Later I've actually developed a program which allowed students to solve 
concrete linear optimization problems with numbers (to practice 
understanding of the algorithm) without wasting their times on 
calculations.)

> I know this because at a slightly different level it's what happened to
> me: I was lazy, didn't practice enough boring mathematical methods
> stuff, and that lack of fluency came back and bit me later.

Math =/= arithmetics.

Essential difference is that arithmetics in mechanical while math is 
like puzzle-solving. We can offload the former to computers, but not the 
later, as it requires actual thinking.

If you're confusing purely mechanical skills like typing and arithmetics 
with problem solving, well, I understand how it bit you.

> ALL actions require feedback! I don't want to blindly issue commands to
> my computer while not even looking to see if it's gone into Sorceror's
> Apprentice mode deleting the wrong files or something.

The difference is that with mouse you need feedback for each action, you 
need feedback immediately as it blocks you.

But with keyboards you can issue multiple keypresses at once and look 
for results later. So this check can be postponed.

It's pretty much the same difference as between primitive networking 
protocol which requires receiving ack packet before sending another one, 
thus limiting packet-per-second to 1/round_trip_time; and protocols like 
TCP which have multiple packets in flight so that bandwidth of network 
can be fully utilized regardless of latency.

> Besides that, aren't you being a bit inconsistent?
> First, touch typing
> is so great because you can keep your eyes on the screen and see what
> the hell you're doing, in context -- then mousing is awful because you
> must keep your eyes on the screen?

No, you're just using straw man shamelessly here.

I never said that touch typing is great and that I want to keep my eyes 
on the screen.

But if you want me to elaborate, touch typing is great because it 
doesn't require you focusing attention on a particular thing, it gives 
you more freedom, and this allows more efficient utilization of resources.

I never said that mouse is awful, it's just a slower compared to keyword 
in many cases (but not all). I use mouse wherever speed isn't important, 
i.e. for infrequently done actions.

On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>> ALL actions require feedback! I don't want to blindly issue commands to
>> my computer while not even looking to see if it's gone into Sorceror's
>> Apprentice mode deleting the wrong files or something.
>
> The difference is that with mouse you need feedback for each action, you
> need feedback immediately as it blocks you.
>
> But with keyboards you can issue multiple keypresses at once and look
> for results later. So this check can be postponed.

As mentioned in another post, this can be useful for data entry on an 
old, cruddy, lagged system or a laggy oldfashioned telnet connection. 
For command entry it's just asking for trouble. Enter a directory and 
select the third file to be deleted sight-unseen? Er, I don't think so. 
What if the third file isn't what you assumed it would be? You could be 
misremembering, or other users (if any) may have added or removed or 
renamed files in there.

>> Besides that, aren't you being a bit inconsistent?
>> First, touch typing
>> is so great because you can keep your eyes on the screen and see what
>> the hell you're doing, in context -- then mousing is awful because you
>> must keep your eyes on the screen?
>
> No, you're just using straw man shamelessly here.

Don't be ridiculous. I'm just pointing out an inconsistency in the 
pro-keyboard-only position.

> I never said that mouse is awful, it's just a slower compared to keyword
> in many cases (but not all). I use mouse wherever speed isn't important,
> i.e. for infrequently done actions.

As do I, for the most part; also for some actions that involve selecting 
from large numbers of options (you can acquire from a 2D array much 
faster than from a 1D list and much faster with a random-access-ish 
selection mechanism than with an arrow-your-way-around mechanism, so 
unless the items have names you can select via short unique prefixes...) 
and actions in a graphics-manipulation context (Photoshop, mainly).

On 10/05/2012 1:05 AM, Madhu wrote:
>
> * Jumpin' Jehoshaphat<jofenu$3vm$2@speranza.aioe.org>  :
> Wrote on Thu, 10 May 2012 00:04:14 -0400:
>
> |>  No indeed.  But we're still at the time when big companies are made
> |>  by convincing people that they need to buy a new computer (or phone
> |>  or pad) every year, and this is done by providing for "free"
> |>  "upgrades" of the system that are more and more bloated, and provide
> |>  slower and slower reaction time.  Lag indeed.
> |
> | If you're dumb enough to use Windoze, sure.
>
> BS.

Classic unsubstantiated and erroneous claim.

> As far as OS/Distro/Software strategies go Linux, Macs, Windows etc.
> are indistinguishable in this regard.  Microsoft just happened to
> pioneer the revenue model,

Classic illogic. The revenue model for Linux does not depend on the user 
buying upgrades.

> Most of the time the software is multiplatform, like AOL/Firefox. All
> the paychecks in this business are either to breed the next generation
> of consumers, or to introduce said bloat and inefficiencies in the
> platform that can eventually be monetized. --- Madhu

Classic paranoia. Where is Mozilla's alleged financial interest in 
making people buy the latest and greatest CPU, mobo, and GPU? Kickbacks 
from Intel, AMD, ATI, Asus, and nVidia? What's your evidence in support 
of your outlandish conspiracy theory, Madhu?

On 2012-05-10 00:58:31 +0000, Jumpin' Jehoshaphat said:

> They usually do, if you want to avoid and/or recover from mistakes.

Well, clearly they don't, sorry.  Let's get away from the typing thing: 
how many notes a second can a good pianist play?  How fast can a 
musician who is imprivising play? How are they doing that?

> As mentioned in another post, this can be useful for data entry on an
> old, cruddy, lagged system or a laggy oldfashioned telnet connection.

You didn't understand my point at all. The bottleneck is often in human 
sensory input.

But it helps with those 'lagged systems' too. Maybe in your ideal world 
computers never go slow, but in reality it isn't the case. Even most 
modern systems can go thrashing if something goes awry, and in my 
experience it's better to use text console at that time.

Also, if you just happen to need to work with server in California from 
Europe you have ~300 ms roundtrip for each packet just due to the speed 
of the light. No matter how fast your network is and how fast your 
computer it. In command prompt it is noticeable, but not problematic at 
all. With GUI it might be more of an issue.

> For command entry it's just asking for trouble. Enter a directory and
> select the third file to be deleted sight-unseen? Er, I don't think so.
> What if the third file isn't what you assumed it would be? You could be
> misremembering, or other users (if any) may have added or removed or
> renamed files in there.

You're strawmanning shit out of this. Not all commands are deleting 
files. Shell commands reference file name, but not position.

I can type `cd .. <enter> ls` without checking that cd was correct. In 
the worst case I'd have to type it again. It isn't like cd will 
accidentally turn to `rm -rf` a.

When I'm typing commands I'm very aware of what they do. So I need 
different levels of attention, and I can do cd/ls stuff much faster than 
rm -rf. And that's actually great because maybe 90% of commands are like 
cd/ls but not rm.

You buffer commands at a rate it makes sense. Even if you call rm, you 
can first type the whole thing, and then read it before pressing enter.

So it is:

rm -rf frobla.txt <look that it's correct> <enter>

Not

r <look> m <look> <space> <look> - <look> r <look> f <look> <space> 
<look> ...


Got it?

In reality it's more like
1. rm -rf fro<TAB>
2. look whether it was completed, there is a list of options or ...
3. when everything looks OK press enter.

So I'm able to enter a number of semantic units before I need to look at 
output, and output doesn't just confirm that I typed stuff correctly, 
but also includes response from file system.

Please learn how to use shell before criticizing it.

>> No, you're just using straw man shamelessly here.

> Don't be ridiculous. I'm just pointing out an inconsistency in the
> pro-keyboard-only position.

And who holds that pro-keyboard-only position? A strawman?

> As do I, for the most part; also for some actions that involve selecting
> from large numbers of options (you can acquire from a 2D array much
> faster than from a 1D list and much faster with a random-access-ish
> selection mechanism than with an arrow-your-way-around mechanism, so
> unless the items have names you can select via short unique prefixes...)

If information is textual chances are that incremental search would have 
worked better.

> and actions in a graphics-manipulation context (Photoshop, mainly).

Except that graphics professionals use pen tablets. You know why?
They don't require feedback from screen. Pen tablets have absolute 
positioning unlike mouses which have relative positioning. This means 
that pen tablet reproduces your motion exactly, you don't need to follow 
cursor to draw a curve you want.

I have wacom pen tablet which can also work in mouse mode (when no 
driver is installed, for example). I tried writing something in mouse 
mode and in tablet mode and results were very different. In tablet mode 
I can write something just like I write something on paper and it 
appears on screen verbatim, In mouse mode writing appears to be totally 
fucked up so you need to watch how cursor moves to have anything readable.

On 2012-05-10 09:24:26 +0000, Jumpin' Jehoshaphat said:

> Classic paranoia. Where is Mozilla's alleged financial interest in 
> making people buy the latest and greatest CPU, mobo, and GPU? Kickbacks 
> from Intel, AMD, ATI, Asus, and nVidia? What's your evidence in support 
> of your outlandish conspiracy theory, Madhu?

You know, there's some kind of horror movie script idea here, where it 
turns out that some terrible virus of the mind is spreading over the 
internet, the victims getting trapped in a loop where they repeat a 
small number of stylised phrases, eventually starving to death, to be 
found, wormy and decaying, over their keyboards.  How will our hero 
stop the spread of the plague?  Stealing a nuke and destroying the 
internet via EMP seems the only option.

Oh: who do you think fund Mozilla?  Where does their income come from?  
Gosh, what a susprise!

On 2012-05-10 04:04:42 +0000, Kaz Kylheku said:

> Why, drag and drop. You have icons on the desktop for all possible characters,
> and then you just drag them one by one to the script icon.

You think that's a joke, but have you seen any of the maths editors 
people use? A lot of them are just like that.

On 10/05/2012 7:33 AM, Tim Bradshaw wrote:
> On 2012-05-10 09:24:26 +0000, Jumpin' Jehoshaphat said:
>
>> Classic paranoia. Where is Mozilla's alleged financial interest in
>> making people buy the latest and greatest CPU, mobo, and GPU?
>> Kickbacks from Intel, AMD, ATI, Asus, and nVidia? What's your evidence
>> in support of your outlandish conspiracy theory, Madhu?
>
> You know, there's some kind of horror movie script idea here, where it
> turns out that some terrible virus of the mind is spreading over the
> internet, the victims getting trapped in a loop where they repeat a
> small number of stylised phrases, eventually starving to death, to be
> found, wormy and decaying, over their keyboards. How will our hero stop
> the spread of the plague? Stealing a nuke and destroying the internet
> via EMP seems the only option.

What does that have to do with Lisp, Bradshaw?

> Oh: who do you think fund Mozilla? Where does their income come from?
> Gosh, what a susprise!

I very much doubt it's conditioned on intentionally bloating their 
software, Bradshaw.

On 10/05/2012 7:44 AM, Tim Bradshaw wrote:
> On 2012-05-10 04:04:42 +0000, Kaz Kylheku said:
>
>> Why, drag and drop. You have icons on the desktop for all possible
>> characters,
>> and then you just drag them one by one to the script icon.
>
> You think that's a joke, but have you seen any of the maths editors
> people use? A lot of them are just like that.

Probably because no standard store-bought keyboard has the alphabet, the 
digits, the commonplace punctuation, the Greek alphabet, an integral 
sign, dot-in-circle, aleph, square-root sign, del, grad, +/-, 
squiggle-equals, not-equals, intersection, union, element-of, ... 
symbols and a bunch of extra shift keys for overbar and the like.

So it's either toolbar buttons, an emacsesque bestiary of 
impossible-to-memorize-them-all control-key combinations most of which 
have no mnemonic connection with what they insert, or typing in verbose 
markup like TeX code. (TeX editors sometimes give you the choice between 
the toolbar buttons and manually typing in TeX markup. Useful if you 
memorize the most commonly needed markup but can then just dig in the 
toolbar drop-downs for less-often-used symbols instead of having to task 
switch to a cheat-sheet, read some possibly-long string, switch back, 
and type it, or copy and paste it.)

On 10/05/2012 7:18 AM, Tim Bradshaw wrote:
> On 2012-05-10 00:58:31 +0000, Jumpin' Jehoshaphat said:
>
>> They usually do, if you want to avoid and/or recover from mistakes.
>
> Well, clearly they don't, sorry. Let's get away from the typing thing:
> how many notes a second can a good pianist play?

Data entry, of a sort, not command entry.

On 10/05/2012 7:32 AM, Alex Mizrahi wrote:
>> As mentioned in another post, this can be useful for data entry on an
>> old, cruddy, lagged system or a laggy oldfashioned telnet connection.
>
> You didn't understand my point at all.

That is incorrect. I just didn't agree with it.

> The bottleneck is often in human sensory input.

Good FPS players prove you wrong.

> But it helps with those 'lagged systems' too. Maybe in your ideal world
> computers never go slow, but in reality it isn't the case. Even most
> modern systems can go thrashing if something goes awry, and in my
> experience it's better to use text console at that time.

In my experience it's better to fix whatever the problem is (e.g. nice a 
process that started hogging the CPU, or restart it if it's not supposed 
to occasionally do that, or even debug it and recompile it) than to just 
try to carry on regardless.

> Also, if you just happen to need to work with server in California from
> Europe you have ~300 ms roundtrip for each packet just due to the speed
> of the light.

Input to your locally-running browser will not be affected by this. 
Stuff typed into a web form will echo promptly and mouse movement won't 
be affected. It may just take a while for the response to get back to 
you after you click "submit" or a link or whatever.

> No matter how fast your network is and how fast your
> computer it. In command prompt it is noticeable, but not problematic at
> all. With GUI it might be more of an issue.

You're hypothesizing somehow puppetting a GUI that's running on *the 
remote machine* rather than using a local client or web browser to 
communicate with the server. That would be ... weird. Mostly you use a 
web interface to a remote machine these days. If for some reason you 
can't (usually because you're the admin trying to remote-fix the machine 
after the httpd died) you grit your teeth, ssh into it, and use a 
command prompt. So when there's a GUI its mouse/keyboard feedback loop 
is local rather than stretching over the network.

>> For command entry it's just asking for trouble. Enter a directory and
>> select the third file to be deleted sight-unseen? Er, I don't think so.
>> What if the third file isn't what you assumed it would be? You could be
>> misremembering, or other users (if any) may have added or removed or
>> renamed files in there.
>
> You're strawmanning shit out of this.

Classic unsubstantiated and erroneous claims.

> Not all commands are deleting files.

That was an example.

> Shell commands reference file name, but not position.

The example was using a program more like dired rather than a command 
prompt.

> I can type `cd .. <enter> ls` without checking that cd was correct. In
> the worst case I'd have to type it again. It isn't like cd will
> accidentally turn to `rm -rf` a.

Actually, if there's line noise you never know. ;)

> When I'm typing commands I'm very aware of what they do. So I need
> different levels of attention, and I can do cd/ls stuff much faster than
> rm -rf. And that's actually great because maybe 90% of commands are like
> cd/ls but not rm.

You could still find yourself wasting time, at the very least, if you 
wind up taking a wrong turn somewhere while overdriving your headlights, 
even if you manage not to crash.

> rm -rf frobla.txt <look that it's correct> <enter>

And if you're in the wrong directory and there are frobla.txts you don't 
want to delete as well as ones you do, in different parts of the 
filesystem ...

> In reality it's more like
> 1. rm -rf fro<TAB>
> 2. look whether it was completed, there is a list of options or ...
> 3. when everything looks OK press enter.

The GUI equivalent would be to click a file and hit del. You'd have to 
look to see that it had acknowledged your click and selected the file 
before hitting del, but that's the same as your having to look before 
hitting enter.

Where you went off the rails is comparing keystrokes to mouse clicks. 
Everything but the "rm" and "enter" parts correspond to one single mouse 
click to select the file. The del key supplies those parts (and gives a 
confirmation prompt in any decent GUI file manager to boot, as one added 
level of safety).

If you're deleting all files of that name under some directory, if 
you're using a recent Windoze you'd type frobla into the search box, 
wait for it to find everything, then hit ctrl+A DEL. Again one wait.

> Please learn how to use shell before criticizing it.

Classic erroneous presupposition.

>>> No, you're just using straw man shamelessly here.
>
>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>> pro-keyboard-only position.
>
> And who holds that pro-keyboard-only position?

You, Madhu, and Kylheku, at the very least.

>> As do I, for the most part; also for some actions that involve selecting
>> from large numbers of options (you can acquire from a 2D array much
>> faster than from a 1D list and much faster with a random-access-ish
>> selection mechanism than with an arrow-your-way-around mechanism, so
>> unless the items have names you can select via short unique prefixes...)
>
> If information is textual chances are that incremental search would have
> worked better.

Information is often not textual, or not solely textual. Textual 
information often lacks short unique prefixes on each item, or one 
doesn't quickly remember the one desired. It's faster to recognize a 
particular icon, if that's unique to your target, than to recognize a 
particular short snippet of text, even if that's also unique, since the 
latter is made of nonunique individual letters.

>> and actions in a graphics-manipulation context (Photoshop, mainly).
>
> Except that graphics professionals use pen tablets. You know why?
> They don't require feedback from screen. Pen tablets have absolute
> positioning unlike mouses which have relative positioning. This means
> that pen tablet reproduces your motion exactly, you don't need to follow
> cursor to draw a curve you want.

That's when drawing freehand rather than doing something else, such as 
dragging pre-created image fragments around and assembling them in some 
manner or applying filters, etc.

There's more sorts of graphics work than you seem to be assuming.

Also, pen tablets are expensive. The last time I saw any in a store the 
cheapest was 4-5x the cost of a decent mouse. Not everyone is going to 
spring for something like that. Particularly among those who work with 
graphics a fair bit but *not* in a capacity where they get paid to do 
so, or at least to do so very often.

Jumpin' Jehoshaphat <jj1058672395@gmail.com> writes:

>> Writing a novel is just so much typing; so automate it!
>
> That's data entry, not command inputs.

You have a problem pal!  Code = Data !!!


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On 10/05/2012 9:18 AM, Pascal J. Bourguignon wrote:
> Jumpin' Jehoshaphat<jj1058672395@gmail.com>  writes:
>
>>> Writing a novel is just so much typing; so automate it!
>>
>> That's data entry, not command inputs.
>
> You have a problem pal!

Classic unsubstantiated and erroneous claim.

> Code = Data !!!

And indeed typing in code is a form of data entry. But directly issuing 
single-gesture (control-key, mouse-click) commands to be executed 
immediately is not really comparable when it comes to the whole "is it a 
good idea to do it blind/while the interface display lags behind?" issue.

On 2012-05-10 08:34:29 +0000, Alex Mizrahi said:
> 
> Huh? At school level people work with concrete numbers, but on more 
> advanced level there are barely any numbers in formulas.

> I don't know much above physics above school level, but I've got M.Sc. 
> applied math degree without being particularly good at arithmetics.

Well yes.  It turns out that in physics numbers do matter.  A very 
important skill (which people are explicitly taught) is to be able to 
have a feeling for whether something is "reasonable" which can mean 
various things, but often means "is it about the right size?" and that 
requires, among other things, the ability to get numerical estimates of 
stuff very quickly.  And although you are almost never doing literal 
arithmetic (you're typically just trying to get an answer which is 
right to an order of magnitude and some kind of notion of how rough the 
answer is), you really can't do this without being pretty competent at 
arithmetic, it turns out.

If you want a really good example of this there are several in 
Feynman's autobiographical books.  Obviously he was better than most.

It's very tempting to say "oh, none of this matters now, you just use a 
computer" but that turns out not to be right for reasons I'm too tired 
to explain now, but are, I think, well-known.


>> I know this because at a slightly different level it's what happened to
>> me: I was lazy, didn't practice enough boring mathematical methods
>> stuff, and that lack of fluency came back and bit me later.
> 

> 
> Math =/= arithmetics.

I am aware of the difference.  That's why I said "at a slightly 
different level".

On 2012-05-10 12:53:39 +0000, Jumpin' Jehoshaphat said:

> Data entry, of a sort, not command entry.

I see.  How conveneient for you.

On 2012-05-10 11:32:37 +0000, Alex Mizrahi said:

> In reality it's more like
> 1. rm -rf fro<TAB>
> 2. look whether it was completed, there is a list of options or ...
> 3. when everything looks OK press enter.

And even that is not what people do: they have typed and executed the 
whole command before they have time to think.  I do this (as I've 
discovered), and the interesting thing is that, after a while, although 
you do execute things you should not have, you (almost) never do it in 
a state where it matters.

On 2012-05-10 12:53:08 +0000, Jumpin' Jehoshaphat said:

> So it's either toolbar buttons, an emacsesque bestiary of 
> impossible-to-memorize-them-all control-key combinations most of which 
> have no mnemonic connection with what they insert, or typing in verbose 
> markup like TeX code. (TeX editors sometimes give you the choice 
> between the toolbar buttons and manually typing in TeX markup. Useful 
> if you memorize the most commonly needed markup but can then just dig 
> in the toolbar drop-downs for less-often-used symbols instead of having 
> to task switch to a cheat-sheet, read some possibly-long string, switch 
> back, and type it, or copy and paste it.)

I'd guess that you've never typed any significant amount of maths.  I 
have, and TeX is just enormously faster than any kind of pick-and-drop 
thing.  Even now, nearly 30 years after doing any large amount of 
stuff, and something like 20 years after really even using TeX much, I 
can look at even quite complex expressions and type them, and very 
often not have to fix anything.  It was designed by someoene who typed 
maths, and that really shows (troff may be as good, I just never learnt 
more than you needed to make a man page).

On 2012-05-10 13:45:41 +0000, Jumpin' Jehoshaphat said:

> And indeed typing in code is a form of data entry. But directly issuing 
> single-gesture (control-key, mouse-click) commands to be executed 
> immediately is not really comparable when it comes to the whole "is it 
> a good idea to do it blind/while the interface display lags behind?" 
> issue.

See my earlier message.  I make my living typing commands at machines, 
in a context where mistakes can be expensive.  I type blind all the 
time, and so do other people I know (I only discovered this recently by 
observing what I do and then asking other people doing the same job).

On 10/05/2012 10:21 AM, Tim Bradshaw wrote:
> On 2012-05-10 11:32:37 +0000, Alex Mizrahi said:
>
>> In reality it's more like
>> 1. rm -rf fro<TAB>
>> 2. look whether it was completed, there is a list of options or ...
>> 3. when everything looks OK press enter.
>
> And even that is not what people do: they have typed and executed the
> whole command before they have time to think. I do this (as I've
> discovered), and the interesting thing is that, after a while, although
> you do execute things you should not have, you (almost) never do it in a
> state where it matters.

Perhaps, but when it's sometimes "rm -rf", "almost never" isn't going to 
be good enough.

On 10/05/2012 10:39 AM, Tim Bradshaw wrote:
> On 2012-05-10 13:45:41 +0000, Jumpin' Jehoshaphat said:
>
>> And indeed typing in code is a form of data entry. But directly
>> issuing single-gesture (control-key, mouse-click) commands to be
>> executed immediately is not really comparable when it comes to the
>> whole "is it a good idea to do it blind/while the interface display
>> lags behind?" issue.
>
> See my earlier message. I make my living typing commands at machines, in
> a context where mistakes can be expensive. I type blind all the time,

Why? Are you using old, obsolete, slow equipment or an old, obsolete, 
slow network protocol that makes the input/feedback loop take a round 
trip to the server and not just complete commands?

On 10/05/2012 10:33 AM, Tim Bradshaw wrote:
> On 2012-05-10 12:53:08 +0000, Jumpin' Jehoshaphat said:
>
>> So it's either toolbar buttons, an emacsesque bestiary of
>> impossible-to-memorize-them-all control-key combinations most of which
>> have no mnemonic connection with what they insert, or typing in
>> verbose markup like TeX code. (TeX editors sometimes give you the
>> choice between the toolbar buttons and manually typing in TeX markup.
>> Useful if you memorize the most commonly needed markup but can then
>> just dig in the toolbar drop-downs for less-often-used symbols instead
>> of having to task switch to a cheat-sheet, read some possibly-long
>> string, switch back, and type it, or copy and paste it.)
>
> I'd guess that you've never typed any significant amount of maths.

Then you'd guess wrong.

> I have, and TeX is just enormously faster than any kind of pick-and-drop
> thing.

It is if there's a convenient way to get at infrequently-used stuff you 
haven't got memorized. Ideally, a visual way so you can find the symbol 
you want by sight and click it. And then if you're starting to use that 
one a lot, or a lot in that particular document, you note what it pasted 
when you did that and type it the next time.

But if you have to task switch to some cheat sheet (likely a giant 
bloated pdf file open in giant bloated Acrobat Reader, bletch) every 
time you want to find the code for some symbol you don't remember it 
will be much slower than if you can open some palette and click it in 
that when you don't remember the code to type.

On 2012-05-10, Jumpin' Jehoshaphat <jj1058672395@gmail.com> wrote:
> On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>>> ALL actions require feedback! I don't want to blindly issue commands to
>>> my computer while not even looking to see if it's gone into Sorceror's
>>> Apprentice mode deleting the wrong files or something.
>>
>> The difference is that with mouse you need feedback for each action, you
>> need feedback immediately as it blocks you.
>>
>> But with keyboards you can issue multiple keypresses at once and look
>> for results later. So this check can be postponed.
>
> As mentioned in another post, this can be useful for data entry on an 
> old, cruddy, lagged system or a laggy oldfashioned telnet connection. 

You missed the part about there being lag that cannot be eliminated.
Even if your computer's interactive response time is a nanosecond, 
there is lag in the brain.

Anything that is blocked on the human having to make a conscious decision is
looking at a 500 millisecond response (Libet's half second delay).

Training to do things unconsciously brings that down, but not to zero.

On 10/05/2012 10:59 AM, Kaz Kylheku wrote:
> On 2012-05-10, Jumpin' Jehoshaphat<jj1058672395@gmail.com>  wrote:
>> On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>>>> ALL actions require feedback! I don't want to blindly issue commands to
>>>> my computer while not even looking to see if it's gone into Sorceror's
>>>> Apprentice mode deleting the wrong files or something.
>>>
>>> The difference is that with mouse you need feedback for each action, you
>>> need feedback immediately as it blocks you.
>>>
>>> But with keyboards you can issue multiple keypresses at once and look
>>> for results later. So this check can be postponed.
>>
>> As mentioned in another post, this can be useful for data entry on an
>> old, cruddy, lagged system or a laggy oldfashioned telnet connection.
>
> You missed the part about there being lag that cannot be eliminated.

No, *you* missed the part about the proficient FPS players whose mouse 
use is not hampered by that lag.

On 2012-05-10, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
>> ALL actions require feedback! I don't want to blindly issue commands to
>> my computer while not even looking to see if it's gone into Sorceror's
>> Apprentice mode deleting the wrong files or something.
>
> The difference is that with mouse you need feedback for each action, you 
> need feedback immediately as it blocks you.

I'm afraid we have been, as I suspected,  wasting time responding to Seamus
MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

The wacky pseudonym, low intelligence, and overall style give it away.

On 10/05/2012 11:10 AM, Kaz Kylheku wrote:
1> Newsgroups: comp.lang.lisp

1> I'm afraid we have been, as I suspected,  wasting time responding to 
Seamus
1> MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

Who is "Seamus MacRae", Kylheku? There is nobody in this newsgroup using 
that alias.

1> The wacky pseudonym, low intelligence, and overall style give it away.

What do your classic erroneous presuppositions have to do with Lisp, 
Kylheku?

On 2012-05-10 14:51:11 +0000, Jumpin' Jehoshaphat said:

> Perhaps, but when it's sometimes "rm -rf", "almost never" isn't going 
> to be good enough.

It'd good enough if it is below whatever else kills the system, which 
it seems to be.

On 2012-05-10 14:52:33 +0000, Jumpin' Jehoshaphat said:

> Why? Are you using old, obsolete, slow equipment or an old, obsolete, 
> slow network protocol that makes the input/feedback loop take a round 
> trip to the server and not just complete commands?

Sorry, what I meant was "type and enter commands without long enough to 
become consciously aware of mistakes".  The systems can echo fast 
enough, I just can't proces the information.

On 2012-05-10 15:10:23 +0000, Kaz Kylheku said:

> I'm afraid we have been, as I suspected,  wasting time responding to Seamus
> MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

I prefer my brain-eating virus theory, but there's no real difference 
in practice.

On 2012-05-10 14:54:50 +0000, Jumpin' Jehoshaphat said:

> It is if there's a convenient way to get at infrequently-used stuff you 
> haven't got memorized.

Right, we call that The TeXbook (or the AMSTeX manual, or whatever). I 
guess I would have referred to it once a day or so when I typed maths 
seriously, may be less.  For anything you use that seldom it hardly 
matters what it is.

On 2012-05-10 15:50:26 +0000, Tim Bradshaw said:

> For anything you use that seldom it hardly matters what it is.

I take that back: it does not matter what it is *so long as it uses no 
screen space*.

On Thursday, May 10, 2012 12:44:17 PM UTC+1, Tim Bradshaw wrote:
> On 2012-05-10 04:04:42 +0000, Kaz Kylheku said:
> 
> > Why, drag and drop. You have icons on the desktop for all possible characters,
> > and then you just drag them one by one to the script icon.
> 
> You think that's a joke, but have you seen any of the maths editors 
> people use? A lot of them are just like that.

ever seen a chinese typewriter?

On 10/05/2012 11:50 AM, Tim Bradshaw wrote:
> On 2012-05-10 14:54:50 +0000, Jumpin' Jehoshaphat said:
>
>> It is if there's a convenient way to get at infrequently-used stuff
>> you haven't got memorized.
>
> Right, we call that The TeXbook (or the AMSTeX manual, or whatever).

Suffering from reading comprehension problems, Bradshaw? I said "a 
convenient way", but you instead suggested copying and pasting from a 
large pdf file that

a) consumes multiple megabytes of memory and disk space
b) requires proprietary software such as Acrobat Reader to view properly
c) which is itself bloated and takes ages to start up
d) and then you have to manually scroll through a very long document
    looking for desired symbols and then copy and paste the corresponding
    codes, rather than simply selecting from a neatly-organized set of
    drop-down palettes and the code being pasted into your document
    automatically.

On 10/05/2012 11:43 AM, Tim Bradshaw wrote:
> On 2012-05-10 14:52:33 +0000, Jumpin' Jehoshaphat said:
>
>> Why? Are you using old, obsolete, slow equipment or an old, obsolete,
>> slow network protocol that makes the input/feedback loop take a round
>> trip to the server and not just complete commands?
>
> Sorry, what I meant was "type and enter commands without long enough to
> become consciously aware of mistakes". The systems can echo fast enough,
> I just can't proces the information.

Your limitations are not everybody's, Bradshaw.

On 10/05/2012 11:41 AM, Tim Bradshaw wrote:
> On 2012-05-10 14:51:11 +0000, Jumpin' Jehoshaphat said:
>
>> Perhaps, but when it's sometimes "rm -rf", "almost never" isn't going
>> to be good enough.
>
> It'd good enough if it is below whatever else kills the system, which it
> seems to be.

For some of us, the goal is to avoid *anything* else killing the system, 
Bradshaw.

On 10/05/2012 11:45 AM, Tim Bradshaw wrote:
> On 2012-05-10 15:10:23 +0000, Kaz Kylheku said:
>
>> I'm afraid we have been, as I suspected, wasting time responding to
>> Seamus
>> MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.
>
> I prefer my brain-eating virus theory, but there's no real difference in
> practice.

What does your illogical brain-eating virus theory or Kylheku's paranoia 
have to do with Lisp, Bradshaw, or even with the digression about mouse 
feedback speed?

>> You didn't understand my point at all.
> That is incorrect. I just didn't agree with it.

You replied with completely irrelevant pieces. Either you didn't 
understand or you were trolling.

I mentioned reduction of frequency of checks required

>> The bottleneck is often in human sensory input.
> Good FPS players prove you wrong.

OK, what is the bottleneck for them?

I know that FPS players can shot with one mouse motion (and I even 
mentioned it previously), but they spend years learning them and they 
use special gaming mice.

While a typical person is sloppy, uses a shitty mouse and shitty 
settings which make absolute positioning impossible. Hence word 'often'. 
Notice it.

Or do you claim that a typical person can click buttons with mouse 
without looking?

>> But it helps with those 'lagged systems' too. Maybe in your ideal world
>> computers never go slow, but in reality it isn't the case. Even most
>> modern systems can go thrashing if something goes awry, and in my
>> experience it's better to use text console at that time.
>
> In my experience it's better to fix whatever the problem is (e.g. nice a
> process that started hogging the CPU, or restart it if it's not supposed
> to occasionally do that, or even debug it and recompile it)

Are you retarded? I need a fucking console to kill that fucking process.
Am I supposed to restart it telepathically or something?

It isn't like it happens all the time, but from time to time shit 
happens, and console is a much better tool for emergencies.

> Input to your locally-running browser will not be affected by this.
> Stuff typed into a web form will echo promptly and mouse movement won't
> be affected. It may just take a while for the response to get back to
> you after you click "submit" or a link or whatever.

How is that related? Should I use a browser instead of SSH?

>> No matter how fast your network is and how fast your
>> computer it. In command prompt it is noticeable, but not problematic at
>> all. With GUI it might be more of an issue.

> You're hypothesizing

I do not hypothesize (unlike you). Everything I wrote is an actual 
experience. I just describe what I did.

> somehow puppetting a GUI that's running on *the
> remote machine*
 > rather than using a local client or web browser to
> communicate with the server.

In many cases something like VNC is absolutely required because software 
in question can only run locally. There is simply no remote mode.

You cannot make sure that all software is client-server one.

Are you saying there is no need in non-client-server software?

> That would be ... weird. Mostly you use a
> web interface to a remote machine these days.

I never used web interface and never seen anybody using web interface.

> If for some reason you
> can't (usually because you're the admin trying to remote-fix the machine
> after the httpd died)

Yeah, I'm like that admin. I set up servers from scratch, for example.

> you grit your teeth, ssh into it, and use a
> command prompt.

Well, maybe you grit your teeth, but I comfortably use SSH each day.

>> Shell commands reference file name, but not position.

> The example was using a program more like dired rather than a command
> prompt.

Your example was shitty. You intentionally mentioned most shitty 
situation to make keyboard look bad.

>> rm -rf frobla.txt <look that it's correct> <enter>
>
> And if you're in the wrong directory and there are frobla.txts you don't
> want to delete as well as ones you do, in different parts of the
> filesystem ...

Does use of mouse prevent this problem? It's totally unrelated.
If you're in wrong directory, you do not look at directory you're using 
and there is a file with same name, you're fucked no matter which input 
you use.

>> In reality it's more like
>> 1. rm -rf fro<TAB>
>> 2. look whether it was completed, there is a list of options or ...
>> 3. when everything looks OK press enter.

> The GUI equivalent would be to click a file and hit del.

No, you first need to find it visually, which is very problematic in a 
directory with many files. You either need to scroll or use incremental 
search using keyboard.
Then hit del.
Then confirm that you want to delete whole tree.

rm = del
-rf = confirms deletion of whole tree
fro<TAB> = clicking file

So, same amount of logical units, or actions, but I'll type this command 
much faster because you'll have to switch between keyboard and mouse and 
look at screen in process.

> You'd have to
> look to see that it had acknowledged your click and selected the file
> before hitting del, but that's the same as your having to look before
> hitting enter.

No, you're ignoring the fact that you need to find file first.

> Where you went off the rails is comparing keystrokes to mouse clicks.
> Everything but the "rm" and "enter" parts correspond to one single mouse
> click to select the file.

No.

> The del key supplies those parts (and gives a
> confirmation prompt in any decent GUI file manager to boot, as one added
> level of safety).

rm also has this confirmation. Surprise! Surprise!

>>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>>> pro-keyboard-only position.

>> And who holds that pro-keyboard-only position?

> You, Madhu, and Kylheku, at the very least.

I don't.

>> If information is textual chances are that incremental search would have
>> worked better.
>
> Information is often not textual, or not solely textual.

It depends on what you're doing.

I'm a programmer, 99% of information I'm working with is textual.

> Textual
> information often lacks short unique prefixes on each item,

It doesn't need to be a prefix, incremental search can find parts in the 
middle.

> That's when drawing freehand rather than doing something else, such as
> dragging pre-created image fragments around and assembling them in some
> manner or applying filters, etc.

You can use pen tablet instead of mouse. Surprise!

People who have them often prefer them to mice. Much faster and more 
precise.

> Also, pen tablets are expensive. The last time I saw any in a store the
> cheapest was 4-5x the cost of a decent mouse. Not everyone is going to
> spring for something like that. Particularly among those who work with
> graphics a fair bit but *not* in a capacity where they get paid to do
> so, or at least to do so very often.

I agree that mouse is an excellent poor man's choice. You can do 
everything with it, but in a slow and sloppy way.

>> In reality it's more like
>> 1. rm -rf fro<TAB>
>> 2. look whether it was completed, there is a list of options or ...
>> 3. when everything looks OK press enter.

> And even that is not what people do:

Depends on 'people' and context. At least I do that. I have a habit of 
using <TAB> not only for a speed up (often it's faster to type) but to 
verify existence and do a 'spellchecking' (my zsh is configured to fix 
typos, but it's not very useful, honestly). And I wait after <TAB> since 
completions are often non-unique.

> they have typed and executed the
> whole command before they have time to think. I do this (as I've
> discovered), and the interesting thing is that, after a while, although
> you do execute things you should not have, you (almost) never do it in a
> state where it matters.

Well, I do things like "cd .." without looking, but rarely commands 
which do something.

> No, *you* missed the part about the proficient FPS players whose mouse
> use is not hampered by that lag.

I've just imagined proficient FPS players using mouse in Emacs. LOL.

(BTW when those FPS players need to reconfigure keybindings in game up 
to their taste they type them in game console with insanely fast speed. 
So they know how to use keyboard efficiently wherever it makes sense.
And I bet they'll learn all keybingings they need if they'd actually 
need to use Emacs.)

On 2012-05-12 05:36:04 +0000, Jumpin' Jehoshaphat said:

> Suffering from reading comprehension problems, Bradshaw? I said "a 
> convenient way", but you instead suggested copying and pasting from a 
> large pdf file that

I did?  Mine sits on the desk beside the computer.

On 2012-05-12 05:36:48 +0000, Jumpin' Jehoshaphat said:

> Your limitations are not everybody's, Bradshaw.

They are common to all humans.  Cats are faster I think, but they don't 
use computers.

On 2012-05-12 05:37:18 +0000, Jumpin' Jehoshaphat said:

> For some of us, the goal is to avoid *anything* else killing the 
> system, Bradshaw.

Quite.  But that's not achievable in a world governed by the laws of 
physics, let alone with the hardware and software we're constrained to 
use in practice.

On 2012-05-12 08:36:26 +0000, Alex Mizrahi said:

> Depends on 'people' and context.

Yes, I was only commenting on what I've discovered that I do (and since 
talked to colleagues about to discover that some of them do the same 
thing) - sorry I was vague about that.  It was surprising to me, and 
even more surprising is how little damage (none that I can see) gets 
done as a result.  I think this may be related to your "experienced 
gamer can do x with the mouse" point in another article: people who do 
this all the time, for long enough, get pretty sensitive to when they 
need to think before executing the command they've typed and when they 
don't.

On 12/05/2012 6:26 AM, Tim Bradshaw wrote:
> On 2012-05-12 05:36:04 +0000, Jumpin' Jehoshaphat said:
>
>> Suffering from reading comprehension problems, Bradshaw? I said "a
>> convenient way", but you instead suggested copying and pasting from a
>> large pdf file that
>
> I did? Mine sits on the desk beside the computer.

Well, that's even stupider. That requires a printer, toner, and paper, 
meaning it actually costs *money* as well as disk space and the need to 
muck about with proprietary apps. And then you can't even copy and paste 
from it! You have to actually copy manually, turning your head a large 
distance to read the next bit of a long, not easily memorized 
alphanumeric string, then turning back to the computer and typing a 
part, turning to read another bit, turning back and typing that, and so 
forth.

Why do you put up with such primitive methods? An irrational hatred for 
GUIs? A particularly urgent need for screen real-estate that begrudges 
the 16 or so additional rows of pixels (out of, I'd hope, at least 1024 
in this day and age) that would be taken up by a toolbar with drop-down 
palettes full of symbols?

And if you do begrudge those things, you'd spend your money better 
getting a second monitor or even a whole second computer than a printer 
and a bunch of ink and paper for it. When not displaying the PDF it 
could be used for other things, and instead of costing or avoiding 
consuming screen real estate it would give you double what you had. And 
you could copy and paste from it, if a second monitor connected to the 
same computer.

On 12/05/2012 6:27 AM, Tim Bradshaw wrote:
> On 2012-05-12 05:36:48 +0000, Jumpin' Jehoshaphat said:
>
>> Your limitations are not everybody's, Bradshaw.
>
> They are common to all humans. Cats are faster I think, but they don't
> use computers.

Apparently proficient FPS players are also faster than you. And perhaps 
most other humans.

On 12/05/2012 4:32 AM, Alex Mizrahi wrote:
>>> You didn't understand my point at all.
>> That is incorrect. I just didn't agree with it.
>
> You replied with completely irrelevant pieces.

Classic unsubstantiated and erroneous claim.

> Either you didn't understand or you were trolling.

Classic erroneous presupposition.

> Or do you claim that a typical person can click buttons with mouse
> without looking?

Without looking at the mouse? Yes. Without looking at the screen? No, 
but then a touch typist doesn't need (or want!) to look away from the 
screen much anyway.

In any event, a proficient mouse user is a lot faster and more accurate 
than a novice like, I assume, you are and anyone else here is who is 
sour on mouse use.

>>> But it helps with those 'lagged systems' too. Maybe in your ideal world
>>> computers never go slow, but in reality it isn't the case. Even most
>>> modern systems can go thrashing if something goes awry, and in my
>>> experience it's better to use text console at that time.
>>
>> In my experience it's better to fix whatever the problem is (e.g. nice a
>> process that started hogging the CPU, or restart it if it's not supposed
>> to occasionally do that, or even debug it and recompile it)
>
> Are you retarded?

What does your ridiculous question have to do with the topic at hand, 
Mizrahi?

> I need a fucking console to kill that fucking process.

What does your foul language have to do with Lisp, Mizrahi? Of course 
you don't; there are graphical process-management tools out there for 
those who prefer them. Also, one hopes one only has to nice processes 
that are hogging the CPU or otherwise slowing the system down on 
infrequent occasions. As for a fix-and-recompile one hopes one only has 
to do that *once*, and then the problem won't happen again.

> It isn't like it happens all the time, but from time to time shit
> happens, and console is a much better tool for emergencies.

So you claim, without evidence.

>> Input to your locally-running browser will not be affected by this.
>> Stuff typed into a web form will echo promptly and mouse movement won't
>> be affected. It may just take a while for the response to get back to
>> you after you click "submit" or a link or whatever.
>
> How is that related? Should I use a browser instead of SSH?

If you're complaining about GUIs being lagged by the network you're not 
using SSH.

>>> No matter how fast your network is and how fast your
>>> computer it. In command prompt it is noticeable, but not problematic at
>>> all. With GUI it might be more of an issue.
>
>> You're hypothesizing
>
> I do not hypothesize

Classic unsubstantiated and erroneous claim.

> Are you saying there is no need in non-client-server software?

You are confused. We had been discussing UIs slowed down by network lag, 
which doesn't affect you when working with purely local software.

>> That would be ... weird. Mostly you use a
>> web interface to a remote machine these days.
>
> I never used web interface and never seen anybody using web interface.

Then you're weird. What can I say?

>> If for some reason you
>> can't (usually because you're the admin trying to remote-fix the machine
>> after the httpd died)
>
> Yeah, I'm like that admin. I set up servers from scratch, for example.
>
>> you grit your teeth, ssh into it, and use a
>> command prompt.
>
> Well, maybe you grit your teeth, but I comfortably use SSH each day.

How can you "comfortably" use anything that forces you to see the work 
you're doing through a keyhole instead of in widescreen HD? Which is 
what a command prompt does, of course, what with the little-to-no 
context it displays while you work. Not to mention forces you to, 
instead of hands-on manipulating whatever it is you're working on, 
forces you to grunt at a robot in pidgin that will then go and do the 
manipulating and hope it doesn't get confused and misunderstand you -- 
one little typo and the thing will merrily start destroying everything 
on the machine systematically (and finish, or do a lot of damage before 
the damage crashes it, too fast for you to intervene and stop it). 
Unless you have a big job to do that's easily specified as a rote 
mechanical action you'll have just as much work to do as doing it 
yourself, with a higher likelihood of error and worse potential 
consequences of such an error. Actually, you'll have *more* work to do 
-- for example, moving a file might, instead of one click and drag 
taking a second or so, take fifty or more keystrokes and three or four 
seconds.

>>> Shell commands reference file name, but not position.
>
>> The example was using a program more like dired rather than a command
>> prompt.
>
> Your example was shitty.

What does your classic unsubstantiated and erroneous claim have to do 
with this debate, Mizrahi?

>>> rm -rf frobla.txt <look that it's correct> <enter>
>>
>> And if you're in the wrong directory and there are frobla.txts you don't
>> want to delete as well as ones you do, in different parts of the
>> filesystem ...
>
> Does use of mouse prevent this problem?

Certainly, since the GUI comes along with it and you can actually see 
where the hell you are. With the CLI you're peering through a keyhole. 
You may see

local %>

and maybe you're in etc/local and maybe you're in usr/local. With a GUI 
you can see at a glance where you are because the files in the directory 
you're in are displayed right there on the screen. If you're in the 
wrong one you'll probably notice right away by what files are (or 
aren't) present.

> It's totally unrelated.

But not uncorrelated. Nor is it uncorrelated with the presence of 
confirmation prompts and trash/recycle bins and other useful safeguards. 
It's much, *much* less likely that you will accidentally delete when you 
meant to do something else, and much, *much* more likely that if you do 
anyway you can *un*do it. Wrong directory? You'll probably see that 
you're in the wrong place, since you can actually see that place and not 
just its name or even a part of its name. Wrong command? It's much 
easier to mistype "em foo.txt" as "rm foo.txt" than it is to confuse an 
editor icon and a trashcan icon, or to miss the former by a large enough 
margin to drop the file on the latter. And then you'll unexpectedly get 
an "OK to delete file?" prompt instead of an editor window. And failing 
*that* you don't really lose the file unless you're stupid enough to 
empty the trash instead of dig the file back out of it that you didn't 
mean to drop there!

Sure, for some things, it's slower, but it's also safer, and any decent 
system still provides a command prompt and a scripting capability for 
tasks that benefit from automation.

> If you're in wrong directory, you do not look at directory you're using

???

>>> In reality it's more like
>>> 1. rm -rf fro<TAB>
>>> 2. look whether it was completed, there is a list of options or ...
>>> 3. when everything looks OK press enter.
>
>> The GUI equivalent would be to click a file and hit del.
>
> No, you first need to find it visually, which is very problematic in a
> directory with many files.

Really? It's a lot easier to spot a distinctive icon and name than just 
a distinctive name, and a lot faster to mouse to and click an icon than 
to type a name longer than ten or so characters.

Not to mention a GUI gives you the nifty ability to have more than one 
"current directory" at a time, instead of having to type a 
potentially-long path anytime you need to switch, or perform an 
operation involving multiple directories (such as moving files to a 
different part of the filesystem).

> So, same amount of logical units, or actions, but I'll type this command
> much faster because you'll have to switch between keyboard and mouse and
> look at screen in process.

Bad comparison. First of all, it's not "same amount of logical units". 
Second, you don't have to switch between keyboard and mouse unless it's 
a *very large* directory (hundreds of files seems to be the threshold 
for when typing part of the name is faster than scrolling to locate the 
file). And third, if you're a touch-typist you don't have to look at the 
keyboard, for the most part, and don't want to either, so whether you're 
typing or not you don't have to look *away from* the screen.

>> You'd have to
>> look to see that it had acknowledged your click and selected the file
>> before hitting del, but that's the same as your having to look before
>> hitting enter.
>
> No, you're ignoring the fact that you need to find file first.

I was assuming you'd already found it, but it's not as if keyboard-only 
is better for finding the file either. You can find it in only one way 
then: by its name. If you don't know its name you have to invoke search 
tools, and at a CLI that tends to mean an arcane syntax and possibly a 
trip to the help files to get *that* right before you even can find the 
file you want to delete! And then the name might be really long and 
awkward to type. And it might have characters in it that tend to give 
shells fits: nontypable symbols, percent signs, leading hyphens, 
quotation marks, and even spaces tend to cause problems there.

With the GUI you can find the file in any of a number of ways. Type 
(some prefix of) the name; scan for it while scrolling with the keyboard 
pgdn key; scan while scrolling with the mouse wheel; set a sort order 
that makes the file go to the top or bottom of the window and then hit 
ctrl+home or ctrl+end (if it's alphabetically first, or larger than any 
other file there, or the newest, or the oldest -- deleting the oldest of 
some set of logfiles would be a common case); or type a query into a 
little search box that works more or less as expected for simple 
substring matches but supports more complex queries as well when needed, 
such as based on modification time, file contents, or other criteria.

>> Where you went off the rails is comparing keystrokes to mouse clicks.
>> Everything but the "rm" and "enter" parts correspond to one single mouse
>> click to select the file.
>
> No.

Still in denial? Seek help.

>> The del key supplies those parts (and gives a
>> confirmation prompt in any decent GUI file manager to boot, as one added
>> level of safety).
>
> rm also has this confirmation. Surprise! Surprise!

Wrong. It just deletes things without checking first. You can make it 
prompt for confirmation, but only by remembering to type something extra 
first.

Not to mention all the various ways it can go wrong. Guess what happens 
if there's a file named "-rf" in a directory where you use "rm *" or 
similar.

>>>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>>>> pro-keyboard-only position.
>
>>> And who holds that pro-keyboard-only position?
>
>> You, Madhu, and Kylheku, at the very least.
>
> I don't.

Classic inconsistency with the rest of your post.

>>> If information is textual chances are that incremental search would have
>>> worked better.
>>
>> Information is often not textual, or not solely textual.
>
> It depends on what you're doing.

Perhaps.

> I'm a programmer, 99% of information I'm working with is textual.

I wear rather more hats here.

>> Textual
>> information often lacks short unique prefixes on each item,
>
> It doesn't need to be a prefix, incremental search can find parts in the
> middle.

You are confused. Tab completion needs a prefix. So does the incremental 
search in typical GUI file managers, such as Windoze Explorer.

You seem to be thinking of searching a text file in an editor, which is 
not what we were discussing; we were discussing finding files in the shell.

>> That's when drawing freehand rather than doing something else, such as
>> dragging pre-created image fragments around and assembling them in some
>> manner or applying filters, etc.
>
> You can use pen tablet instead of mouse.

If you have a spare $200 lying around, perhaps you can.

> I agree that mouse is an excellent poor man's choice. You can do
> everything with it, but in a slow and sloppy way.

Classic erroneous presupposition. Obviously you've never seen a mouse 
wielded by someone truly proficient in its use -- or you've seen bad 
mice. Ball mice that haven't had their bearings cleaned in a while, 
perhaps. Even a ten-dollar optical mouse from the bargain bin at Office 
Depot will outperform *that*.

On 12/05/2012 6:34 AM, Tim Bradshaw wrote:
> On 2012-05-12 05:37:18 +0000, Jumpin' Jehoshaphat said:
>
>> For some of us, the goal is to avoid *anything* else killing the
>> system, Bradshaw.
>
> Quite. But that's not achievable in a world governed by the laws of
> physics, let alone with the hardware and software we're constrained to
> use in practice.

Hardly an excuse for making choices likely to accelerate the process, 
like overusing unix's execrable "rm" manually instead of leaving that 
for use by heavily-tested-and-debugged scripts, where it belongs. Unix 
"rm" is like a nailgun with fully automatic fire and no safety regulator 
preventing it from working if something isn't pressed up against it. You 
want that held by a robot arm over a conveyor belt cordoned off from any 
approach by humans with big signs saying "KEEP CLEAR WHILE EQUIPMENT 
OPERATING", humming away with distant supervision making cheap Japanese 
cars until someone hits the big red "Emergency Stop" button so 
maintenance can be performed safely. You don't want that wielded by the 
human hands of a handyman building a house, unless you don't mind seeing 
the neighborhood riddled with holes if, in typical human fashion, that 
handyman errs.

On 12/05/2012 4:58 AM, Alex Mizrahi wrote:
>> No, *you* missed the part about the proficient FPS players whose mouse
>> use is not hampered by that lag.
>
> I've just imagined proficient FPS players using mouse in Emacs. LOL.
>
> (BTW when those FPS players need to reconfigure keybindings in game up
> to their taste they type them in game console with insanely fast speed.
> So they know how to use keyboard efficiently wherever it makes sense.

Has anyone claimed otherwise?

On 2012-05-12 11:05:22 +0000, Jumpin' Jehoshaphat said:

> Well, that's even stupider. That requires a printer, toner, and paper, 
> meaning it actually costs *money* as well as disk space and the need to 
> muck about with proprietary apps.

You will be shocked to discover that I bought my copy of the TeXbook, 
in a shop, in 1987 (amusingly on the flyleaf it has a note pointing to 
the UK TeX archive that starts "uk.ac").    And yes, it costs money, 
but there's a famous quote about money and time, isn't there?

> And then you can't even copy and paste from it! You have to actually 
> copy manually, turning your head a large distance to read the next bit 
> of a long, not easily memorized alphanumeric string, then turning back 
> to the computer and typing a part, turning to read another bit, turning 
> back and typing that, and so forth.

Paper has this wonderful property that you can read it in bed, outside, 
and so on, and it has really good characteristics for reading: it might 
be that the most recent generation of tablets is getting close to that, 
but I suspect they aren't really anywhere near yet.  And, of course, 
people who make their living typing up mathematical manuscripts don't 
have a problem reading something and typing it in again.  And for added 
value *reading something and writing it out is how you learn it*, while 
cutting ans pasting pretty much ensures you never learn.  Pretty 
quickly you never need to refer to it at all unless you have to write 
some particularly hairy macro.

As for screen space: it still matters, especially if (like me) you want 
never to have to use anything you can't carry with you: I have no time 
for huge screens taking up half a room in my house.  It also matters, 
if what you do is writing, to have an editor where what you see on the 
screen is *just the text* rather than some vast encrustation of obscure 
toolbar crap (for writing TeX I typically want just the text with a 
preview window beside it being kept up to date by latexmk in the 
background, though I am not sure I really want the preview - I'd have 
to write more than I currently do to know).  Interestingly people are 
finally realising this: I don't really use many commercial WP systems, 
but I maintain my CV in Pages, and the current version of that has a 
pretty decent full-screen mode which has had the courage to just 
"waste" most of the screen space by making it black rather than make 
lines absurdly long or fill it with spurious buttony cruft.

Well, I'm done with this now.

On 12/05/2012 8:10 AM, Tim Bradshaw wrote:
> On 2012-05-12 11:05:22 +0000, Jumpin' Jehoshaphat said:
>
>> Well, that's even stupider. That requires a printer, toner, and paper,
>> meaning it actually costs *money* as well as disk space and the need
>> to muck about with proprietary apps.
>
> You will be

You will let me stay caught up on this thread for more than just a few 
minutes at a time!

>> And then you can't even copy and paste from it! You have to actually
>> copy manually, turning your head a large distance to read the next bit
>> of a long, not easily memorized alphanumeric string, then turning back
>> to the computer and typing a part, turning to read another bit,
>> turning back and typing that, and so forth.
>
> Paper has this wonderful property that you can read it in bed, outside,
> and so on,

Not very useful when it's a computer reference so the place where you 
need to refer to it is at your desk with your computer within easy 
reach. None of those arguable advantages over electronic documents 
applies in that case, but all of the disadvantages (no search, no copy 
and paste, expensive, bulky to store...) still apply.

> and it has really good characteristics for reading: it might
> be that the most recent generation of tablets is getting close to that,
> but I suspect they aren't really anywhere near yet.

Classic contradiction, and inside a single sentence at that.

> And for added value *reading something and writing it out is how you
> learn it*

It was last century. Nowadays we have superior ways of learning, as we 
do other things.

> while cutting ans pasting pretty much ensures you never learn.

You're not making sense. You can see what you just pasted and will 
remember it if you find yourself starting to use it frequently.

> Pretty quickly you never need to refer to it at all unless you have to
> write some particularly hairy macro.

Don't be ridiculous. There are thousands of arcane commands, many with 
not-very-mnemonic names, for thousands of different symbols and other 
things. Unless you never use more than a specific, fixed, narrow subset 
of them, you *will not* remember all of the ones you use and sometimes 
*will* need to refer to something or have some other method of inserting 
a symbol.

> As for screen space: it still matters, especially if (like me) you want
> never to have to use anything you can't carry with you:

If you'd rather live a vagrant-ish life, with a few portable gadgets and 
maybe a vehicle but no house or other large, fixed possessions, then 
good for you. (Though that isn't very compatible with giant shelves full 
of printouts and books!)

Most of us don't mind, or actively like, putting down roots and having a 
house and other bulky, non-portable things.

> It also matters, if what you do is writing, to have an editor where what
> you see on the screen is *just the text* rather than some vast
> encrustation of obscure toolbar crap

That "vast encrustation of obscure toolbar crap" is how the rest of us 
can find less-frequently-used symbols and commands when we need to use 
them in seconds of clicking instead of hours of poring over manuals or 
paging through unhelpful help files or even digging through drawers for 
a printed cheat-sheet listing thousands of obscure control-key 
combinations or command strings.

>>> That is incorrect. I just didn't agree with it.

>> You replied with completely irrelevant pieces.

> Classic unsubstantiated and erroneous claim.

I've substantiated it twice (or thrice?). Re-read what I said and come 
back when you understand.

> In any event, a proficient mouse user is a lot faster and more accurate
> than a novice like, I assume, you are and anyone else here is who is
> sour on mouse use.

Classic unsubstantiated and erroneous assumption.

I use mouse when I play those first-person shooters: after all, they 
were designed with mouse in mind. I also use mouse for web browsing, 
drawing and lots of other things. But I prefer keyboard for file-related 
stuff, running commands, writing code and so on.

I really don't get why do you think I'm some mouse-hating zealot. It was 
just a great opportunity for you to troll people, wasn't it?

>>> In my experience it's better to fix whatever the problem is (e.g. nice a
>>> process that started hogging the CPU, or restart it if it's not supposed
>>> to occasionally do that, or even debug it and recompile it)
>> Are you retarded?

> What does your ridiculous question have to do with the topic at hand,
> Mizrahi?

Everything you wrote so far has absolutely nothing to do with topic at 
hand, Jephosophat. So, why not?

By the way, who allowed you to call me by the last name? I didn't.

>
>> I need a fucking console to kill that fucking process.
>
> What does your foul language have to do with Lisp, Mizrahi?

Retarded people like you annoying me to no end, Jehoshaft. Sorry, I 
can't help it.

> Of course
> you don't; there are graphical process-management tools out there for
> those who prefer them.

lolwut, when system is thrashing mouse is barely moving. Good fucking luck.

> Also, one hopes one only has to nice processes
> that are hogging the CPU or otherwise slowing the system down on
> infrequent occasions.

"Hogging the CPU" isn't a problem at all. Thrashing is when kernel 
itself 'hogs' a system due to intensive paging or something.
In theory this shouldn't happen, but it happens.

If you had more practice you would know that.

> As for a fix-and-recompile one hopes one only has
> to do that *once*, and then the problem won't happen again.

You don't even understand what I'm talking about... System might be out 
of memory for a lots of reasons.

>> How is that related? Should I use a browser instead of SSH?

> If you're complaining about GUIs being lagged by the network you're not
> using SSH.

I compared VNC to SSH. Some programs can work only over VNC or a similar 
protocol, so I had a chance to compare these approaches.

>>> You're hypothesizing
>> I do not hypothesize
> Classic unsubstantiated and erroneous claim.

LOL.
I say I have a very concrete experience: system is thrashing, GUI is not 
responsive, I go to console and fix problem from it.
Do you claim that it didn't happen?
Do you want me to send you a video of incident or something?

>> Are you saying there is no need in non-client-server software?

> You are confused. We had been discussing UIs slowed down by network lag,
> which doesn't affect you when working with purely local software.

And?


>> Well, maybe you grit your teeth, but I comfortably use SSH each day.
>
> How can you "comfortably" use anything that forces you to see the work
> you're doing through a keyhole instead of in widescreen HD?

My terminal is "widescreen HD".

> what a command prompt does, of course, what with the little-to-no
> context it displays while you work.

Ehm. I see a history which goes a long back. You don't.

> Not to mention forces you to,
> instead of hands-on manipulating whatever it is you're working on,

Whenever I think of something my hands do that. It is was more hands-on 
than you can imagine.

Do you experience any communication problem when you talk to people? I 
don't. I don't have a problem in communicating with server over SSH.

> Unless you have a big job to do that's easily specified as a rote
> mechanical action you'll have just as much work to do as doing it
> yourself, with a higher likelihood of error and worse potential
> consequences of such an error.

Well, um. Let's say I need to check access rights on file 
/home/foo/bar.txt on server quux. I type

    ssh quux stat /home/foo/bar.txt

It takes just a couple of seconds to get results.

This is what I would call 'doing it myself' -- I think of something, 
translate it to shell language, type and get results.

Please describe how you would do this.

  Actually, you'll have *more* work to do
> -- for example, moving a file might, instead of one click and drag

You're missing the fact that you need to find file and place to drag it 
to before, which takes a lot of time.

> taking a second or so, take fifty or more keystrokes and three or four
> seconds.

'fifty or more keystokes' includes finding file. You intentionally 
compare apples to oranges.

> You may see
>
> local %>
>
> and maybe you're in etc/local and maybe you're in usr/local.

I see full path.

> With a GUI
> you can see at a glance where you are because the files in the directory
> you're in are displayed right there on the screen.

Oh, so you read whole directory list before you do somethihg? How cute.
Yes, it totally makes sense to look at files instead of full directory path.

> Sure, for some things, it's slower, but it's also safer,

It's possible to configure rm to ask always.

> Not to mention a GUI gives you the nifty ability to have more than one
> "current directory" at a time,

I can open many terminals and many terminal tabs.

>> It doesn't need to be a prefix, incremental search can find parts in the
>> middle.
>
> You are confused. Tab completion needs a prefix.

It depends on what you use and how you configured it.
I use zsh which has very sophisticated and configurable completion 
system. It can, among other things, do glob expansion:

`cd *890<TAB>` becomes `cd 1234567890/`

> You seem to be thinking of searching a text file in an editor, which is
> not what we were discussing; we were discussing finding files in the shell.

Shell is much more general concept, see here:
http://en.wikipedia.org/wiki/Shell_(computing)

I believe Emacs with dired and stuff can be seen as a shell too, after 
all it provides same basic functionality as Windows Shell. And you can 
use free-form incremental search in dired.

Tim Bradshaw <tfb@tfeb.org> writes:

> Paper has this wonderful property that you can read it in bed,
> outside, and so on, and it has really good characteristics for
> reading: it might be that the most recent generation of tablets is
> getting close to that, but I suspect they aren't really anywhere near
> yet. 

Well, the only thing that tablets lack vs. paper, is the energetic
independence.  Paper just use whatever light energy you shower it with.
Tablets need a daily reload.   Other than that, I prefer to read on
tablet (or computer screen) and I have always prefered it.  (Zoom,
choice of font, ease of navigation, not counting copy-and-paste, even on
tablet thru email).


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

>> They are common to all humans. Cats are faster I think, but they don't
>> use computers.

> Apparently proficient FPS players are also faster than you. And perhaps
> most other humans.

Reaction time was a subject of scientific studies, and results are well 
known. See here:

http://en.wikipedia.org/wiki/Mental_chronometry

If you think that FPS players have different reaction time, please cite 
a study.

I guess you're mistaken: proficient FPS players are trained to move 
controller to exact required position without further feedback. I.e. 
once they see something they send commands to muscles to move cursor and 
shoot without analyzing picture.

But this is still a subject of reaction time, so time from seeing a 
target to shooting is at least 100 ms (likely more).

The difference between you and a professional FPS player is that you 
need feedback to position cursor. I.e. you see a target, move a mouse, 
check whether you over-shoot or under-shoot, move it again and so on.

So, basically, for them it is 100+ ms. For you it is N * 100 ms where N>1.

Got it, Jehoshaphat?

On 05/12/2012 09:21 PM, Pascal J. Bourguignon wrote:
>
> Well, the only thing that tablets lack vs. paper, is the energetic
> independence.  Paper just use whatever light energy you shower it with.
> Tablets need a daily reload.   Other than that, I prefer to read on
> tablet (or computer screen) and I have always prefered it.  (Zoom,
> choice of font, ease of navigation, not counting copy-and-paste, even on
> tablet thru email).
>
Well a kindle is not backlit. It has a contrast that is better than 
newspaper. I have the DX version which has 9.5" screen. Good enough to 
read PDF's which is why I wanted it. I only need to recharge it one a 
week or so. Electronic ink has the advantage that it doesn't consume 
energy except when you change pages which is perfect for reading books. 
However it is too slow to really do anything interactive. All the same I 
am quite happy with it. In many ways it is better than a book. At least 
these heavy things you call handbooks. It weight much less, fits in one 
hand, and you can put it down without loosing your page.

On 2012-05-12, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
>>> They are common to all humans. Cats are faster I think, but they don't
>>> use computers.
>
>> Apparently proficient FPS players are also faster than you. And perhaps
>> most other humans.
>
> Reaction time was a subject of scientific studies, and results are well 
> known. See here:
>
> http://en.wikipedia.org/wiki/Mental_chronometry
>
> If you think that FPS players have different reaction time, please cite 
> a study.

You're responding to someone who has never written anything that was correct,
and never responded to any point anyone has ever made in a way that showed
understanding. Furthermore, never written a single article that was topical to
the newsgroup in which it was posted.  Not a shred of antyhing to do with Lisp
here, etc.  Moreover, that someone changes identities more often than underwear
to evade killfiles.  The right treatment for this despicable maggot is swift
and total ostracism.

You and I are real people with real credentials; let's talk about something.

What interesting thing have you worked on lately?

* Alex Mizrahi <4fae84f6$0$284$14726298@news.sunsite.dk> :
Wrote on Sat, 12 May 2012 18:42:44 +0300:

| I believe Emacs with dired and stuff can be seen as a shell too, after
| all it provides same basic functionality as Windows Shell. And you can
| use free-form incremental search in dired.

Emacs "wdired" is more than that.  After a C-x C-q, you can edit the
dired buffer like any other emacs buffer --- change names of files,
reedit symbolic links, etc).  Then when you (C-c C-c) commit the
changes, wdired will batch the changes and then perform the file system
operations.

Sadly this powerful UI notion of 1) notating changes, 2) batching them
up and 3) actually performing them appears to have lost to the more
crippling "manipulate on representation with immediate effect" idea.

This was most painfully evident when I tried using the much advertised
gnu `parted' program for disk partitioning.  All other tools have
traditionally allowed you to build up the partition table and then
commit the changes.  On the other hand parted immediately screws up the
filesystem on any command --- following with the top-down "dumb down the
software" investments model

--- Madhu

On 12/05/2012 3:35 PM, Alex Mizrahi wrote:
>>> They are common to all humans. Cats are faster I think, but they don't
>>> use computers.
>
>> Apparently proficient FPS players are also faster than you. And perhaps
>> most other humans.
>
> Reaction time was a subject of scientific studies, and results are well
> known. See here:
>
> http://en.wikipedia.org/wiki/Mental_chronometry
>
> If you think that FPS players have different reaction time, please cite
> a study.

You're purposely missing the point, as usual. I'm not claiming the 
reaction time is different. I'm claiming the reaction time is not a 
problem because you can train your automatic motor memory to perform 
actions, even requiring some degree of feedback (hand/eye coordination), 
fast enough.

> The difference between you and a professional FPS player

How do you know I'm not one? ;)

On 12/05/2012 5:53 PM, Kaz Kylheku wrote:
> On 2012-05-12, Alex Mizrahi<alex.mizrahi@gmail.com>  wrote:
>> If you think that FPS players have different reaction time, please cite
>> a study.
>
> You're responding to someone who has never written anything that was correct,

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kylheku?

> and never responded to any point anyone has ever made in a way that showed
> understanding.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kylheku?

> Furthermore, never written a single article that was topical to the newsgroup
> in which it was posted.

The parent post of my first post here was equally off-topic, Kylheku.

> Moreover, that someone changes identities more often than underwear to evade
> killfiles.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kylheku?

> The right treatment for this despicable maggot is swift and total ostracism.

Who is "this despicable maggot", Kylheku? There is nobody in this 
newsgroup using that alias.

> You and I are real people with real credentials; let's talk about something.

Classic erroneous presupposition that I'm fictitious.

> What interesting thing have you worked on lately?

What does your question of Mizrahi have to do with Lisp, Kylheku?

On 12/05/2012 11:42 AM, Alex Mizrahi wrote:
>>>> That is incorrect. I just didn't agree with it.
>
>>> You replied with completely irrelevant pieces.
>
>> Classic unsubstantiated and erroneous claim.
>
> I've substantiated it twice (or thrice?).

Classic unsubstantiated and erroneous claim.

> Re-read what I said and come back when you understand.

Classic erroneous presupposition.

>> In any event, a proficient mouse user is a lot faster and more accurate
>> than a novice like, I assume, you are and anyone else here is who is
>> sour on mouse use.
>
> Classic unsubstantiated and erroneous assumption.

On your part.

> I use mouse when I play those first-person shooters: after all, they
> were designed with mouse in mind. I also use mouse for web browsing,
> drawing and lots of other things.

But have not become sufficiently proficient with it to not find it slow, 
Mizrahi, by your own admission.

> I really don't get why do you think I'm some mouse-hating zealot.

Based on the contents of your previous posts to this thread, Mizrahi.

> It was just a great opportunity for you to troll people, wasn't it?

No.

>>> Are you retarded?
>
>> What does your ridiculous question have to do with the topic at hand,
>> Mizrahi?
>
> Everything you wrote so far has absolutely nothing to do with topic at
> hand, Jephosophat.

Classic unsubstantiated and erroneous claim.

> So, why not?

Well, for one thing, it's rude, and a leading question like that might 
lead people to jump erroneously to the conclusion that the answer would 
have been "yes".

> By the way, who allowed you to call me by the last name? I didn't.

You disclosed it to a public newsgroup, Mizrahi. Would you prefer if I 
called you "idiot" instead?

>>> I need a fucking console to kill that fucking process.
>>
>> What does your foul language have to do with Lisp, Mizrahi?
>
> Retarded people like you annoying me to no end, Jehoshaft.

Who is "Jehoshaft", Mizrahi? There is nobody in this newsgroup using 
that alias.

> Sorry, I can't help it.

What does your Tourette's Syndrome have to do with mouse speed *or* 
Lisp, Mizrahi?

>> Of course
>> you don't; there are graphical process-management tools out there for
>> those who prefer them.
>
> lolwut, when system is thrashing mouse is barely moving.

You must be using a badly-designed system. Properly designed systems 
give much higher CPU priorities to the processes and threads involved in 
updating the cursor display and feeding the event pump. Proper task 
management tools also run with elevated priority, so that they'll remain 
snappily responsive even if something else is bogging down the system, 
as long as that something else doesn't also have elevated priority.

> Good fucking luck.

What does your foul language have to do with Lisp, Mizrahi?

>> Also, one hopes one only has to nice processes
>> that are hogging the CPU or otherwise slowing the system down on
>> infrequent occasions.
>
> "Hogging the CPU" isn't a problem at all. Thrashing is when kernel
> itself 'hogs' a system due to intensive paging or something.

That shouldn't happen unless your system has too little RAM for what 
you're trying to do with it, or the OS is poorly written.

> If you had more practice you would know that.

Classic erroneous presupposition. I've been using computers for decades 
and probably since before you were in diapers, Mizrahi.

>> As for a fix-and-recompile one hopes one only has
>> to do that *once*, and then the problem won't happen again.
>
> You don't even understand what I'm talking about...

Classic unsubstantiated and erroneous claim.

> System might be out of memory for a lots of reasons.

We had been discussing CPU hogs, not memory, Mizrahi. You changed the 
subject to memory with your last post, which is the one *after* the one 
I was responding to there, Mizrahi. But the most usual reasons are you 
don't have enough in the hardware or you're using a crappy OS, Mizrahi.

>>> How is that related? Should I use a browser instead of SSH?
>
>> If you're complaining about GUIs being lagged by the network you're not
>> using SSH.
>
> I compared VNC to SSH.

Classic unsubstantiated and erroneous claim. You only mentioned VNC for 
the first time *later* in that posting. At the point where I wrote the 
above SSH was the only one of the two you'd mentioned.

>>>> You're hypothesizing
>>> I do not hypothesize
>> Classic unsubstantiated and erroneous claim.
>
> LOL.

What does your amusement at your own mistake have to do with Lisp, Mizrahi?

>>> Are you saying there is no need in non-client-server software?
>
>> You are confused. We had been discussing UIs slowed down by network lag,
>> which doesn't affect you when working with purely local software.
>
> And?

If you're confused by simple English, I cannot help you, Mizrahi.

>>> Well, maybe you grit your teeth, but I comfortably use SSH each day.
>>
>> How can you "comfortably" use anything that forces you to see the work
>> you're doing through a keyhole instead of in widescreen HD?
>
> My terminal is "widescreen HD".

Classic unsubstantiated and erroneous claim. You don't by default see 
the context of your own actions, unlike with a GUI, Mizrahi.

>> what a command prompt does, of course, what with the little-to-no
>> context it displays while you work.
>
> Ehm. I see a history which goes a long back. You don't.

Classic unsubstantiated and erroneous claim. The command prompt can be 
told explicitly to display a command history or a listing of the current 
directory but you don't see these automatically. At best, a command 
prompt user is swinging a narrow flashlight beam around in a darkened 
room while a GUI user has the main overhead lights on and can see 
everything at once, all the time.

>> Not to mention forces you to,
>> instead of hands-on manipulating whatever it is you're working on,
>
> Whenever I think of something my hands do that. It is was more hands-on
> than you can imagine.

Classic unsubstantiated and erroneous claim. For one thing I don't have 
to imagine; I've used both. For another, instead of just picking up a 
file and moving it you have to talk to a command interpreter that will 
then do it for you ... *if* you managed to get the spelling of 
everything right.

> Do you experience any communication problem when you talk to people?

No, but I find it faster to, say, pick up an object from a shelf and put 
it on a table myself than to tell someone else to do it, even if they're 
immediately compliant and very fast, unless I'm nowhere near the object 
and they're right next to it. It's also less likely that something will 
go wrong; versus the someone else mishearing me or thinking I meant a 
different object. Of course, the CLI doesn't make mistakes, per se; but 
it is easily confused by any typo or by any ambiguity. And by spaces in 
filenames, hyphens at the starts of filenames, and so on, and so forth.

>> Unless you have a big job to do that's easily specified as a rote
>> mechanical action you'll have just as much work to do as doing it
>> yourself, with a higher likelihood of error and worse potential
>> consequences of such an error.
>
> Well, um. Let's say I need to check access rights on file
> /home/foo/bar.txt on server quux. I type
>
> ssh quux stat /home/foo/bar.txt
>
> It takes just a couple of seconds to get results.
>
> This is what I would call 'doing it myself' -- I think of something,
> translate it to shell language, type and get results.

The need to translate and type it is the thing that increases the time 
and the error probability.

> Please describe how you would do this.

I'd click or otherwise select the file's icon in an FTP browser at my 
end and hit alt-enter to get "Properties". The file ownership would be 
displayed along with various other information.

Not necessarily much better than typing your short command, but no need 
for repetitive "ssh quux" prefixes and if the filename is a lot longer 
and more awkward to type than "bar.txt" it's a helluva lot faster to 
click it than type it.

> Actually, you'll have *more* work to do
>> -- for example, moving a file might, instead of one click and drag
>
> You're missing the fact that

Classic unsubstantiated and erroneous claim.

> you need to find file and place to drag it to before, which takes a
> lot of time.

In most cases, if I'm moving files I'm moving many from the same place 
to the same other place, or subdirectories of that other place, and then 
I only need to find the directories once. At your precious CLI you'll 
need to keep specifying one of them over and over again, though the 
other be your shell's cwd.

Even for a one-off move of a single file it's likely it's the newest, 
oldest, or something-else-est file in its directory, and I'll have it 
open and set to the appropriate sort order for that file to be the 
top-left one in that case.

One thing you're missing from your shell use is the ability to just open 
a directory and leave it open, backgrounded, to switch to quickly if you 
are frequently doing things there but doing other things in between. 
Your shell, with its one-cwd-at-a-time philosophy, makes user 
multitasking difficult by contrast.

>> taking a second or so, take fifty or more keystrokes and three or four
>> seconds.
>
> 'fifty or more keystokes' includes finding file.

Versus a quick visual scan and a click, taking a second or less, or at 
worst a scroll wheel flick or two first and then those, taking two to 
three seconds. And that even if the file name is 200 characters long and 
full of spaces, quotation marks, and other things your shell is allergic to.

> You intentionally compare apples to oranges.

Classic unsubstantiated and erroneous claim.

>> You may see
>>
>> local %>
>>
>> and maybe you're in etc/local and maybe you're in usr/local.
>
> I see full path.

Classic unsubstantiated and erroneous claim, and indeed impossible even 
in principle for deep enough nested subdirectories (77 characters and 
the terminal width is reached at the > of the prompt and you type your 
command blind, off the right-hand side of the screen; 81 or more and 
some of the path would be out of view too).

I've actually seen some unix systems display a prompt of just

%>

Now you're in a darkened room with*out* a flashlight. Yay.

>> With a GUI
>> you can see at a glance where you are because the files in the directory
>> you're in are displayed right there on the screen.
>
> Oh, so you read whole directory list before you do somethihg? How cute.

Of course not. But it's there at a glance if I do need to refer to it, 
and if I'm not where I expected to be I'll notice it.

Do you carefully scan every inch of a room you're in every time you take 
a step or work with an object in it? No. Would you like to work in the 
same room, but in pitch darkness? Thought not.

>> Sure, for some things, it's slower, but it's also safer,
>
> It's possible to configure rm to ask always.

Classic unsubstantiated and erroneous claim. There are things you can do 
to try, but they all run into problems. For example you can alias rm to 
rm -i but you're liable to get an infinite recursive expansion rm -> rm 
-i -> rm -i -i -> ... and failing that there are various other caveats; 
you could also (if sysadmin) change the source code and recompile rm, or 
rename the rm binary to rmx and write a script rm that calls rmx -i with 
its arguments, but then scripts that expect rm without -i to return 
promptly rather than prompt the user will break.

>> Not to mention a GUI gives you the nifty ability to have more than one
>> "current directory" at a time,
>
> I can open many terminals and many terminal tabs.

Classic unsubstantiated and erroneous claim.

>>> It doesn't need to be a prefix, incremental search can find parts in the
>>> middle.
>>
>> You are confused. Tab completion needs a prefix.
>
> It depends on what you use and how you configured it.

Classic unsubstantiated and erroneous claim. Tab completion needs a prefix.

>> You seem to be thinking of searching a text file in an editor, which is
>> not what we were discussing; we were discussing finding files in the
>> shell.
>
> Shell is much more general concept,

Classic irrelevancy. We were, specifically, discussing a CLI shell ala 
Unix "sh".

On Tue, 08 May 2012 20:29:47 +0200, "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html

Simply priceless :-)

On Tue, 08 May 2012 23:54:09 +0300, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
>>   http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html
>
> Maybe if Yegge typed slower his essays would be shorter and more
> readable.
>
> But, anyway, there isn't really a need to learn touch typing -- in a
> few decades of intensive typing you can pick it up automatically. Not
> just letters but all keys you use.

That's exactly the sort of 'touch typing' I know.  Typing is now, after
~19 yeras, an acquired habit for me.  I don't type super-fast, and I
don't always write the correct thing, but I don't really have to look at
the keyboard anymore.

Funny personal story:

In Greek touch-typing is called 'blind system'; an allusion to the fact
that you are not supposed to look to the keyboard while typing. Now,
when someome asks me how I learned to touch type, I jokingly explain
that I started by a similar 'blind system': not looking at the screen,
but staring _really_ hard to the keyboard and trying not to miss the
correct keys.  For about 10 years in a row...

On 2012-05-13, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> On Tue, 08 May 2012 20:29:47 +0200, "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
>> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html
>
> Simply priceless :-)

I too once didn't know how to touch type properly, with all ten fingers, and it
was obvious that this was sorely lacking in my programming, participation in
BBSes and so on.

In the ninth grade, I, too, like Steve, found a typing class on the list of
available things to take and signed up.

However, being academic minded, I simply could not fathom sitting through an
entire semester of a retarded class built around cranking out mindless
gibberish.  To think that I would have to attend that properly to get a grade
and probably pass some typing tests and whatnot just didn't sit well with me.
One week into it, I dropped the course and switched to something meaningful.

But of course, I had made a resolution to learn to type, and would fulfill it
somehow.  So I borrowed a typing tutorial book from a library. The book had
some progressive exercises: various sentences to type out one by one. I too
each exercise and instead of typing it once, I filled the entire screen with
repetitions of that text before moving on to the next piece of text. I forced
myself not to look at my fingers.

The progression made it easy because the first exercises were confined to the
home row, gradually adding more and more distant keys.

Within a some two weeks, I had gone through the whole book and was able to
touch type.

On Thursday, May 10, 2012 3:08:02 PM UTC+1, Tim Bradshaw wrote:
> On 2012-05-10 08:34:29 +0000, Alex Mizrahi said:

> > Huh? At school level people work with concrete numbers, but on more 
> > advanced level there are barely any numbers in formulas.
> 
> > I don't know much above physics above school level, but I've got M.Sc. 
> > applied math degree without being particularly good at arithmetics.
> 
> Well yes.  It turns out that in physics numbers do matter.  A very 
> important skill (which people are explicitly taught) is to be able to 
> have a feeling for whether something is "reasonable" which can mean 
> various things, but often means "is it about the right size?"

yes, fine. And I can do those sort of calculations

> and that 
> requires, among other things, the ability to get numerical estimates of 
> stuff very quickly.

ok.

> And although you are almost never doing literal arithmetic

quite

> (you're typically just trying to get an answer which is 
> right to an order of magnitude and some kind of notion of how rough the 
> answer is),

which usually means adding up powers of 10

> you really can't do this without being pretty competent at 
> arithmetic, it turns out.

no. You just have to be add and subtract reasonably small numbers. The average primary school child could do this.

> If you want a really good example of this there are several in 
> Feynman's autobiographical books.  Obviously he was better than most.

hardly ordinary even amongst physicists. 

> It's very tempting to say "oh, none of this matters now, you just use a 
> computer" but that turns out not to be right for reasons I'm too tired 
> to explain now, but are, I think, well-known.

riight. "Well known" in this case being old wives tale

> >> I know this because at a slightly different level it's what happened to
> >> me: I was lazy, didn't practice enough boring mathematical methods
> >> stuff, and that lack of fluency came back and bit me later.
> 
> > Math =/= arithmetics.
> 
> I am aware of the difference.  That's why I said "at a slightly 
> different level".

> You're responding to someone who has never written anything that was correct,
> and never responded to any point anyone has ever made in a way that showed
> understanding. Furthermore, never written a single article that was topical to
> the newsgroup in which it was posted.  Not a shred of antyhing to do with Lisp
> here, etc.  Moreover, that someone changes identities more often than underwear
> to evade killfiles.  The right treatment for this despicable maggot is swift
> and total ostracism.

I know, but still it is kinda entertaining, up to a point.

This might be a classic example of bikeshedding:

http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

Non-essential topic gets a lots of discussion because everybody has an 
opinion and it's easy to discuss it, while more important questions 
require more mental effort and background knowledge and thus are ignored.


> You and I are real people with real credentials; let's talk about something.
> What interesting thing have you worked on lately?

1. Two weeks ago I announced nodeweb web microframework, but it was not 
discussed in newsgroup at all. Bikeshedding FTW.

2. I've repaired abcl-web to work with latest ABCL. I had to interact 
with Java stuff to do that, and in two days I've seen so much bizarre 
and broken stuff that I can probably write a book about it.

3. I'm considering reviving my easy-web-programming project, this time I 
have a clearer idea about what it should do.

That's all, I think. What's about you?

>> What interesting thing have you worked on lately?

> What does your question of Mizrahi have to do with Lisp, Kylheku?

Like, everything?

Kaz asks about news on Lisp-related projects in a Lisp _news_ group. 
This is a very appropriate use of newsgroup.

On 15/05/2012 3:52 AM, Alex Mizrahi wrote:
>>> What interesting thing have you worked on lately?
>
>> What does your question of Mizrahi have to do with Lisp, Kylheku?
>
> Like, everything?
>
> Kaz asks about news on Lisp-related projects in a Lisp _news_ group.

Actually, he just asked "What interesting thing have you worked on 
lately?" which is very broad and general and not specifically about 
Lisp, Mizrahi. The answer could as easily be "cataloguing 7000 
photographs of Adriana Lima", Mizrahi.

On 15/05/2012 17:12, Jumpin' Jehoshaphat wrote:
> On 15/05/2012 3:52 AM, Alex Mizrahi wrote:
>>>> What interesting thing have you worked on lately?
>>
>>> What does your question of Mizrahi have to do with Lisp, Kylheku?
>>
>> Like, everything?
>>
>> Kaz asks about news on Lisp-related projects in a Lisp _news_ group.
>
> Actually, he just asked "What interesting thing have you worked on
> lately?" which is very broad and general and not specifically about
> Lisp, Mizrahi. The answer could as easily be "cataloguing 7000
> photographs of Adriana Lima", Mizrahi.

....but when this question is asked in a Lisp news group, it very 
obviously is about Lisp. (What else?)

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
The views expressed are my own, and not those of my employer.

On 15/05/2012 1:35 PM, Pascal Costanza wrote:
> On 15/05/2012 17:12, Jumpin' Jehoshaphat wrote:
>> Actually, he just asked "What interesting thing have you worked on
>> lately?" which is very broad and general and not specifically about
>> Lisp, Mizrahi. The answer could as easily be "cataloguing 7000
>> photographs of Adriana Lima", Mizrahi.
>
> ...but when this question is asked in a Lisp news group, it very
> obviously is about Lisp. (What else?)

How is it "very obviously" about Lisp? It doesn't specifically mention 
Lisp. Its immediately-surrounding context is Kylheku waxing paranoid and 
launching personal attacks at another user, which has nothing to do with 
Lisp.

On 15/05/2012 19:58, Jumpin' Jehoshaphat wrote:
> On 15/05/2012 1:35 PM, Pascal Costanza wrote:
>> On 15/05/2012 17:12, Jumpin' Jehoshaphat wrote:
>>> Actually, he just asked "What interesting thing have you worked on
>>> lately?" which is very broad and general and not specifically about
>>> Lisp, Mizrahi. The answer could as easily be "cataloguing 7000
>>> photographs of Adriana Lima", Mizrahi.
>>
>> ...but when this question is asked in a Lisp news group, it very
>> obviously is about Lisp. (What else?)
>
> How is it "very obviously" about Lisp? It doesn't specifically mention
> Lisp. Its immediately-surrounding context is Kylheku waxing paranoid and
> launching personal attacks at another user, which has nothing to do with
> Lisp.

Ugh, it's you again... :(


-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
The views expressed are my own, and not those of my employer.

On 15/05/2012 2:02 PM, Pascal Costanza wrote:
> On 15/05/2012 19:58, Jumpin' Jehoshaphat wrote:
>> How is it "very obviously" about Lisp? It doesn't specifically mention
>> Lisp. Its immediately-surrounding context is Kylheku waxing paranoid and
>> launching personal attacks at another user, which has nothing to do with
>> Lisp.
>
> Ugh, it's you again... :(

And just what the hell is *that* supposed to mean?

> How is it "very obviously" about Lisp? It doesn't specifically mention
> Lisp. Its immediately-surrounding context is Kylheku waxing paranoid and
> launching personal attacks at another user, which has nothing to do with
> Lisp.

Kaz mentioned 'real credentials'; this, apparently, means something 
Lisp-related.

On 15/05/2012 5:36 PM, Alex Mizrahi wrote:
>> How is it "very obviously" about Lisp? It doesn't specifically mention
>> Lisp. Its immediately-surrounding context is Kylheku waxing paranoid and
>> launching personal attacks at another user, which has nothing to do with
>> Lisp.
>
> Kaz mentioned 'real credentials'; this, apparently, means something
> Lisp-related.

"Apparently" as judged based on what? It could mean he has an FBI badge 
or a diploma in Japanese language studies for all we know. Those are 
"credentials". For that matter, your dotsrc.org news server login is a 
"credential".

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?

There is a LISP plugin for Eclipse that you can use called CUSP (use
your favorite search engine), and there's also Jabberwocky but it's not
currently in development. http://sourceforge.net/projects/jabberwocky/ 

Like Pascal said, if you feel inclined, write a LISP plugin for
Netbeans. You should be able to use CUPS as your basis IMHO. 

I do not mind using Emacs, I've been using for close to 20 years. But
took me a while to grow on me, so much that I use Emacs binding on
Eclipse (go figure) that I need to use for work. 



> Thanks for your time

-- 
Luis Anaya
Hacking PL/1 since 1990

Tim Bradshaw <tfb@tfeb.org> writes:

> On 2012-05-10 12:53:08 +0000, Jumpin' Jehoshaphat said:
>
>> So it's either toolbar buttons, an emacsesque bestiary of
>> impossible-to-memorize-them-all control-key combinations most of
[chomp]
> I'd guess that you've never typed any significant amount of maths.  I
> have, and TeX is just enormously faster than any kind of pick-and-drop
> thing.  Even now, nearly 30 years after doing any large amount of
[chomp]
> maths, and that really shows (troff may be as good, I just never
> learnt more than you needed to make a man page).

I learned troff/tbl/eqn in College (long story short, Ma Bell computer
grant) and I feel more comfortable typing eqn instructions than in 
LaTeX (forget about straight TeX). 

But at the end, is the same difference, if you are comfortable typing 
those commands using a text editor, you will be faster than drag and dropping 
from a palette. The only work around to drag and dropping is memorizing 
yet another slew of commands that start with Control or Alt used to
substitute those palette buttons.  

-- 
Luis Anaya
Hacking PL/1 since 1990

On 24/05/2012 8:39 AM, Luis Anaya wrote:
> But at the end, is the same difference, if you are comfortable typing
> those commands using a text editor, you will be faster than drag and dropping
> from a palette. The only work around to drag and dropping is memorizing
> yet another slew of commands that start with Control or Alt used to
> substitute those palette buttons.

Of course, if you'd bothered to actually read my post you'd know that my 
preference is to be able to *do both*, so I can type frequently used 
commands but don't have to dig through pdfs (or, worse, paper manuals) 
all the time for the ones I use less frequently. Best of both worlds.

Jumpin' Jehoshaphat <jj1058672395@gmail.com> writes:

> On 24/05/2012 8:39 AM, Luis Anaya wrote:
> Of course, if you'd bothered to actually read my post you'd know that

Of course I did not bothered. The reply was not meant to you. 

> my preference is to be able to *do both*, so I can type frequently
> used commands but don't have to dig through pdfs (or, worse, paper
> manuals) all the time for the ones I use less frequently. Best of both
> worlds.

I do not have (or had) any problems with anybody's preference of using a mouse
interface IDE. As a matter of fact, I listed two LISP IDE's that are
mouse enabled which are sensible options for programming in LISP besides
learning EMACS. 

(IMHO).

But, my mama used to say that "someone's head is a different world" and 
we all interact with computer systems in different ways within the 
limitations of the presented interface. 

Your point on self documenting facilities in software interfaces is
quite valid, but so it is the economy of hand movements, which is what
seems to be the core point of debate. For all the discussion, it seems
to boil down to personal preference; how much an individual is willing
to spend learning keyboard commands vs having a visual representation to
the expense of hand movement from the core position. 

I'm ,by no means, an expert in the study of Human-System
Interaction. I presume that there are plenty of published papers in
this matter for those who want to pursue this fully.


-- 
Luis R. Anaya
papoanaya aroba hot mail punto com

On 25/05/2012 10:23 AM, Luis Anaya wrote:
> Jumpin' Jehoshaphat<jj1058672395@gmail.com>  writes:
>
>> On 24/05/2012 8:39 AM, Luis Anaya wrote:
>> Of course, if you'd bothered to actually read my post you'd know that
>
> Of course I did not bothered. The reply was not meant to you.

Then it should have been a private email instead of a news post.

> Your point on self documenting facilities in software interfaces is
> quite valid, but so it is the economy of hand movements, which is what
> seems to be the core point of debate.

It seems to me that going to a palette-bar involves less hand movements 
than going to a pdf open in another window and scrolling/searching 
around in it, let alone going to a paper manual, to look something up.

> For all the discussion, it seems to boil down to personal preference;
> how much an individual is willing to spend learning keyboard commands
> vs having a visual representation to the expense of hand movement
> from the core position.

Classic erroneous presupposition that having a visual representation 
precludes also having keyboard-only access to all/the most common commands.

> I'm ,by no means, an expert in the study of Human-System
> Interaction.

That much has become quite obvious, Anaya; no need to tell me about it.

Jumpin' Jehoshaphat <jj1058672395@gmail.com> writes:

> On 25/05/2012 10:23 AM, Luis Anaya wrote:
>
> Then it should have been a private email instead of a news post.

Some people frown on unsolicited email in usenet.

> It seems to me that going to a palette-bar involves less hand
> movements than going to a pdf open in another window and
> scrolling/searching around in it, let alone going to a paper manual,
> to look something up.

That's your opinion. The question is, how often do you look for the
document to get the information you need vs the guarantee of having to
move your hand out to touch the mouse. 

>
> Classic erroneous presupposition that having a visual representation
> precludes also having keyboard-only access to all/the most common
> commands.

It depends on implementation and it is not certain. This is also an
erroneous presuposition that all software programs that have a visual
reprentation will include an equivalent key shortcut. It is up to the
developers, product manager or interface engineer to decide that and varies.

>> I'm ,by no means, an expert in the study of Human-System
>> Interaction.
>
> That much has become quite obvious, Anaya; no need to tell me about it.

At least I admit it. 

If you are and expert, by all means, show me your references and 
credentials to back up your claims. So far you have
written your opinions on this matter without any references.

However, we all have the right to have an opinion. I do respect that.

Luis Anaya

On 29/05/2012 4:35 PM, Luis Anaya wrote:
> Jumpin' Jehoshaphat<jj1058672395@gmail.com>  writes:
>
>> On 25/05/2012 10:23 AM, Luis Anaya wrote:
>>
>> Then it should have been a private email instead of a news post.
>
> Some people frown on unsolicited email in usenet.

Classic pontification.

>> It seems to me that going to a palette-bar involves less hand
>> movements than going to a pdf open in another window and
>> scrolling/searching around in it, let alone going to a paper manual,
>> to look something up.
>
> That's your opinion.

Classic unsubstantiated and erroneous claim. It's a measurable fact.

> The question is, how often do you look for the
> document to get the information you need vs the guarantee of having to
> move your hand out to touch the mouse.

Classic erroneous presupposition that having a palette toolbar 
inevitably precludes being able to directly type in the codes and 
commands that you remember.

>> Classic erroneous presupposition that having a visual representation
>> precludes also having keyboard-only access to all/the most common
>> commands.
>
> It depends on implementation and it is not certain. This is also an
> erroneous presuposition that all software programs that have a visual
> reprentation will include an equivalent key shortcut. It is up to the
> developers, product manager or interface engineer to decide that and varies.

That some software could be badly designed does not support your claim 
that palette bars are automatically bad. Furthermore, in the specific 
context of TeX software you should *always* be able to type a TeX 
command in directly -- if you remember which one to type to do what you 
want to do.

> If you are and expert, by all means, show me your references and
> credentials to back up your claims. So far you have
> written your opinions on this matter without any references.

What does your pontification have to do with Lisp, Anaya?

> However, we all have the right to have an opinion. I do respect that.

What does your pontification have to do with Lisp, Anaya?

> Luis Anaya

What does your alias have to do with Lisp, Anaya?