Right...who cares about getting a country to overthrow it's dictatorship without using our troops to force it....

Assuming that your company offers licenses. Many patents frequently do not allow anyone to take a license unless you are cross licensing something, thus a small company has no way to get a license since they do not have a valuable patent portfolio that they could cross license with. The result is that patents frequently stifle competition.

Is it really innovative if a company has to come up with a less efficient way of doing something or must purposefully leave out features from a product, to avoid being sued over patents? Or pay large sums of money (assuming that they offer licenses) to get a license? Not to mention the cost of having the patent lawyers to begin with in order to tell them that their idea is currently patented and they can't do it. The entire thing is ridiculous.

That's a great idea, but in practice it only happens in a very small number situations. Not only that, but it means you have to invest a lot of money developing a product and hope that some company comes up and buys you, which also has enough money to license the patents involved. Your analysis might make sense if we were dealing with one patent, but frequently new software is dependent upon multiple patents. Each of which could potentially have high price tags or not even be available for license.

Not only that, but the entire situation also provides a disincentive for individual developers creating applications. Look at the recent Lodsys thing with Apple. Thousands of developers sued over a patent that should never have been granted. Many of them just took their applications off the App Store, or deactivated functionality, or paid thousands of dollars. This is innovation? Hardly.

The few times where patents might help innovation are far outweighed by the amount of times that Patents hinder innovation and hurt competition. We're just seeing it in overdrive with software because the industry moves so far, 20 years is WAY too long for a software patent. Despite my own bias in wanting software patents to go away, a compromise makes sense to me. Bring it down to 5 years, maybe even 2 or 3 years. Those are all long enough for software patents.

Executive Orders have the force of law.

Actually, engineers at all your competitor companies will have to waste more time, money, and effort to figure out a way to do the same thing you did, but not the same way you did it. And make sure that it is a sufficiently different approach so that you can't sue them for patent violation. I wouldn't call that encouraging innovation. It's also hindering innovation when you have a small company with a great idea, but can't implement it because they would not be able to pay for patent licensing. As a result the great idea never gets made, all because someone has a monopoly on an idea. It happens often enough that it's a very bad thing.

You assume that every candidate will be able to solve every problem you give them. You don't think it's possible for a candidate to come up with a solution that is incorrect despite being given correct requirements? Also, if I tell them their solution wouldn't work and they disagree and show me I'm wrong and their solution does work, then I'd be impressed that they were able to come up with a solution I hadn't thought of. It has nothing to do with me being smarter than them or not, just being more familiar with the problem. You shouldn't be asking a question to a problem that you aren't familiar with, simply by being very familiar with the problem I would be able to tell with pretty good accuracy if a particular solution would work or not. Obviously you know more than you have told them, you at least know 1 or more valid solutions. It would be pointless to give them the solution :).

You have never come up with a solution to a problem and then found an edge case that meets the requirements, but the current design would not be sufficient to fix? In such a case the only solution is to modify the design to accommodate the new case. You also assume that clients are always capable of describing all the requirements they need the first time and never make mistakes or forget something, all of which is very common. Not to mention that this is a hypothetical situation that is fabricated specifically to see how the candidate would respond in a similar real-world situation. Thus you seem to be taking this way too seriously.

I can understand this to a point, but we aren't talking about a formal analysis. We're talking about "you need to design something that achieves this specific goal." Something that every programmer who is capable of working on their own should be able to do. If you have to design everything for the programmer and they can only implement someone else's design, then they aren't an extremely useful programmer.

"Surprises" could simply be edge cases the candidate hadn't thought of. The point is to get a dialogue going and see how they think, how they approach the problem, how they react if things don't go smoothly, etc. Collaboration would evolve normally from this type of discussion where you aren't sitting and waiting for responses from the candidate but actually discussing the problem with them.

What is your point? Google is an advertising company that makes products which are then vehicles for advertising. They aren't good developers because the product they created doesn't make money for them directly? That's a completely ridiculous way of looking at it.

The frustrated part is not something I assume will happen, neither do I assume that the first approach to the problem will be wrong. However, when giving an interview problem, if they get the answer to the problem there are two ways to continue the interview. You can ask a different problem, or you can continue with the current problem and take it further. Usually, the most common solution to a few design problems that I ask during an interview falls apart if you extrapolate and add new requirements. Not only that, but frequently (very frequently unfortunately) a candidate will start working on a solution that just will not work. You don't correct them immediately, you see whether they recognize that their solution won't work and admit they are wrong and change their approach.

While I don't assume that this will happen, I do try to purposely cause this to happen. If they come up with a solution that works, I will purposely say "ok, now what if you need to do this...." which will be something that I know will require them to change their current design to accommodate. The point is not to "make myself feel smarter than the candidate" the point is to see whether the candidate is able and willing to modify their current design to changing requirements. This is an important skill, and one that I've seen many candidates lack.

"Many" good programmers is not "all" good programmers. Not only that, but "needing help" is not the same as "working collaboratively". If they can't work collaboratively, that's a bad sign.

Hmm, that "obsolete" droid you have? I did a little searching a while ago, downloaded an application, and then installed a custom rom on the phone (I'm assuming you're talking about the original droid which was unlocked). Now, my "obsolete" phone is only as obsolete as its hardware, running 2.3.7

IE has bitten me many times....big ole red welts on the massive rewrites of web site code for things that work standard in other browsers but require special IE handling...

Having your OS be managed code is a horrible idea. The OS should be native code. Otherwise you'll have to write a native code JIT anyways which needs to run....inside an OS...you see the problem. You could always bootstrap it, but that just seems messy.

In addition, C++ optimizes exceptionally well. You can see massive improvements simply from compiler optimizations. Would you care to have some kind of source backing up your claim that Objective-C optimizes better than C++? It seems highly unlikely. As far as compilers, I agree that LLVM is definitely better than gcc, but nothing really stops you from using LLVM to compile Android instead of gcc.

Lastly, whole program optimization is useful for any program. Doesn't matter how dynamic it is, no one rights fully optimized code that is optimized in every possible way (unless you're awesome and writing assembly directly which very few people do anymore). The compiler will always find things it can optimize, and whole program optimization will find more optimizations to make than simply running optimizations on the individual modules only.

Care to back up that statement? By definition, the difference between whole program optimization and per module optimization, is that the whole program optimization can do more optimizations. It can be certain about the safety of more things like inlining thus reducing the memory footprint and improving performance.

JIT has nothing to do with the OS and everything to do with the applications that are running on top of it. The JIT was for dalvik running applications, the OS is, for the most part, compiled C++.

Actually, to be pedantic cause it's fun. Catering your business to people with an IQ over 60 will cost you less than half of potential customers, 100 is the average IQ by definition. Thus everyone with an IQ over 60 is catering to more than half the people in the world. :)

Gah, why is my statement being so misunderstood.

I was arguing AGAINST apple. GP said questioned whether it could be a natural progression from the standpoint that Apple "re-invented" the touch screen. But just because Apple made the touchscreen technology more popular with a good product does not mean that the idea of icons on a screen to touch was not a natural progression from the desktop model of a mouse and clicking on things.

Apple should NOT be allowed to stop others from implementing stuff, especially because it's not even anything novel, it's just a natural progression of ideas.

Nice assumption you're making. I was not voting in apple's favor at all. In fact, i was pointing out that Apple didn't "re-invent" the touchscreen. I was pointing out that making some old technology popular by getting to market with something that people liked more, does not prohibit something from being a natural progression.

It is definitely a sad fact that requirements for obviousness are not followed well enough. And I do not like the iPhone better. Best not to make assumptions. I avoid all Apple products.

I think you're referring to the hardware, as in having one whole touch screen rather than a split phone with a touch screen and keyboard. Which is only a small piece of the claims.

The idea of a screen, with icons and apps, etc. that you could touch, was how android was developed from the beginning. Considering the announcement of Android was only 10 months after the iPhone's announcement (5 months after it's release) there's no way they could have entirely redesigned it as people claim in order to "steal" the iPhone ideas. There's two things that happened: simultaneous development of ideas between Android and iOS, and normal competition (Hey, that guy's product does this. People love this. Let's do it too). But the behavior and ideas of a touch screen, with apps, icons, etc. weren't stolen. In fact, Android released with the android market and ability to get apps. The iPhone did not.