大多數早期的計算機，比如在普林斯頓大學高級研究所約翰·馮·諾伊曼地下實驗室運轉的那台，都包括一個基礎的視覺顯示裝置。在這個裝置中，每一個比特都有燈，所以你可以看到比特時不時地跳動一下。[3]通過這種方式，你可以真實地看著程序運行。[4]我喜歡這樣看待計算，計算是材料狀態變化、比特翻轉的具體過程。
可以想像，如果程序員想讓這些燈更有用，就可能會出現不同的計算機編程方法。想像一下，這個模糊又原始的可視比特陣列的跳動會變得越來越好，直到你可以在屏幕上繪製和重新繪製比特，這樣我們就可以一邊運行程序一邊修改程序。
怎麼做到這一點呢？你如何知道你所繪製的比特的意義或含義？你怎麼知道哪個比特負責做什麼事情呢？
你如何保證計算機不死機？你的繪製能不能做到足夠完美？記住，即使最細微的錯誤也可能導致計算機死機。
這些比特不能僅僅顯示為無意義的混亂，我們必須將比特組織成有意義的圖片，因此一定要有清晰的、帶強制約束力的繪製方法。
請暫時放下對這一方法是否實際、可取或可行的懷疑。
我懷疑，如果當時的計算機編程沿著這個方向發展，今天的整個社會將截然不同。主要原因可能有些難理解，不過之後我會再回到這一點：當你看著這些比特並進行操作時，你會對計算機有更加實質和現實的感覺。
然而，源代碼不是完全現實的。它是與特定計算機語言相關的抽像描述。源代碼使我們一直專注於這樣的抽像語言，數字文化的居民從一開始就相信這樣的語言，也許還因為過於相信AI等抽像實體或所謂的完美形態而變得有些脆弱。
我們先將這一假設放在一邊，可視化、可實時編輯的具體計算方式將實現「無模式」，更適合VR。你可以在身處VR的同時改變VR，這會更有趣！
我剛剛描述的只是個設想，但源代碼編程的概念已經盛行起來。
源代碼有很多值得喜歡的地方。你每次測試軟件時都清楚軟件的狀態，所以理論上至少可以讓測試更加嚴謹。在實際中，軟件仍然很難調試，這是另外一個話題了。有的人可能不知道，「軟件錯誤」（software bug）一詞源自霍珀在一台早期計算機裡抓到的飛蛾，這只飛蛾導致了程序中斷。
我見過霍珀幾次，我也非常尊重她的工作。老實說我有點怕她，但這個例子很好地說明了還存在一些計算機科學忘記探索的路徑。我們沒有必要認為所有軟件都必須遵循霍珀設定的模式。