Later in the game, sure. Who's going to build the early toolset? Who's going to own it? Will their be a FOSS API, or will we be locked in?

All of that design infrastructure needs to be built by somebody, and that somebody stands to make a forunate. The tasks you listed are a decent summary of the likely eventual outcome.

But:

• Who will do the work to create this beautiful API? • Who will create this coprocessor architecture? • Will this theoretical stack be built by Microsoft, Amazon, Google, etcetera, or be FOSS?

These questions are completely unanswered, and will affect my users of whatever quantum. When analyzing data, one cannot usually just gloss over the underlying math. All abstractions, by definition, are incomplete.

But that's the exciting thing about right now. Most inventions occur when science outruns engineering. When engineering and cutting edge science just about to finally converge, that's when market opportunities are most prevalent.

How many people/companies did it take to build GPUs? A lot of people, to be sure, but as a fraction of all software engineers, that number is incredibly tiny.

The vast majority of software engineers---even if we filter to just the set who have actually used GPUs for a project---only know the high-level APIs (OpenGL for graphics, CuDNN for AI, etc.). Fewer engineers are familiar with the more general-purpose APIs (CUDA, OpenCL, etc.), and even fewer still know any of what goes on underneath those layers.

Bottom line: it takes a relatively small community of people to build tools for everyone else to use. People will need to know how to use the highest level of APIs, but most need not understand what goes on underneath that.

Or a better way to put it in my own opinion: in the early days of any emerging technology, most of the founding members have little clue what to do except the concepts and ideas, so implementing toolsets which can be used on both quantum computers and non-quantum computers will be a learn-on-job work for most people, leaving a very very very small pools of experts who devoted his/her life to this area.

These questions are not completely unanswered. These dry problems are what Rigetti Quantum Computing [1] is working on.

[1] http://rigetti.com/about

I came to the same conclusion after implementing a QC emulator. But note that QC doesn't even typically change exponential functions to polynomial; rather it will cut the exponent in half.

More often than not it cuts the polynomial exponent in half via some use of Grover's.

I'm having trouble wrapping my head around a quantum computer emulator, how is that implemented on a conventional computer? Could you elaborate? Thanks.

You can simulate quantum processes on a classical computer by keeping track of the amplitude of every basis state in the tensor product space of the thing you are simulating. Basically, you're running a physics simulation. It's extremely inefficient, and in terms of classical RAM required it is exponential in the number of qubits you are trying to simulate, but useful for prototyping, debugging, and learning about quantum algorithms.

Google wrote a nice one that makes use of WebGL: http://www.quantumplayground.net/

Thanks for the link.

But this is like arguing that computer scientists shouldn't take algorithms courses. Actually, it's not just like it, it -is- arguing that they shouldn't bother learning to understand certain types of algorithms. Without that knowledge, how do you possibly know how to get an advantage from the co-processor beyond blind luck or hoping the API implements exactly the functionality you want?

It's more like arguing that computer scientists shouldn't have to learn how ICs are fabricated and how PCBs are designed. They can learn if they want, but they shouldn't have to.

Quantum algorithms are so vastly different in nature from classical algorithms that it will necessarily be its own branch of science. It takes an entirely different mode of thinking; for example, basic physics laws forbid you from copying a qubit that is in an arbitrary quantum state. That's right, you cannot copy a quantum variable as that would violate fundamental laws of the universe as we know it. Most computer scientists are not used to that kind of thinking. However traditional computer science thinking will not vanish, because quantum computers will never be a replacement for classical computers; they are good at speeding up very specific classes of computations and not particularly suited for general computing or building interfaces with the outside world.

Quantum computer science and classical computer science will be two fields of study that will both continue to evolve in their own right.

I strongly disagree. The IC and PCB analogy is not accurate. The equivalent would be saying that computer scientists should not need to learn about ion traps and SQUIDs, and I would agree with that. Quantum algorithms, on the other hand, are just algorithms, albeit ones in which you are allowed an extra operation. While now may or may not be the time to introduce this into CS courses, quantum information processing will only become more important over time, rather than less. The argument about them never superseding classical computers isn't something that there is any real support for, except that it is hard to build QCs at the moment. The same could have been said for classical computers not that long ago. It's not clear from your answer whether you know this or not, but quantum computers can perform classical computation. So, this is like in the 40s saying that there would always be a roll for human computers or mechanical computers, while now we would think that was a ridiculous position given at how good we have gotten at making ICs.

I'm not an expert on quantum programmig but the impression I kind of got is that you don't just go around writing quantum programs like you would for a classical computers. Instead, you have very particular problems where very particular quantum algorithms are more efficient than the classical ones.

If I had to bet I would guess that quantum programming is going to be more like "linear programming", where instead of programming the algorithm instructions you program by preparing the inputs that you will pass to the specialized subsystem.

So, to be clear, you're predicting that quantum computers will work on exactly the same code but give a magical speedup?

Seems naive to me.

Quantum computers may work in analogous ways, but making predictions about what you'll need to know is presumptuous. `factor` is the easiest way to use a quantum computer in an "api" sense and, by itself, isn't very useful at all.

They said "quantum computing", not "quantum mechanics". You still need to know which operations are suitable for speedup.