在那个几乎没人再实践的耐心时代，打开一本计算机杂志，找到一个跨越三四页的BASIC或汇编程序清单，然后开始一行一行地抄写。不能跳过，也不能“够近”，因为一个额外的空格或者一个换位的括号意味着程序根本无法运行。我记得键盘敲击声整整几个小时，那种机械的节奏更像是专注于不犯错，而不是实际理解自己在输入什么。到最后，有时一个下午过去了，按下运行，屏幕上却弹出一条某行的语法错误，没有任何实质性的解释。那时候没有堆栈溢出。没有搜索按钮。只有你，桌子上摊开的杂志，以及如果有的话在下一期发布的勘误表。那时的调试几乎是一种身体上的体验。将屏幕上的字符与纸上的字符逐一比较。意识到那个看起来像小写字母“l”的“1”让你困惑了半个小时。或者在三十行数字中找不到某个DATA行。这个过程缓慢，有时很乏味，但它教会了人们现在试图通过练习和教程模拟的一些东西：仔细阅读代码，在动手之前理解结构。在这一切中有着社区，只是分散而缓慢，以邮件的方式运转。人们给编辑写信指出清单中的错误，其他人则提交同一程序的变体，改进或适应其他计算机。给编辑的信是一种论坛的前身，只是问题与回答之间有几周的延迟。与现在编程聊天中发生的情况并没有太大不同，除了我们将纸张和邮票换成了即时回复——老实说，我仍然不确定这在每个意义上都是一个好的交易。并不是说现在的事情更糟。有自动补全，有能在几秒钟内标记错误的AI，整个社区只需一键即可接入——这节省了以往没有学习太多而浪费掉的几个小时，只有挫败感。但在这个过程中也失去了一些东西，那就是慢慢阅读的义务，理解每一行，因为没有捷径可走。从杂志上编码并不高效。它完全是另一回事。一个社交新闻和讨论社区 Comuniq © 2026 | 评论 | 条款 | 指南 | 联系