4 ms·

I've only recently started to pay attention to Elm after hearing some good things about it so this article was timely for me. I've also dealt repeatedly with th

I've only recently started to pay attention to Elm after hearing some good things about it so this article was timely for me. I've also dealt repeatedly with the example the author uses, a wizard or multistep form, so I was definitely interested to see how it played out. And I was nodding my head in rhythm with the author until he got to the section on lenses. He writes: That’s 14 lines of code to update one single field. Not only is this single example somewhat confusing to follow, you also need to imagine how this update function will look when taking into account the five or so other fields just in the address record! This is — quite frankly — pretty terrible. The trick here is not to stare out of the window and contemplate rewriting everything in ClojureScript. Instead, the thing to do is write a whole bunch of lenses. To my eye, the lenses code he ended up writing didn't look all that much prettier or shorter to me. I guess it's more neatly structured and could even be organized its own file? Is the advantage that you're providing access at each level of the nested record as you code it out? Are there other approaches to this nested field problem?

auslegung 6y ago
I did elm for about a year professionally, and loved it. Reading the discourse thread he links, I''m guessing one of Richard Feldman's recommendations could be to flatten the structure. I'm sure there are times when that's no better than 14 lines to update 1 field, but it should probably be used more than it is. As for why his lenses code can be better than the 14 lines, you're exactly right, it can be extracted into its own file making it an easy-to-use API made of stable code. That lenses code is simple, though unusual at first glance. Once it's an established pattern in your codebase it'll take 5 seconds to grock an entire file of it.
- pyrale 6y ago
  > I'm guessing one of Richard Feldman's recommendations could be to flatten the structure. That's his stance regardless of the situation, and it's a bit annoying if you're legitimately struggling with painful code.
  - rtfeldman 6y ago
    From early in the article: > This [flat Msg design] does work, but at some point it becomes cumbersome to support a large number of constructors. As guessed, I'd personally stick with the simpler flat approach the article acknowledges and then tries to improve on. Nesting that data structure is (according to the article) an ergonomics improvement, but then the rest of the article is about how to solve ergonomics problems caused by the very nesting that was supposed to make things nicer! Given that, surely it's reasonable to raise the question of whether this nesting was actually an improvement after all. My conclusion at the end of the article is that in retrospect nesting did more harm than good, and knowing that, I would have happily left it flat. Incidentally, "leave it flat" is not my stance in all cases. For example, I gave a whole talk that could have been titled "when to nest" - https://youtu.be/DoA4Txr4GUs https://youtu.be/DoA4Txr4GUs - and my most popular Elm project uses nesting in multiple places - https://youtu.be/RN2_NchjrJQ https://youtu.be/RN2_NchjrJQ But indeed, in this case, I'd happily leave Msg flat and not bother with all the lens stuff!
    - xupybd 6y ago
      Given the tone towards your comments in the article, hats off to you for such a civil and constructive response.
yakshaving_jgt 6y ago
> To my eye, the lenses code he ended up writing didn't look all that much prettier or shorter to me. I guess it's more neatly structured and could even be organized its own file? I would typically shuffle all these lenses into their own file, yes. It doesn't look shorter in the small example, but applied to a real-world example — given that lenses compose — the savings quickly begin to add up. The result (at least, in my experience) is that `update` functions are much shorter and easier to follow.
rkangel 6y ago
The lenses code is not much better to access one field, but creating equivalents for other fields then becomes a composition of bits you mostly already have.

auslegung 6y ago

I did elm for about a year professionally, and loved it. Reading the discourse thread he links, I''m guessing one of Richard Feldman's recommendations could be to flatten the structure. I'm sure there are times when that's no better than 14 lines to update 1 field, but it should probably be used more than it is. As for why his lenses code can be better than the 14 lines, you're exactly right, it can be extracted into its own file making it an easy-to-use API made of stable code. That lenses code is simple, though unusual at first glance. Once it's an established pattern in your codebase it'll take 5 seconds to grock an entire file of it.

pyrale 6y ago
> I'm guessing one of Richard Feldman's recommendations could be to flatten the structure. That's his stance regardless of the situation, and it's a bit annoying if you're legitimately struggling with painful code.
- rtfeldman 6y ago
  From early in the article: > This [flat Msg design] does work, but at some point it becomes cumbersome to support a large number of constructors. As guessed, I'd personally stick with the simpler flat approach the article acknowledges and then tries to improve on. Nesting that data structure is (according to the article) an ergonomics improvement, but then the rest of the article is about how to solve ergonomics problems caused by the very nesting that was supposed to make things nicer! Given that, surely it's reasonable to raise the question of whether this nesting was actually an improvement after all. My conclusion at the end of the article is that in retrospect nesting did more harm than good, and knowing that, I would have happily left it flat. Incidentally, "leave it flat" is not my stance in all cases. For example, I gave a whole talk that could have been titled "when to nest" - https://youtu.be/DoA4Txr4GUs https://youtu.be/DoA4Txr4GUs - and my most popular Elm project uses nesting in multiple places - https://youtu.be/RN2_NchjrJQ https://youtu.be/RN2_NchjrJQ But indeed, in this case, I'd happily leave Msg flat and not bother with all the lens stuff!
  - xupybd 6y ago
    Given the tone towards your comments in the article, hats off to you for such a civil and constructive response.

yakshaving_jgt 6y ago

> To my eye, the lenses code he ended up writing didn't look all that much prettier or shorter to me. I guess it's more neatly structured and could even be organized its own file? I would typically shuffle all these lenses into their own file, yes. It doesn't look shorter in the small example, but applied to a real-world example — given that lenses compose — the savings quickly begin to add up. The result (at least, in my experience) is that `update` functions are much shorter and easier to follow.

rkangel 6y ago

The lenses code is not much better to access one field, but creating equivalents for other fields then becomes a composition of bits you mostly already have.