I'm familiar with dry-rb coding style and I think it is very difficult to reason about. Metaprogramming often feels like magic but it comes at a price - hard for newbies to grok and impossible for static tools to work with. I would only advise using it (if at all) in well-tested libraries that expose a well-documented public API.
I'm an experienced Rubyist who's done their fair share of horrible hacky things.<p>This is quite nice. It avoid some of the issues that other metaprograming techniques will land you, and the associated debugging hell.<p>Nicely written too.
This article demonstrates the mess you can get into when you mix OOP with metaprogramming and why Ruby has a bad reputation for encouraging it. Metaprogramming seems to compound the contortions of OOP in contrast to the elegance macros add to functional languages like Clojure and Elixir. Ruby's method_missing and instance_eval seem like ugly hacks compared with the simple quote/unquote of Lisp-based languages.
i like the hand-drawn class diagrams. =)<p>i wish there were more of these (ruby) metaprogramming articles, since there is a lot of ingenuity going on under the covers.<p>it's just like jargon in specialized fields - so much is packed into so few symbols. it allows those who understand it to express more complex ideas more easily but also serves as a barrier to those unfamiliar with the jargon.