This was done previously with the `short_maps` library, which the author—a member of the Elixir core team—eventually retired and archived due to regrets from the undesirable impacts on clarity.
There was also a relatively popular fork shorter_maps [0], mentioned in the blog post above. My motivation for implementing es6_maps instead of using/updating shorter_maps was (I'm copying from my post in the Elixir forums [1]):
1. I do firmly believe this is a good language feature and a very natural extension of map literals syntax;
2. at the same time, being a language feature it should be simple - es6_maps works only with atom keys and has no extra features over the key expansion.
Point 1 is additionally reinforced by how easy it was to introduce to the compiler - I’m injecting just 9 lines of simple code, while parser and lexer already accept short-form maps without modifications.
That's quite surprising to me. As someone who writes a lot of Javascript, I usually find it easiest to read with this syntax than without it, and I generally recommend to my team that they use the shorthand where they can. This is because the meaning is clear and well-known, and being concise (while still being clear) is very valuable.
I wonder what specifically the original author found made it more difficult to read. Was it unfamiliarity? They allude to some confusion between sigils and strings, so I wonder if the issue was partly an Elixir-specific one.
The map '%{username, age, first_name, last_name}' would be 1 character away from the tuple '{username, age, first_name, last_name}'. It is easy to miss the '%' character and you'll waste some time figuring out why your code is throwing match and/or function clause errors at runtime.
Using this logic [username, age first_name, last_name] is only 2 characters away.
This example is easy to catch because tuple and map work completly different-it's not python.
I really don’t understand why some people are so against this as a language feature. I get that the community tries to stay away from “magic” but where is the line between magic and convenient syntactic sugar.
For example keyword lists as the last argument to a function don’t need brackets, and keyword lists are really lists of tuples where the first item is an atom. I feel like those two things are in some ways less obvious and more magical than this map shorthand.
Magic == “I don’t like it, but I want to sound more objective or rational than I really am”.
You’re definitely correct that there’s as good an argument that these implicit features you mention are “too magical” as there is the the “ES6” syntax is too magical.
1. I do firmly believe this is a good language feature and a very natural extension of map literals syntax;
2. at the same time, being a language feature it should be simple - es6_maps works only with atom keys and has no extra features over the key expansion.
Point 1 is additionally reinforced by how easy it was to introduce to the compiler - I’m injecting just 9 lines of simple code, while parser and lexer already accept short-form maps without modifications.
[0] https://github.com/meyercm/shorter_map [1] https://elixirforum.com/t/es6-maps-ecmascript6-style-shortha...