The Right Thing?
prog21.dadgum.com
prog21.dadgum.com
Sure, but common sense would guide programmers about such tradeoffs. The extra time spent loading an additional library dependency would be amortized over the total execution time of the program -- IF -- the program makes repeated use of the library.
If a js file only has a single getElementById() call, substituting that with a JQuery library to get the "$" syntax would be overkill.[1] Howevever, if the javascript has many complicated DOM selects and bunch of animations, the extra JQuery load time can be justified.
One of the reasons to use a library the author didn't touch on was "insurance against unknown edge cases." For example, I could attempt to write 50 lines of code to uppercase a lowercase Unicode string. However, my attempt would have bugs in it. Instead, it would be more prudent to use the ICU library. It's a hassle to add that dependency and it's many thousands of lines more than my "simple" program but the ICU developers covered more edge cases than I ever thought of.
What is the best number?
Where are my legs?
Most modern software has incredibly complex dependency chains and that's what makes it fragile and unpredictable most of the time. If we focus on making the languages, runtimes and core libraries flexible enough that we don't need to assemble code from dozens of hobbyist GitHub projects to put up an app with a reasonably modern UI, we would make a huge step forward.
This isn't the right case all the time, but if implementing something is only a few dozen lines and isn't already provided in an appropriate form by a library that you're using, there's nothing wrong with just implementing it from scratch.
The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself.
This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far.
Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment.
I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.
> We have so many hobbyist libraries precisely because our languages and tools are so flexible.
I beg to differ. The (initially) small hobbyist libraries are often working around the deficiencies of the language/runtime/core libraries. This has been the case for JavaScript since jQuery. If a third-party library doesn't implement a format or a protocol, or an intricate algorithm, but rather tries to augment the language, that is a huge red flag.
Perhaps some of them take it too far, but it's at least an interesting perspective, in light of stuff like the post and your experiences in Ruby.
I do agree in general that you have to be sure to consider the external dependency as a cost, and the benefit you get for it better outweigh the costs. Exactly how you determine that varies from language to language quite substantially, and probably varies by personal taste and experience level too. For instance, you might be less inclined to take an external dependency for something you find quite easy to write yourself, whereas someone not as skilled may find it preferable to take the external dependency if it means they don't have to learn the nuances of whatever it is enough to write it themselves.
* License is it compatible with the rest of your code?
* Relative size of module vs what you need from it. The size of the module introduces a non-trivial maintenance burden.
* Difficulty of just doing it yourself. Is the thing you need to do non-trival? like say encryption? or Distributed Consensus?
* Is the module compatible with the internals of your system? Will it require significant changes to how your code or application works?
* Platform support? Will the module work on all the platforms your code/application will run on?
All of these things influence the decision. A knee jerk response of "Just use X" may be right but you'll find yourself in the position of not knowing why it's right and thus unable to adjust if it ever stops being right.
It's too bad the File::Slurp module has bugs, and the author seems unresponsive about them, but it's not a core module, and other authors are free to produce alternatives, which is exactly what happened. Looks like the change in the fine author's code would have amounted to a two line difference.
In my opinion, it would still make sense to use a CPAN module - I'm glad their orginal code is faster, and if it works with that specific use case - fine with me.
The problem, obviously, is if the fine author of the home-grown code needs similar functionality somewhere else. Do they make their home-grown code into a module for reuse, or just copy/paste? Say they copy/paste and then they find a bug in their implementation years down the line (or worst, someone else does, as this author has moved on to greener pastures).
Uh-oh - same problem as relying on a module, but now it's more work to fix (the code is everywhere and perhaps has evolved now independently), and there wasn't the framework of module authors, testing infrastructure, bug tracking system, peer review, etc, etc, etc there to have a drop in replacement for ya.
The line to draw for reusable code is certainly yours to make. My line not to cross is when I'm practicing, "Copy and Paste Programming" - easy enough to take the extra 5 minutes and package the code up for reuse. Makes it easier to make my unit tests up and all the rest of the good practices of a Perl programmer.
> During the summer rumours about a new attack against SSL started circulating.
> The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.
RC4? That heap of junk? You're kidding.
[18 months later]
> Last week, a group of researchers announced significant advancements in the attacks against RC4, unveiling new weaknesses as well as new methods to exploit them.
Jeez, who could have seen that one coming.
It's doubly frustrating when a library function is obsoleted and replaced wholesale rather than fixed of whatever defects it has.
And file I/O is triply frustrating because there are all sorts of corner cases, plus leaked abstractions from the file system and hardware.
The moral of the story is that you should never use libraries, and never do any reading or writing of files. Wait, what?
https://www.jwz.org/doc/worse-is-better.html
...would've said that module embodied Worse is Better philosophy of something that snowballed into a mess with uptake and feature creep. Just guessing: haven't read its source or anything.
Concise and correctness just often go hand in hand. Your approach is likely closer to The Right Thing. ;)