[erlang-questions] A modest proposal to eliminate tuples

[Chris Pacejo]

Even given my admittedly poor job trying to channel Swift I figured at
least someone would get the reference :/
(http://en.wikipedia.org/wiki/A_Modest_Proposal for those still in the
dark.)

No, I'm not actually calling for tuples to be removed from Erlang.
That would be absurd; Dmitry K pointed out at least one good reason
why.

But now that maps have been officially introduced, popular opinion
seems to overwhelmingly be leaning in the direction of utilizing maps
for both values with a static (keys known at compile time)
heterogeneous (differing types of values) structure, and values with a
dynamic (keys determined at runtime) homogeneous (single type of
values) structure.  For the same reasons that tuples and lists are
(rightly) kept separate (namely declaration of intent, ability to
typecheck, and efficiency of implementation), I strongly believe that
these two use cases of "map-like-things" should be kept separate.

My stance is certainly not without precedent -- older languages such
as OCaml and SQL get the distinction right.  (In OCaml, it's the
difference between an anonymous object and a Map.  In SQL, it's the
difference between a row and a relation.)  But certain modern
dynamically typed interpreted languages -- Python, Ruby, JavaScript,
to name a few -- lose this important distinction, and conflate all
"things that have keys and values" as a single type, whose
inefficiencies are masked only by those languages' lack of type
discipline and poor implementation performance.  (Though JavaScript
nominally distinguishes between the two forms -- objects can have only
string keys, and there is a Map class -- in practice programmers often
don't.  See the concurrent JSON thread.)

I apologize for the troll, but my past direct attempts to bring this
issue to the list's attention have been lost in long threads with
little to no discussion.  I just fear an Erlang ecosystem in which,
five years hence, this singular "map" structure is used for such
wildly distinct purposes that we are forced to accept that they are
opaque, unanalyzable, and slow, and nothing can be done about it.