为什么 Erlang 元组模块有争议?
问题说明
Erlang 中的参数化模块问了一个类似的问题，它是关于什么".我的问题是关于为什么"?
A similar question was asked Parameterised Modules in Erlang, it is about "what". My question is about "why"?
OTP 技术委员会 - 影响 R16 的决定 包含有关此问题的董事会决定，但我不知道这个决定背后的原因.
OTP Technical Board - Decisions affecting R16 contains the board decision about this issue, but I don't know the reason behind the decision.
Stateful Module in Programming Erlang 2ndEdition by Joe Armstrong 详细介绍了这个特性，但是我看不到作者的态度.
Stateful Module in Programming Erlang 2ndEdition by Joe Armstrong introduces this feature in detail, but I don't see the author's attitude.
如果我们阅读官方文档 Function Calls，我们会看到此功能是故意略读的.其实官方文档强烈反对使用这个功能，参考效率函数调用.如果是这样，为什么 Joe Armstrong 在他的书中提到了这样的功能?
If we read the official document Function Calls, we see this feature is deliberately skimmed. In fact, the official document strongly discourages using this feature, refer to efficiency function calls. If so, why Joe Armstrong mentions such feature in his book?
我认为这个功能很棒.正如上面提到的那样，我的客户端代码可能如下所示
I think this feature is awesome. As the above book mentioned, my client code could be like below
Obj:find(Key),
Obj:is_key(Key),
那么，不幸的是，我们不关心 Obj 是由 dict:new() 还是 gb_tree:new() 创建的, dict 和 gb_tree 不共享一致的接口，例如我们有 gb_tree:lookup 而不是 gb_tree:find.
Then, we don't care whether Obj is created by dict:new(), or gb_tree:new(), unfortunately, dict and gb_tree do not share a consistent interface, e.g. we have gb_tree:lookup instead of gb_tree:find.
正确答案
我不能告诉你控制一切的大阴谋集团内部的讨论是什么，但我可以告诉你一些我从未考虑过使用它的原因特点:
I can't tell you what the discussion was within the Great Cabal That Controls Everything, but I can tell you a few reasons why I never have considered using this feature:
- 不合适.Erlang 是功能性的，这是对 OOP 风格的结构体的奇怪介绍，这种结构体具有手臂和腿之类的东西.我不喜欢我的代码与自身发生冲突.
-
它引入了句法复杂性和语义模糊性，但没有赋予我新的超能力.
- It doesn't fit. Erlang is functional and this is a weird introduction of OOP-style structs-that-have-arms-and-legs sort of thing. I don't like my code to clash with itself.
-
It introduces syntactic complexity and semantic abiguity but grants me no new superpowers.
-
复杂性:
-
Complexity:
Foo的属性X现在等于10还是20?"- 为什么我在这里写
dict:is_key(Value, Thingy)，然后在那边写Thingy:is_key(Value)? - 我真的想一直遇到
dict:is_key(Key, Foo:get_value(Key2))这样的代码吗?" - 我已经有一大群流程专门用来做这件事，并将状态的复杂性从流程代码中转移到异步消息的世界中(在代码中，我可以在一次调用一个函数)...
- 如果我真的需要这不是流程字典的用途吗?
- "Is attribute
XofFooequal to 10 or 20 right now?" - "Why do I write
dict:is_key(Value, Thingy)here and thenThingy:is_key(Value)over there? - "Do I really want to encounter code like
dict:is_key(Key, Foo:get_value(Key2))all the time?" - I already have an army of processes designed to do just this and move the complexity of state out of the process code and into the world of asyncronous messages (in code I can deal with an isolated snapshot of time within a single call of a function)...
- If I really need this isn't that what the process dictionary was for?
-
歧义:
-
Ambiguity:
- 这是我正在调用的方法或模块函数的‘事物’吗?"
- 等等，这不应该是功能性的吗?"
- 是否可以将其放入闭包并将其发送到其他地方?如果 '其他地方' 是另一个节点怎么办?我是否必须突然开始关心它?"
这引入了不透明状态(坏)而不是 ADT(好，我们已经拥有).
This introduces opaque state (bad) instead of an ADT (good, and something we already have).
Erlang 的符号赋值(又名单一赋值")很棒，为什么要破坏它?
Erlang's symbol assignment (aka "single assignment") is great, why destroy that?
这篇好文章是转载于：学新通技术网
