Another thing, though--I just modified the script to compute frequencies without regard for direction, and there were actually rather few adjacent pairs in the top frequency rankings. There are quite a few (16) pairs between re/er and the next-most-frequent adjacent pair, de/ed. Out of the first 35 or so pairs, 5 were adjacent. I don't know whether that's "good" or "bad", when compared to Dvorak pairings; I would be interested in finding out
how comprehensive my source dict file is, compared to, say, Webster's or the OED, and
where the adjacent and same-finger key pairings come up in the freq ranks, on both keyboards.
"er" and "re" aren't adjacent? or were you just saying adjacent and using the same finger (typically) to strike the keys?
Oh--right, right. Yes, thanks for pointing that out--I was referring to same-fingerness, not adjacency. Yes, the issues are a bit muddled in switching between historical context and current practical usage...
Always nice on occasion to see not everyone on/. is brain dead &/or can't see past their own brainwashing.
Uh-huh. But you cited http://www.dvortyboards.com/, a merchandising site, as a source for further info. This appears to be the source of your claim "that your fingers move 1/16th the distance when using Dvorak compared to QWERTY"--a claim that they offer no solid evidence for (and they don't even quantify this notion of "finger movement"!).
# input: one word per line.
while(){chomp;$_=lc($_);1 while s{^(\w)(\w)}{$p{$1.$2}++;$2;}e;}
foreach my $key (sort{$p{$b}$p{$a}}keys%p) {print"$key\t",$p{$key},"\n";}
On my system (/usr/dict/words on solaris--dict from ispell? not sure) this gives er, in, an, on, te, le, at, en, re, ar as the most frequent. None of these are adjacent (and adjacency is really the only issue now that bar action's no longer involved). A better comparison would look at combos irrespective of order, though, and I don't feel like doing that right now.
I appreciate your point, but keep in mind also that we don't know what the bar mechanism behind the keys was; it may even be that the bars for close keys like t and h were positioned such that they would not be in conflict.
Of course, there's also the lack of strong evidence for superiority of Dvorak. At least, I haven't yet seen somebody to link to a well-documented case for Dvorak based on typist efficiency, and I have seen a
link (from above, courtesy briancarnell) that cites a specific study demonstrating that Dvorak's not worth the effort.
There's a great book on doing all of this stuff called _The Independant Home_. Unfortunately, it seems to be out of print, as I can't find it at any of the major book outlets online.
Well, I did an Amazon search on "independent home" (with "ent", not "ant") and did turn up a couple of books that looked correct. Try the search that way--is the book you're talking about in there?
Re: Like online gaming anti-cheats?
on
eLection '04
·
· Score: 1
Purely electronic balloting would only work if there was a truly secure way of making sure that the votes cast were the votes counted, and the binary that did the counting was the binary compiled by the published source.
This has occurred to me, too, at times, and it always reminds me of some article I read here sometime back about preventing cheating in online game networks. It seems to me there should be a way for all computers in the vote-recording-and-tallying network to periodically run checksums on each others' files (e.g., every time one tallying computer submits a batch of votes); I'd imagine these verifications could also be posted publicly. Of course, my security knowledge is practically nil, so I'd like to know what sort of problems a scheme like that would present.
Re:Geeks who cut their teeth on it malign it?
on
KBasic
·
· Score: 1
FWIW, I had access to an apple III and a commodore (as well as numerous apple ][-ish machines at school) when I was a young proto-geek, and BASIC wound up being what kept me OUT of programming... its syntax and ways of doing things seemed silly and arbitrary to me, and I wound up not doing any programming until years later when I encountered Perl, Scheme, and Java.
It's completely plausible, though; last year Dr. Hofstadter organized a very similar panel discussion (albeit without such universally well-known guests) here at Indiana University, and he seemed fascinated enough by the idea that I could easily imagine him parlaying it into a bigger discussion like the one at Stanford (especially since Kurzweil and Moravec were the two authors whose works he referred to most frequently).
I love vim/vi (don't get me wrong), but I think that "ease of use for newbies" isn't a feature I'd attribute to either vi or emacs. When I want to recommend an editor for someone who's not a heavy UNIXer, I'd more likely recommend something along the lines of Pico -- something that has a smaller command-set and a design that meshes better with the "word processor" mental model that most people have been trained to carry around.
For expert users, emacs and vi are two great tools; as soon as I was comfortable with a modest number of commands in vi I began to see the limitations of Pico, Notepad, and other typically word-processorish programs (which I'd never want to use for wading through code--or through anything else, by now!). Both offer good ways of remembering commands (vi mnemonics, emacs command-names and bindings (sorry, I wish I knew enough Emacs to offer better examples)), and both are customizable enough that you can easily get at all the commands you use most often. For me the deciding factors were the speed of vi and the efficiency of its mnemonics.
(okay, my one semi-OT gripe (I'm sure the Emacs folk could see this one coming): lispmode kinda sucks. Any Vimmers out there got a suggestion on how I can customize things to improve it?)
Well, I can sympathize with the problem of not really needing the books, and yes, just about all the ORA books I've bought and read so far are good ones, but there are occasionally a few problems that seem to slip by the staff--what comes to mind right away is Advanced Perl Programming, which (in spite of being a conceptually great, and well-designed, tutorial) has some errors in references to code examples (and errors in code examples) and the like that just shouldn't have made it past a crack editorial staff.
Slashdot Mirror
Another thing, though--I just modified the script to compute frequencies without regard for direction, and there were actually rather few adjacent pairs in the top frequency rankings. There are quite a few (16) pairs between re/er and the next-most-frequent adjacent pair, de/ed. Out of the first 35 or so pairs, 5 were adjacent. I don't know whether that's "good" or "bad", when compared to Dvorak pairings; I would be interested in finding out
Man, I must be bored.
Oh--right, right. Yes, thanks for pointing that out--I was referring to same-fingerness, not adjacency. Yes, the issues are a bit muddled in switching between historical context and current practical usage...
Uh-huh. But you cited http://www.dvortyboards.com/, a merchandising site, as a source for further info. This appears to be the source of your claim "that your fingers move 1/16th the distance when using Dvorak compared to QWERTY"--a claim that they offer no solid evidence for (and they don't even quantify this notion of "finger movement"!).
Let's make a stab at objectivity re letter pairs:
# input: one word per line.while(){chomp;$_=lc($_);1 while s{^(\w)(\w)}{$p{$1.$2}++;$2;}e;}
foreach my $key (sort{$p{$b}$p{$a}}keys%p) {print"$key\t",$p{$key},"\n";}
On my system (/usr/dict/words on solaris--dict from ispell? not sure) this gives er, in, an, on, te, le, at, en, re, ar as the most frequent. None of these are adjacent (and adjacency is really the only issue now that bar action's no longer involved). A better comparison would look at combos irrespective of order, though, and I don't feel like doing that right now.
I appreciate your point, but keep in mind also that we don't know what the bar mechanism behind the keys was; it may even be that the bars for close keys like t and h were positioned such that they would not be in conflict.
Of course, there's also the lack of strong evidence for superiority of Dvorak. At least, I haven't yet seen somebody to link to a well-documented case for Dvorak based on typist efficiency, and I have seen a link (from above, courtesy briancarnell) that cites a specific study demonstrating that Dvorak's not worth the effort.
Cheers.Well, I did an Amazon search on "independent home" (with "ent", not "ant") and did turn up a couple of books that looked correct. Try the search that way--is the book you're talking about in there?
This has occurred to me, too, at times, and it always reminds me of some article I read here sometime back about preventing cheating in online game networks. It seems to me there should be a way for all computers in the vote-recording-and-tallying network to periodically run checksums on each others' files (e.g., every time one tallying computer submits a batch of votes); I'd imagine these verifications could also be posted publicly. Of course, my security knowledge is practically nil, so I'd like to know what sort of problems a scheme like that would present.
FWIW, I had access to an apple III and a commodore (as well as numerous apple ][-ish machines at school) when I was a young proto-geek, and BASIC wound up being what kept me OUT of programming... its syntax and ways of doing things seemed silly and arbitrary to me, and I wound up not doing any programming until years later when I encountered Perl, Scheme, and Java.
It's completely plausible, though; last year Dr. Hofstadter organized a very similar panel discussion (albeit without such universally well-known guests) here at Indiana University, and he seemed fascinated enough by the idea that I could easily imagine him parlaying it into a bigger discussion like the one at Stanford (especially since Kurzweil and Moravec were the two authors whose works he referred to most frequently).
I love vim/vi (don't get me wrong), but I think that "ease of use for newbies" isn't a feature I'd attribute to either vi or emacs. When I want to recommend an editor for someone who's not a heavy UNIXer, I'd more likely recommend something along the lines of Pico -- something that has a smaller command-set and a design that meshes better with the "word processor" mental model that most people have been trained to carry around.
For expert users, emacs and vi are two great tools; as soon as I was comfortable with a modest number of commands in vi I began to see the limitations of Pico, Notepad, and other typically word-processorish programs (which I'd never want to use for wading through code--or through anything else, by now!). Both offer good ways of remembering commands (vi mnemonics, emacs command-names and bindings (sorry, I wish I knew enough Emacs to offer better examples)), and both are customizable enough that you can easily get at all the commands you use most often. For me the deciding factors were the speed of vi and the efficiency of its mnemonics.
(okay, my one semi-OT gripe (I'm sure the Emacs folk could see this one coming): lispmode kinda sucks. Any Vimmers out there got a suggestion on how I can customize things to improve it?)
Well, I can sympathize with the problem of not really needing the books, and yes, just about all the ORA books I've bought and read so far are good ones, but there are occasionally a few problems that seem to slip by the staff--what comes to mind right away is Advanced Perl Programming, which (in spite of being a conceptually great, and well-designed, tutorial) has some errors in references to code examples (and errors in code examples) and the like that just shouldn't have made it past a crack editorial staff.
*shrug* Chalk it up to deadlines, I guess...