Hacker News Reader

Comment by fishnchips | Hacker News Reader

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.

View on HN

I'm immediately put off by any system that doesn't let me figure out WTF something actually is until runtime. I should be able to learn most of what I need to know about a codebase with a basic text editor and grep. Some questions should be for documentation to answer, but "what the hell is this variable representing?" isn't one of them.

I prefer to let my code and my tools remember stuff for me. Rails and similarly-magical Ruby systems have too high a (human) memory overhead for my taste. Hard to jump in and out of if it's not the main thing you do every day.

I think Rails does a pretty good job of making well-documented sense. Lots of crappy gems abuse things like implicit global variables, rewriting core methods, and other monstrous applications of metaprogramming.

It is hard to reason about. I think if you understood it (meaning you are a core contributor) then you feel like it really helps organize your code and keep everything reasonable. But to a newbie it is the exact opposite.

I know in my projects I use some techniques which if you continued to work on the project you would really appreciate how many problems it solves but it seems crazy to my coworkers. Luckily it's a small gem and I'm the one who works on it but still.

The problem as I see it is when metaprogramming is used laterally or vertically. If code at a higher scope changes code at a lower scope, this makes a lot more sense than the arbitrary and profane directions of mutability that Ruby allows. So, like all things in Ruby, it's a matter of how the tool is used.

To metaprogramming! The cause of -- and solution to -- all of life's problems.

Things like "super.tap" make me think I'm about to go on a wild goose chase.

It's pretty simple and useful; instead of

  def my_method
    super_result = super
    ...
    (do something with super_result, or simply after super has been called)
    ...
    super_result <== to make sure your method returns the result of super
  end

you can just do this:

  def my_method
    super.tap{|result| (do something with/after result) } <== will still return the result of super
  end

Tap is by far my favorite method though usually on hashes to add conditionals

I know what it does, but isn't it (and your examples) an instance of the Call Super[1] antipattern?

1. https://www.martinfowler.com/bliki/CallSuper.html

From my understanding, the anti-pattern is related to creating an API that requires a call to super when overriding a method. super.tap may be used when interacting with an API that employs the "call super" anti-pattern, but calling super is not itself an instance of the anti-pattern; it can be used in perfectly legitimate cases as well.

it's a tool in the toolbox - just occasionally it can give a really elegant solution to something that would otherwise be spaghetti

like many other features on the fringe of a language it's important to understand when it's appropriate to use

also - there are few better buzzes writing code than doing something neat, skinny and appropriate with those Ruby features

I would only advise using it (if at all) in well-tested libraries that expose a well-documented public API.

I sometimes fantasise about a world where what you describe is just... how we write software. I really wish i could use my colleagues libraries instead of digging into their source code.

Metaprogramming in Rails is for infrastructure code, not business logic.

As far as the metaprogramming is encapsulated in a module with a good API and serves to make business code easier to read, it can be extremely helpful.

Reply on news.ycombinator.com