Why I hate Ruby (or at least some common practices of its developers)
1–10 of 10 posts
Re: Why I hate Ruby (or at least some common practices of its developers)
#2A better solution for monkey patching is in the works: http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-pra...
That being said, any language feature can be abused and misused
Re: Why I hate Ruby (or at least some common practices of its developers)
#3It 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.
Re: Why I hate Ruby (or at least some common practices of its developers)
#4Summary: 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.
Re: Why I hate Ruby (or at least some common practices of its developers)
#5Really? 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?
Re: Why I hate Ruby (or at least some common practices of its developers)
#6Flagged for linkbait title.
Re: Why I hate Ruby (or at least some common practices of its developers)
#7Really? 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 a…
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.
Re: Why I hate Ruby (or at least some common practices of its developers)
#8A better solution for monkey patching is in the works: http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-pra... That being said, any language feature can be abused and misused
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)
Re: Why I hate Ruby (or at least some common practices of its developers)
#9Summary: 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.
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.
Re: Why I hate Ruby (or at least some common practices of its developers)
#10Digging 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.