
Lessons learned from some of the best Ruby codebases - ingve
http://blacklane.github.io/2016/04/23/lessons-learned-from-some-of-the-best-ruby-codebases-part-1/
======
majewsky
Rubyistas sure have a bizarre definition of "best codebases".

> This elegant trick of having a class inherit from Module allows us to use a
> class in a kind-of module context and to use a module in a kind-of class
> context.

This summarizes exactly why I hate Ruby: bizarre syntax tricks all over the
place, and (not only junior) developers desperately trying to figure out how
that instance variable over there teleported over here, because some gem
developer wanted to be clever.

> Procto turns your ruby object into a method object. The code example from
> the README speaks for itself so I’ll just paste it here:

No it doesn't. What is even going on in there?!?

> This whole chunk of code looks a little more complex than it actually is:

Another thing that I often encounter in Ruby code, particularly in gems.

~~~
tarr11
Yeah, hard to figure out what is going on here. I wish that procto code was
more documented.

Too much class level and module level munging morphs code into a sub language
only readable by the author.

I am generally supportive of this, though, if it masks enough underlying
complexity.

In this case it's just syntactic sugar.

~~~
catnaroek
> I am generally supportive of this, though, if it masks enough underlying
> complexity.

In general, anything that makes the static structure of your program less
discernible to whoever has to read it, can be considered technical debt. If
you find yourself doing lots of dynamic metaprogramming, chances are you need
to rethink your application's architecture.

------
barrkel
The chief lesson here is parameterized modules - specifically, parameterizing
modules by instantiating a class derived from Module, rather than simply
including the instance methods of a module directly.

I don't think this is an esoteric technique, any gripes about the specific
examples chosen notwithstanding (probably chosen for their simplicity, not
their utility). It's little different to inheriting from a template in C++.

------
jwdunne
Hrm. I've bashed out quite a bit of crazy brand Ruby to achieve some cool
looking interface. I wouldn't do this in production code.

The problem is of definition. My definition of clean is readable, clear and
understandable. If it takes a significant portion of a blog post and the
research before hand to understand what the hell is going on, I wouldn't call
that clean as I define it.

Ideally, you want code that is understood quickly so that it can be maintained
with the least effort. Seeing an object used as module violates my
understanding of how modules were designed to be used and I would have to
spend time figuring out how. It may be 2 minutes or 10 but regardless it's
time that need not have been spent.

Cool magic can sometimes be helpful. Often its just cool.

