5 ms·

Ruby meta programming is awesomely powerful, but also one of the main reasons I never want to work in another’s Ruby codebase again. There is always some develo

Ruby meta programming is awesomely powerful, but also one of the main reasons I never want to work in another’s Ruby codebase again. There is always some developer who read some article like this and invents their own DSL to solve a problem that didn’t need one. It’s pure pain to debug it.

f6v 3y ago
Classic: saving two lines of code, but completely breaking maintainability.
- tremon 3y ago
  Exhibit #1: rake's DSL syntax. It allows "neat" syntax abominations like rule :name, [:param] => [:dep1, 'dep2'] do |t| where every argument except the name can either be missing, single (value) or multiple (array). Sure, it has the "advantage" that it's syntactically valid Ruby code, but it then requires some 70 lines of awful code to actually parse that data into a usable construct: https://github.com/ruby/rake/blob/7b50e9dc37abc57fd365c16cb131cc33d8389ec0/lib/rake/task_manager.rb#L86-L145 https://github.com/ruby/rake/blob/7b50e9dc37abc57fd365c16cb1...
  - elcapitan 3y ago
    I always have to look up the variations of that parameter passing when writing rake tasks, not sure that is such a good sign that it's a great design in the first place.
UncleOxidant 3y ago
I feel the same. For my own projects where it's only me working on the code it can be really nice, powerful and big productivity boost. But if you start having multiple people on the codebase it's not going to be fun to debug.
jweir 3y ago
I love Ruby and we use Ruby and we do not allow meta-programming. Too difficult to maintain. Even `send` is frowned upon, but allowed under some circumstances.
- actualwill 3y ago
  If you have some group that all understands and checks each other from the beginning, Ruby is probably great. However it was every startups default choice for a while, and those code bases get wrecked and have no oversight until way later. A lot of bad ideas becomes foundational. This scenario is far more common than good Ruby code bases. It’s just easier to rule out Ruby when looking for new jobs.
sdsd 3y ago
I agree, but I wonder how people feel about Racket in this context, where the "language oriented programming" approach is common and the idea that you solve problems by creating a DSL is the norm.

f6v 3y ago

Classic: saving two lines of code, but completely breaking maintainability.

tremon 3y ago
Exhibit #1: rake's DSL syntax. It allows "neat" syntax abominations like rule :name, [:param] => [:dep1, 'dep2'] do |t| where every argument except the name can either be missing, single (value) or multiple (array). Sure, it has the "advantage" that it's syntactically valid Ruby code, but it then requires some 70 lines of awful code to actually parse that data into a usable construct: https://github.com/ruby/rake/blob/7b50e9dc37abc57fd365c16cb131cc33d8389ec0/lib/rake/task_manager.rb#L86-L145 https://github.com/ruby/rake/blob/7b50e9dc37abc57fd365c16cb1...
- elcapitan 3y ago
  I always have to look up the variations of that parameter passing when writing rake tasks, not sure that is such a good sign that it's a great design in the first place.

UncleOxidant 3y ago

I feel the same. For my own projects where it's only me working on the code it can be really nice, powerful and big productivity boost. But if you start having multiple people on the codebase it's not going to be fun to debug.

jweir 3y ago

I love Ruby and we use Ruby and we do not allow meta-programming. Too difficult to maintain. Even `send` is frowned upon, but allowed under some circumstances.

actualwill 3y ago
If you have some group that all understands and checks each other from the beginning, Ruby is probably great. However it was every startups default choice for a while, and those code bases get wrecked and have no oversight until way later. A lot of bad ideas becomes foundational. This scenario is far more common than good Ruby code bases. It’s just easier to rule out Ruby when looking for new jobs.

sdsd 3y ago

I agree, but I wonder how people feel about Racket in this context, where the "language oriented programming" approach is common and the idea that you solve problems by creating a DSL is the norm.