3 ms·

You could probably get 90% of the utility with a janky collection of shell scripts fronted by a voice recognition engine. Think Alexa/Google Assistant/Siri/etc

by ovi256 7y ago

You could probably get 90% of the utility with a janky collection of shell scripts fronted by a voice recognition engine. Think Alexa/Google Assistant/Siri/etc with a bunch of company- or task- specific scripts. I purposefully ignore the robot-arm in an open universe capability, because that's still too far away, AFAIK. Jarvis in the movie was Hollywood smooth: made to look great in a movie. Even the goofs were great, and it behaved like a puppy, to be likable to the audience. You don't need that in a work assistant. But if you remove that, plus the robot-arm, you're left with a voice controlled Outlook assistant, which is useful, but not sexy.

vSanjo 7y ago
I completely agree. A friend once said all we need is 'the sinew between the questions'. Connecting them (contexts, intents, etc) and making it close to 1.0 probability on decisions through the entire conversation. I think the 'marble rock' of Jarvis is there already, and with ML/AI we can likely make it 'David-shaped' but the refinement, 'warmth' and complexity of Jarvis is man-hours that would likely be better spent elsewhere.
- oblio 7y ago
  I'm not sure I get your references (marble rock, David-shaped).
  - Veen 7y ago
    It's a reference to Michelangelo's David and this: Every block of stone has a statue inside it and it is the task of the sculptor to reveal it.
glandium 7y ago
There's also the the voice-controlled CAD ("throw in a little hot rod red in there").
threeseed 7y ago
Actually you could've built Alexa/Siri etc back in 1997 with DragonDictate and a whole bunch of scripting. And in many areas it would've been just as good as what we have today.
- TeMPOraL 7y ago
  I had a better UX around playing music with WinAMP, Microsoft Speech API, and a little program I wrote to glue the two together via Win32 API WM_ messages, in 2007, than I have today with Google Now. Today the problem is a) the voice recognition part, which happens on-line though it shouldn't (introducing large latency and unnecessary Internet dependency), and b) scriptability, which is something none of the voice assistant vendors want to give to you, for business reasons. A better reality would have voice parsed on-device (possibly with models from on-line service providers), and available as a voice-to-text API that could be easily accessed by local scripts.

by ovi256 7y ago

vSanjo 7y ago

I completely agree. A friend once said all we need is 'the sinew between the questions'. Connecting them (contexts, intents, etc) and making it close to 1.0 probability on decisions through the entire conversation. I think the 'marble rock' of Jarvis is there already, and with ML/AI we can likely make it 'David-shaped' but the refinement, 'warmth' and complexity of Jarvis is man-hours that would likely be better spent elsewhere.

oblio 7y ago
I'm not sure I get your references (marble rock, David-shaped).
- Veen 7y ago
  It's a reference to Michelangelo's David and this: Every block of stone has a statue inside it and it is the task of the sculptor to reveal it.

glandium 7y ago

There's also the the voice-controlled CAD ("throw in a little hot rod red in there").

threeseed 7y ago

Actually you could've built Alexa/Siri etc back in 1997 with DragonDictate and a whole bunch of scripting. And in many areas it would've been just as good as what we have today.

TeMPOraL 7y ago
I had a better UX around playing music with WinAMP, Microsoft Speech API, and a little program I wrote to glue the two together via Win32 API WM_ messages, in 2007, than I have today with Google Now. Today the problem is a) the voice recognition part, which happens on-line though it shouldn't (introducing large latency and unnecessary Internet dependency), and b) scriptability, which is something none of the voice assistant vendors want to give to you, for business reasons. A better reality would have voice parsed on-device (possibly with models from on-line service providers), and available as a voice-to-text API that could be easily accessed by local scripts.