5 ms·

As someone who doesn’t use rails at all, I found this refreshing. In my day to day, I’m exhausted by the endless arguments that arise from using an unopinionate

As someone who doesn’t use rails at all, I found this refreshing. In my day to day, I’m exhausted by the endless arguments that arise from using an unopinionated framework, the likes of fast api or flask. I’m not sure that these argument provide any value to the users we build for. I wish more frameworks would layout their values like this and let the developers who use them stop talking about these “invaluable” points.

philwelch 3y ago
There’s a lot of value in having decisions made for you ahead of time. Nonetheless, decision fatigue is one of the things that annoyed me most about Rails after working in it for the first few years of my career; the flexibility and “expressiveness” of Ruby syntax makes it so writing code is a series of pointless decisions. Do I use parentheses in my function call? Do I use do/end or braces? Array indices or helper methods like .third? I’ve grown to question the value of this sort of thing. Rubyists used to say that various Ruby frameworks were DSL’s (DHH here restrains himself to saying it “looks like” a DSL) but frankly, leaving the parens off of method invocations isn’t a very convincing magic trick once you know how it works, and it’s not worth having to second guess whether to use parens every time you want to call a method.
- LapsangGuzzler 3y ago
  …or you can use a standard formatter like standardrb and end that conversation entirely. You’re right, it’s easy to bikeshed on which syntax constructs are more elegant, but the Ruby ecosystem provides tools to eliminate the need for that conversation.
  - philwelch 3y ago
    > …or you can use a standard formatter like standardrb and end that conversation entirely. This is the solution I've gravitated to in other languages (e.g. Black, gofmt), but that was after my time in the Ruby ecosystem.
- andrewmutz 3y ago
  That's interesting. I've had the opposite reaction to those many little decisions: it doesn't matter. Do whichever you like. All of the options are sufficiently readable.
  - sodapopcan 3y ago
    It matters somewhat. I had a coworker who used to avoid parens any time it was possible which I found incredibly annoying: "foo bar" .split(" ") .map(&:capitalize) .join " " There is really no advantage to not putting parens for the `join` call. Meanwhile, it makes modification a pain as well as makes for some ugly diffs. But as a sibling comment mentioned: just use a linter.
    - weaksauce 3y ago
      the convention that i think most rubyists gravitate toward is to always include parens for method calls when calling something that takes a parameter. omit if there are no parameters.
      - sodapopcan 3y ago
        It is, and it's how I do it when I write Ruby. I was just responding to "it doesn't matter" part of the parent comment. If you decide not to use parens, then you get situations like the one I illustrated where you have to use parens for chaining then you're left with a decision about what to do with the last one.
        andrewmutz 3y ago
        Why are the parens important in this example?
        sodapopcan 3y ago
        You can't chain without parens. # Does not work "foo bar" .split " " .join " " There was a proposal to introduce a "pipe" operator at one point which was shot down [0]. It wasn't actually a pipe operator at all and really just an operator that would have made the previous syntax possible (|>, instead of .) [0] https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d
- hakunin 3y ago
  While those decisions are completely meaningless as far as performance or correctness of your program goes, they do have value for readability. One way to deal with them is of course to install something like standardrb and never think about it. The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.
  - philwelch 3y ago
    > The other way is to read the code you just wrote, and see what reads clearer/better in a specific case. Yes, that's the extra decision step in my main workflow loop that I'd like to cut out whenever possible.
    - hakunin 3y ago
      I think in general it's almost impossible to cut out human consideration and still get auto-clarity. With an auto-formatter you gain a little speed and lose a little readability. I think most people are really arguing about whether this trade off is worth it. Some are arguing that any readability gains are minimal (and debatable), but then it's like arguing that there's no point to being a better writer, and information can just be auto-formatted for human consumption with a set of standard heuristics. I guess we might actually get this world once everything is written by ChatGPT to maximize consistency. But then, how can we both claim to like complete and total mechanical consistency in code, and dislike it in any other form of writing? If code can be written more than one way, shouldn't we optimize it the same way for fellow devs as good writers would for their readers?
      - philwelch 3y ago
        To be blunt with you, I think Rubyists cling to optional parentheses for purely aesthetic reasons; all of the supposed Ruby “DSL’s” that are just method invocations without parentheses would be no less and arguably even more clear and readable with parentheses.
        hakunin 3y ago

philwelch 3y ago

There’s a lot of value in having decisions made for you ahead of time. Nonetheless, decision fatigue is one of the things that annoyed me most about Rails after working in it for the first few years of my career; the flexibility and “expressiveness” of Ruby syntax makes it so writing code is a series of pointless decisions. Do I use parentheses in my function call? Do I use do/end or braces? Array indices or helper methods like .third? I’ve grown to question the value of this sort of thing. Rubyists used to say that various Ruby frameworks were DSL’s (DHH here restrains himself to saying it “looks like” a DSL) but frankly, leaving the parens off of method invocations isn’t a very convincing magic trick once you know how it works, and it’s not worth having to second guess whether to use parens every time you want to call a method.

LapsangGuzzler 3y ago
…or you can use a standard formatter like standardrb and end that conversation entirely. You’re right, it’s easy to bikeshed on which syntax constructs are more elegant, but the Ruby ecosystem provides tools to eliminate the need for that conversation.
- philwelch 3y ago
  > …or you can use a standard formatter like standardrb and end that conversation entirely. This is the solution I've gravitated to in other languages (e.g. Black, gofmt), but that was after my time in the Ruby ecosystem.
andrewmutz 3y ago
That's interesting. I've had the opposite reaction to those many little decisions: it doesn't matter. Do whichever you like. All of the options are sufficiently readable.
- sodapopcan 3y ago
  It matters somewhat. I had a coworker who used to avoid parens any time it was possible which I found incredibly annoying: "foo bar" .split(" ") .map(&:capitalize) .join " " There is really no advantage to not putting parens for the `join` call. Meanwhile, it makes modification a pain as well as makes for some ugly diffs. But as a sibling comment mentioned: just use a linter.
  - weaksauce 3y ago
    the convention that i think most rubyists gravitate toward is to always include parens for method calls when calling something that takes a parameter. omit if there are no parameters.
    - sodapopcan 3y ago
      It is, and it's how I do it when I write Ruby. I was just responding to "it doesn't matter" part of the parent comment. If you decide not to use parens, then you get situations like the one I illustrated where you have to use parens for chaining then you're left with a decision about what to do with the last one.
      - andrewmutz 3y ago
        Why are the parens important in this example?
        sodapopcan 3y ago
        You can't chain without parens. # Does not work "foo bar" .split " " .join " " There was a proposal to introduce a "pipe" operator at one point which was shot down [0]. It wasn't actually a pipe operator at all and really just an operator that would have made the previous syntax possible (|>, instead of .) [0] https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d
hakunin 3y ago
While those decisions are completely meaningless as far as performance or correctness of your program goes, they do have value for readability. One way to deal with them is of course to install something like standardrb and never think about it. The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.
- philwelch 3y ago
  > The other way is to read the code you just wrote, and see what reads clearer/better in a specific case. Yes, that's the extra decision step in my main workflow loop that I'd like to cut out whenever possible.
  - hakunin 3y ago
    I think in general it's almost impossible to cut out human consideration and still get auto-clarity. With an auto-formatter you gain a little speed and lose a little readability. I think most people are really arguing about whether this trade off is worth it. Some are arguing that any readability gains are minimal (and debatable), but then it's like arguing that there's no point to being a better writer, and information can just be auto-formatted for human consumption with a set of standard heuristics. I guess we might actually get this world once everything is written by ChatGPT to maximize consistency. But then, how can we both claim to like complete and total mechanical consistency in code, and dislike it in any other form of writing? If code can be written more than one way, shouldn't we optimize it the same way for fellow devs as good writers would for their readers?
    - philwelch 3y ago
      To be blunt with you, I think Rubyists cling to optional parentheses for purely aesthetic reasons; all of the supposed Ruby “DSL’s” that are just method invocations without parentheses would be no less and arguably even more clear and readable with parentheses.
      - hakunin 3y ago