当我们反对动态类型时，我们在反对什么？

关于静态类型和动态类型孰优孰劣的争论，几乎和编程本身一样古老。支持静态类型的一方说类型安全、编译期检查、重构可靠。支持动态类型的一方说灵活、生产力高、代码简洁。两边各执一词，谁也说服不了谁。

但我倾向于认为，这场争论的大部分火力打错了靶子。动态类型本身并不是问题——真正的问题是动态类型 + 面向对象。

为了说明这一点，我们来看三个同样是动态类型、但命运截然不同的语言：Python、Elixir和Wolfram Language。

Python：问题不在动态，而在对象 ​

Python毫无疑问是动态类型。你写：

def process(x):
    return x.some_method()

直到运行时才知道x有没有some_method。如果它没有，你将在生产环境收获一个AttributeError。

Python社区对这件事的回应是“鸭子类型”：如果它走起来像鸭子，叫起来像鸭子，那它就是鸭子。这听起来很理想，但现实是——你永远不知道拿到的是不是一只鸭子，只能祈祷写文档的人足够勤快，或者自己把所有可能的类型试一遍。

究其根源，问题并不在于Python是动态类型的，而在于Python是面向对象的：数据是对象，行为是附加在对象上的方法。当调用x.some_method()时，你同时依赖了两样东西：x的类型，以及该类型上存在some_method。这两样东西在Python里都没有编译期保证。

重构一个Python项目时，重命名一个方法有多痛苦？需要全局搜索，靠grep找到所有调用处，然后祈祷没有遗漏。IDE可以帮你，但仅限于它能静态分析的范围。动态特性（猴子补丁、getattr、元类）让任何静态分析工具都只能做到“尽力而为”。

这不是动态类型的错。这是行为附着在数据上这个模型，在缺乏类型约束时的必然结果。

Elixir：动态，但数据与行为分离 ​

Elixir同样是动态类型。你写：

def process(x) do
  do_something(x)
end

同样不知道x的具体类型。但区别在于：do_something是一个独立的函数，不是x身上的方法。如果x不合适，得到的是一个模式匹配错误（FunctionClauseError），并且这个错误发生在函数入口处——你至少知道是哪个函数、什么参数、为什么没匹配上。

更重要的是，Elixir的模式匹配和守卫（guard）提供了接近静态类型的保障。可以在函数头声明你能处理什么：

def process(%{type: :user} = user), do: handle_user(user)
def process(%{type: :admin} = admin), do: handle_admin(admin)

如果传入的数据不符合任何模式，程序会清晰地失败。不会像在Python里那样，在一个if分支里走几十行突然因为.some_method()不存在而崩溃。

Elixir的管道操作符|>进一步强化了这种数据–行为分离：

数据是数据，行为是函数。数据从函数之间流过，而不是函数挂载在数据上。在这种模式下，动态类型几乎没有带来任何问题——不需要IDE补全方法名，因为这个世界上根本没有方法；你需要知道的是一个函数接受什么数据、返回什么数据，而这些可以通过文档、Dialyzer或者简单的模式匹配来理解。

Elixir甚至通过协议（Protocol）提供了一种多态机制，同样独立于数据本身。可以在不修改数据定义的情况下，为不同类型的数据实现相同的行为。

Wolfram Language：动态，且没有“对象”这个概念 ​

Wolfram Language（Mathematica）可能是最极端的例子。它是纯粹基于符号表达式的动态语言。没有类，没有对象，没有方法。只有表达式和对表达式的变换规则。

Person["Alice", 30]

这是一个表达式。它的头（Head）是Person，参数是"Alice"和30。用户通过模式匹配来定义变换规则：

greet[Person[name_, age_]] := "Hello, " <> name <> ", age " <> ToString[age]

尽管在某些其他语言里<>表示“不等于”，但在Wolfram Language里，它表示字符串连接。

当用户写下greet[Person["Alice", 30]]时，Wolfram Language寻找这个叫greet的模式，并看看一个头为Person、包含两个参数的表达式能否匹配该模式。如果匹配，那么模式左边将被替换为右边；如果不匹配，那么用户清楚地知道是哪里不匹配——因为规则是显式的，并且和数据是分离的。

Wolfram Language中最强大的特性之一是，可以用相同的模式匹配系统来操作任意表达式。数字是表达式，列表是表达式，图形是表达式，代码本身也是表达式。一切都统一在符号表达式这个模型下，没有“对象”或“方法”这种额外的概念层级。

在这个语言里，动态类型完全不是问题。用户永远不会收到“对象没有这个方法”的错误，因为从来不会在什么东西上调用方法。你把表达式交给一个模式，模式根据表达式结构来决定替换为什么。仅此而已。

真正的分界线在哪里？ ​

现在我们可以回到最初的问题：当我们反对动态类型时，我们在反对什么？

把三种语言并排放：

这个表格揭示了一个清晰的模式。不是动态类型导致了Python社区熟悉的那些痛苦。是动态类型 + 面向对象——即动态类型与“对象带有方法”这一约定的结合——制造了问题。

原因很根本：

1. 当行为附着在数据上时，你必须知道数据的具体类型才能调用行为。在动态类型下，这种知识只能在运行时获得。这意味着每个.method()调用都是一个潜在的运行时故障点。
2. 当行为与数据分离时，你只需要知道数据长什么样。你不需要关心数据是什么“类型”——你只需要知道它有什么字段、符合什么结构。模式匹配让你可以在函数入口处一次性检查结构，而不是在后续的每个方法调用中提心吊胆。
3. 重构在面向对象 + 动态类型的组合下尤其痛苦。重命名一个方法意味着找到所有调用该方法的代码——这在方法调用散布在代码各个角落的情况下几乎不可能做到完备。而在函数式语言中，一个函数只有一个定义点，调用它的地方可以通过简单的搜索找到。
4. 工具支持在面向对象 + 动态类型下先天受限。IDE无法可靠地告诉你一个变量上有什么方法可用，因为直到运行时你才知道它是什么。而在数据–行为分离的模型中，IDE只需要告诉你一个函数接受什么参数。

结语 ​

所以，当我们反对动态类型时，我们实际上反对的是“在运行时才知道一个对象上有没有某个方法”这件事。这是一种特定的、发生在面向对象语言中的现象。在Python中它无处不在，在Ruby中同样普遍，在JavaScript中稍有不同但仍存在。

但这不是动态类型本身的罪过。Elixir和Wolfram Language证明，动态类型可以是一种愉快、高效且可靠的编程体验——前提是你接受“数据就是数据，行为就是行为”这样的分离。当你把方法从对象身上剥离下来，变成一个独立的、作用于数据的函数时，动态类型的所有“缺点”几乎都消失了。

下次在争论动态类型和静态类型的优劣时，不妨先问一个问题：我们真正想避免的，到底是运行时不知道值的类型，还是运行时不知道一个对象上能调用什么方法？

这两个问题经常被混为一谈，但它们是完全不同的两件事。