4 ms·

I take issue with several of these. "Idiomatic Ruby" shoehorn's dogma into the least dogmatic language. Elsif? How about a case statement? A lot of the idiom

by ericb 2y ago

I take issue with several of these. "Idiomatic Ruby" shoehorn's dogma into the least dogmatic language. Elsif? How about a case statement? A lot of the idioms are great until you need to debug them. At that point you have to replace them with non-idioms because you can't even debug the code you wrote without changing it. Why give someone grief for starting with something debuggable? I dislike the social pressure and "Rubocop's Karen-ing" used to inflict these idioms when they are a mixed bag, at best, and demonstrably worse in cases.

jacknews 2y ago
The & thing can be handy, used sparingly, and the Rails issue of pulling results into memory to process them, rather than using 'pluck' etc is a real thing, but I agree the other suggestions are garbage. I think this blog is called 'Ruby Magic', and Rails especially has that reputation of being inscrutable magic; these suggestions just make it worse. Forget idioms and using obscure features of the language or framework - just write simple clear code.
- dieselgate 2y ago
  I’ve written a lot of ruby code but am not super advanced. Can you elaborate on what you mean about “pluck” and memory? Came across it in rails docs yesterday but haven’t seen it used in a codebase before
  - durkie 2y ago
    My guess is that they're referring to how Rails will instantiate full objects for ActiveRecord database requests and this is often not what you want, because we often just want a single or a few attributes from the model. So if you had a model Activity, and you wanted to get the names of some of them, the slower/higher memory approach would be something like: Activity.where("id < 100").map(&:name) This pulls results from the database, instantiates each as Activity objects, then iterates through each to get its name. You can see in the logs that it grabs the entire object: Activity Load (133.7ms) SELECT "activities".* FROM "activities" WHERE (id < 100) .pluck instead grabs just the field you're looking for without instantiating the entire object. So the better way to grab the list of activity names would be like: Activity.where("id < 100").pluck(:name) And you can see from the logs that it makes a more narrow query: (3.8ms) SELECT "activities"."name" FROM "activities" WHERE (id < 100)
    - dieselgate 2y ago
      Awesome thanks for the reply, am making an effort to learn more activerecord and didn’t know pluck would function like this. Was playing around with it last night on a ruby hash and missed the memory advantages
    - jacknews 2y ago
      yes, this exactly, thanks.
qudat 2y ago
I’m in a codebase now that dynamically generates functions, as if ruby/rails wasn’t hard enough to debug with its insistence on autoloading. The whole stack is a dumpster fire filled with footguns. Where “show me where this function is defined” turns into an impossible task.
- irjustin 2y ago
  mmmm this is a problem of the engineers not the language though =\ Overuse of dynamically generated functions is possible in any high level language. The worst offender that I had seen was a PHP wordpress plugin that stored a custom function per row in the DB brought to life via `eval`. Those were the days.
  - chowells 2y ago
    > Overuse of dynamically generated functions is possible in any high level language. A large number of high-level languages resolve functions at compile time, rejecting programs containing references to functions that don't exist.
    - dragonwriter 2y ago
      No language in which dynamically generated functions exist does so, because if it did it would be impossible to use them. I will agree that dynamically generated functions are not overused in languages in which they cannot be expressed at all, but...
- zdragnar 2y ago
  After years of programming against REST(ish) APIs backed by statically typed languages, I'm now fighting one built by a team that loves ruby/rails. It's a terrible experience. No auto-generated specs. Can't even look at the code to know what some request parameters are supposed to be (had to go digging through pagy docs for that one). One day, a value in a response that is normally a string was suddenly an array on certain queries. The whole approach is so haphazard move-fast-nobody-cares that it grinds my gears and I'm not even contributing to their code, just consuming it. My kingdom for a better experience.
LandR 2y ago
I've been in a situation at a job where we were trying to debug some code, not ruby, but still written very concisely and clever. To even have a chance of debugging it we had to pull out more variables etc so we could breakpoint each part rather than it being this complicated one liner. After they debugged it, and fixed it, I watched them rewrite it back into the complicated one liner because it looks nicer... I just don't get it. It's like they just didn't see the pain they went through. We built our own hells.
- rezonant 2y ago
  Was there some kind of side effect that prevented you from simply using the debugger to evaluate parts of the statement to interrogate the results?

by ericb 2y ago

jacknews 2y ago

The & thing can be handy, used sparingly, and the Rails issue of pulling results into memory to process them, rather than using 'pluck' etc is a real thing, but I agree the other suggestions are garbage. I think this blog is called 'Ruby Magic', and Rails especially has that reputation of being inscrutable magic; these suggestions just make it worse. Forget idioms and using obscure features of the language or framework - just write simple clear code.

dieselgate 2y ago
I’ve written a lot of ruby code but am not super advanced. Can you elaborate on what you mean about “pluck” and memory? Came across it in rails docs yesterday but haven’t seen it used in a codebase before
- durkie 2y ago
  My guess is that they're referring to how Rails will instantiate full objects for ActiveRecord database requests and this is often not what you want, because we often just want a single or a few attributes from the model. So if you had a model Activity, and you wanted to get the names of some of them, the slower/higher memory approach would be something like: Activity.where("id < 100").map(&:name) This pulls results from the database, instantiates each as Activity objects, then iterates through each to get its name. You can see in the logs that it grabs the entire object: Activity Load (133.7ms) SELECT "activities".* FROM "activities" WHERE (id < 100) .pluck instead grabs just the field you're looking for without instantiating the entire object. So the better way to grab the list of activity names would be like: Activity.where("id < 100").pluck(:name) And you can see from the logs that it makes a more narrow query: (3.8ms) SELECT "activities"."name" FROM "activities" WHERE (id < 100)
  - dieselgate 2y ago
    Awesome thanks for the reply, am making an effort to learn more activerecord and didn’t know pluck would function like this. Was playing around with it last night on a ruby hash and missed the memory advantages
  - jacknews 2y ago
    yes, this exactly, thanks.

qudat 2y ago

I’m in a codebase now that dynamically generates functions, as if ruby/rails wasn’t hard enough to debug with its insistence on autoloading. The whole stack is a dumpster fire filled with footguns. Where “show me where this function is defined” turns into an impossible task.

irjustin 2y ago
mmmm this is a problem of the engineers not the language though =\ Overuse of dynamically generated functions is possible in any high level language. The worst offender that I had seen was a PHP wordpress plugin that stored a custom function per row in the DB brought to life via `eval`. Those were the days.
- chowells 2y ago
  > Overuse of dynamically generated functions is possible in any high level language. A large number of high-level languages resolve functions at compile time, rejecting programs containing references to functions that don't exist.
  - dragonwriter 2y ago
    No language in which dynamically generated functions exist does so, because if it did it would be impossible to use them. I will agree that dynamically generated functions are not overused in languages in which they cannot be expressed at all, but...
zdragnar 2y ago
After years of programming against REST(ish) APIs backed by statically typed languages, I'm now fighting one built by a team that loves ruby/rails. It's a terrible experience. No auto-generated specs. Can't even look at the code to know what some request parameters are supposed to be (had to go digging through pagy docs for that one). One day, a value in a response that is normally a string was suddenly an array on certain queries. The whole approach is so haphazard move-fast-nobody-cares that it grinds my gears and I'm not even contributing to their code, just consuming it. My kingdom for a better experience.

LandR 2y ago

I've been in a situation at a job where we were trying to debug some code, not ruby, but still written very concisely and clever. To even have a chance of debugging it we had to pull out more variables etc so we could breakpoint each part rather than it being this complicated one liner. After they debugged it, and fixed it, I watched them rewrite it back into the complicated one liner because it looks nicer... I just don't get it. It's like they just didn't see the pain they went through. We built our own hells.

rezonant 2y ago
Was there some kind of side effect that prevented you from simply using the debugger to evaluate parts of the statement to interrogate the results?