Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never use a dependency that you could replace with an afternoon of programming

blog.carlmjohnson.net

Post reply on HN
Print view View original

101–110 of 333 posts

Re: Never use a dependency that you could replace with an afternoon of programming

#101

Post by hungry_haibt »

jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

Great rule. I was wondering, how do you manage updating the Jackson JSON parsing package. What if you have 100 such packages and they get updated weekly with breaking changes ?

Re: Never use a dependency that you could replace with an afternoon of programming

#102

Post by tluyben2 »

axlee wrote: post #28
tluyben2 wrote: post #18

Earlier 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…

Well, my point was more that if a programmer thinks '5 minutes work' it's often 10+ minutes; so when a programmer thinks 'an afternoon', you can possibly lose a week. And then the article really doesn't work.

And yeah, I would and do write leftpad myself it it's not in the stdlib. But if there is a large library full of similar (string) functions that I might need, I would include that library. Not a singular dependency for this type of function.

Re: Never use a dependency that you could replace with an afternoon of programming

#104

Post by drchiu »

I mean... this depends. I use Rails mostly in my work, and in recent years I’ve pared down the libraries I would use (ie. that will go into the Gemfile). I generally stay away from any other externalities beside this list of libraries, and so I make it so that they’re almost “my own.” Seems to be a good balance between getting too dependency dependent vs veering off to reinvent the wheel.

Re: Never use a dependency that you could replace with an afternoon of programming

#105

Post by vishnugupta »

Obviously each situation is unique, however, I’ve been burned more often by trying to clean up hand rolled out code than using a library.

I can recall quite a few instances where engineers, even experienced ones, went down this path ended up trying to reinvent such age old technologies as version control system, web server, just to name two.

Re: Never use a dependency that you could replace with an afternoon of programming

#106

Post by triceratops »

hungry_haibt wrote: post #101
jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

Great rule. I was wondering, how do you manage updating the Jackson JSON parsing package. What if you have 100 such packages and they get updated weekly with breaking changes ?

Update all your dependencies periodically - monthly, quarterly, whatever. Freeze dependencies in the meanwhile.

Re: Never use a dependency that you could replace with an afternoon of programming

#107

Post by nayuki »

jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

> don't use a dependency to implement your core business

In logic language, you're saying "If X is your core business, don't outsource X".

> Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who knows how to write a business case.

The rest of your argument is interpreted as "If X is not your core business, don't in-house X".

These two logical implication statements are not equivalents of each other, but are converses. Casual language often conflates If, Only-If, and If-And-Only-If.

Re: Never use a dependency that you could replace with an afternoon of programming

#108

Post by Ajedi32 »

ghj wrote: post #82
axlee wrote: post #28

Earlier quoted context omitted.

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…

This is so hilariously overengineered: not failing when passed the wrong types, arbitrarily caching padding of len The most egregious is the bad big O analysis for a pointless binary search. The loop does indeed run O(log(n)) times but `ch += ch` still takes O(ch.length) which is growing exponentially. It ends up being a complicated way of still taking O(n) time while creating a lot of intermediate strings. It isn't…

Did you run benchmarks to validate those assumptions? The developers of left-pad did: https://github.com/left-pad/left-pad/blob/master/perf/perf.j...

It's not overengineered if thousands of downstream projects are relying on it, some of which might see significant benefits from those performance optimizations.

Re: Never use a dependency that you could replace with an afternoon of programming

#109

Post by yoz-y »

lordnacho wrote: post #80
JadeNB wrote: post #69

Earlier quoted context omitted.

> a well known guy on SO wrote an answer that looks like a huge warning sign For those who are in today's 10000, you might mean this piece of art: https://stackoverflow.com/questions/1732348/regex-match-open...

That's exactly it! Luckily I hadn't started coding when I found it.

The old classic. I still end up using regexes when I need to clean up HTML because even though it's not the right way, it's the way that is sufficient 95% of the time.

Re: Never use a dependency that you could replace with an afternoon of programming

#110

Post by MrStonedOne »

Dependencies are part of the same calculations that normal programming follows.

Easy to program vs Easy to maintain vs Easy to understand vs Easy to scale vs Easy for the cpu to do.

Dependencies are easy to program, you include them.

Dependencies are hard to maintain, in that you can't expand or change their behavior.

Dependencies can be either hard or easy to understand (compared to your own code).

Dependencies are hard to scale, something you coded yourself can avoid validating inputs that have already been validated, or otherwise be smarter about how it does things to avoid overhead.

(one example would be a system for parsing info from a large amount of data, most dependencies will make you either store it all in one place on disk or memory, where a custom solution can more easily stream it to avoid memory or disk overhead. (take a ftp server that wants to calculate and store 5 hashes for each of the files uploaded, it can either have 5 libraries each read the file after upload, or it can load the entire file back into memory after upload or it could just stream the info to 5 custom rolled hashing systems that handle calculating the data as its being uploaded and written without needing to re-read it from disk after upload. one will be faster and scale better.))

So half the articles about dependencies on hacker news can be broken down to one message:

Don't use a dependency when rolling it yourself is better for your use case.

The other half are about conveying why and when rolling it yourself can give you benefits for your use case.

Post reply on HN