大多数早期的计算机，比如在普林斯顿大学高级研究所约翰·冯·诺伊曼地下实验室运转的那台，都包括一个基础的视觉显示装置。在这个装置中，每一个比特都有灯，所以你可以看到比特时不时地跳动一下。[3]通过这种方式，你可以真实地看着程序运行。[4]我喜欢这样看待计算，计算是材料状态变化、比特翻转的具体过程。
可以想象，如果程序员想让这些灯更有用，就可能会出现不同的计算机编程方法。想象一下，这个模糊又原始的可视比特阵列的跳动会变得越来越好，直到你可以在屏幕上绘制和重新绘制比特，这样我们就可以一边运行程序一边修改程序。
怎么做到这一点呢？你如何知道你所绘制的比特的意义或含义？你怎么知道哪个比特负责做什么事情呢？
你如何保证计算机不死机？你的绘制能不能做到足够完美？记住，即使最细微的错误也可能导致计算机死机。
这些比特不能仅仅显示为无意义的混乱，我们必须将比特组织成有意义的图片，因此一定要有清晰的、带强制约束力的绘制方法。
请暂时放下对这一方法是否实际、可取或可行的怀疑。
我怀疑，如果当时的计算机编程沿着这个方向发展，今天的整个社会将截然不同。主要原因可能有些难理解，不过之后我会再回到这一点：当你看着这些比特并进行操作时，你会对计算机有更加实质和现实的感觉。
然而，源代码不是完全现实的。它是与特定计算机语言相关的抽象描述。源代码使我们一直专注于这样的抽象语言，数字文化的居民从一开始就相信这样的语言，也许还因为过于相信AI等抽象实体或所谓的完美形态而变得有些脆弱。
我们先将这一假设放在一边，可视化、可实时编辑的具体计算方式将实现“无模式”，更适合VR。你可以在身处VR的同时改变VR，这会更有趣！
我刚刚描述的只是个设想，但源代码编程的概念已经盛行起来。
源代码有很多值得喜欢的地方。你每次测试软件时都清楚软件的状态，所以理论上至少可以让测试更加严谨。在实际中，软件仍然很难调试，这是另外一个话题了。有的人可能不知道，“软件错误”（software bug）一词源自霍珀在一台早期计算机里抓到的飞蛾，这只飞蛾导致了程序中断。
我见过霍珀几次，我也非常尊重她的工作。老实说我有点怕她，但这个例子很好地说明了还存在一些计算机科学忘记探索的路径。我们没有必要认为所有软件都必须遵循霍珀设定的模式。