3 ms·

I think that the things that Ruby optimises for - mainly that code should be beautiful english prose - just aren't things that developers widely ended valuing.

I think that the things that Ruby optimises for - mainly that code should be beautiful english prose - just aren't things that developers widely ended valuing. I think that it's syntax, or what "beautiful ruby code" looks like, is significantly different from most other languages, making it more off putting to pick up or switch between.

nullstyle 3y ago
You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby." More here: https://www.artima.com/articles/the-philosophy-of-ruby https://www.artima.com/articles/the-philosophy-of-ruby
- berkes 3y ago
  You are right about Ruby. But what DHH does/did with it for Rails is of a different order. There, often, "beauty" is in the way. Hundreds (or thousands) of methods magically appearing from nowhere on a Record, by inflecting a database scheme runtime. Thats neat and all, but I'd very much rather just explicitly write getters and setters. It's not as if (with autocomplete) such things are a time sink.
  - nullstyle 3y ago
    Yes, RoR is a different and larger beast than Ruby. It also does not optimize "mainly that code should be beautiful English prose." You can import the joyful drive of Ruby into your RoR codebases. I've worked on plenty of rails codebases that were a pleasure to work in. Far more than any other web framework I've worked with.
    - berkes 3y ago
      I consider e.g. 'scope' to just be (slightly harder to test and follow) over a class method. I consider a concerns to be more complex and unexpected versions of a Module. I consider "render @foo" to be just an incomprehensible version of the explicit "render_partial("the_name", ...)" And so on. All of these have bitten me many times, oft in production even. Many of these caused me and my step debugger hours of wading though deep stacks of method-missing or runtime code definitions.
- madeofpalk 3y ago
  > Sometimes people jot down pseudo-code on paper. If that pseudo-code runs directly on their computers, it's best, isn't it? I think this turns people away from Ruby (and is what Ruby people love about Ruby). I'm not a fan of Go, but people say they enjoy writing Go, which looks very different from Ruby.

nullstyle 3y ago

You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby." More here: https://www.artima.com/articles/the-philosophy-of-ruby https://www.artima.com/articles/the-philosophy-of-ruby

berkes 3y ago
You are right about Ruby. But what DHH does/did with it for Rails is of a different order. There, often, "beauty" is in the way. Hundreds (or thousands) of methods magically appearing from nowhere on a Record, by inflecting a database scheme runtime. Thats neat and all, but I'd very much rather just explicitly write getters and setters. It's not as if (with autocomplete) such things are a time sink.
- nullstyle 3y ago
  Yes, RoR is a different and larger beast than Ruby. It also does not optimize "mainly that code should be beautiful English prose." You can import the joyful drive of Ruby into your RoR codebases. I've worked on plenty of rails codebases that were a pleasure to work in. Far more than any other web framework I've worked with.
  - berkes 3y ago
    I consider e.g. 'scope' to just be (slightly harder to test and follow) over a class method. I consider a concerns to be more complex and unexpected versions of a Module. I consider "render @foo" to be just an incomprehensible version of the explicit "render_partial("the_name", ...)" And so on. All of these have bitten me many times, oft in production even. Many of these caused me and my step debugger hours of wading though deep stacks of method-missing or runtime code definitions.
madeofpalk 3y ago
> Sometimes people jot down pseudo-code on paper. If that pseudo-code runs directly on their computers, it's best, isn't it? I think this turns people away from Ruby (and is what Ruby people love about Ruby). I'm not a fan of Go, but people say they enjoy writing Go, which looks very different from Ruby.