

Why I hate Ruby (or at least some common practices of its developers) - prog
http://www.benjamincoe.com/post/6234388028/why-i-hate-ruby-or-at-least-some-common-practices-of

======
lindvall
Really? What is it going to take to get beyond the stupid provocative titles?

Can we work on being constructive? It would be pretty sweet if people started
writing post-mortems for crazy bugs they found the way people write them for
outages.

What was the process you went through to track down this problem? Were there
any interesting tools or processes you employed?

What was the final solution?

What can we (both you and your team and the community as a whole) do in the
future to prevent this sort of thing from happening again?

~~~
sunchild
It seems to be more or less universally true that anyone complaining about a
particular language, framework, platform, IDE, text editor, etc. is staring
into the abyss of whatever outdated, outmoded, outmaneuvered way of thinking
that they've invested themselves into. Everyone else is busily improving on
what we've got to work with.

------
tung
Digging around, I found that the author used the JSON gem, relying on to_json
taking an optional generator arg. But, yajl-ruby and ActiveSupport define
to_json themselves without that, leading to breakage. Those, and the fix for
his project[1], are all on GitHub.

The author claims most Ruby programmers are monkey-patching and causing these
problems. That's almost right: they _were_. But by and large, they know better
now, and would happily replace it with better code, if they could just find it
and fix it: that's the real problem.

The author could help by, say, logging an issue, or forking and pull
requesting a fix. I checked GitHub; his ID, bcoe, doesn't show in the issues,
nor in the pull requests of yajl-ruby's GitHub page[2].

I'm not saying he _must_ do this for every problem with every open-source
project he happens across, but even one contribution helps more than this
steam-venting blog post.

[1] <https://github.com/bcoe/tire/commit/2dd5fc03>

[2] <https://github.com/brianmario/yajl-ruby>

------
melvinram
Summary: OP used a gem that depended on other gems, didn't write tests for it
and deployed it. This caused problems and he had to go down a rabbit hole
which led to a lot of frustration.

Snarky response: Duh. Test before you deploy.

~~~
btilly
And you've missed the point.

Monkey patching is a really bad idea for reasons that have been understood for
decades. A lot of Ruby folks think that monkey patching is the bee's knees.
The result is that a lot of Ruby gems monkey patch things in conflicting ways.

Every other language community that he discussed frowns on monkey patching and
doesn't do it to any significant degree. And it means that stuff isn't nearly
as fragile.

------
rawsyntax
A better solution for monkey patching is in the works:
[http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-
pra...](http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/)

That being said, any language feature can be abused and misused

~~~
moomin
It's worth pointing out that clojure's protocols actually address the
"multiple issues of the same method" problem. It looks like Yehuda's been, at
the very least, reading the same books as Rich Hickey (this is a good thing)

------
sunkencity
It doesn't have to be ruby to make it hard to integrate your own frankenstack.
Can be just as tricky on Java with different types of dependency injection
framework and configuration xmls.

------
grandalf
Flagged for linkbait title.

