3 ms·

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

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.

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.