Has Map shorthand syntax in other languages caused you any problems?

Yes, I do :slight_smile: It’s one of very few complaints I have about Elixir as a language :smiley:

1 Like

This seems like an unnecessary feature causing the code to become a little more obscure. Javascripts destructuring is no match for Elixir’s pattern matching and this feels like it is going to confuse a lot more people than help them.

Edit: I saw this before the Proposal thread. I voted in there.

The very question of this topic is a leading question. For completeness I’ll answer it first though. Yes, it has caused me problems. I used to know javascript very well 10 years ago, but these days I spend maybe 10% of my time in it. Coworkers use the shorthand syntax, and it forces me to slow down to understand what’s going on.

The real question to be asking here though is whether this belongs in Elixir, regardless of whether it has or has not caused problems in other languages.

Code is read more often than it is written so we should optimize for reading convenience over writing convenience. I don’t recall any time in my 20+ years as a professional programmer when typing speed was my bottleneck in writing quality code. Even if I concede this is a problem for some of you out there, please set up your editor/IDE to give you a shorthand writing syntax, and leave the core language syntax alone.

TL;DR Look to your editor to micro-optimize your ability to write code quickly


I’ve not really had issues, but then again I’ve used it for a long time.

It would be a nice-to-have in Elixir, but not required, would help reduce those super long controller heads though.

I don’t like those, they should require [] and I try to put [] but the formatter keeps removing it… >.<

Either way, those save 2 characters, unlike map shorthand that saves a LOT more, a whole LOT more.

Easier to do in a typed language, but not in an untyped/dynamically-typed language like Elixir.

Like the amount of C++ I can write by only typing a few things is astounding. I feel hugely more productive in C++ than I do in Elixir, even though it takes more code.

You are misunderstanding a critical part of the @OverminDL1 zen. OvermindDL1 doesn’t experience problems with any lamguage construct. He will immediately write the perfect macro that implements such language feature in the perfect way xD


Coild you expand on this idea? How does rhis work? Lots of editor snippets?

@tmbb mind taking that to another thread?

I’m not using JS anymore and don’t want those problems in Elixir

1 Like

The question was not directed to me, but I am really not a fan of this. Back on my learning ruby days ,which have similar syntax, it was very confusing to me.

1 Like

Lol, I love macro’s (and templates in C++, I’m a bit of a template horror in C++ ^.^;)…

Mostly just tooling. My ‘main’ IDE I use for C++ is KDevelop (occasionally CLion and emacs). Just taking a simple thing as typing a variable name I usually only type a character or two and it infers from the types, context, scope, and other things that only a statically typed language has to know which binding I’m wanting and can autocomplete it out with full namespacing and all. I use editor snippets as well but honestly I don’t do a lot of classes (I prefer functions) and snippets aren’t as useful around there. It’s mostly just the tooling the likes of which a language like Elixir in its current state just is not capable of having as I can literally just hit ‘autocomplete’ without typing anything else in a surprising amount of contexts and it ‘just know what I want it to do’

I’m done, there’s really not much to it, and who knows, this might spur more tooling ideas for someone to make for Elixir. ^.^

I really really wish I could tell the formatter to add lists around keyword argument lists… >.>

I also hate that I can’t do something like [a: 42, blah], you have to instead to [blah, a: 42], which doesn’t always work as the order is different, or do [a: 42 | rest], instead having to do [a: 42] ++ rest, so I end up doing a surprising amount of [a: 42] ++ [blah] and [a: 42] ++ rest… >.>

But still, after sleeping on it I think map shorthand could instead just be ‘struct’ shorthand to start with, as those are atom-only and statically known keys, still unhappy with any string/atom related syntax for normal map shorthand though…