Hacker News Reader

Comment by majewsky | Hacker News Reader

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.

View on HN

because some gem developer wanted to be clever

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -Brian Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan

I love Ruby. I hate Rubyistas that make code that's impossible for others to read or comprehend. I find the rails source actually pretty good here.

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

LOL didn't you read lines 385-472 of some_ruby_interpreter_file.c on MRI version 2.2.1p347?

...

When we're looking to write programming languages to make our ability to program more concise and powerful, clever tricks and hacks defeat the purpose. Those belong in the 90's and earlier.

> clever tricks and hacks defeat the purpose.

There is nothing wrong with clever tricks (would you dismiss HAKMEM?), as long as they follow from simple principles that can be applied systematically. Alas, everything is ad-hoc in Ruby-land.

I moved from Perl to Python a few years ago. While I preferred the cleverness that Perl allowed me to do, I often found that I would shoot myself in the foot by being too clever too early.

Python feels more restrictive (in that it doesn't encourage you to use fancy tricks - even though they are often available). But I feel I write clearer more maintainable code.

You're right that the “clever” tricks that dynamic languages allow (and, to varying degrees, encourage) make programs less easily comprehensible for humans and machines alike. However, this is an indictment of dynamism, not cleverness.

As an example of why clever tricks aren't always a bad thing, Haskell's lens library is essentially a big bag of tricks for manipulating compound data structures. However, lens differs from your typical dynamic metaprogramming library in significant ways:

(0) Its design actually follows from a few, simple and very general principles. So you don't need to memorize the entire lens API; instead, you can use the principles to discover the API. The only other thing that offers a similar degree of discoverability is IntelliSense, but IntelliSense for dynamic languages is typically not as good as it is for languages like Java and C# - especially when dynamic metaprogramming is used!

(1) You don't need to resort to arcane reflection hacks to figure out what's going on in lens code. Parametricity (free theorems) and type class laws (provided that you follow them, and this is usually very easy to check) tell you everything you need to know.

(2) Since lenses, traversals, prisms, etc. are ridiculously general, the time and effort you invest in learning them pay off over a wider range of projects.

Your tone of the comment is turning people off, but essentially you are right. I only read the "Concord" gem part. I would consider this as an unnecessary abstraction that only obscures the code more. I wish people would strive to write more dumb and straight forward code more. This is especially true if you are writing code in a team setting.

I wouldn't call it “abstraction”, a term that I reserve for things that hide their implementation details well. (Litmus test: if you use the abstraction wrong, will the error message show you any implementation details?) Rather, it's boilerplate generation - basically a dynamic counterpart to Lisp macros.

Also, I see nothing wrong with the tone of the comment.

The direct counterpart is programming on the Common Lisp Object System meta-object level: different meta-classes, funcallable objects, etc.

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

It's quite clear to me, but I've been programming Ruby for quite a long time. Conversely, I have the same reaction you're having when I look at a lot of "modern" javascript. So I'm not sure the problem is with Ruby as much as they way some programmers try to be clever, no matter the language.

Reading the linked post makes me wonder if some people use the most obscure parts of Ruby as a sort of shibboleth

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.

> 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.

The code itself is well documented and actually quite simple; worth a look https://github.com/snusnu/procto/blob/master/lib/procto.rb

I'm a rubyist.

I really think that we (rubyists) go for style points way too much. Side-effect of metaprogramming, and a younger-ish audience? Maybe.

Reply on news.ycombinator.com