Live data from Hacker News

Using Voice to Code Faster than Keyboard

ergoemacs.org

41–50 of 137 posts

Re: Using Voice to Code Faster than Keyboard

#41
This is a cool project, as I think a voice interface would be the ultimate in computing, something like in "2001, A Space Odyssey," or "Star Trek."

I remember first playing with voice recognition and voice command on a PPC Mac back in 1994.

That the technology hasn't progressed along the same lines as cell phones and processors is testament to how difficult voice recognition actually is when dealing with a wide variation of dialect within any given language.

I would love to be able to use my voice as my main input to my computers and other devices.

Re: Using Voice to Code Faster than Keyboard

#42
post #37
post #16

I was trying to work something like this out to try about a month ago but had to put it aside for later. Running my speech recognition inside a virtual machine was a dealbreaker, but not all that uncommon for people doing this sort of thing. I really, really wanted to get Julius[1] running in OS X but after a couple tries I couldn't get it to build (problem on my end– this is a good reminder to get it sorted out). If…

That does work well. I'm happy to pay for Dragon, but I find the Windows version so superior to the OSX software I refuse to run it on OSX...

The OS X "version" is a nightmare. It's guaranteed to break with every major OS release. Nuance takes months to release working versions. When it does work, it's hostile to any other apps that use the accessibility hooks, such as Text Expander, Alfred, etc., which would be awesome with speech input.

The history of the Mac version (acquisition of a company that licensed the Dragon engine) means that it and the Windows versions are very likely permanently divergent. Given the relative market sizes, the Windows version has the best development, the best recognition, and the least schizophrenic product support.

I am glad that dictation (apparently powered by Nuance's engine anyway) is to be included in Mavericks, including a disconnected (i.e., non-Siri) mode. Maintaining an application with a skeleton crew and relying on system services that change at a fundamental level every couple years is not a path to customer satisfaction.

Re: Using Voice to Code Faster than Keyboard

#43

I like it a lot. I wish there would be solution to tie this with say Google Glass, and be able to go on a walk or sit in the woods and code or make notes with it, hands free. Or while doing cooking or laundry, etc. It's unfortunate he couldn't get the OSS speech recognition to work, though.

Yea, Google Glass would be ideal for DoucheScript Brogramming. Everyone could listen to you reindent your code while you held up the line at Starbucks.

Re: Using Voice to Code Faster than Keyboard

#44

I wonder if we should also be voice coding in a language drastically different then for example, C++? Maybe a language more syntactically friendly for voice?

Fully agree This why we started working on a new language called "english script" : https://github.com/pannous/natural-english-script/tree/maste...

Re: Using Voice to Code Faster than Keyboard

#45

I guess it depends on the type of software you're working on, but input speed has never been close to being the bottleneck with coding for me... Most of the time I'm trying to figure out what to do or how to implement an algorithm. Rarely do I get those mad-scientist frenzies where I'm typing away frantically trying to get all the words down as they come into my mind in a flash of inspiration.

It's very different for different programmers.

I've worked with people who are skilled developers and who can't even touch type. They have a slow-pace, methodical way of working. Many look at the keyboard over glasses and hunt and peck. The professor who ported plan 9 to raspberry pi (recent video here) is an example of this approach.

On the other hand, I have a shocking memory and can't hold context for long. Sometimes I come to write a piece of code and find that I wrote it last week and can't remember a thing about it.

I work by crashing through. I stalk the problem, procrastinate, drink tea, write short essays about what's stopping me from getting started. Eventually I get the whole problem in my head, and then need to get it down and done before I get tired. When I'm in this state and I need to solve a problem that I could use a standard library function for, often I'll just hammer out code to make the problem go away (list comprehension, string manipulation and the like) in order not to cause any extra load on my short term memory or distraction. Raw typing speed is very important. A drop in pace would hurt a lot.

Re: Using Voice to Code Faster than Keyboard

#46

I wonder if we should also be voice coding in a language drastically different then for example, C++? Maybe a language more syntactically friendly for voice?

One of the rules of Forth was that you had to provide a standard pronunciation with the documentation of all your words, so you could speak Forth code over the phone. That was important when words consist of any sequence of characters or punctuation, delimited by spaces.

Re: Using Voice to Code Faster than Keyboard

#48
Whenever I see posts about voice controlling your computer, I spontaneously think "thank the heavens I don't have to share an office with you." I realize some people work alone, at home or in a sound proof office, but every work environment I've worked in has had a shared acoustic space.

These voice control schemes almost always end up as a cool gimmick, and rarely as a productivity boosting solution.

Re: Using Voice to Code Faster than Keyboard

#50

I guess it depends on the type of software you're working on, but input speed has never been close to being the bottleneck with coding for me... Most of the time I'm trying to figure out what to do or how to implement an algorithm. Rarely do I get those mad-scientist frenzies where I'm typing away frantically trying to get all the words down as they come into my mind in a flash of inspiration.

This; if I'm typing and jumping around the code at full speed for long periods it usually means either:

1. I haven't understood the problem

2. I haven't understood the solution

3. I need to spend five minutes improving my Vim macros

Post reply on HN