[OT] unbelievable: #ifdef _OTHER_LIB_H

[CraigDillabaugh via Digitalmars-d]

clip
>
> There are heuristics that can get such homonyms right based on 
> the context.  As voice recognition advances, they are being 
> applied and increasing accuracy by leaps and bounds.  One nice 
> consequence of the current mobile boom is that a ton of work is 
> getting put into improving the speech recognition engines of 
> Google Now, Siri, and Cortana.
>
>> Please, give me a keyboard anytime.
>
> Only if you want to go really slow, like people who still write 
> stuff out longhand or use mechanical typewriters these days. :) 
> Take a look at the wpm numbers I linked above, voice is much 
> faster than typing and recognition is becoming much more 
> accurate.

Just wanted to make a couple of comments on 'voice activated 
coding'.

My typing speed is not the bottleneck in my coding, it is the 
speed at which I reason about the problem at hand.  So voice 
activated/typing isn't likely going to make a huge difference in 
my coding speed.

However, what does influence my coding speed significantly is how 
well I am able to concentrate.  Voice activated coding might work 
well in your home office, but how would it play out at an office, 
or a school lab.  Will we all get our own, sound-proof offices 
... or headsets that filter out everything but our own voices?

I think this issue is going to be more of a hinderance to voice 
activated coding than the technical issues.

Also, I bet that on heavily used systems the bottleneck for a 
voice activated system is not going to be the speed at which the 
user speaks, but the speed at which the voice processor 
interprets what they are saying (like when the GC kicks in :o)  
Sure, there is no reason that this should be the case, but modern 
software seems to stall often enough just handling basic text.