Shared dependencies can also reduce, code though. Do you really want 10 slightly different implementations of the same thing after you've brought in a few large dependencies?
Never use a dependency that you could replace with an afternoon of programming
41–50 of 333 posts
Re: Never use a dependency that you could replace with an afternoon of programming
#42The single best way to avoid dependencies is to use a language with a large standard library. Given the variance in standard library coverage, it’s rarely productive to argue about this topic in a language agnostic way. Using only stdlib in Go is very different from using only stdlib in JavaScript.
The best way to avoid dependencies is to use a language that is built in a way such that dependencies are worthless. Like APL, J, or kdb+/q. All of these languages are incredibly small, have almost non-existent standard libraries, and yet are designed in such a way that a large standard library becomes superfluous.
Having a large standard library speaks poorly of the composability and orthogonality of language primitives.
Re: Never use a dependency that you could replace with an afternoon of programming
#43I don’t have enough afternoons for this.
Re: Never use a dependency that you could replace with an afternoon of programming
#44It's a matter of judgement, but here's a few observations:
- With a little experience, you know what gets fiddly and what doesn't. Today for instance, I needed a way to remove tags in an SVG document, which looks a lot like HTML tags. I quickly ended up finding that Regex is not the solution (a well known guy on SO wrote an answer that looks like a huge warning sign). I also couldn't enumerate all the corner cases. So I found a lib that does it, along with an SO answer that turns it into a two-liner.
- Dependencies vary in quality. Some are basically like another standard lib. Boost for instance is very well used. The tough ones are where the lib seems to be "finished", where there seem to be few commits recently, but the project was once lively and functional. IIRC libev comes to mind here. And then there are the totally dead projects, where there's a load of issues open and nobody saying anything.
- Try to lock down versions. If you get a thing working with a certain version, there's no reason you need the newest new as soon as it's pushed. You can probably live with doing a scan for updates now and again.
- Your afternoon of programming needs to have a clear end. That hashmap you wrote will very likely spew out issues over the next few days. CSV parser, maybe. Bessel function, that'll work.
Re: Never use a dependency that you could replace with an afternoon of programming
#45Earlier quoted context omitted.
You don't believe in software licensing, do you?
Vendoring dependencies is usually not the same thing as ripping off someone else’s code. It usually just boils down to keeping a copy of the version of a dependency you used.
Copying someone else's code and putting it in your software repository is an excellent way to find yourself violating a wide variety of open source licenses.
This is actually one of the most common causes for GPL violations. And companies have gotten into serious trouble for that.
Either rewrite the code, or maintain it as a dependency and follow the licensing rules. Don't simply copy code from it into your project unless you have explicit reason to believe that that is OK to do.
Re: Never use a dependency that you could replace with an afternoon of programming
#46Frankly my own code is usually the worst dependency I could have.
so true :(
Re: Never use a dependency that you could replace with an afternoon of programming
#47Earlier quoted context omitted.
That is the issue I have with it: ‘an afternoon’ is already way too vague. Make it ‘5 minutes’ (left pad etc) then I think it works out.
Is that really 5 minutes? (For when left-pad was relevant) var cache = [ '', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' ]; function leftPad (str, len, ch) { // convert `str` to a `string` str = str + ''; // `len` is the `pad`'s length now len = len - str.length; // doesn't need to pad if (len >= 1; // "double" the `ch` so this operation count grows logarithmically on `len` // each time `ch` is "doubled", the `len` w…
One of the points of the article is that when you code a dependency for your purpose, you get smaller code. For example, I know I'll always pass it a string, so I don't need to type-check.
I started with the problem of "I need a function that pads a string with a character out to some length". Coding it up took under 1 minute, easily under 5 minutes.
function leftPad (str, len, ch) {
const neededPadding = len - str.length;
if (neededPadding The fact that the left-pad code has optimizations (which don't matter for the place I'm using it) and type-checks (which don't matter; my higher level unit tests would catch that mistake) is beside the point.
Re: Never use a dependency that you could replace with an afternoon of programming
#48Totally agreeing with this but the issue is maintenance. Sure, I can find a package and copy and paste a few files and make it my own — or do it from scratch even!
But then, that's not really my core domain, so I'll most likely never touch that piece again anytime soon. A quality package tends to have that covered (with a small risk, too if it's an untrusted source).
Re: Never use a dependency that you could replace with an afternoon of programming
#49I'm the opposite. I always think I can solve it in an afternoon and always realize there are a lot of intricacies. Fuck making popup positioning in browsers. That shit is hard to get just right.
Ugh please just don't use popups at all. I block every single one I see with custom CSS rules. GDPR cookie warnings, "please subscribe", stupid "can i help you" chat popups, everything.
Re: Never use a dependency that you could replace with an afternoon of programming
#50Earlier quoted context omitted.
That is the issue I have with it: ‘an afternoon’ is already way too vague. Make it ‘5 minutes’ (left pad etc) then I think it works out.
Is that really 5 minutes? (For when left-pad was relevant) var cache = [ '', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' ]; function leftPad (str, len, ch) { // convert `str` to a `string` str = str + ''; // `len` is the `pad`'s length now len = len - str.length; // doesn't need to pad if (len >= 1; // "double" the `ch` so this operation count grows logarithmically on `len` // each time `ch` is "doubled", the `len` w…
[deleted]