6 ms·

I’ve found the Ruby community really cares about DUX. Not sure why it’s not in other language communities

choxi 2y ago
Matz said he designed Ruby to optimize for developer happiness, it’s just a core principle of the language since it was created
- kuboble 2y ago
  Happiness of a developer writing code can be a misery of a one having to read / debug it. I worked in ruby for a couple years around 2009 and having to deal with a code that implemented most of its logic via method missing is still one of the strongest negative memories I have about coding.
  - viraptor 2y ago
    Another annoying one from that category is Ruby's forwarded methods. Since they're created via generated, injected code, you can't query which method it forwards to at runtime. Or not easily anyway.
  - MatthiasPortzel 2y ago
    `binding.irb` and `show_source` have been magical in my Ruby debugging experience. `binding.irb` to trigger a breakpoint, and `show_source` will find the source code for a method name, even in generated code somehow.
    - richjdsmith 2y ago
      … I’ve been using Ruby for years and never thought to use show_source like this in a debugger. Thanks kind stranger, you just made my day!
  - RangerScience 2y ago
    Yep yep, that's the whole "sharp knives" thing. What I advise (and aim for) is only pulling out the sharp knives for "library" code, but application code should stay "simple" (and this much more easily navigable). Otherwise you can absolutely make a bloody mess!
toasterlovin 2y ago
I don’t really mean this to be derogatory toward people who enjoy other things, but Ruby is a language and ecosystem by and for people who have taste.
- continuational 2y ago
  Certainly a taste for global state, it seems.
  - atemerev 2y ago
    Dogmatically rejecting global state even if it simplifies things in some particular case _is_ poor taste. Even a goto can be elegant sometimes.
    - zelphirkalt 2y ago
      Usually though it just creates long term issues, putting off important work to later.
      - bmacho 2y ago
        Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.
        lolinder 2y ago
        But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not. If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off removing global state for later. You will regret it eventually, and it doesn't cost much to do it right the first time. (Also, no mainstream language I'm aware of forces you to not use global state. Even Java, famed for its rigidity, has global state readily available if you really do need it.)
rochak 2y ago
Umm, doesn’t Go do so as well? Personally, I’ve had a better experience working with Go tooling.
- jatins 2y ago
  Go ecosystem is generally good. However, given that Go as a language doesn't have any "fancy" (for the lack of a better word) syntactical features you can't create DSL's like this though Ruby's expressiveness comes at a cost and I'd personally stick with Go in a team but use something like RubyLLM for personal projects
  - lolinder 2y ago
    I'm wary of equating "ability to create dsls like this" with "prioritizing developer experience". Ruby and go each prioritize different parts of the developer experience. Ruby prioritizes the experience of the author of the initial code at the expense of the experience of the maintainer who comes later. Go prioritizes the experience of a maintainer over the experience of the initial author. Both prioritize a developer, both de-prioritize a different developer, and which one makes more sense really depends on the ratio of time spent on writing greenfield code versus maintaining something another human wrote years ago who's long gone.
    - smw 2y ago
      I disagree with the idea that Go prioritizes the maintainer. More lines of code typically makes maintenance more difficult. Go is easy to read line by line, but the verbosity makes it more challenging to understand the bigger picture. I find changes in existing Go software often end up spreading far deeper into the app than you'd expect. The runtime is fantastic, though, so I don't see it losing it's popularity anytime soon.
      - danenania 2y ago
        > More lines of code typically makes maintenance more difficult. That’s kind of just the surface level of maintenance though. Go is not so much focused on making it easy to read a single file, but on minimizing the chains of abstraction and indirection you need to follow to understand exactly how things work. It’s much more likely that all the logic and config to do something is right there in that file, or else just one or two “Go to definition” clicks away. You end up with way more boilerplate and repetition, but also looser coupling between files, functions, and components. Contrast that to a beautiful DSL in Ruby. It’s lovely until it breaks or you need to extend it, and you realize that a small change will require refactoring call sites across a dozen different files. Oh and now this other thing that reused that logic is broken, and we’ve got to update most of the test suite, and so on.
RangerScience 2y ago
Every language prioritizes something (or somethings) because every language was made by a person (or people) with a reason; python and correctness; Java and splitting up work; Go and something like "simplicity" (not that these are the only priorities for each language). As another comment points out, Matz prioritized developer happiness. My favorite example of this is the amazing useful and amazing whack Ruby array arithmetic; subtraction (`arr1 - arr2`) is element-wise removal, but addition (`arr1 + arr2`) is a simple append. These are almost always exactly what you want to do when you reach for them, but they're completely "incorrect" mathematically.
- okeuro49 2y ago
  > python and correctness I thought it was Python and readability and "one way of doing things".

Matz said he designed Ruby to optimize for developer happiness, it’s just a core principle of the language since it was created

kuboble 2y ago
Happiness of a developer writing code can be a misery of a one having to read / debug it. I worked in ruby for a couple years around 2009 and having to deal with a code that implemented most of its logic via method missing is still one of the strongest negative memories I have about coding.
- viraptor 2y ago
  Another annoying one from that category is Ruby's forwarded methods. Since they're created via generated, injected code, you can't query which method it forwards to at runtime. Or not easily anyway.
- MatthiasPortzel 2y ago
  `binding.irb` and `show_source` have been magical in my Ruby debugging experience. `binding.irb` to trigger a breakpoint, and `show_source` will find the source code for a method name, even in generated code somehow.
  - richjdsmith 2y ago
    … I’ve been using Ruby for years and never thought to use show_source like this in a debugger. Thanks kind stranger, you just made my day!
- RangerScience 2y ago
  Yep yep, that's the whole "sharp knives" thing. What I advise (and aim for) is only pulling out the sharp knives for "library" code, but application code should stay "simple" (and this much more easily navigable). Otherwise you can absolutely make a bloody mess!

toasterlovin 2y ago

I don’t really mean this to be derogatory toward people who enjoy other things, but Ruby is a language and ecosystem by and for people who have taste.

continuational 2y ago
Certainly a taste for global state, it seems.
- atemerev 2y ago
  Dogmatically rejecting global state even if it simplifies things in some particular case _is_ poor taste. Even a goto can be elegant sometimes.
  - zelphirkalt 2y ago
    Usually though it just creates long term issues, putting off important work to later.
    - bmacho 2y ago
      Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.
      - lolinder 2y ago
        But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not. If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off removing global state for later. You will regret it eventually, and it doesn't cost much to do it right the first time. (Also, no mainstream language I'm aware of forces you to not use global state. Even Java, famed for its rigidity, has global state readily available if you really do need it.)

rochak 2y ago

Umm, doesn’t Go do so as well? Personally, I’ve had a better experience working with Go tooling.

jatins 2y ago
Go ecosystem is generally good. However, given that Go as a language doesn't have any "fancy" (for the lack of a better word) syntactical features you can't create DSL's like this though Ruby's expressiveness comes at a cost and I'd personally stick with Go in a team but use something like RubyLLM for personal projects
- lolinder 2y ago
  I'm wary of equating "ability to create dsls like this" with "prioritizing developer experience". Ruby and go each prioritize different parts of the developer experience. Ruby prioritizes the experience of the author of the initial code at the expense of the experience of the maintainer who comes later. Go prioritizes the experience of a maintainer over the experience of the initial author. Both prioritize a developer, both de-prioritize a different developer, and which one makes more sense really depends on the ratio of time spent on writing greenfield code versus maintaining something another human wrote years ago who's long gone.
  - smw 2y ago
    I disagree with the idea that Go prioritizes the maintainer. More lines of code typically makes maintenance more difficult. Go is easy to read line by line, but the verbosity makes it more challenging to understand the bigger picture. I find changes in existing Go software often end up spreading far deeper into the app than you'd expect. The runtime is fantastic, though, so I don't see it losing it's popularity anytime soon.
    - danenania 2y ago
      > More lines of code typically makes maintenance more difficult. That’s kind of just the surface level of maintenance though. Go is not so much focused on making it easy to read a single file, but on minimizing the chains of abstraction and indirection you need to follow to understand exactly how things work. It’s much more likely that all the logic and config to do something is right there in that file, or else just one or two “Go to definition” clicks away. You end up with way more boilerplate and repetition, but also looser coupling between files, functions, and components. Contrast that to a beautiful DSL in Ruby. It’s lovely until it breaks or you need to extend it, and you realize that a small change will require refactoring call sites across a dozen different files. Oh and now this other thing that reused that logic is broken, and we’ve got to update most of the test suite, and so on.

RangerScience 2y ago

Every language prioritizes something (or somethings) because every language was made by a person (or people) with a reason; python and correctness; Java and splitting up work; Go and something like "simplicity" (not that these are the only priorities for each language). As another comment points out, Matz prioritized developer happiness. My favorite example of this is the amazing useful and amazing whack Ruby array arithmetic; subtraction (`arr1 - arr2`) is element-wise removal, but addition (`arr1 + arr2`) is a simple append. These are almost always exactly what you want to do when you reach for them, but they're completely "incorrect" mathematically.

okeuro49 2y ago
> python and correctness I thought it was Python and readability and "one way of doing things".