| |||||||||||||
Otte: staring into the abyssOtte: staring into the abyssPosted Jul 28, 2012 20:07 UTC (Sat) by nix (subscriber, #2304)In reply to: Otte: staring into the abyss by Wol Parent article: Otte: staring into the abyss
The whole point of being a touch typist is YOU DO NOT LOOK AT THE TYPEWRITER (or screen)Touch typists don't look at the screen? Huh? (OK, I know you can touch-type while e.g. reading something else... but generally one looks at the screen quite a lot when one is typing.)
(Log in to post comments)
Otte: staring into the abyss Posted Jul 28, 2012 22:26 UTC (Sat) by Wol (guest, #4433) [Link]
You've obviously never worked with a *trained* typist. Typists are trained NOT to look at the output! In an exam they would get heavily penalised for it.
A trained typist does 120wpm (here w actually means 5 characters). So that's 10 characters a second SUSTAINED OUTPUT. How are you going to "context switch" between reading the text you're copying, and the output on paper or screen?
You may look at the screen a lot while typing, but a trained typist looks at what they're copying, not what they've copied. While I'm typing I mostly don't look at the keyboard. Okay, I look at the screen to make sure I haven't made a mistake, but the point of being a trained typist is that you don't make mistakes, so you don't need to check the screen to find them. As such, if the computer throws things up on the screen, it is a REAL nuisance - don't forget I said a trained typist AVERAGES ten characters a second...
Cheers,
Otte: staring into the abyss Posted Jul 29, 2012 8:20 UTC (Sun) by rschroev (subscriber, #4164) [Link]
Very little of my daily typing involves copying text, and I presume the same is true for most of us. Most of my typing is for writing new text and code, so there is no source to look at. Looking at the output on screen seems to me to be the most logical thing to do. I don't just look at what I just typed, but also at the structure of the surrounding text, especially when I'm coding.
Sometimes when a coworkers asks me something, I look at them and keep typing, but then they think I do it just to show off. Which is true, partly.
I have to admit that I can't type without making mistakes, even though I've had some typing training (long ago). I make little mistakes when typing normal text like this comment, but it gets worse when I have to type a lot of non-alphanumeric characters, like when I'm writing code.
Otte: staring into the abyss Posted Jul 29, 2012 12:49 UTC (Sun) by Wol (guest, #4433) [Link]
Yup.
Something else I thought of, too - which is faster, to context-switch and take advantage of the computer's help, or to just carry on typing? If you're a fast typist, the computer "being helpful" is just getting in the way.
I play classical guitar, so I actually class myself as a 6-fingered typist, and typing this comment here it's actually quite obvious. I'm using my left hand "correctly" as a touch-typist and it's making almost no mistakes. My right hand is doing a two-fingered "hunt-n-peck", and making a lot of mistakes. So even if I don't have something to copy, autocomplete can be a real nuisance for me.
So yeah, for many of us auto-complete probably is helpful. But for someone who knows how to type, it's almost certainly faster and easier to turn it off (that is, you can find out how!) and do everything long hand - you'll do it faster than you can context switch.
Cheers,
Otte: staring into the abyss Posted Jul 29, 2012 13:12 UTC (Sun) by nix (subscriber, #2304) [Link] If you're a fast typist, the computer "being helpful" is just getting in the way.That's why IntelliSense-class 'helpful' things should obey two rules: operate on a customizable delay, and don't pop up things that change the semantics of input unless explicitly requested. In the Emacs world, CEDET with auto-complete.el does this, displaying potential tab-completions in faint text beside the cursor after a short delay (when you've obviously stopped typing in the middle of an identifier because you can't remember what it is), and only on hitting, say, the tab key do you get an actual popup menu to select potential matches from. I've seen IntelliSense systems that lack one or the other of these properties and they are both intolerable to use, either spamming you with stuff you already know, or popping up things and blocking user input when you don't want that.
Otte: staring into the abyss Posted Jul 29, 2012 13:09 UTC (Sun) by nix (subscriber, #2304) [Link]
Well, yeah, like I said. If you're copying text, you look at the text -- but if you're not, you don't stare into space! You look at the screen. (You *don't* look at the keyboard.)
Now you might defined a trained touch-typist as a trained touch-typist only if they happen to be doing transcription or other copying at the moment, but I think that's a tiny bit restrictive. It is possible to do things with computer systems other than copying text. :)
Otte: staring into the abyss Posted Jul 31, 2012 1:58 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
I find with my touch typing skills applied to an editor like VI, I can do complex bulk edits (such as moving blocks of code between functions, re-indenting blocks of code, etc) faster than the eye can even recognize what's happening on the screen. On a slow link, I can get ahead of the refresh significantly.
Others say they get dizzy if they try to watch.
So, while my eyes may be facing the screen, I'm not really seeing everything that I'm typing. And then there's plain text. Since my web browser routinely inserts 5-10 second pauses while I type, I often find myself looking away and thinking about what I'm trying to say rather than watching the herky-jerky nature of the text box.
I may not be a 120wpm professional secretary, but on timed typing tests I can pull 90-95wpm. I feel that's pretty respectable for an electrical engineer. ;-)
Otte: staring into the abyss Posted Jul 31, 2012 23:05 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh, likewise (only with Emacs instead of vi). However, I do have to think about it when I'm doing that. If I'm typing bulk text -- or at least bulk code -- I make typing errors often enough that I'll have to go back and correct later on, at least one every 80-character line. And this is despite actually having had touch-typing training a while back (as one of many things I was trying to fix my RSI: it didn't help).
I am willing to believe that my clinical coordination deficits make me a bad example though. Perhaps most people with typing training typo much less often than me, and can avoid looking at screens for long periods?
Otte: staring into the abyss Posted Aug 3, 2012 11:48 UTC (Fri) by man_ls (subscriber, #15091) [Link] Can't see how. I can imagine prose writers typing along by heart; the legendary Asimov comes to mind -- and his prodigious output is witness. But for code I don't know anyone who can write by heart. As has been said above, structure and context are crucial. Perhaps a more textual language might do the trick, and bring along miraculous productivity improvements... I think I prefer a more concise language, even at the cost of indentation marks.
Otte: staring into the abyss Posted Aug 3, 2012 12:31 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I guess it depends on the language and the nature of what it is you're writing. For what it's worth, I've typed most of this comment without looking at the text box. :-) It's just easier that way. I'll go back and read it before I hit submit. As for code, it's more often true that I'm not really "seeing" my edits when I'm restructuring existing code, as to writing new code. I do structure my code visually a rather particular way, though, so that I can do quite a lot with my peripheral vision. So, I more half-see than see much of my code, but I do rely on sight pretty heavily. I'm one of these folks that lines things up religiously. Examples:
/* Calculate bit_r 8-bit bit-reverse table */
for (i = 0; i < 256; i++)
{
uint_32 bit_r = i;
bit_r = ((bit_r & 0xAA) >> 1) | ((bit_r & 0x55) << 1);
bit_r = ((bit_r & 0xCC) >> 2) | ((bit_r & 0x33) << 2);
bit_r = ((bit_r & 0xF0) >> 4) | ((bit_r & 0x0F) << 4);
stic_bit [i] = i << 8;
stic_bit_r[i] = bit_r << 8;
}
...
stic->stic_cr.read = stic_ctrl_rd;
stic->stic_cr.write = stic_ctrl_wr;
stic->stic_cr.peek = stic_ctrl_peek;
stic->stic_cr.poke = stic_ctrl_poke;
stic->stic_cr.tick = stic_tick;
stic->stic_cr.reset = stic_reset;
stic->stic_cr.dtor = stic_dtor;
stic->stic_cr.min_tick = 57; /* to get started. stic_tick will reset. */
stic->stic_cr.max_tick = 57;
stic->stic_cr.addr_base = 0x00000000;
stic->stic_cr.addr_mask = 0x0000FFFF;
stic->stic_cr.parent = (void*) stic;
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->stic_accessible = 0;
stic->gmem_accessible = 0;
if (stic->req_bus)
{
stic->req_bus->intak = ~0ULL;
stic->req_bus->intrq = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->next_busrq = ~0ULL;
stic->req_bus->next_intrq = ~0ULL;
}
Code like that I can often whip out while only half-looking at the screen.
Otte: staring into the abyss Posted Aug 4, 2012 12:37 UTC (Sat) by nix (subscriber, #2304) [Link] Yep. And code like that is great if the data you are entering is really columnar. It's awful for e.g. the very assignments you show it used for, becaue it's actually quite hard for the eye to track from, say, one of those = 0's back to the thing you're assigning to -- you have to track across a lot of whitespace without deviating horizontally, which the eye is notably bad at. In this specific case it doesn't matter because the assignments are all either of 0, or at the end of a block, or of a name similar to the name of the variable, or there happens not to be much whitespace, but can you see how bad this close variant is? (reordering things to provide an example with enough horizontal whitespace to make my point, I know this makes no sense as code anymore):
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq = 0;
stic->stic_accessible = 14;
stic->gmem_accessible = 0;
It's actually quite hard to see which variable that 57 or 14 are assigned to: they're lost in a sea of horizontal whitespace, while the columnar format makes it appear that all those 0s and 14s and 57s are related to each other, when they are not at all. Isn't this clearer?
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq = 0;
stic->stic_accessible = 14;
stic->gmem_accessible = 0;
Another problem with lining things up like you suggest is that it encourages people to use tabs to line things up, rather than restricting themselves to using tabs solely in the left margin as sole indentation mechanism. And I don't need to tell you why that is an awful idea unless you have a way of enforcing that absolutely everyone on the project uses the same tab size. (I prefer to do as GNU is increasingly doing and simply ban tabs outside of literal strings. It's too easy for a thoughtless co-worker with the wrong tab size to turn a codebase into mush with a single save when tabs are in wide use. With spaces, this is impossible, even if you do lose the easy 'change the indentation by changing the tab size' trick. This trick rarely works in practice because most people don't have the discipline to use tabs and only tabs as indentation mechanism, with no padding out with spaces, and to use them nowhere else, ever.)
Otte: staring into the abyss Posted Aug 4, 2012 16:45 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link] Actually, I find your compressed whitespace version harder to follow, probably because I'm in the habit of moving my eyes between columns and working fields in groups. I'll read a few field names (as in 2 to 4), then jump to the column of values, then back to the column of field names, etc. That is to say, my visual scanning is roughly like this:
stic->phase
stic->next_phase
stic->fifo_ptr
...followed by...
= 0;
= 57;
= 0;
All three values are centered together in the highest-res portion of my vision. That doesn't work as well when the second target is more like:
= 0;
XXXXX = 57;
XXX = 0;
If it makes sense to do so, I'll even insert a blank line to make the grouping more obvious, or use different horizontal columns for the values in the groups, if the groups are more logically separate. If I always scanned field name by field name one at a time, it'd be a problem. But since I tend to bunch fields in logical groups, and tend to treat them as groups, it's actually easier for me to follow when I can see all the field names simultaneously, and then see all the field values simultaneously. My brain can remember field order for a handful of fields at a time, and so treating them in groups goes much faster for me. Now, in C++, where all those fields would be constructor arguments instead, I'd probably group them differently. In any case, I try to group things to that my innate visual sense of "alike" and "different" help me spot anomalies. In your compressed version, I have to play "find the value", and I forget what value I'm looking for after awhile. I'm forced to read field-by-field, which is much slower for me. I'm /less/ likely to find unintended discrepancies. I guess it's the same reason I write "max" with this idiom:
if (max < val)
max = val;
It's easier to see I've hooked everything up properly if I can read down the columns and everything reads in the same order in each column. BTW, on the tabs thing: I've got a strict no-tabs policy in our team, and we set indentations at 4. It's easily enforced so far, though, because there's no more than a few of us at any given time. We're attached to a chip design team, so there's no danger of us suddenly growing our software team...
Otte: staring into the abyss Posted Aug 5, 2012 7:27 UTC (Sun) by dirtyepic (subscriber, #30178) [Link]
Conversations like this are why I love this site.
Otte: staring into the abyss Posted Aug 6, 2012 8:30 UTC (Mon) by nix (subscriber, #2304) [Link]
Aaah, thanks for that description. I think you've elucidated the key difference here, perhaps without knowing you did. Probably because you're attached to a chip design team, which tends to emit lots of stuff with big initialization blocks filled with heaps of magic constants, you're in the habit of *using* huge initialization blocks filled with magic constants and so have come up with a reading mechanism which ties those constants together, because those constants often really *are* related.
I've never worked on anything like that (I started out on financial database stuff, then as soon as I started working for a major database vendor I stopped working on databases and started working on stuff closer to the toolchain), and would consider heaps of simple assignments bunched together like that tantamount to lack of sufficient ingenuity: it's usually unnecessary code, since it's normally right next to the declaration anyway. So as long as it's something C would permit in an initializer, I'd probably use one (a designated initializer if necessary). Inside designated initializers, which are certain to contain a group of closely related initializations, I often *do* line things up as you suggest, as long as the amount of introduced whitespace is low -- so I think perhaps there is less difference between our coding styles than was at first visible.
My rule is simple: avoid the boring and evil (one is hard to write: the other is hard to read). What is boring to me is that repeated-over-and-over 'stic->' in your example: what is evil is a spaced-out initializer with a lot of space in which the eye gets lost. (Your solution there would probably be to group them differently so that variables with names of similar lengths were grouped together: mine would generally be to not space them out. I can't really call this a huge difference in style.)
In any case, there is one situation where spacing-out is always called for: same-line comments. *Nobody*, not even weird people who voluntarily use Hungarian notation, puts all their same-line comments right next to the code it describes unless the line is long. And not even in these days of 200-column xterms does anyone write a 200-column same-line comment.
My apologies for not turning this into a dark-curse-ridden my-way-or-/dev/null flamefest. I'm aware that I am below quota on these for this year and will lose my Internet access privileges unless I get some better flame up.
Otte: staring into the abyss Posted Aug 6, 2012 13:02 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] My rule is simple: avoid the boring and evil (one is hard to write: the other is hard to read). What is boring to me is that repeated-over-and-over 'stic->' in your example: what is evil is a spaced-out initializer with a lot of space in which the eye gets lost. In Pascal, I could have used a "with" block, but C lacks such things. In perl, I use the fat comma in a nicely indented initializer block:
my %hash =
(
foo => 0,
bar => 42,
baz => 1,
quux => 1234,
gronk => 0
);
The particular code I shared earlier (the STIC code) actually largely pre-dates wide availability of C's designated initializers. With a modern C compiler I would instead consider putting initializers like that block into const structures and use structure assignment to copy the block in in one go. That would both eliminate the boring repeated prefix, and would also likely reduce the overall code footprint since it would replace the discrete scalar assignments with a loop.
Otte: staring into the abyss Posted Aug 6, 2012 13:58 UTC (Mon) by nix (subscriber, #2304) [Link]
I believe we are in violent agreement then, modulo a tiny niggle over code style that should have no effect on modern code :)
|
|||||||||||||