why not just copy the code from the dependency into your own sources?
You don't believe in software licensing, do you?
Never use a dependency that you could replace with an afternoon of programming
21–30 of 333 posts
Re: Never use a dependency that you could replace with an afternoon of programming
#22Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?
That was my first thought: I've seen these projects before — they're where you find 5 slightly different implementations of similar logic, no logging or tests, failures as soon as someone uses Unicode, etc. and I get an order of magnitude performance improvement by replacing that code with an external module which has had the other 19 afternoons' worth of work it actually takes.
Re: Never use a dependency that you could replace with an afternoon of programming
#23Even if this is true, the problem is you don't know what's going to take an afternoon of programming. How many times have we all said "should only take an hour" just for it to take four days?
If someone spent the time and effort building something you need, I don't see a problem with using it. It all depends on what kind of system you're building, what the security and stability guarantees are, and in general what trade-offs you want to make.
In other words, "never" is usually bad advice.
Re: Never use a dependency that you could replace with an afternoon of programming
#24Never use store-bought bricks if you can replace them with an afternoon of brick making.
Re: Never use a dependency that you could replace with an afternoon of programming
#25I'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.
Re: Never use a dependency that you could replace with an afternoon of programming
#26This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…
I'd extend "afternoon" to "half a week", but in general I agree with OP.
> Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version.
The meaning of "afternoon work" should be considered "of good enough quality". Tests, structure, reasonable docs, all that. It shouldn't be a fastest written something, it should be a normal code.
> and still not achieve the performance of the pre-built version.
Some losses in performance are acceptable for greater visibility and better fit for the project. If you need non-trivial performance gains - well, those are also achievable by code, are you sure you can actually write such code in a few days?
> Find a bug in the dependency? Submit a patch.
That's the point. To submit a good patch, you have to internalize the system. It's easier to do if the system is yours - doesn't do much except what you need.
> Worried about the dependency changing? Lock the version.
Now you've locked yourself out of upstream bug fixes.
> Don't reinvent the wheel.
Here is a wheel patented in 1972 in US, with noticeable benefits over the traditional idea: https://en.wikipedia.org/wiki/Mecanum_wheel :) .
We do reinvent the wheel whenever we need to have an actual wheel for a device, not an abstract concept. Similarly, we write for loops, "reinventing" them for our specific purpose. Those are all different wheels, loops and needs. Don't mistake the "idea" of a hashtable with an implementation.
Re: Never use a dependency that you could replace with an afternoon of programming
#27This reminds me of the Node left-pad module problem in a way. I think if something is so trivial to write, you should write it rather than using a dependency. If it is non-trivial, I prefer the official standard libraries for a programming language. That is if a solution exists in the standard library. I think the Go standard library with its batteries included mantra and the level of support it gets is good example…
Or just C&P the relevant open source code (license allowing). Removing a dependency doesn’t have to mean writing from scratch.
If you copy the code into your project you at least need to keep track of the original authors and licensing or you're in violation of the copyright 99% of the time.
Re: Never use a dependency that you could replace with an afternoon of programming
#28Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?
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` would need to be "doubled" too
// similar to finding a value in binary search tree, hence O(log(n))
if (len) ch += ch;
// `len` is 0, exit the loop
else break;
}
// pad `str`!
return pad + str;
}Re: Never use a dependency that you could replace with an afternoon of programming
#29This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…
> I can write a hashtable implementation in an afternoon, but it's going to have bugs If it has any bugs that would surface in a year of production (while the dependency version wouldn't) then you didn't write an equivalent in an afternoon. The advice, if it's to be useful at all, must be things that you could completely replace in the same quality, in an afternoon . It's the left-pads and is-odds, to begin with.
> that you could completely replace in the same quality
And the quality of the original might be questionable for many cases.
Re: Never use a dependency that you could replace with an afternoon of programming
#30This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…
> Worried about the dependency changing? Lock the version.
And get p0wned a year later when some security researcher finds a vulnerability in code that you don't even use, but pulled in as part of that dependency.