Why Erlang tuple module is controversial?

问题:

A similar question was asked Parameterised Modules in Erlang, it is about "what". My question is about "why"?

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 introduces this feature in detail, but I don't see the author's attitude.

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),

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.

回答1:

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:

1. 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.

2. It introduces syntactic complexity and semantic abiguity but grants me no new superpowers.

   • Complexity:

     1. "Is attribute X of Foo equal to 10 or 20 right now?"
     2. "Why do I write dict:is_key(Value, Thingy) here and then Thingy:is_key(Value) over there?
     3. "Do I really want to encounter code like dict:is_key(Key, Foo:get_value(Key2)) all the time?"
     4. 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)...
     5. If I really need this isn't that what the process dictionary was for?

   • Ambiguity:

     1. "Is this a 'thing' I'm calling a method of, or a module function I'm calling?"
     2. "Wait, wasn't this supposed to be functional?"
     3. "Is it OK to put that in a closure and send it off somewhere else? What if 'somewhere else' is another node? Do I have to start caring about that suddenly?"

3. This introduces opaque state (bad) instead of an ADT (good, and something we already have).

4. Nobody uses this, so why waste effort supporting it, especially considering the corner cases it might bring up. That's support overhead and effort I would rather see go into features that we all do use.
5. The "gain" here is only perceived as a benefit to people who can't bear to part with Java-isms. There isn't much difference between Foo:is_key(Key) than dict:is_key(Key, Foo). Other than the fact that I am certain on first reading, even in a complete absence of context, that the data object being operated upon in the second version is definitely a dict.

Erlang's symbol assignment (aka "single assignment") is great, why destroy that?

回答2:

There are other issues as well:

• When I write Foo:bar(42) where Foo maybe either just a module name or maybe a tuple module but I don't see the difference. This means I might be calling either bar/1 or bar/2.

• I can call the same function in different ways.

• It can be difficult to relate errors in functions to the call as the arity is different.

And more. I think it is a shame that we didn't get rid of tuple modules when we got rid of parametrised modules. They were originally just a hacky way of implementing parametrised modules.