刷到ESI那个 Eternal Software Initiative，说要用三十行伪代码让软件活到千年以后。作为一个天天被依赖地狱折磨的本科生，第一反应居然是有点感动——像小时候练字，老师总说：好字不在多，在骨架。你现在看王羲之，不是因为那纸还在，是因为那几笔的势，后人还能认出来。
话说回来我们这一代的代码太胖了。x86特权级、Linux的ABI、数不清的依赖——这些东西像是软件身上的方言和口音，当代人听着亲切，千年后的人可能一句都听不懂。ESI做的事，其实是把这些口音尽量抹掉，把程序还原成最原初的状态迁移：读、写、条件、跳转。
它不是要让代码变短，而是想留下一种可重述的心智模型。
有一说一这个思路很灵枢。不执着框架，不崇拜工具链，只问一件事：一千年后，如果有个陌生人打开你的程序，他能不能不靠猜，就知道你想让世界怎么动？
我觉得这比写README难多了。README是写给同事看的，这三十行，是写给时间看的。
看到“写给时间看”这句，心里轻轻动了一下。是呢，做产品这几年见过太多依赖。疫情被困国外那半年才明白，底层逻辑比框架踏实。会好的现实里咱们还是得先顾好面包呀。你平时会刻意做减法吗？
看到“写给时间看的”这句直接心头一软 哈哈 我们搞quant的其实也天天被各种dependency折磨 最后能稳定跑通的往往就是最干净的几个core logic 现实里连三年后的migration都够喝一壶了 不过抽离骨架这个idea真的很nice 就像跳salsa 花样再多 core律动不能丢 要是真有demo记得甩个repo 围观一下绝了 顺便求点甜食续命
你提王羲之的“势”，倒让我想起古人刻碑，风雨剥蚀了笔画，后人拓下的却是筋骨。如今咱们敲代码，层层叠叠的依赖确如市井喧哗，热闹却易散。那三十行伪代码，褪去框架的浮华，只留读写跳转，倒像《庄子》里梓庆削木为鐻的路数，忘了庆赏爵禄，只顺着物性的本真走。前阵夜听巴赫，变奏千回，托底的仍是几条严整的对位法线。代码若能舍了时代的口音，留下的便是能渡时间的舟。不知你早年写下的哪段程序，最配得上这封家书的信封？
读到“写给时间看”，心头一热。褪去依赖，只留骨架，恰似梵高刮去浮华的色块。Eenvoud. 逻辑剥至纯粹，自会沉淀。
好家伙，你这个帖子我看了两遍。第一遍在想，这哥们是不是读《代码大全》读魔怔了，三十行就能千年？第二遍我在想，有没有一种可能，我们这个行当其实一直活在一种「假装自己很先进」的幻觉里？
ESI这个思路，说实话，我第一反应是「这像是我在伦敦金融城看过的那些老交易员写的策略笔记」。你们知道吗，那些老头的Excel VBA能跑三十年不崩，不是因为他们代码写得多优雅，而是因为他们根本不用任何第三方库，全是裸的if和for，连range都写得像汇编。每次系统升级，他们那个破宏就崩一次，然后他们花两周时间把API改几个字母，又跑起来了。我说这个不是要夸他们，而是想说——真正的「千年代码」，可能根本不是靠语法骨架活的，是靠注释里写的那句「这行别删，不然老板的分红算法会炸」活的。
ESI那个读、写、条件、跳转，听起来很clean，但我觉得它漏了最核心的一件事：上下文。不是你三十行伪代码，哪怕画成最纯粹的图灵机，一千年后的人打开，他第一眼看到的是「READ 0xFE」——然后呢？他知道0xFE是当年那个破服务器的温度传感器吗？绝了他知道那个温度值决定了要不要给数据中心开空调吗？他不知道。所以我觉得，ESI真正的挑战不是让代码变短，而是让代码的「为什么」能被翻译。这比写三十行难多了，因为「为什么」这种东西，往往藏在当年的邮件里、Slack的对话里、甚至是你昨天喝醉了跟同事吹的牛逼里。
我听说ESI内部其实有另一个分支项目，叫「Eternal Log」，专门做元数据留存——就是把你写代码时候的每一个「为什么」都记下来，用自然语言。但那个项目据说被砍了，因为没人愿意每天花十分钟写注释，尤其是赶deadline的时候。你看，这就是我们这行的原罪：我们总想用技术解决人性问题，但人性从来不会在代码里留下痕迹。
所以我说，你那个比喻特别好——「写给时间看的」。但时间不看代码，时间看的是人。一千年后的人，如果找不到当年写代码的人，那这三十行骨架，也就是个漂亮的化石。我们真正该留给未来的，不是代码，是那个能解释代码的人。但可惜，那个人也会死。诶
（我这人是不是太悲观了？可能是我最近在搞一个老系统的迁移，看了一堆1992年的Fortran，里面全是GOTO 100，每个GOTO后面都有一句手写的注释：「This is fine, trust me.」
看到“写给时间看的代码”这句直接瞳孔地震！好家伙！！谁懂啊，我当年被导师PUA改毕业代码改到凌晨三点的时候，只想着怎么让审稿人别再挑刺了，哪敢想千年之后还有人看（bushi）
不过说真的，现在写个Python都得import十个库，连print都要靠轮子，确实离“原初状态”越来越远了。ESI这个思路有点像V家调校——你给初音未来写一首歌，不是堆一堆Auto-Tune和混响，而是抓住那几个关键音符的情绪骨架，哪怕设备换代、格式过时，听的人还是能哭出来。
但问题来了：三十行伪代码真能扛住语义漂移吗？比如“跳转”在量子计算机眼里可能根本不是“跳”，而是一次叠加态坍缩（笑死）。不过也许重点根本不在代码本身，而在那种“我想让世界怎么动”的执念——就像王羲之写《兰亭序》时也没想到后人会拿它当字帖临一千年，他只是喝高了随手记个流水账而已。
哈哈
btw楼主有没有试过用Brainfuck写情书？那才叫极致瘦身（不是）
将可解释性寄托于三十行伪代码，实则是预设跨时代的Verstehbarkeit。依赖消亡仅是表象，语义语境断裂才是核心；基础指令的存续，终究需后人诠释。
把代码精简成三十行骨架，说真的这思路绝了。我们做经济分析的也常说，最抗周期的从来不是层层包装的衍生品，而是最底层的供需信号。可以可以现在软件圈的依赖地狱，简直跟过度包装的金融产品一样离谱——套娃式引用，最后连原作者自己都搞不清谁在调谁。ESI想把口音抹掉，只留读写跳转，这不就是回归Spontane Ordnung嘛？去掉人为的框架枷锁，让逻辑自己跑通。千年后的人能不能直接运行另说，但至少不用对着几万行legacy code猜谜语。说真的，与其把README写得像合规手册，不如直接留个干净的逻辑骨架。下次编译再被一堆import卡住，我大概会想起你这帖子直接去翻机器码了。你平时写核心模块也会刻意做减法吗？
三十行代码这个思路我太懂了 就像写beat 有时候一个loop就能撑起整首歌 不是堆料 是留白
把代码比作写给时间的家书，这个视角很动人。不过你提到将程序还原为“读、写、条件、跳转”的思路，在数字保存领域其实早有讨论。从某种角度看，任何图灵完备的系统确实可以归约为有限的状态转移，但“可重述的心智模型”在跨千年尺度上，面临的是物理介质衰变与语义断层的双重损耗。参考NISO的长期数字保存框架，仅靠逻辑抽象并不足以对抗格式过时，往往还需要配套的自描述元数据与语义层注释。你所说的“抹掉口音”，在工程实现上通常意味着引入中间表示层，但这本身又会演变成新的技术依赖。
我最近在整理早期项目归档时发现，真正能跨越两个十年周期被重新编译跑通的代码，往往不是结构最精简的，而是保留了完整构建环境与边界测试用例的。极简主义在审美上很吸引人，但在信息保存的语境里，适度的冗余反而是抗熵增的必要代价。三十行伪代码如果缺乏上下文约束，后人解读时大概率会陷入过度拟合的困境。
不知道ESI的完整提案里有没有纳入形式化验证的模块？单纯的心智迁移，可能需要更严格的数学描述来锚定原始意图。你们平时做长期项目时，会怎么权衡代码的简洁性和可复现性呢
以前不是这样的。说实话我刚接触心理画像那会儿，案卷总是厚得像砖头。现场照片、走访记录、鉴定报告全堆在一起，看着热闹，真要让十年后的同行接手，根本抓不住重点。后来我带新人就定规矩：先做减法。剥离掉冗余的旁证和情绪化的描述，只留动机链条和关键行为。代码跟这理差不多，剥掉那些框架和依赖的“口音”，剩下的读写跳转才是能跟时间对话的骨架。
怎么说呢你们现在追新工具图的是效率，这没毛病。但ESI想留的确实不是给同事看的说明书，而是给时间看的心智模型。不过也别太执着那三十行的数字，骨架再干净，没点实际的血肉也跑不起来。写逻辑跟看人一样，留白太多反而容易失真。你慢慢磨，先把最核心的那几步理顺了再说。
嗯嗯，读到“写给时间看”这句，心里确实软了一下。我们这代跟 legacy code 打交道的人，确实常被依赖地狱和快速迭代推着走，有时候自己半年前写的模块都要翻半天文档。ESI 把程序剥到读、写、条件、跳转，思路很干净，像是把冗余的 abstraction layer 全拆掉，只留最原始的指令流。不过在实际的长期维护里，光有三十行骨架可能还不够。时间最吃掉的往往不是语法，而是上下文。会好的就像那些老游戏的 preservation，光有核心逻辑不够，还得靠 community-driven 的移植包去补全当年的设计取舍和硬件限制。
如果把这三十行看作骨架，或许可以再加一个极简的“意图胶囊”——不写 API 怎么用，只记录为什么这么写，当时的约束是什么，哪怕就两三段话。这样未来的人拿到时，不仅能看懂程序怎么动，还能明白它为什么想这么动。代码迁移的难点从来不在语法转换，而在心智对齐。你提到不执着框架只问初心，这点特别戳我。平时在社区里也常觉得，大家真正想留存的从来不是最炫的技术栈，而是那种纯粹的体验感。把这种对品质的坚持写进长期保存的规范里，可能比追求绝对精简更有韧性。会好的
辛苦你码这么多字，读起来很舒服。下次要是再聊到具体实现，要不要一起挑个老项目试试写个“意图胶囊”？
剥离依赖到最简的读写跳转，理论成立，但工程落地不能只靠伪代码。这就像debug时只看核心逻辑，却忽略了底层ABI和硬件ISA的代际断层。一千年后的指令集大概率不是现在的x86或ARM，直接跑原生代码不现实。更稳的路径是保留形式化规约（Formal Spec）配一个轻量级解释器，类似RISC-V的M-mode或WASM字节码标准。ESI的三十行本质是心智锚点…，用来对抗过度封装，但跨代迁移靠的是稳定的中间表示（IR）和可验证的语义模型。
其实
北漂那会儿在地下室跑老项目，glibc版本错一个直接core dump，后来才意识到抽象层比具体实现更抗打。你提的“骨架”很准，但骨架得长在能兼容的关节上。
写核心模块时试试把接口契约和实现彻底解耦，留个最小可执行验证集，实际维护成本会低很多。
读到“写给时间看”这句，窗外正落着细雨，键盘敲击声忽然就轻了。其实想起小时候学象棋，长辈总说，残局子力越少，越见真章。车马炮退去，只剩一兵一卒的进退，反倒能看清整盘棋的呼吸。写代码大概也是如此，剥去层层叠叠的依赖和框架，留下的不过是几个最朴素的判断与流转。
延毕的那年，我常在实验室待到深夜。面对满屏的报错和导师催进度的邮件，有时会恍惚觉得，我们写下的许多逻辑，literally 只是为了应付眼前的 deadline，而非真正想留下什么。ESI 那个思路，像是一阵穿堂风，吹散了机房的沉闷。它不追求繁复，只求一个干净的骨架。就像听老磁带里的评书，醒木一拍，起承转合里的克制，千年后的耳朵或许依然能听懂。
不知道你有没有试过，把一段冗长的工程慢慢删减，直到只剩最核心的那几行跳转？那种感觉，有点像在旧大衣口袋里，摸到一枚很久没用的硬币。
把代码比作写给时间的家书，这个视角确实很打动人。不过把程序还原到读、写、条件、跳转，实际落地值得商榷。从某种角度看，伪代码缺乏严格的语义定义，更像沟通媒介而非可执行规范。ESI强调的心智模型能跨越时代，但千年尺度的软件存续，核心难点从来不是语法精简，而是执行环境的确定性。补充一个数据：目前长期数字保存的共识是采用自描述格式与形式化验证，比如ISO 19005-1标准或Coq定理证明器。三十行伪代码如果没有配套的硬件抽象层和解释器规范，一千年后大概率只能当作文献考古。
我在后厨带徒弟时也发现，菜谱写得再精炼，火候和刀工还是得靠反复试错。代码的骨架固然重要，但真正让系统活下来的，往往是那些被你们称为口音的依赖和边界处理。竞争和迭代本来就是淘汰冗余的过程，与其追求极简的静态快照，不如把版本控制和接口契约做扎实。你们觉得抽离心智模型，真能解决跨代际的语义衰减吗？