4 ms·

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'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.

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.