Hacker News Reader

Comment by billyruffian | Hacker News Reader

I'm in the middle of writing some of this right now.

For 'reasons', I need to add callback hooks into a particular HTTP Client library my org uses across several dozen of projects. The library we commonly use doesn't have hooks.

I've got a couple of options: switch wholesale to a different library, build a child class, build a nasty bit of monkey patching boiler plate, or build a little library which prepends some logic into the ancestors chain.

The first and second would cause eye-rolls ("I'm just calling an internal api in the way I've always done, why are you making me change it everywhere!"). The monkey patching boilerplate, well, gross. But a little bit of prepend logic packaged into a gem and I've got the behaviour I need.

One of the tremendous joys I get from ruby is never having the feeling that the language or runtime can't do something I need. Whether that thing should be done or which way it should be done is another matter.

View on HN

As you can see from below, it's cultural. It's also the reason why every Rails codebase turns really bad as it grows: metaprogramming keeps being used extensively instead of being limited. Modules abused, stuff monkey patched, methods creating other methods continuously.

The consequences are always: code unmaintainable over the long term.

Unfortunately to reach this disillusioned state you need to hit some really hard walls, which doesn't happen to all ruby devs.

That's a matter of developer discipline and foresight. I've be managing a Rails project since late 2011 (that's my longest run so far), usually adding a few features per year and fixing bugs, mostly alone or with another developer. If I put too much magic into the code I'd spend much of my time figuring out what I did months ago. Instead I can usually read my code from 2011 / 2012 and understand what it does. The puzzling exceptions are not so exceptional: I'm having the same experiences with the other code bases I'm working on (Python, Elixir.)

So in doubt no metaprogramming. Example: I never wrote a macro in a real world Elixir project.

I can't say anything about the number of featurea, that's entirely business driven, but of course you shouldn't be writing macros in Elixir on a standard application.

But it's not abnormal for a rails codebase to have a Concern (rails module) that provides a class method that does something, specific to the application. Which is equivalent to a macro.

I have seen a couple of Rails codebases and "metaprogramming keeps being used extensively instead of being limited" was not the problem in any of them. Instead it was mostly picking bad dependencies, rushing to delivery, layering complex features on top of one another. The code was maintainable, it is the business logic (and the decisions made hastily) what made it unmaintainable.

> Unfortunately to reach this disillusioned state you need to hit some really hard walls

I have seen quite a few Rails apps, some pretty old, and these were not the hard walls which were hit. One way of not hitting those specific walls (which are pretty soft IMO) is hiring decent people, decently compensated. And empowering them to make decisions.

Notice that we might have a different definition of metaprogramming. Including a module, to me, is part of metaprogramming.

A lot of codebases do that, and they create chain of undeclared dependencies between multiple modules being included that make impossible to determine the requirements to use such module in the first place.

The development tend also to slow down to a cripple, as well as being overstaffed to compensate.

Reply on news.ycombinator.com