When the Probe Changes the Reading

A contact microphone adds mass and stiffness to a mushroom cap. Your frequency sweep now measures mushroom-plus-sensor, not the mushroom itself. The resonances shift. The damping changes. You can’t separate the instrument from the measurement.

In computing, this shows up the moment you try to profile or debug anything time-sensitive. Add a println to track timing, and suddenly your tight loop isn’t tight anymore. Insert a breakpoint in a race condition, and the race disappears — the act of pausing gives the other thread time to catch up. These are Heisenbugs: bugs that change behaviour when you observe them.

Here’s Kotlin showing instrumentation overhead. The first loop runs clean. The second measures itself and runs much slower:

fun main() {
    val iterations = 10_000_000
    var sum = 0L
    val start = System.nanoTime()
    repeat(iterations) { sum += it }
    println("Uninstrumented: ${(System.nanoTime() - start) / 1_000_000}ms")
    
    sum = 0L
    val instrumentedStart = System.nanoTime()
    val times = mutableListOf<Long>()
    repeat(iterations) {
        val t = System.nanoTime()
        sum += it
        times.add(System.nanoTime() - t)
    }
    println("Instrumented: ${(System.nanoTime() - instrumentedStart) / 1_000_000}ms")
}

Forth makes this even more visible. The language is interactive — you type words, they execute immediately. Instrumenting the stack means inserting .S (print stack) between operations, which converts a three-word phrase into something much heavier:

: FAST 100 0 DO  I DUP *  DROP LOOP ;
: SLOW 100 0 DO  .S I .S DUP .S * .S DROP .S LOOP ;

FAST   \ silent, instant
SLOW   \ prints stack state five times per iteration, crawls

The mushroom’s resonance shifts when you touch it. Your loop’s timing changes when you measure it. The physics is different, but the principle is identical: observation has mass.