Saturday, April 19

Calibrating the keyboard autorepeat setting

The default keyboard autorepeat setting on most systems is boringly slow. Even worse, the delay before autorepeat kicks in is so long. This is great for novice users, but we programmers deserve better. Here's a calibration procedure that I use:

  • The autorepeat delay should be as short as possible, but a concentrated, damp but short keypress should not cause multiple keypress events.
  • To determine the most suitable autorepeat rate, test your accuracy. Open an editor and try to enter multiple lines of about 50 characters using the autorepeat feature. Pick the highest setting with which you can consistently get the line length within 2-3 characters of the target. (The 2-3 character margin comes from the practice of releasing the autorepeated key a little early and entering the remaining 1-3 characters, if any, with separate keystrokes.)

For me an autorepeat delay of ~250ms and 80 char/s rate works well. To get your numbers, you can use the command xset q | grep 'repeat rate' .

This tweak make the standard direction keys (and particularly the backspace & delete keys) much more useful: you can frequently get away without using special editor commands or, say, having to select things to delete them and thus resetting the X buffer. It makes things a little faster and more responsive. Try reverting to the standard setting after a few weeks of fast repeat to feel the difference.

Sunday, April 13

Perl program 'design'

Acme::Eyedrops allows you to 'design' your Perl programs (if you have any; you'd better not). Basically, given a Perl program and a "shape" file, it produces a perl program that visually resembles the given shape and behaves like the former program. Here's my favorite example:

    ''=~(        '(?{'        .('`'        |'%')        .('['        ^'-')
    .('`'        |'!')        .('`'        |',')        .'"'.        '\\$'
    .'=='        .('['        ^'+')        .('`'        |'/')        .('['
    ^'+')        .'||'        .(';'        &'=')        .(';'        &'=')
    .';-'        .'-'.        '\\$'        .'=;'        .('['        ^'(')
    .('['        ^'.')        .('`'        |'"')        .('!'        ^'+')
   .'_\\{'      .'(\\$'      .';=('.      '\\$=|'      ."\|".(      '`'^'.'
  ).(('`')|    '/').').'    .'\\"'.+(    '{'^'[').    ('`'|'"')    .('`'|'/'
 ).('['^'/')  .('['^'/').  ('`'|',').(  '`'|('%')).  '\\".\\"'.(  '['^('(')).
 '\\"'.('['^  '#').'!!--'  .'\\$=.\\"'  .('{'^'[').  ('`'|'/').(  '`'|"\&").(
 '{'^"\[").(  '`'|"\"").(  '`'|"\%").(  '`'|"\%").(  '['^(')')).  '\\").\\"'.
 ('{'^'[').(  '`'|"\/").(  '`'|"\.").(  '{'^"\[").(  '['^"\/").(  '`'|"\(").(
 '`'|"\%").(  '{'^"\[").(  '['^"\,").(  '`'|"\!").(  '`'|"\,").(  '`'|(',')).
 '\\"\\}'.+(  '['^"\+").(  '['^"\)").(  '`'|"\)").(  '`'|"\.").(  '['^('/')).
 '+_,\\",'.(  '{'^('[')).  ('\\$;!').(  '!'^"\+").(  '{'^"\/").(  '`'|"\!").(
 '`'|"\+").(  '`'|"\%").(  '{'^"\[").(  '`'|"\/").(  '`'|"\.").(  '`'|"\%").(
 '{'^"\[").(  '`'|"\$").(  '`'|"\/").(  '['^"\,").(  '`'|('.')).  ','.(('{')^
 '[').("\["^  '+').("\`"|  '!').("\["^  '(').("\["^  '(').("\{"^  '[').("\`"|
 ')').("\["^  '/').("\{"^  '[').("\`"|  '!').("\["^  ')').("\`"|  '/').("\["^
 '.').("\`"|  '.').("\`"|  '$')."\,".(  '!'^('+')).  '\\",_,\\"'  .'!'.("\!"^
 '+').("\!"^  '+').'\\"'.  ('['^',').(  '`'|"\(").(  '`'|"\)").(  '`'|"\,").(
 '`'|('%')).  '++\\$="})'  );$:=('.')^  '~';$~='@'|  '(';$^=')'^  '[';$/='`';

Saturday, April 5

The meaning of code

I had an "Aha!" moment today when I came to a Wittgensteinian realization that while the sense of a piece of code corresponds to the formal behaviour of that code, the meaning of the snippet is the set of possible contexts where this code could be used. This idea has changed my view of teaching programming (I have been teaching Python in a local school for a couple months now).

This attitude is nothing new, but for some reason I have not come across it, or rather, I have never seen it applied. (The fashionable problem-based learning thing has some similarities, but isn't quite it.) Having an idea to start from, it was not hard to find good articles expanding the idea. I especially liked Robert Strandh's short writeup on idioms and Elliot Soloway's Learning To Program = Learning To Construct Mechanisms And Explanations (1986). Experienced programmers will not learn much, but anyone dealing with CS education, teachers and students alike, ought to have a look.

The moral is that emphasis should be placed on reading exemplary code ("experienced programmers do X this way") rather than definitions ("function Y does Z"). Programming seems to be closer to language use than to mathematics, and teaching methods should reflect that.