Yes, this is the sort of thing that scares me away from Ruby.
I'm worried this sort of "screw it just add a library" is going to spread further in my language of choice: Java.
In my time doing open source programming on the side, I've found that it has become more common with the advent of things like mvn and gradle to just slather on layers to your stack even for the simple tasks.
Need a function to turn a byte buffer into a string? Download these 3 Apache commons libraries and their dependencies.
I understand if you are relying on a large portion of a library and you need to use it, but why bring an entire library in for one function.
There are ideas floating around that make it appealing to do just that. For example, the commons library might be considered "battle-tested," and who really knows what could happen with your own custom byte-buffer-to-string function? Maybe you missed something? Maybe there is some "best practice" that you didn't follow? Maybe the commons library is optimized? And writing your own thing doesn't add business value. Developer time is more expensive than dependencies. And so on.
Me, I very often prefer to write things myself, in a way that can get labelled as NIH. My inclination is based on bad experiences with trying to debug external libraries. Sometimes I look at open source library code and find staggering complexity that I have no need for. Yes, maybe the library is great, but if its combinatorial size is 10,000 times the functionality that we need, then depending on its correctness becomes scary to me. And when I need to customize it, due to some requirements alteration, I will find it difficult and tedious.
Black-box type libraries for isolated complicated tasks like codecs and crypto I will happily use.
Otherwise, I'm a fan of the "design patterns" approach to reuse, which is all about learning from others, but without creating reusable formal abstractions in library form. So if you teach me how to write an URL router, I can then use your insights without depending on your code base, and I can adapt the idea so it fits my application perfectly.
Urgh. I find design patterns the worst approach. It's just copy-paste at a slightly higher level. If you really understand a pattern, you should be able to express it formally - i.e. as code.
Richard P. Gabriel's book Patterns of Software has a chapter about that. (It's free and out of print.)
Bluntly, it's kind of like: if you really understand a style of house building, you should be able to deliver it as a prefab. Maybe true in some way, but also neglects the drawbacks of standardized components.
> I understand if you are relying on a large portion of a library and you need to use it, but why bring an entire library in for one function.
Why not? An extra 3MB of disk space? A few milliseconds more of compile time? Maven makes it very easy to work with dependencies (and you want to use maven anyway, even if you have no dependencies, so that you have a proper release process). At this point I think of basic utility libraries like guava-collections, commons-io, httpclient and junit as part of the standard library. If I need even one function from one of them I'll add the dependency. Better that than have two inconsistent ways of doing the same thing.
I'm worried this sort of "screw it just add a library" is going to spread further in my language of choice: Java.
In my time doing open source programming on the side, I've found that it has become more common with the advent of things like mvn and gradle to just slather on layers to your stack even for the simple tasks.
Need a function to turn a byte buffer into a string? Download these 3 Apache commons libraries and their dependencies.
I understand if you are relying on a large portion of a library and you need to use it, but why bring an entire library in for one function.