voice control has inherent lag.

That's a good point and I agree there is lag. There is, say, intrinsic lag, in the need to receive enough sound to reliably distinguish one "command" from another. Then there is the lag required by the computer to make that discernment.

The summary asked "what's next?" and I would think current processing limitations, the discernment part, could be mitigated by advancements in processing power and algorithms. We may not be there, yet, but I could foresee a time when we would.

As for the intrinsic lag (and to some extent the processing lag) one could "lead" one's shots. Nothing says I have to wait until the target is already under the cross hairs before I *start* saying my command. Much like a quarterback leads his receiver, only sonically.

NOTE: I am NOT suggesting this would replace existing controls, but rather could act as a *supplement* to those already provided.

Besides, every input has a delay between the time I conceive of what I want to do and the time where I've commanded the computer to do it. Trackballs, joysticks, mice, and keyboards all have some delay. I'm thinking that there are at least *some* cases where one can use an audio input to achieve one's goal faster than using only the currently available manual controls.

btw if you wanted you could without too much trouble configure your pc to press shoot button on saying pew pew. but you'd get your avatars head shot off.

With *current* hardware, yes. Again, I was thinking of the future where processing overhead delay could be lessened to the point where this would be practicable, and with "leading" the shot, vocally.

Further, this need not be limited to only firing a weapon. That was just a sample use case for the sake of discussion. See my other example of saying "one" or "seven" while playing Sudoku on my computer instead of having to find and select it from a menu. I'm sure there are others and I'd love to see the /. community comes up with as possibilities and applications.

Obviously, there are cases where this would not help. Fine, don't use it. But I would think there ARE cases where this could augment/enhance existing controls. Maybe not right now, but in the foreseeable future, yes. Especially when both hands are busy trying to do other things, already.

In a word: Voice.

1.) Playing sudoku on my pc, it would be nice (and faster) if I could just SAY "one" or "seven", instead of trying to select it from a menu or scroll my trackwheel until that number is selected.

2.) One step further, though, instead of just "words" use custom sounds. Make the initial sound of saying the letter "T". Each time that sound is "heard" fire the (currently selected) gun.

3) I'm sure that even a small vocabulary of sounds could provide rapid access to select and use different armaments. "Boom", "Bam", "Pow", "Pop", "Pip" could, for example, select andor fire decreasingly destructive arms. Use your imagination.

Cues campy 70's Batman and Robin TV fight scenes and munches popcorn.. ;^)

Just how in the world do they expect us to automate our tests, now? Will we have to program little hand-waving robots to make gestures? And we'll, of course, need different-sized hands and fingers, too.

Just imagine a room full of computers with hand waving robots whirring around running unit, functional, and system tests of a new app.

Then imagine filing a bug report with explicit steps to reproduce.

Oh, this will be fun.

Physicists - please cover your ears, I'm trying to simplify.

When particle move near the speed of light their mass increases. At the speed of light it becomes infinite. Imagine a very light particle, moving very fast. By making it move near C I can get any mass I want. So now imagine i make the original particle lighter, an keep moving it faster in such a way that its moving mass stays the same. In the limit a particle with zero mass moving at the speed of light can have some moving mass. That is how a photon works.

Gravity will bend light, but the effect is very weak because light is moving very quickly. Gravity around a black hole is so strong that it will stop even light.

Real relativity and general relativity changes this a little, but the basic idea is the same. Photons are very light -> massless. They move very fast -> speed of light, so they have mass from their motion. Gravity doesn't bend light much - but black holes have very strong gravity so they do bend light.

*This* is what keeps me coming back to /.!

When I was in college (many moons ago), we covered Newtonian physics, but they only mentioned general/special relativity in passing, and poorly at that. I was exposed to the concept of black holes, newtron stars, and white dwarfs, in my astronomy courses, but again in a superficial, hand-wavy manner. Thank you very much for your clear and lucid explanation!

So, IIRC, gravity is a relatively weak force, compared to, say, electrostatic forces. And yet, near a black hole, gravity is so intense that even light cannot escape. Such a maelstrom of insanely massive currents and magnetic fields must be swirling around black holes, pulsars, etc.! That we can ponder about, and even quantify, such things... simply amazing!!

Aaaaah! rest mass == massless, but because of their energy, and e=mc^2, there is, effectively, a mass, which the black hole can act upon... got it! Thanks!

I've also heard that black holes are so massive that the force of gravity does not let anything escape including light.

So, if photons have no mass, how do black holes keep the photons from escaping?

Homophones were my first thought as well, especially given how many times I've seen misuses of:

• their, there, they're
• to, too (and two)
• than, then
• your, you're

For more words, see: multinyms. Therein are differently-spelled yet similarly-sounding words in groups of triplets up to and including septuplets!

Here are some potentially troublesome examples that came to mind; please reply with more!

• you.are.here
• yew.our.hear
• have.whey.their
• marry.merry.Mary
• hale.seas.are
• tolled.inn.vane
• knot.holy.rued
• won.hilt.wander

As a concept for monetizing something they don't even own, I think it's absolutely brilliant. I remember when "pet rocks" were all the rage, and then the "blank on board" signs. As a novelty item, they'll probably make a fortune. Of course, the natural name for their sequel would be: four.words.too.

Q: What's wrong with complexity?

A: It hides bugs!!

Notwithstanding that some tasks are inherently complicated and there's just no simple way to express it I would posit that the problem with unnecessary complexity is that it hides bugs.

Bugs hide in the edges. They swarm in corners. They positively thrive in interfaces.

Simple (i.e. clean) code helps make the bugs stick out.

There is some business case or need behind each programming effort. That case/need has an underlying language, a grammar, that embodies what needs to be done and when and how. The challenge in software development is to find programming constructs which, inasmuch as is possible, clearly expresses the problem's solution.

Through hard-won experience we've discovered things that suggest where bugs like to hide; what are sometimes called "Code Smells." Massive, nested IF statements. GOTO statements. Global variables. Side effects.

But, these are only symptomatic. There are times when some of these ARE necessary to achieve maximum performance. In other words, not all cases are bad, but they suggest a long, hard look to ensure they are necessary.

Consider programming languages. We started with machine code. Then we wrote assemblers to make it easier to express what we wanted to do. Then came macros and functions. Still later we developed higher level languages. All of these steps allowed us to more easily express what we were trying to do.

Consider this continuum. Case 1: A single program with thousands of lines of code and no functions or subroutines. Case 2: The same application implemented with thousands of functions, each of which contain at most 5 lines of code.

There's probably a sweet spot in between those extremes. A point where the abstractions of what needs to be done closely mimics the problem domain. Where the inputs and outputs are clearly delineated and checked. Where each function is the "right size". As the lowest level functions are implemented and tested, they provide a framework, a language in which one can more easily express what is being done. It is clear what is attempted and how. And it is clear when things are amiss. It makes the bugs "stick out."

When we fail to do this, when we unnecessarily complicate the code, then problems arise. We struggle to grok the code. In this struggle, overwhelmed in trying to follow the "good" paths, we fail to see all its shortcomings. We provide hiding places for bugs. They blend in. They avoid observation. Or, when detected, resist eradication. For some samples, take a look here.

tl;dr. Given: Some problems are just plain complicated and defy any further simplification. Fine. Other problems are amenable to consistent abstractions. When we fail to do that, we introduce unnecessary complexity. We breed bugs.

Started in 1972 with 110 (?) baud dialup on an ASR-33 teletype from Junior High to the High School's DEC PDP-8 mini running TSS88. IIRC it had 8K 12-bit words of memory. Had to dial (yes, rotary dial) the phone number and put the handset into the Acoustical Coupler. Off line storage was to paper tape. Started with BASIC, then moved on to assembler and FOCAL. Then in High School they upgraded to a PDP-11 running RSTS/E. Wow -- was that thing FAST! <grin>

Typed in many, many basic programs from DECUS, and whatever other sources we could find. There were about 4-5 of us who would hang around the "computer room" and grab whatever unused half-hour time slots we could.

First computer I bought was an Ohio Scientific Challenger 4P. Later purchases included: Atari 800, Commodore 64, IBM Clone 286@10MHz.

Besides "Compute "magazine, I also subscribed to "Run", "Byte", and later "PC Magazine". Typing and debugging and trying new things. That was key. An insatiable curiosity as to how things worked and how could I make it do what I wanted it to do.

Ah, good times.

What would be REALLY interesting is if they will also pay employees based on their weight?

I imagine some kind of bonus/surcharge on top of their standard pay rate might be able to work, without it devolving into an unhealthy situation (e.g. bulimia).