Programming is especially suited for steno, because there's so much boilerplate to write again and again, even in an eloquent language like Python. If I want to define a function, I have to type:
def someFunction(arg): stuff.
That's eight strokes just to get started, plus 20 more strokes to write "someFunction", "arg", and "stuff". In steno, on the other hand, you could write something like DFD in a single stroke, and it would put in the def, the space, the parentheses, the colon and the carriage return automatically, then jump you up to the space after the def to write your function name and arguments, then then drop you back down to the body of the function, all in four strokes. Best of all, once you defined that function name in your steno dictionary, you wouldn't need to worry about remembering to write out the name in camel case each time. Just use a single stroke like SPHUPBGS (pronounced "smunction"), for instance, and start thinking of it as just another word, instead of two words mashed together in a lexically unnatural way.
I love the way Vim has mapped a useful command to each key of the qwerty keyboard. It's immensely powerful once you get used to it. But it's only got 26 keys to choose from, and it takes a long time to learn which key does what, since the correlation between "move one word forward" and the "w" key is pretty abstract and arbitrary. In steno, you could certainly keep using just the w key, if it's what you're used to, but you could also, say, map the "move one word forward" command to a single stroke like "WOFRD" (pronounced "woffered"). That's mnemonically much more useful than just "w", and an even bigger advantage is that the number of possible one-stroke commands is almost infinite. Instead of one stroke equalling one letter, steno lets one stroke equal one syllable, which is about five times more efficient quantitatively. As a qualitative improvement, the advantage is inestimable.
All of that either already exists as described, or keystroke-count equivalents exist, in every programmer editor. If people aren't using it in existing editors they sure aren't going to pick up a radically different keyboard layout to use it.
(Said the guy who types in an increasingly-heavily-modified Dvorak layout. I recently mapped Backspace to "change window" (i.e., ALT-Tab in most WMs), since I long since moved Backspace to Caps Lock. You can't be much more willing to fiddle with your keyboard layout than I am.)
Thinking and debugging take up a lot of time, but typing time is still nontrivial and worth optimizing. Especially in debugging where moving around the file quickly is important, vim's movement commands make this quicker.
I do agree that being able to navigate an editor like vim quickly is the determining factor in code writing, however, I do not think WPM is directly related to one's ability to do this. Even though I don't type insanely fast, I can hit a 1-5 key combination in an instant.
Correct me if I'm taking this the wrong way, but I don't think WPM even applies to programming. To audio typers, secretaries, etc. it's a good measure of how well you can keep up.
To a programmer, you can only go so fast when you're not even dealing with human language that has no natural flow, and the quirks of the editor of your choice. Especially on, say, a Mac, where you could be typing a '#' far more times than you ever would in any other situation, or a backtick or pipe.
It's probably telling that we're favouring languages that reduce the syntactic complexity of coding, like CoffeeScript in favour of Javascript, Ruby, maybe Python, Clojure, and the functional languages like Haskell and Erlang. Not just because it's easier to read, but because it's easier to type.
I might just be talking rubbish, of course. But I wouldn't use typing speed as a performance metric for a programmer.
It's not much of a performance metric , but I don't really enjoy typing very much in situations where I have decided what I'm going to do and then have to type it out.
I can't generally think and type very well at the same time.
This means for me that trying a random idea I have quickly is much more enjoyable in say python that it is in Java.
Sometimes I want to just try something random in Java but I really can't be bothered to type all the code required to create a new class, handle exceptions and then also do the compile and run.
If I had super fast typing skills or a more concise language I would find much less friction is doing that, this would make my programming time much more educational and make me better in the long run.
It's the fluency that steno lends to composing text or code that's far more useful than the speed. Tab-complete requires that you pause for a short time to read your options while you flip through them. Steno is entirely deterministic; you can implement the command in one stroke without twisting your hands around (unlike metacommands, especially those used in emacs, which can result in the dreaded emacs claw), and you know exactly what the result is going to be. Because you're writing entire words with each stroke, if you accidentally hit the wrong key, you'll be able to reverse the error in a single "delete last stroke" command, rather than having to backspace 20 times to correct a letter transposition error you made several words ago. Qwerty requires commands and variables to be broken down into minuscule portions, with the potential for error occurring each time a key is deployed. Steno reduces that error potential drastically by chunking words and variables into single-stroke entities, requiring less vigilance for error and allowing for a much smoother flow of thought and composition.
Typing speed usually isn't the limiting factor, but being able to touch-type (really touch-type, which allows you to keep your eyes on the screen instead of going back and forth) is extremely valuable: it makes text entry much more natural, and allows you to catch typos.
Visual Studio, for example, has boiler plate snippets, type prop[tab][tab] for a prop declaration, for[tab][tab] for a for loop, fore[tab][tab] for a foreach, etc. There's auto-brace completion and ctrl-enter to add a semi-colon and move to the next line (surprisingly useful with auto-braces). The point being that editors can make boiler plate very easy.
To be completely honest these features don't save much time, even though I use them all the time. As you say thinking and debugging do, compiling not so much unless you're working on a very big project.
Writing fast means you can express the idea in your head before you forget exactly how you figured it was going to work. This is the reason I find most compelling to be able to type fairly fast as well as know the keyboard shortcuts for jumping around (for example jump word in VS is ctrl-left/right arrow).
Revelations can fade fast once you start implementing them.
Compiling is quick in many languages, but you're mostly right about debugging and thinking. However, the key to productivity is to stay in flow, and having to type the same boring boilerplate over and over again tends to take me out of it.
http://en.wikipedia.org/wiki/Flow_(psychology)
An interesting take, though I thought most IDEs have most of those features already? (I personally dislike features that auto-jump me around apart from auto-indent.) It's funny she brought up vim since vim can be made to do those things as well; it's not limited to 26 characters since you can have multicharacter commands in any mode just fine.
I still don't really "get" the syllable perspective but it seems like it's just a mapping of one stroke (I think my confusion is what constitutes a "stroke") on specialized hardware to several on a qwerty board? So I guess you're limited to the number of keys on a qwerty board for single-point-of-entry commands with vim, but you could always use the specialty keyboard and map the output of those as multi-character vim commands... It seems the main benefit is having those mappings done for you and available system-wide.
I still don't really "get" the syllable perspective but it seems like it's just a mapping of one stroke (I think my confusion is what constitutes a "stroke") on specialized hardware to several on a qwerty board?
As far as I can tell, steno works by mapping a "stroke" (a combination of keys pressed at once -- like a chord on a musical instrument) to a "syllable" which appears to be a chunk of a word for prose but apparently can be any chunk of text for things like programming. I think this is why she recommends a 45$ "gamer's keyboard", most regular keyboards have a limit to the number of simultaneous key presses that will be registered. Also it appears that when using a keyboard for steno you still only use a limited number of keys. From the video it looks like she barely strayed from the home position.
6 Keys on USB, if I recall correctly. However, PS2 doesn't limit you at all, and a number of keyboard let you press any number of keys you want. (Typically high-end mechanical keyboards, or gaming keyboards.) A honza mention in his (dead) comment, the technical term is "n-key rollover" where n=6 for USB, and n="n" when it's unlimited.
The newer USB keyboards with n-key rollover don't have this limit. I'm able to depress 22 keys at a time on a Sidewinder X4 ($45) or a Filco Majestouch ($120) connected via USB and have them all register perfectly. Yep, the steno layout is only two rows for fingers, one row for thumbs, and one meta-row for numbers. There's very little movement of the hands required, which makes it both ergonomic and efficient. Chords of 1 to 22 keys are mapped to syllables, words, or phrases. It's a lot like playing a piano.
Zen Coding [1] gives you some of that advantage, by turning many complex constructs into 3-4 character keywords, and placing the caret automatically at meaningful places (some textmate bundles do this too). The approach works really well for CSS and HTML.
I still don't really "get" the syllable perspective but it seems like it's just a mapping of one stroke (I think my confusion is what constitutes a "stroke") on specialized hardware to several on a qwerty board? [..] It seems the main benefit is having those mappings done for you and available system-wide.
From playing around with it for a few minutes, there's a little bit more to it than that. It auto-inserts spaces between words, but there are some keys which add to the end of the previous word (e.g. one button adds 'es' to words ending in 's' or 's' to other words, or makes a new word if part of another chord). So it isn't a direct one-chord-to-one-string-of-characters mapping.
Vim already has the capability to allow pressing a key chord to perform a custom function. Just use the plugin vim-arpeggio at https://github.com/kana/vim-arpeggio. And you can already do something like “DFD” expanding to “def someFunction(arg): stuff” by using the vim-snipmate plugin at https://github.com/garbas/vim-snipmate. That “snippets” functionality is based on TextMate’s snippets feature, and I know Eclipse supports snippets too.
Thus, steno is not necessary for either of the advantages mentioned. However, it still might be good to have the mindset of using tools like vim-arpeggio more, and steno still might make typing variable names slightly faster.
Hmm...seems like it might be possible to use vim-arpeggio to implement steno on vim. Then whenever you're writing prose, turn steno on and type 200wpm in insert mode, while still having all the vim editing features available.
Because all proprietary steno software builds in a 1.5-second buffer between when the stenographer enters the stroke and when the stroke is transmitted to an external program. Imagine having to wait 1.5 seconds for each command to execute. It's infuriating. Plover is the only steno software that uses a length-based stroke buffer rather than a timing-based one, so it sends commands immediately, making it work beautifully with Vim and every other external program I've tried it with. The difference in usability is startling.
Ah, ok. I was actually thinking of something different: implementing steno chords in vim itself, instead of hooking it to an external program like plover. Since vim-arpeggio already handles simultaneous keystrokes, it seems it'd mainly be a matter of importing all the chords into vim-arpeggio.
But I didn't know anything about steno before today so I'm probably over-simplifying. And it's pretty interesting that plover can work with vim...I'd love to see a blog post or screencast showing how that works.
I'm incredibly excited about Plover - but only for English typing, not coding. I guess for typing strings in code, maybe. But coding? No. The ratio of typing to thought in coding is vanishingly small.
http://stenoknight.com/WritingCoding.html
Programming is especially suited for steno, because there's so much boilerplate to write again and again, even in an eloquent language like Python. If I want to define a function, I have to type:
def someFunction(arg): stuff.
That's eight strokes just to get started, plus 20 more strokes to write "someFunction", "arg", and "stuff". In steno, on the other hand, you could write something like DFD in a single stroke, and it would put in the def, the space, the parentheses, the colon and the carriage return automatically, then jump you up to the space after the def to write your function name and arguments, then then drop you back down to the body of the function, all in four strokes. Best of all, once you defined that function name in your steno dictionary, you wouldn't need to worry about remembering to write out the name in camel case each time. Just use a single stroke like SPHUPBGS (pronounced "smunction"), for instance, and start thinking of it as just another word, instead of two words mashed together in a lexically unnatural way.
I love the way Vim has mapped a useful command to each key of the qwerty keyboard. It's immensely powerful once you get used to it. But it's only got 26 keys to choose from, and it takes a long time to learn which key does what, since the correlation between "move one word forward" and the "w" key is pretty abstract and arbitrary. In steno, you could certainly keep using just the w key, if it's what you're used to, but you could also, say, map the "move one word forward" command to a single stroke like "WOFRD" (pronounced "woffered"). That's mnemonically much more useful than just "w", and an even bigger advantage is that the number of possible one-stroke commands is almost infinite. Instead of one stroke equalling one letter, steno lets one stroke equal one syllable, which is about five times more efficient quantitatively. As a qualitative improvement, the advantage is inestimable.