[OT] unbelievable: #ifdef _OTHER_LIB_H

[Joakim via Digitalmars-d]

On Friday, 28 November 2014 at 01:04:40 UTC, Adam D. Ruppe wrote:
> On Thursday, 27 November 2014 at 19:58:33 UTC, Joakim wrote:
>> You would have to be a very slow talker if you could type 
>> faster.
>
> I don't think it would be a one-to-one correspondence. I saw a 
> youtube where a guy had rigged a voice interface for code and 
> he didn't say things like "foo left paren bar comma baz right 
> paren semicolon" it was more like "foo bah bar *click*" - he 
> made a new language with various sounds.

Yeah, that's what I tried to give an example of to ketmar above.

> On the other hand, by the same reasoning, talking faster than 
> typing doesn't necessarily match up because like how would you 
> say "a = *b | c"? I would probably say something like "a equals 
> what's pointed to by by bitor c"... and I type it at about the 
> same speed as I say it since there's more syllables than 
> symbols. Autocomplete and such can give an edge to the typing 
> too.

It "wins" there because the only reason you're using single 
characters is because they're faster to type, despite not being a 
good coding practice for future maintenance, ie what do a, b, and 
c actually signify?  You will be able to give each of those 
variables actual names quicker when speaking and the resulting 
code will be more maintainable.

> I don't think talk-coding would be slow - in my head, sometimes 
> I say these things as my fingers translate it to code - but I 
> don't think it would be much faster either.
>
> Now, talking vs typing prose is a different story, my fingers 
> couldn't keep up with my brain on writing this email. But with 
> code, my fingers typically aren't the bottleneck.
>
>
> (and it certainly wouldn't revolutionize the industry, where 
> the slowest part for me tends to be figuring out WTF the 
> customer is asking for anyway...)

I agree with most of this, the bottleneck for coding usually 
isn't the keyboard, since you're usually pausing to think.  There 
are some speed demon keyboard coders who could probably go even 
faster with voice though.

I brought up using voice recognition as a general computer 
interface but, of course, everybody here only focused on the 
niche case of coding. :) I was talking about using it for 
everything: manipulating the GUI, entering text, etc.  The hand 
gestures are there as a fallback for when you can't use voice or 
because sometimes they are more expressive, say for manipulating 
spatial objects or drawing.

>> Windows Start menu to launch applications and get into the 
>> right system settings, ie by using the keyboard.
>
> A friend asked me over the weekend how to get to the calculator 
> on Windows 8. One person was giving the old Win 95 answer 
> "click start, go to programs, accessories, then click 
> calculator". That doesn't work on Win8... and I think the new 
> way is so much better:
>
> I said "hit that windows button on the keyboard then type 
> "calculator" and hit enter".
>
> She did that and agreed it is super easy.

Over the years, I've increasingly come to the conclusion that 
search is a universal interface that is still underused.  Of 
course, part of that is because of indexing issues, but search is 
just much more natural and can easily be updated to take voice 
input.

> I think the biggest benefit of a GUI isn't so much ease of use 
> as the ability to browse the options. If she didn't know there 
> was a calculator, she would never have thought to just type the 
> word, but might have noticed the icon while looking at the 
> start menu. But if you already know what you want, it is hard 
> to beat just asking for it directly.

Yeah, that has long been a benefit of GUIs, though as the number 
of options get very large, it doesn't scale.  I cannot remember 
where anything is in the Windows Control Panel these days, since 
it's so overstuffed with settings that the initial panel leaves 
out many categories, so I invariably use search to find the 
settings panel I want.  You can also use search to browse by 
using different keywords, but if the keywords aren't done well, 
you might miss it that way too.

On Thursday, 27 November 2014 at 21:05:14 UTC, ketmar via 
Digitalmars-d wrote:
>> You'll simply hand the recognizer software a bunch of old code 
>> that exemplifies your programming style and it'll figure out 
>> that you prefer spaces there and automatically add them for 
>> you, without having to say it or configure it. :) That's 
>> actually fairly easy, if your style is at all consistent.
> that recognizer still must be able do do semantic analysis on 
> each
> language i want to use, or it will fail on almost any 
> compilcated
> sentense.

You wouldn't need semantic analysis for formatting style, which 
is what we were talking about.

>> > ah, and occasional "ah, hello, honey, how do... DAMN IT! 
>> > FSCK! GET
>> > LOST! oh, no, honey, i'm not talking with you... what do you 
>> > mean by
>> > 'you never talking with me'? ehm... shit."
>> "break<pause>ah, hello, honey, how do..."
> so i can't code and talk simultaneously anymore? ah, that's 
> what i call
> "new technologies"! ;-)

Well, just as vi introduced modal editing and had you switch back 
and forth decades ago, speech recognition will have to do the 
same initially.  Eventually it'll be smart enough to tell the 
difference between speech directed at it and elsewhere.  We're 
still in the vi phase of speech recognition interfaces. ;)

On Friday, 28 November 2014 at 09:25:53 UTC, Jérôme M. Berger 
wrote:
> Joakim wrote:
>> "break<pause>ah, hello, honey, how do..."
>
> 	As everybody knows, this works just fine:
> https://www.youtube.com/watch?v=mWZLa4AnN5k ;)

Seems like it's working great to me, the problem is MS allowing 
that keyphrase in the game's content. :)

On Friday, 28 November 2014 at 14:08:02 UTC, CraigDillabaugh 
wrote:
> 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?

Yeah, headsets, which programmers often already use to listen to 
music while coding, or those little jaw mics if you just want the 
microphone.  If the mic is close enough, you can talk in a low 
voice and still be recognized.  Call centers use headsets and 
pack them in, I doubt it can't be done for other fields too.

> 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.

Google made their speech recognition available offline on Android 
a couple years back, ie it's not tied to servers with massive 
resources anymore.  With specialized hardware, I don't think 
it'll be a problem, but I don't know the details of the latest 
advances.  I know the just-released Android 5.0 added support for 
specialized low-power, always-on voice recognition chips, so you 
can talk to your phone when the screen is off and instantly turn 
it on, which the Moto X and Nexus 6 and 9 have.