Why Erlang tuple module is controversial?

后端 未结 2 429
别那么骄傲
别那么骄傲 2021-01-12 09:19

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

OTP Technical Board - Decisions affecting R16 conta

2条回答
  •  别那么骄傲
    2021-01-12 10:10

    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?

提交回复
热议问题