Ah yes, now I remember why I stopped learning ruby and was generally disgusted with the language. Along with the standard library having numerous ways to do the same thing and the general use of monkey patching (and the ruby users actually thinking monkey patching is good)
Ruby-style monkey-patching just seems like an awful idea. I cringe when I see it used in JavaScript, though it is less and less often seen in the wild now that browsers are less terrible and we tend to use babel and other transpilers instead of having to shim and polyfill around the more broken parts of the language.
I don't know about expecting other languages to behave like [that] too, but the Ruby community certainly does a lot of monkey patching. When I was developing in Ruby I saw this often and it annoyed me a bit.
It disgusts me on levels I cannot describe that this is standard operating procedure for ruby modules (gems, etc) and is the main reason I could never use it. Adding and replacing methods on builtin classes? Are these people out of their minds?! I don't understand it. I've used monkey patches once or twice and it always feels really dirty.
Ruby is a beautiful language but to me it’s too hard to understand what ruby code is doing by just looking at the code because so much happens with monkey patching and such.
My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp.
In regards to monkey-patching, while I'm not a Ruby programmer by any means, I sorely feel its absence in other languages. It's in JavaScript (expando objects as well as being able to override and overwrite built-in methods of existing types), and to some extent available in C# (extension methods are a sort-of expando object, but there is very little ability to overwrite a method). Like operator overloading, sure, don't build a project completely off of it (I'm looking at you, C++'s iostream), but when you need it, damn you need it. I'm still delving into Python (late to the party, whatever), but I definitely use Python in much more of a tinkering fashion, so monkey-patching is something I would desire in the language.
Slight counter point re: ruby, I complain A LOT about ruby's and the communities tendency to monkey patch everything. It's a dangerous practice that needs to be REALLY well thought out. just like C++ and the operator overloading, I've had bad and good experiences with both. I don't think they need to be removed from the languages but I do think good experienced developers should loudly and quite often proclaim the dangers of over use.
Ruby's flexibility makes it great for going fast and hacking things, but oh my god can it lead to monolithic spaghetti.
Magical eager backfills, mysterious action at a distance method_missing dispatch, crazy class hierarchies and transclusion, endpoints with reflective behavior, nonsensical tests with horrific abuse of rspec, ...
I've spent engineering years tearing down Ruby crud others have built, and it's led me to have a distaste for the language like no other.
Yea, monkey patching is helpful when dealing with a 3rd party library that needs to be tweaked 10 layers up the inheritance chain without having to change the object type all over the whole system.
If it gets overused it causes problems but there are times when it is close to a miracle. That said, there is a reason ruby devs are so test conscious.
Ruby is too forgiving, has multiple syntaxes for the same thing, and lets people do really obscure shit in a large codebase (monkey patching, hidden imports, etc). In short: it enables developer laziness.
I've found Ruby code the hardest to debug over the years. Also, I think the web development community is waking up to the value of type safety.
I will use Ruby for the occasional script because I like its backtick syntax for invoking other commands, but that's it.
I think this is it. Love Ruby as a language. Have grown to hate the way Ruby developers write stuff. Stuff ends up with so much abstraction and indirection. End up yearning for a simpler time when you could write code that just did what you needed it to.
Lack of namespaces and monkeypatching (extending classes) are THE "features" that keep me from using ruby seriously every time I try to approach the language.
I agree. When I think Ruby it brings to mind the Chef code base. Massive amounts of indirection via one line, but only one time used?, methods. Mixin abuse requiring manually searching an ungodly number of files to figure out where behavior is coming from. Errors pointing to non-existent lines of code because somebody thought it was a good idea to generate classes in loop to avoid boiler plate. Sandi Metz' "come to Jesus" book.
Two good things and one bad thing. The good things are multi-line lambdas (which Ruby calls blocks) and loose syntax rules, which I found weird at first but is the secret behind all of that DSL stuff.
The bad thing is the cultural tendency of the Ruby community towards monkey patching, which in my opinion trades long term maintainability for short term convenience.
I'm sorry, but I really don't follow at all. You call this approach heavy handed when in fact it's relatively small amount of source code that makes for much more readable developer code down the line. To me, Maybe seems like a much lighter touch than monkey patching Object.
And I don't understand your insistence that you're "writing another language" in Ruby by using a few functional constructs. For a language that uses .each as its base iterator and encourages you to pass blocks around it seems quite fitting, in fact.
Anyways, probably going to have to agree to disagree here. I come from the "every good language is a shitty lisp" school of thought so my personal lens might just not line up with yours.
reply