I learned Ruby before I learned Rails, and the books/tutorials I followed were pretty heavy on the metaprogramming and OO usage (inheritance, etc.).
What I find fascinating is that when I read more recent articles/books, the approach is much more functional in nature, with the OO part sometimes seeming little more than namespacing (Sandy Metz, for example).
I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby. But even 'idiomatic Ruby', based on the books-you-should-read suffers from similar problems.
It's all fun and exciting to write Ruby code, but if I hadn't been subjected to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-and-functional way', my output would've suffered from the same issues Rails code does.
That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.
Writing maintainable code in most languages involves knowing exactly when to apply the "cool stuff". Ruby meta-programming can be incredibly powerful - e.g. I'm working on a project at the moment where we dynamically build a very large, complex REST API by introspecting the ORM models augmented with data about access control etc. The entire web API is maybe a tenth of the code it'd have been if we wrote all the code manually, and that proportion is steadily dropping as we add more models.
But the key there is that the meta-programming involved is very, very limited for a very high payback. As it is, it raises the barrier for new hires, and we want to make sure not to raise it higher.
And most of the rest of the code is taking an increasingly functional approach.
I tend to think there is "too much magic" in a lot of Ruby projects, so I try to be very careful and limit it to places were it so drastically cuts down on the amount of code that we can justify quite a lot of explanation and still come out far ahead. But when everything lines up, the benefits can be dramatic.
> That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.
Ruby is in that regard a lot like C or Perl. It gives you lots of power and options to solve a problem your way but that doesn't mean you should always do so. Rails has used those options extensively and that explains a lot of the criticism you hear about it.
This also means Ruby is not for everybody but what language is? IMO you can write unmaintainable code in any language and there is none that makes that hard enough, so I'm firmly in the camp that I'd rather have the full power at my fingertips when I need it than being restricted.
Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.
Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.
What I find fascinating is that when I read more recent articles/books, the approach is much more functional in nature, with the OO part sometimes seeming little more than namespacing (Sandy Metz, for example).
I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby. But even 'idiomatic Ruby', based on the books-you-should-read suffers from similar problems.
It's all fun and exciting to write Ruby code, but if I hadn't been subjected to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-and-functional way', my output would've suffered from the same issues Rails code does.
That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.