An introduction to metaprogramming in Ruby

Ruby's metaprogramming allows you to create really nice, ergonomic abstractions. I can write `has_one :posts` in a User model class in Rails and a ton of useful functionality pops into existence.

On the other hand, that deep magic metaprogramming can be really hard to follow if you need to understand how it works. Tracing back through (or even debugging) a metaprogramming-heavy codebase is a nightmare.

I'd argue that deep magic metaprogramming is great for when you have abstractions you almost never need to dig into. Rails is great because it's relatively rare that I need to go spelunking in the rails codebase itself (and thus understand the deep magic). Instead, I can rely on a huge pile of documentation, stack overflow answers, conference talks, etc to figure out how to use rails' abstractions (like `has_one :posts`) without needing to understand their implementation.

On the other hand, the average production codebase should minimize their use of metaprogramming. When I don't understand how Joe's `Whatsit` interface works, I'm much more likely to need to dig into Joe's code to understand how to use that abstraction. If I have to understand Joe's deep magic every time I do that, it's a net loss.

I've worked with Ruby for over fifteen years off and on and the last seven exclusively -- in a large codebase with a fair amount of metaprogramming. We've onboarded engineers, junior and senior, who previously have never used Ruby and it's been interesting to see who does and doesn't have a hard time with it. It doesn't seem to match overall experience and skill level. It's more of a sense that people with patience and a kind of outcome oriented approach (over fixating on why something is done a certain way) will have an easier time unwinding the complexity.

One thing I've noticed, and this is something that seems to bother non-Ruby engineers, is the people that flourish in a complex Ruby application prefer to read code over documentation.

Makes sense. In some ways there's less magic to ruby, because it's not using macros, templates, reflection, generics etc. In other languages you're stepping out of "normal" code into "special" code to make the magic work.

I loved it.. until something broke and searching a method name didn’t work because it was using dynamic method names. A full day of unpacking the Spree Commerce shipping system put me off a bit.

Other than a 60ms startup differential Ruby doesn't sacrifice ANY speed compared with Python. Those days are over.

> overall I like how magical Rails feels because it lets me go so fast

You going "fast" now means that others (including the future you) will go "slow" later.

The deeper you go in ruby, the more you regret metaprogramming.

It's fine for those 2-3 cases, and should be banned everywhere else. In rails is highly abused. What rails achieved and it's good at can be achieved with less metaprogramming, but of course nobody is going to build another rails, since rails is already there.

Rust does it well, too. For such a crunchy language, there are a surprising number of macros, but my experience using them has always been fantastic.

Rust’s macro system is the first I’ve seen with the same potential. But of course, an equal to Rails has yet to surface; and even if one does, being a compiled language still counteracts a lot of its ergonomics.

Try Clojure. It takes metaprogramming to a level higher than Ruby's.

Arguably reducing LOC helps maintainability, as long as it's done in a clear manner. That's one of the main points of abstraction, and all programming languages offer various abstraction facilities, unless it's a language like brainfuck.

Came to see some Python zealot use the term “monkey patching” and was not disappointed

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

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.

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.

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.

When i was around 20 i learned Ruby as basically my first language and it has been a joyride ever since. I had a chance to develop and co-develop things in other languages but for me there is none matching speed, joy and effectivity of Ruby.

Everyone's mileage may vary but i definitelly do recommend learnign Ruby as a first leanguage. What i also recommend starting developers is to not follow dogmatic advices blindly.

I don’t know Ruby but I’ve been a huge fan of Lisp macros (Clojure).

As with all abstraction mechanisms, you avoid them until you need them. When you do need them, they become a force multiplier.

A lot of macros can be avoided with data driven programming, which is likely one of the strongest techniques in terms of cost/benefit.

A light form of meta programming is source code generation (often used in tandem with data driven). It lets you have macro-like power, but the guts are spilled out for you to modify further or reason about easily. In some languages it’s the only thing you can do at that abstraction level.

In any case, meta programming is very powerful. But its quality and utility hinges on you to avoid it until you exhaust all of the lower level techniques. Else you end up with the worst kind of wrong abstraction.

Do! When the need arises. Language designers wouldn't include such facilities if there was never a need. Ruby is hardly alone in this. I can't imagine a Lisper ever saying never use macros. C++ has templates, Rust has macros, Python has magic methods, metaclasses and decorators. Javascript, Java, Perl, C let you do some pretty horrific stuff because sometimes you need the the flexibility. If you look at enough library and framework code, you will see those things in use.

Don't! Be dogmatic about programming. There are always use cases.

method_missing is great if you're wrapping an object

    class Wrapper < BasicObject
      def initialize(obj)
        @obj = obj
      end

      def method_missing(name, *, **, &)
        ::Kernel.puts "Calling #{name}"
        @obj.send(name, *, **, &)
      end
    end

Yeah no. There are times when it's useful. I think most of the times you don't need it but you coming in and saying don't use it sounds a bit pretentious.

Ruby does not have to do what other languages are doing. There is no good or bad.

Do you have any stories? Tried using it and it backfired? Were bitten by a nasty bug in a gem?

I have used Sorbet in my web framework. The method signatures can be tedious to type out sometimes, but it helps a lot when refactoring code. I feel more confident that my changes will work. It's not as flexible as TypeScript, but it's pretty good and has saved me from mistakes many times. The language server helps a lot with autocompletion so I don't have to keep every little detail in my head all the time. Sometimes I have to structure the code a little bit different just to make Sorbet happy which is annoying, but I've also been able to replace huge parts of the codebase quite easily.

How's sorbet? We're looking into it and the webpage looks great, but how's actual usage?

Do you also not allow loops, because they are the devil’s lettuce?

Metaprogramming is just a higher level of abstraction that lets you express things that would otherwise be tedious or repetitive. It’s not that different than using a loop to avoid having to write the same thing over and over again. Avoiding it at all costs is dogmatic and kind of silly.

why?

Metaprogramming Ruby by Paolo Perrotta is an awesome in-depth resource in comparison. It’s a bit outdated but the base of metaprogramming magic in Ruby hasn’t changed much in 3.0+

> As an Objective-C developer Ruby sounds very familiar.

Both are heavily influenced by Smalltalk.