Within technical limitations, they can do anything they want with their site. However, some things they could do may have legal or financial consequences.

One of the things that keeps traditional aircraft pretty safe is that the pilot is inside the plane and is highly motivated not to crash. Perhaps to keep drones safe as well, we should keep the risk with the pilot -- if you crash a drone, the penalty is the same as if you were inside the plane you were remotely piloting (penalty up to and including death).

The range of penalties would of course need to be scaled to the size of the drone -- a toy quad-copter is not the same as a Predator, but the point is the legal infrastructure needs to ensure responsibility for those piloting drones. Note that I emphasized the pilot. The pilot needs to be on the hook, not the company employing the pilot, the manufacturer of the drone, or anyone else.

Think of the fun that could be had with this. Fits in the same socket and does who knows what.

Good example of a high bandwidth, high latency data transfer.

You mean like Java Web Start or .Net Click Once?

As long as internal car data bus allows me to tie the sound system to the suspension system so I can bounce with the music down the road.

Um... PowerShell has nothing to do with Visual Studio. In fact (among other things), PowerShell lets you easily script against the native .NET libraries without having to compile code.

Prior art: New Coke.

I think it is more about understanding the semantics of the interview question, because being able to understand specifically what is being asked is a critical skill in programming. There is a subtle but important distinction between "How would you obtain the value for PI in your program?" and "How would you calculate PI in your program?" An excellent answer to an interview question about "calculating PI" would be a discussion about what is really being asked as such a discussion would indicate that the candidate recognizes the subtleties and also knows that questions asked of programmers are not always clear or precise. (Of course having an answer to each possible flavor or meaning of the question is a bonus.)

Because doing so was the task suggested by the parent thread as a possible interview question. A response to that suggested using a programming library to instantiate a circle object and simply extract the circumference and diameter properties from the object, apply a little math and voila. My comment was that doing so didn't count as calculating PI, rather it was just indirectly extracting the constant from some other programming library.

If I were doing the interviewing I wouldn't expect someone to know how to calculate PI, but I would expect someone to know the difference between extracting a constant from a library (directly or indirectly) and knowing the mathematical or other process for deriving the constant. I would be concerned if a candidate didn't know the definition of PI.

I agree with your comments on memorization of APIs and code being a poor indicator of a solid programmer.

Only if you could tell me to how many digits the approximation of 22/7 is accurate for during the interview. If that was your answer, I would need to further probe into how you approach problems that there is not simple shortcut for.

Of course then you are not actually calculating PI, you are extracting (via geometry / math) the value of PI embedded in the circle class that you probably didn't write.

Off the top of my head I have no idea how to actually calculate PI from scratch. If I get to leverage the underlying geometric or trigonometric libraries in the environment, sure; but from scratch, no. I could, of course, look it up, but the context of the interview question above didn't imply that reference material was an option.

If I were interviewing someone and asked the "calculate PI question" and they gave me the response that I gave above, I would consider it a "passing" answer. When I interview people (for programming or otherwise), I am more interested in their ability to understand and clarify the question and how they approach answering the question instead of the actual technical answer. You can look up technical references, you can't look up how to think and communicate.

Here in the United States, in the state of Oregon, a blinking yellow is a cautionary signal, it is not a yield. Here is the driver's manual as a reference. Same rules in the state of Washington and Calfornia. I haven't checked the rest of country but to my knowledge the rules for basic traffic signals are consistent across the entire US.

Where are you from where this is not the case?

Please just have a profile option that says "Don't ever change anything on the interface", ever.

If you move the blue button labeled "Compose" located in the upper left corner of the screen to the upper center of the screen, my dad won't be able to find it and he will call me and say his email is broken. If you change the color of the button, he will call me and tell me that email is broken. If you change the label from "Compose" to "New Email", he will call me and say his email is broken. If you pop up a great big dialog box on the middle of the screen that uses a bold blinking font and uses very noticeable colors, and this dialog box says "Welcome to the new mail interface, click here to learn about it.", my dad will somehow figure out how to close the dialog without reading it or the associated help and of course, he will think that email (or the Internet itself) is broken.

No, I can't just teach my dad to be more flexible. Unlike other compatibility issues as technology progresses, I can not replace or "upgrade" my dad. He is 78 years old and is not into learning new tricks. He is a smart guy and is capable off learning new things, but he is old and crotchety and complains a lot every time he has to...

Please please please remember that there is a segment of the user base that views even simple interface changes as a huge deal.

How about even simpler? Cyclists follow the same rules as drivers of cars or any other vehicle type on the road.