42 comments

[ 3.5 ms ] story [ 67.1 ms ] thread
Or just reprogram your keyboard (xmodmap) to make any button do anything you want.
For the windows folk, autohotkey does the trick quite well.
Or create your own alternate keymap with the officially sanctioned Microsoft keyboard layout creator[0] (I used it to recreate the exact Apple French layout[1]). Advantages are you can easily reinstall it, it does not need external software, and you can switch layouts easily with the OS language bar.

[0] http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx

[1] https://dl.dropbox.com/s/zwx8un3kp5f8q3k/Apple%20Keyboard%20...

I really thought some time about remapping the / on the german keyboard (which is Shift-7) to 7 and vice versa (yeah, http:77site.com7foo7bar7page.html). But in the meantime I learned to hit the keys properly and switched to another system altogether.
I'm curious - do you physically take the keys off and swap them when you do major mapping changes like this to make using it easier? Or just use touch typing/muscle memory and ignore what's written on the keys?
For me it's the latter. I learned to code on a US keyboard, because that was the only layout we had in Yugoslavia back in the day. Then I came to live in Chile, where you can't even find a US keyboard, and had to get used to not caring about what's written on the keys.
I use Colemak and occasionally one-handed Dvorak (when I'm having RSI issues in one hand or the other), but my keys are laid out QWERTY. Move the keys, and touch typing becomes much more difficult because you lose your "homing bumps" at the f and j positions. Also, learning a new layout is easiest with a diagram floating on the screen, not by trying to look through your fingers at the keyboard.
I am another Colemak user. I use a Truly Ergonomic keyboard on my desktop, and having to look at the keyboard because of the odd placement of enter, tab, quotes, etc. absolutely kills my throughput compared to my laptop.
Interesting. I had not seen that kind of keyboard before. Seems like having "b" on the left hand would also be distracting, but maybe that's how other people type.
The keys I remap are the non-letter keys (Caps, Control, Esc, Backquote, Backslash, Backspace) with all different key shapes, so I just have to go with muscle memory. (Of course, I'm remapping them because I have the muscle memory, so it's ok. ;)
:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

:-

I have the number keys mapped to their symbols (i.e. pressing 1 gives !, pressing Shift+1 gives 1 etc.) using a custom XKB map. Feels so much more efficient, although I don't have any hard stats.
Sounds almost like a FR layout.
FR layout is great for this (and writing lisp is easier when the parenthesis are easily typed) but the []{} characters are horrible to type!

  0	70015
  1	51196
  2	34396
  3	27248
  4	28487
  5	18818
  6	14918
  7	12900
  8	12680
  9	12231
  !	8811
  "	65196
  £	22
  $	10677
  %	7848
  ^	2890
  &	15019
  *	78756
  (	164996
  )	164418
  121.73935896998462% fewer keystrokes
EDIT: scratch that, I was including my node_modules folders.
Use dashes for separators like in Lisp.
Just it doesn't work in most languages, as the - sign is usually the minus operator. In Java and Python 3 for example you can use Unicode in identifiers, maybe you can use mdash there (unless they forbid punctuation characters).
For Emacs users, there is the wonderful package Smart Dash Mode: http://malsyned.net/smart-dash.html

It takes a pretty good stab at whether you want a dash or an underscore, based on context.

It's a whole lot easier on the wrists.

(The only problem is you start to wish you had it everywhere, not just in Emacs.)

> (The only problem is you start to wish you had it everywhere, not just in Emacs.)

Which is the cruelest joke of most of emacs' functionality, for me.

Wow, as an Vim user, I think this is seriously cool. Now it'd need to support camelCode as well, so when I write camel-code in JavaScript, I get the right thing. That'd be awesome.
From reading PEP 3131 and UAX 31, it looks like the only non-ASCII punctuation mark that would be permitted is U+2040 CHARACTER TIE (⁀).
In Perl 6 - is the infix minus operator and a valid delimiter.
Actually Yukihiro "Matz" Matsumoto, designer of Ruby is Japanese. It's pretty ironic, isn't it?
Seems rather apropos, really.
It's not ironic at all. One would expect that authors using a particular keyboard layout would tend to favor characters that are easy to type. In that way, it's the opposite of irony. The outcome is exactly what we'd expect.
> It's not ironic at all.

Ironically, my sentence was sarcastic. :)

OT: As far as you guys know, is there a language-agnostic keyboard for programmers?

This is my current .Xmodmap file

keycode 48 = quotedbl apostrophe quotedbl apostrophe

keycode 66 = Tab Caps_Lock NoSymbol Caps_Lock

keycode 20 = underscore minus underscore minus

(comment deleted)
If youre going to use a Japanese keyboard, why not go all the way and use Kanji in your code also? Instead of (courtesy of Wikipedia)...

  def create_set_and_get(initial_value=0) # Note the default value of 0
    closure_value = initial_value
    return Proc.new {|x| closure_value = x}, Proc.new { closure_value }
  end
...we could write (excuse my Chinese)...

  做 创_去_和_来(先_值=0)
    闭_值 = 先_值
    回 程.新 {|x| 闭_值 = x}, 程.新 { 闭_值 }
  终
Oh look: all the "words" are a single character each! Why not get rid of all those silly grammar symbols in between them (just like in Chinese and Japanese writing)...

  做创去和来(先值=0)
    闭值=先值
    回程新{|x|闭值=x},程新{闭值}
  终
Now there's tons of whitespace on the righthand side, so why not make it all a single line, with spaces instead of newlines...

  做创去和来(先值=0)  闭值=先值  回程新{|x|闭值=x},程新{闭值}  终
A lot terser! Makes all the talk about semicolons and underscores sound a little silly to some people, doesn't it?
Alternatively, seeing as we are playing around with symbols...

سجل للذهاب والمجيء (القيمة الأولى = 0) = 1 قيمة مغلقة قيمة جديدة مقابل {| X | قيمة وثيقة = س}، {تشنغ عتبة نهاية}

A bit longer than the example using CJK characters, though.
Already exists: http://www.chinesepython.org/. (Scroll down for a short translated code snippet.)

English info: http://www.chinesepython.org/english/english.html.

Chinese Python is a Chinese version of Python, but doesnt utilize the inherent tersity of CJK characters. For example it translates "import sys" as "載入 系統". The example I gave would eliminate spaces, semicolons, underscores between words by using one and only one CJK character per English word, so in the example "import sys" would become, say, "入統".
> The Control key is in a far more comfortable position below the Tab key, where caps lock would be on a traditional keyboard

Well, there's tradition and there's tradition... Traditional Unix systems usually had ctrl there, and the old Symbolics/"MIT space cadet" keyboard actually had what I believe is the equivalent of backspace ("rub out") in that location. The modern location of caps lock seems to be a PCism.

Edit: Forgot to mention, notably even the Apple II and III had ctrl there, I don't think Apple switched to the "modern" layout until the Mac:

http://www.flickr.com/photos/suburbia_org_uk/4820757193/

http://www.old-computers.com/museum/photos/Apple_III_Keyboar...

Interesting, according to the stats, if you have = sign done with out the shift it would have saved another 20% of the keystrokes.
I don't like his statistics so much:

Ruby - Saving 34% (6,613 keystrokes) PHP - Saving 52% (105,250 keystrokes)

Those percentages are not the most helpful. They represent a relationship between the positive delta and the negative delta, rather than a savings for the project (which I feel is the first implication in a percentage saved).

Yeah I don't really like them either, and I wrote them. I thought twice about including the percentages, and I did try to highlight that fact:

    Note that the percentages below are only relative to
    these 2 sets of 3 characters, and don’t represent the 
    total percentage of keystrokes saved.
The percentages are only really there to provide an easier way to compare the (relatively small) Ruby sample, and the (relatively large) PHP sample. Simply saying that one project saved 6000 strokes vs. the other with 100,000 strokes seemed a bit meaningless given the relative sizes of the projects, and doing a full-on frequency analysis of modifier key usage seemed like more trouble that it was worth... perhaps in hindsight I should have done it anyway.

zokier provided an interesting link to a previous discussion below (http://news.ycombinator.com/item?id=2973776, specifically http://news.ycombinator.com/item?id=2977303) which does a much more thorough analysis of Finnish/Swedish vs. US layouts - I'd like to run his code using the Japanese layout when I get a chance.