Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

github.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#21

Post by kzemek »

rubyn00bie wrote: post #10

I personally don’t think this is a good idea, and I think the formatter plugin is going to give someone insane amounts of regret one day. It’s neat as “look what I did” but Elixir is all about removing magic. It (lack of magic) is one of the things I appreciated most, having originally come from Ruby and Rails. I’ve been using it professionally for nearly ten years, and I can say this isn’t a feature I’ve ever really…

> I think the formatter plugin is going to give someone insane amounts of regret one day

The formatter plugin features a "reverse" flag exactly to prevent any kind of regret like that. You can reformat your code automatically to remove all shorthand maps and remove the dependency in a couple simple steps.

> I’d really encourage you to put a note at the top of the readme that this shouldn’t be used in production code.

Noted, although I do think it's production ready. I'm going to keep updating the library if or when a new version of the Elixir compiler breaks it, and it does feature an easy way out in case I disappear.

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#22

Post by kzemek »

jzimbel wrote: post #8

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. https://github.com/whatyouhide/short_maps https://andrealeopardi.com/posts/a-story-of-regret-and-retir...

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.

[0] https://github.com/meyercm/shorter_map [1] https://elixirforum.com/t/es6-maps-ecmascript6-style-shortha...

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#23

Post by sb8244 »

rubyn00bie wrote: post #10

I personally don’t think this is a good idea, and I think the formatter plugin is going to give someone insane amounts of regret one day. It’s neat as “look what I did” but Elixir is all about removing magic. It (lack of magic) is one of the things I appreciated most, having originally come from Ruby and Rails. I’ve been using it professionally for nearly ten years, and I can say this isn’t a feature I’ve ever really…

I don't agree that this is magic. It's only "magic" because the language doesn't do it today (thus requiring the compiler extension.) If this were in the language itself, it would probably be pretty popular.

The argument against it feels like "because we've always done it this way."

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#24

Post by oxidant »

sb8244 wrote: post #23
rubyn00bie wrote: post #10

I personally don’t think this is a good idea, and I think the formatter plugin is going to give someone insane amounts of regret one day. It’s neat as “look what I did” but Elixir is all about removing magic. It (lack of magic) is one of the things I appreciated most, having originally come from Ruby and Rails. I’ve been using it professionally for nearly ten years, and I can say this isn’t a feature I’ve ever really…

I don't agree that this is magic. It's only "magic" because the language doesn't do it today (thus requiring the compiler extension.) If this were in the language itself, it would probably be pretty popular. The argument against it feels like "because we've always done it this way."

Agreed. It's just syntax, similar to implicit keywords (mentioned already) and & anonymous functions[0].

Pattern matching a large number of items off a map is verbose. Putting many new keys in a map can be verbose if they're existing variables.

I'd rather have shorter code that was just as readable than many lines that add to cruft.

[0] Reading `&%{foo: &1.bar}` as a new Elixir dev looks like character soup and is arguably more magical.

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#25

Post by bryantwolf »

I've been using Destucture [1] for a few years. It's an interesting compromise that works for atom and string keys because it's explicit, kind of like the sigil approach. Though this seems way more streamlined, especially as someone who uses JS for front-end apps.

[1]https://github.com/danielberkompas/destructure/

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#26

Post by kzemek »

bryantwolf wrote: post #25

I've been using Destucture [1] for a few years. It's an interesting compromise that works for atom and string keys because it's explicit, kind of like the sigil approach. Though this seems way more streamlined, especially as someone who uses JS for front-end apps. [1] https://github.com/danielberkompas/destructure/

Oh nice, I didn't know about that one! It's interesting how many solutions are in this space; aside from Destructure[0] and shorter_maps[1] I also know about shorthand[2] and synex[3].

[0] https://github.com/danielberkompas/destructure [1] https://github.com/meyercm/shorter_maps [2] https://hex.pm/packages/shorthand [3] https://hex.pm/packages/synex

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#27

Post by igsomething »

MrJohz wrote: post #13
jzimbel wrote: post #8

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. https://github.com/whatyouhide/short_maps https://andrealeopardi.com/posts/a-story-of-regret-and-retir...

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 rea…

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.

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#28

Post by leononame »

boxed wrote: post #12
leononame wrote: post #11

Earlier quoted context omitted.

JS and python are just about all programming languages? I'm not trying to be snarky, but e.g. I haven't seen it in Go, F# and Rust, some languages where I have at least seen _some_ code. I also don't remember a similar pattern in Java, C# and C nor PHP or Dart, but I will readily admit that it's I haven't coded in any of these in the last two years, so I might be a bit out of touch and I'm not super proficient in all…

Go, and F# do almost all positional arguments. I think Rust too. Java, C#, C, PHP are also positional only or 99% of the time. I assume Dart too. We are talking named/keyword/etc. Personally I find positional arguments to be an anti-pattern in all but a very specific set of circumstances.

If I understand correctly, we aren't talking about named/keyword arguments. This is about a shorthand syntax in ES6 objects, nothing to do with function arguments.

In JS, when creating an object, instead of writing {name: name}, where "name" is both the key in the map as well as the variable you want it to assign to, you can do {name}, whereas e.g. in Go you would do map[string]any{"name": name}.

Edit: Or, for completeness' sake, it's the same with structs in Go, where you would instantiate a struct like this: Person{name: name}.

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#29

Post by leononame »

pflanze wrote: post #17
leononame wrote: post #11

Earlier quoted context omitted.

JS and python are just about all programming languages? I'm not trying to be snarky, but e.g. I haven't seen it in Go, F# and Rust, some languages where I have at least seen _some_ code. I also don't remember a similar pattern in Java, C# and C nor PHP or Dart, but I will readily admit that it's I haven't coded in any of these in the last two years, so I might be a bit out of touch and I'm not super proficient in all…

If we're talking about constructing structs, like in `Foo { bar, baz: 123 }` (with the `bar` style shortcut in it), I have used that kind of syntax 10 times in 16 KLOC of Rust. Not a lot, but it does happen, and I found it kinda neat when LSP integration suggested its use. I've probably used it more for pattern matching (`let Foo { bar, baz } = ...`), but haven't measured the number of instances of that idiom.

You're right constructing struts in Rust works with that pattern, so I'll take the Rust bit back.

Re: Show HN: es6_maps, new Elixir syntax feature via runtime compiler hacking

#30

Post by h0l0cube »

bryantwolf wrote: post #25

I've been using Destucture [1] for a few years. It's an interesting compromise that works for atom and string keys because it's explicit, kind of like the sigil approach. Though this seems way more streamlined, especially as someone who uses JS for front-end apps. [1] https://github.com/danielberkompas/destructure/

I like this because it makes the sugaring distinct. Anyone unfamiliar with the sugar will know there's something different going on, while not really adding much noise.
Post reply on HN