在看一些量子计算机相关的文献，看到这么一段：
来源： http://www.monoidal.net/papers/tutorialqpl-2.pdf
Speci cation and veri cation.
In classical programming languages, debuggers
are useful tools while writing programs. In quantum computation, due to
impossibility to watch quantum information without modifying it, a debugger
for a program is a lost cause.
In classical programming languages, one can develop test suites to analyze
the behavior of a program and check whether it (statistically) behaves
correctly in the expected input data-range. In the case of embedded software, if
it is not possible to do it with the actual device, one can usually perform these
tests o -site. In quantum computation, because of the cost of running code
early quantum computers and the impossibility to e efficiently simulate quantum
computation on large inputs, test suites are not an option.
In typed classical programming languages, one has the choice between
strong type systems, dynamic type systems, or even blends of these, bearing the
fact that run-time errors can be captured and potentially resolved by the user
(as in LISP, for example). In quantum computation, due to the cost of the run
of a quantum computation and the difficulty to keep stable quantum memory,
the programmer cannot afford run-time errors in his code, specially if they come
from something as simple as the attempt to clone a quantum bit.
The conclusion is that the work have to be done upstream.
简单的说就是由于观察者效应，对量子态的观察必定会造成结果的改变，你不可能设个断点然后把量子CPU上的寄存器内容撸出来看了，还能继续正确运行，你一观察内容就变了。所以调试器是不可能有的。
由于运行成本高，以及不可能有效的对输入数据规模很大时的运算过程进行模拟，所以测试也是不可能。
唯一的出路只有在编译时验证。
所以如果人类一开始捡到了外星人的黑科技，尝试在没有电子计算机的情况下，直接去点量子计算机的科技树，可能根本无法做到自举，因为要写出一定规模的量子程序，需要首先有另外一种运算能力强的设备去撸编译器。
来源： http://www.monoidal.net/papers/tutorialqpl-2.pdf
Speci cation and veri cation.
In classical programming languages, debuggers
are useful tools while writing programs. In quantum computation, due to
impossibility to watch quantum information without modifying it, a debugger
for a program is a lost cause.
In classical programming languages, one can develop test suites to analyze
the behavior of a program and check whether it (statistically) behaves
correctly in the expected input data-range. In the case of embedded software, if
it is not possible to do it with the actual device, one can usually perform these
tests o -site. In quantum computation, because of the cost of running code
early quantum computers and the impossibility to e efficiently simulate quantum
computation on large inputs, test suites are not an option.
In typed classical programming languages, one has the choice between
strong type systems, dynamic type systems, or even blends of these, bearing the
fact that run-time errors can be captured and potentially resolved by the user
(as in LISP, for example). In quantum computation, due to the cost of the run
of a quantum computation and the difficulty to keep stable quantum memory,
the programmer cannot afford run-time errors in his code, specially if they come
from something as simple as the attempt to clone a quantum bit.
The conclusion is that the work have to be done upstream.
简单的说就是由于观察者效应，对量子态的观察必定会造成结果的改变，你不可能设个断点然后把量子CPU上的寄存器内容撸出来看了，还能继续正确运行，你一观察内容就变了。所以调试器是不可能有的。
由于运行成本高，以及不可能有效的对输入数据规模很大时的运算过程进行模拟，所以测试也是不可能。
唯一的出路只有在编译时验证。
所以如果人类一开始捡到了外星人的黑科技，尝试在没有电子计算机的情况下，直接去点量子计算机的科技树，可能根本无法做到自举，因为要写出一定规模的量子程序，需要首先有另外一种运算能力强的设备去撸编译器。
3
Select Language