How One Programmer Is Coding Faster By Voice Than Keyboard

mikejuk writes "Is it possible that we have been wasting our time typing programs. Could voice recognition, with a little help from an invented spoken language, be the solution we didn't know we needed? About two years ago Tavis Rudd, developed a bad case of RSI caused by typing lots of code using Emacs. It was so severe that he couldn't code. As he puts it: 'Desperate, I tried voice recognition'. The Dragon Naturally Speaking system used by Rudd supported standard language quite well, but it wasn't adapted to program editing commands. The solution was to use a Python speech extension, DragonFly, to program custom commands. OK, so far so good, but ... the commands weren't quite what you might have expected. Instead of English words for commands he used short vocalizations — you have to hear it to believe it. Now programming sounds like a conversation with R2D2. The advantage is that it is faster and the recognition is easier — it also sounds very cool and very techie. it is claimed that the system is faster than typing. So much so that it is still in use after the RSI cleared up."

Comments

Probably not faster than auto complete

[ModernGeek]

The first thing that came to mind was how much useless and repetitive things that a programmer has to churn out to make things work, however I'd have a hard time believing that this could be faster than someone using something like autocomplete as done in .NET.

Re: Probably not faster than auto complete

[alen]

Yeah, but Microsoft is evil and everyone knows you are dumb as door nails if you cheat with autocomplete and code suggestions in a modern IDE rather than type everything yourself

Re:Probably not faster than auto complete

[complete loony]

He's been in the local paper a few times as a human interest story during his life, but there's nothing available online that I can find. Though he has told me a fair number of anecdotes from work over the years.

Once he turned up to a job interview after being referred by an old colleague. The interviewer hastily excused himself to call the guy; "You didn't tell me he didn't have any hands". "I didn't think it was relevant to his ability".

After discovering that a Y2K compliance project was starting (ie using 4 digit dates everywhere), with an estimate of 8 people for 2 months. He came back after about 2 hours with all the changes checked in.

Re: Probably not faster than auto complete

[Anonymous Coward]

Maybe you were too young, but they pretty much created the concept of autocomplete for programming with Intellisense.

You might have had a point about my youth and inexperience if MS had developed autocomplete for punchcards, 'cos that's what I learned on, but in reality it's been around longer than Windows has been.

I remember using autocomplete coding in some IDE on a Vax box in the mid '80s, and later using it on Suns and Amigas in the late '80s and early '90s (Pascal variant, maybe?). I know Delphi had good autocompletion.

So no, Microsoft didn't invent it, and no amount of revisionist history here will change that....

Emacs

[captain_dope_pants]

Really ? He'd have been better off with VI - everyone knows it stands for Voice Input :p

Re:Emacs

[doti]

VI VI VI

the editor of the beast

You can't win..

[Jah-Wren Ryel]

So how long until he gets laryngitis and has to start typing again?

Re:You can't win..

[Seumas]

If you watch the video, he discusses that. He does about 40-60% of his coding with this system and he does keep voice-strain in mind (in fact, he was sucking on a hard candy during the demonstration to keep his voice from drying out). You may not do 100% of your work in it, but just imagine if you could cut the amount of typing you do down to about half of normal? Suddenly, you're spreading some of the load to your voice, keeping either from being excessively stressed.

Coding != Typing

[JaredOfEuropa]

It's an impressive demonstration of voice recognition, and rather useful for people suffering from RSI, but to suggest that we may all benefit from this? Besides the fact that speech-to-text is a decidedly crappy input method in open plan offices (especially with the extra noises added on), it is also questionable if this will make us code faster. In my experience, typing speed is not really a major limiting factor in coding speed, when taking problem solving and debugging into account. When coding, I do not spend that much time ting, actually.

Re:Coding != Typing

[oodaloop]

I do not spend that much time ting, actually.

You don't say?

Re:Coding != Typing

[buchner.johannes]

In the talk he says open source voice recognition software, e.g. Sphinx, don't work at all, and you have to go for Dragon.
But then creates writes his own command language.

So I don't understand why do we need voice recognition software that recognizes English? All we need is a open source package that translates sounds into some phonetic dictionary (e.g. IPA), and from there the second problem is to translate that into a native language.

Or even simpler, give it a dictionary of commands, and get it to find the closest match, or if all are unlikely, do nothing.

Why try to go for something so hard, but there is no software for the simpler problem that would make people very productive by just commanding the computer?

Codijng faster by voice because...

[Anonymous Coward]

His coding by hand has been crippled by RSI. That's like saying someone can get around faster in a wheelchair because they've broken their legs.

Re:Codijng faster by voice because...

[jeffb (2.718)]

That's like saying someone can get around faster in a wheelchair because they've broken their legs.

You might want to look up the record time for completing the Boston Marathon in a wheelchair vs. on foot.

Writing is easy

[rrohbeck]

90% of my work is debugging and even figuring out the failure scenario and testing against it. Writing the fix and new code is easy and quick.

Re:Writing is easy

[rrohbeck]

I'm not debugging *my* code :)

Re:Try that with LISP

[Mitchell314]

"Open parenthetheeth liphth wun too theven clothe parenthetheeth wetun"

Huh, it actually works.

This is like the corded keyboard

[Required Snark]

The mouse/keyboard combination was not the original combination envisioned by Douglas Englebart, the inventor of the mouse. He paired it with a chorded keyboard that could be operated with one hand. Clearly text input with one hand and mouse input with the other is a better input paradigm, but it is still not in use much today.

This use of speech recognition seems like a similar situation. It works for a few people, but it will not ever have a large user community. QWERTY keyboards are so dominant that their network effect makes other input modes irrelevant. Even those who adopt it will still be using conventional keyboards away from their custom environment.

Re:Try that with LISP

[Anonymous Coward]

The first demo in the talk is editing lisp.

autocomplete as done in Borland C++ ..

[dgharmon]

> I'd have a hard time believing that this could be faster than someone using something like autocomplete as done in .NET ..

autocomplete was around long before .NET as was context-sensitive-help before Microsoft renamed it Intellisense ..

Re:autocomplete as done in Borland C++ ..

[Anubis IV]

Sure, but he was merely offering an example that most people here are likely at least somewhat familiar with. He never made any claims to its originality. I mean, if I was making a car analogy, I'd likely reference a car that people here know, rather than the earliest one that exhibited the traits I was referencing, just because the purpose of the statement is solely to supplement understanding of a separate topic.

Oompah Oompah Band

[Tablizer]

Pararenthesis parenthesis parenthesis. ... Was that one too much?

No, open "parenthesis" will be abbreviated "pah". And close parenthesis will be "ump".

Thus, coding will sound like, "Umpah lumpa, dipity doo, I have another puzzle for you..."

http://www.youtube.com/watch?v=qw0zZttfUaw

Input is not the limiter when coding

[gweihir]

Unless you are programming utterly structure starved glue-code, input is not the limiting factor, thinking about what you want to input is.

Re:Input is not the limiter when coding

[pla]

Unless you are programming utterly structure starved glue-code, input is not the limiting factor, thinking about what you want to input is.

You beat me to it.

I can type in code pretty damned fast - Fast enough that people frequently ask me how often I go through keyboards - Fast enough that I've actually had people in the room with me ask if I had just typed something meaningful or merely mashed keys for the hell of it - And, while coding, I tend to spend far, far more time thinking than coding. Someone watching me program for an hour would see 3-5 minutes at a time of complete inactivity, followed by assaulting the keyboard for a 30 second burst, rinse wash repeat.

Re:Input is not the limiter when coding

[Kjella]

You beat me to it. I can type in code pretty damned fast - Fast enough that people frequently ask me how often I go through keyboards - Fast enough that I've actually had people in the room with me ask if I had just typed something meaningful or merely mashed keys for the hell of it - And, while coding, I tend to spend far, far more time thinking than coding. Someone watching me program for an hour would see 3-5 minutes at a time of complete inactivity, followed by assaulting the keyboard for a 30 second burst, rinse wash repeat.

I think I can have considerably longer buffer/burst cycles, the challenge is keeping the big picture in your head while doing the little parts, and there I feel the duration of the bursts matter. If I've figured that to solve a business problem I need to change code sections A2, B4, C3 and D1 I'll start working on A2 and if it's quick and easy I won't forget the rest while if I struggle and need to churn out a lot of boilerplate by the time I'm done I might not remember what those other changes were. Either you then have to take notes or pseudocode the whole solution first or recreate it from memory, in those cases faster input would help keep me "in the flow", even though the input itself is only a small fraction of the wall time.

New rapping fad

[Tablizer]

You: "Biff Niff Bobblewop, Mop Top, Flip Flop Dribble Nibble Bazzle Dazzle Ropple Popple Slip Dip..."

Boss: "Get to work, no more rapping!"

You: "I'm not rapping, I'm programming via voice commands. Actually, I'm doing both."

Boss: "Yeah, right. It's called Riff Raff."

Re:The secret is hot sauce

[PolygamousRanchKid]

So... what? Do you just chug it?

I believe it's intended to be administered as an enema . . .

You might be able to convince some frat boys into trying it . . . they're already doing it with alcohol.

Not shocking

[quantaman]

Not a fan of evolutionary psychology, but I think there's a lot of reason to think we do have an aptitude for spoken language. I wouldn't be at all surprised if a well designed voice system left more mental focus available for the task of coding.

I'm not sure if the technology is there yet, and you still don't want to hear your officemates jabbering away, but I could see the theoretical usability of a spoken word interface surpassing that of typing.

Lisp programmers need foot pedals

[ebno-10db]

What Lisp programmers really need are two foot pedals - one for left parentheses and one for right parentheses. That should cover 90% of their input requirements.