Folders 编程语言：用文件目录结构写代码

编程语言的设计往往围绕语法、类型系统或运行时展开，但出现了一种截然不同的思路——把代码组织方式本身当作语言的核心抽象。这就是 Folders Programming Language（文件夹编程语言）引发讨论的原因。

什么是 Folders 编程语言

Folders 是一个实验性质的编程语言概念，它把文件系统中的「文件夹」（目录）作为程序结构的基本单元。换句话说，程序不再由一堆文本文件里的函数和类构成，而是由嵌套的目录层级来表达逻辑关系：一个文件夹代表一个模块或作用域，子文件夹代表其内部逻辑，层级嵌套对应程序的嵌套结构。

这个项目最初发布在 Hacker News 上，迅速引起了开发者社区的关注。它的新颖之处在于：把大多数人每天都要打交道的文件管理器，变成了一种可执行的编程媒介。

要理解 Folders 的独特之处，可以对比已有的一些非文本编程范式。例如，可视化编程语言（如 Scratch、LabVIEW）用图形节点和连线表达逻辑，电子表格（如 Excel）用单元格和公式表达计算。Folders 与它们的共同点是：把程序结构从纯文本中解放出来，交给一种更直观、更易操作的外部结构来承载。区别在于，Folders 选择的载体是文件系统——一个所有操作系统都原生支持、且用户日常就在使用的层级结构。这意味着 Folders 的「程序」可以直接在文件管理器中打开、浏览、拖拽，而不需要专门的 IDE 或可视化编辑器。这种「零工具依赖」的特性，正是它区别于其他可视化编程方案的关键。

为什么用文件夹来编程

从现有信息来看，Folders 的核心动机是让程序结构「可视化且可导航」。传统编程语言中，代码的结构隐藏在缩进、括号和命名约定里，而文件夹天然具备层级性和可视化的组织能力。

一个直观的理解是：当你打开一个项目目录时，你看到的目录树其实已经很接近程序的调用结构或模块依赖关系。Folders 把这个巧合变成了设计原则——目录树就是程序本身。这让非程序员也能通过熟悉的文件管理操作来理解一个程序的组成。

在传统编程语言中，代码结构通常由抽象语法树（AST）或作用域规则来定义，而文本文件只是这些结构的线性表示。开发者需要在大脑中把缩进、括号和命名约定重新映射回层级关系。Folders 颠倒了这个过程：它让文件系统的物理层级直接成为程序的逻辑层级，消除了文本表示与逻辑结构之间的转换成本。从认知科学的角度看，人类对空间层级（如文件夹嵌套）的记忆和导航能力，往往强于对符号序列（如代码缩进）的解析能力。这或许能解释为什么许多开发者在阅读陌生项目时，第一反应是查看目录树而非源文件内容——Folders 正是把这种本能操作变成了编程本身。

它带来的想象空间

围绕这类设计的讨论通常集中在几个方向：一是可读性，层级化的目录结构比纯文本代码更直观；二是工具生态，操作系统自带的文件管理器、搜索和拖拽操作可以直接用于编程；三是协作，模块边界由文件系统强制划分，减少了命名冲突。

不过，用文件夹表达逻辑也有明显代价。复杂的控制流（循环、条件、异常）很难用纯目录层级优雅表达，类型系统和运算逻辑缺少自然的文本语法载体。这也是为什么这类语言往往停留在概念验证阶段——它更像是对「程序结构可见化」这一命题的探索，而非通用编程的替代品。

这里提到的「控制流难以用目录层级表达」，涉及编程语言理论中的一个基本区分：声明式结构与命令式控制流。目录树天然适合表达声明式的包含关系（模块 A 包含子模块 B），因为层级本身就是一种静态的、无时序的包含结构。但循环、条件分支、异常处理等控制流描述的是执行顺序和运行时状态，它们是动态的、有时序的，与静态的目录层级存在根本性的表达鸿沟。类似的问题也出现在其他非文本编程尝试中，例如用 JSON 或 YAML 描述程序逻辑时，控制流往往需要借助特殊键名或外部解释器来模拟。Folders 如果要走向实用，可能需要引入某种混合机制——比如在文件夹中嵌入小型脚本文件来处理控制流，但这又会削弱其「纯文件夹」的简洁性。

值得关注的设计信号

Folders 之所以能在 Hacker News 上获得讨论，是因为它触及了一个长期被忽视的问题：我们组织代码的方式，是否真的最适合人类理解？主流语言用文本文件加语法糖来解决结构问题，而 Folders 选择用操作系统的原生层级来承担这个职责。

对于关注 AI 编程、低代码和可视化开发的开发者来说，这种思路有参考价值。当 AI 越来越多地参与代码生成时，程序结构的表达方式可能会成为新的接口设计焦点——文件夹作为一种人人熟悉的结构，或许能降低人与 AI 协作时的理解成本。

面向实际使用的几点提醒

需要说明的是，Folders 目前更像是一个概念探索而非成熟工具链。如果你打算尝试类似思路，需要注意：文件系统对文件数量、路径长度和特殊字符有天然限制；版本控制（如 Git）对空目录和重命名的支持并不完美；跨平台的文件名规范差异也会带来兼容问题。这些工程细节往往决定了这类想法的落地边界。

文中提到的版本控制问题值得展开。Git 本质上是为文本文件的内容追踪而设计的，它记录的是文件内容的差异（diff），而不是目录结构本身的语义变化。这就导致两个具体问题：第一，Git 无法跟踪空目录，因为空目录没有文件内容可供提交，而 Folders 中一个空文件夹可能代表一个空模块或占位作用域；第二，当文件夹被重命名或移动时，Git 通常将其视为「删除旧文件 + 添加新文件」，而不是一次结构性的重命名操作，这会丢失历史连续性。对于以目录结构为核心的程序来说，这些限制意味着版本控制需要额外的约定或工具来弥补，例如用占位文件标记空目录，或依赖 git mv 等命令来保持重命名追踪。这些工程细节看似琐碎，却直接影响 Folders 类方案能否融入现有的开发工作流。