I would revise this to: Don't bring in more code than you need. But if the choice is between writing something yourself and using someone else's well-tested, heavily-used library, always go for the latter.
How much time will it take to implement each option?
How much time will it take in the future to support it?
What security risk does each option incur?
What is the risk of the project being abandoned?
What is the risk of the project changing in non-backwards compatible ways?
What are the performance characteristics of each option?
"I think Javascript is better because I prefer to use technologies I know" can be part of an ideology.
> "I think Javascript is better because I prefer to use technologies I know" can be part of an ideology.
But that's not what the OP said. Instead, it was "I think we should use Javascript because... uh... I dunno. Let's just do it!". That's not ideology by any possible meaning of the word.
On the other hand, I've been learning to use GSON's parser in my Sponge plugin (a Minecraft server) because the SpongAPI dependency pulls that in anyway.
Albeit, both libraries are dead simple to use so it's a bit contrived, but I see a lot of projects that would pull in Spring's RESTTemplate into a Camel project when they've already pulled in CXF or have Apache's HTTPClient readily available via other dependencies.
(And no, URLConnection is terrible. TERRIBLE.)
I also spend more time actually reading through specs to see how well they exercise the code.
That's probably standard procedure for a lot of people, but it's something that I had to learn to always do.
Absolutely. However, there are plenty of situations where what you pull down from npm or rubygems isn't actually all that well-written or well-tested.
When I first started programming I kind of had this impression that if an open source library is published on a package repo and people are using it then it must be much better than anything I could write. I have learned the hard way over the years that is not always true.
Mycode -> facade -> library
Navigating code becomes more cumbersome and stack traces longer. I do like this approach too but it isn't free.
Usually only 1 or 2 lines of the trace matter, you learn to skip the rest pretty fast.
https://dzone.com/articles/spring-vs-java-ee-the-real-story-...
An even more breathtaking stack trace image can be found here:
https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...
And the PDF version:
https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...
Hopefully a facade will introduce a small constant number of stack frames...
Anyway, with something like Lodash for JavaScript, I'd even want to "facade" that into a project-specific utilities thing. Right now we're on an old major version of it and upgrading would require changing hundreds of locations. When very many files in a project mention the same external dependency, that seems like a recipe for future sadness.
Unless you're using Spring, of course, then all bets are off. That's the biggest downside of IOC containers, they tend to ruin the usefulness of stack traces and the "step in/step out" functions of the debugger.
As for project-level management of external dependencies the tooling can be used to provide a facade for imports. I'm not sure about Webpack but JSPM already does this using a config.js file that maps all of the dependencies to readable import names, sans version numbers so the site doesn't break on future updates.
Ideally, once ES6 modules are used more widely it would be great to see libs start to adopt the facade pattern to provide finer granularity of control without deep linking into a project's source.
At one time there was a lot of zombie processes lingering for a long-ish time until the parent terminated and the zombies were reaped by init. I didn't bother to look at the implementation for xpopen, as I assumed it was just a call to popen. Turned out it wasnt; it was fork/exec with a socketpair turned into a FILE* with fdopen. The child was not waited for in xpclose.
I think there can be times when the facade pattern makes sense. I think there can be times when importing the world makes sense. I think there can be times when the opposite is true too. I think talking about these things in an abstract way can miss the point of the very insanity in some concrete solutions out there.
A lot of the dependencies discussed in this blog post are libraries that aren't actually adding anything useful: the various JSON parsing libraries that should be replaced with the parser in stdlib, or rspec testing libraries that shouldn't have ever been a regular runtime dependency.
[1] Managing complexity and dependencies is probably the most important concern going into the future, not just in programming, but also in every other complex system.
I see it as a sliding scale. If I'm parsing 1 string with the same date format into 1 object, I'm not going to pull in some general purpose time parsing library - I'll write the 10 lines of code myself, a few unit tests, and be happy.
If in the future I start having to deal with different date strings and some need to do more than just throw up a single date on a page somewhere, I'll get a date/time library.
> I pretty squarely disagree with Rob Pike on that one.
So does pcwalton. Ever heard of https://www.rust-lang.org/ ?
I just disagree with him on this one thing.
There's a reason smart people are good at solving problems, and it's not because they always defer to what other people 'know' to be true!
And so does the person you hire down the line to extend that app. Never forget that part when talking copying and tweaking code. :)
> Clear is better than clever.
> Reflection is never clear.
At the end of the day, the only person who is responsible for the quality of your proje t is you. You have to figure out which parts of your project are key to your operation and which are just window dressing. If your job is to make a blogging platform, I would expect many features of formatting documents to be reimplementations of other people's work, because you have to know you are relying on yourself for your core purpose.
I also don't understand the heartburn other developers have over knowing "OMG L, THERE IS SOMEONE ON TEH INTARWEBS AND THEY ARE REINVENTING THE WHEEL". It smacks of fear, a fear that is ultimately rooted in insecurity. If a person was secure in their knowledge of their skills, their ability to understand problems and fix them, then there should be nothing to fear from a dozen or a million different libraries doing the same thing and running into one or two of them on one's next project. It is just a matter of course.
I actually do fear a million reimplementations of, say, RSA.
My rule of thumb is if the stuff we need can be reduced to a few functions, it's better to copy so you at least know which code you are using and don't have thousands of lines of code in you repo where you don't know if they are ever being used,
There are two mindsets in coding, this code needs to work right now and this code needs to work in 20 years. Linking code is very likely to break in the second time frame. Public API's are generally unstable, services goes away, and people break things. But, if all you need is a toy demo then feel free.
As for your second point, I think you're overly focused on the wrong area. Both linked and static code demonstrably have many problems over that time period – if you recompile, you have to maintain an entire toolchain and every dependency over a long period; if you don't, you're almost certainly going to need to deal with changing system APIs, hardware, etc. — linking doesn't do a thing to make a 20-year old Mac app harder to run. In both cases, emulation starts to look quite appealing – IBM has, what, half a century with that approach? – and once you're doing that the linker is a minor bit of historical truvia.
By isolating out parts you actually need you have a better chance of making updates with reasonable effort.
Not saying this is for everybody but a lot of dependencies can be a killer.