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

61–70 of 333 posts

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

#61

Post by goldenkey »

cogman10 wrote: post #53
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 actually a great example of why you SHOULDN'T use left pad. I've not profiled it, but I'm going to guess that now-a-days this will be faster than the current implementation on npm. function leftPad (str, len, ch) { str += ''; len = len - str.length; if (len Why? because the VM is (very likely) going to do exactly what the cache would have done. It can replace `ch.repeat(len) + str;` with a presized string all…

This code checks for ch !== 0, yet the bypass branch afterwards calls .repeat. The Number type in JS has no repeat method.

Static typing would actually fix this kind of coding error.

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

#62

Post by reificator »

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…

Yes, particularly when you know the types that will be passed in. True that typechecking in JS can be a little timeconsuming, so it might take 10-15 for me to write a general purpose left pad.

Also I seem to remember that someone benchmarked the cached version and found it to be slower than the naive approach anyway. I could be mistaken there.

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

#63

Post by gm »

No. Some reasons:

1) As everyone else has said, we are horrible at estimating.

2) We think we might only need 1% of an external dependency, until we do not. Case in point: By this criteria, no one needs a grid/datatable library.So we write it "in an afternoon". Then we're asked for an export to Excel. Later on we're asked for pagination with large data sets. And then an export to PDF. How many afternoons did that cost you?

3) Writing new code is an excellent opportunity to create new bugs and implement bad design because we're on hurry since it took nowhere near an afternoon of code to write and we cut corners.

Anyway, those are just three that come to mind immediately.

This is not an argument against the "afternoon rule", but is really an argument against making simple-sounding black and white rules to solve to problems that are inherently complex, and are thus, gray areas.

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

#64

Post by avmich »

andrewstuart wrote: post #36
sparker72678 wrote: post #14

Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?

I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…

> you absolutely should use every dependency you can that will save you time

> Find a dependency that will save you an afternoon? Grab it.

Agree. The point of the article, though, is that dependencies are often saving much less time than they promise - so much less that it's better to avoid them.

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

#65

Post by microcolonel »

cogman10 wrote: post #53
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 actually a great example of why you SHOULDN'T use left pad. I've not profiled it, but I'm going to guess that now-a-days this will be faster than the current implementation on npm. function leftPad (str, len, ch) { str += ''; len = len - str.length; if (len Why? because the VM is (very likely) going to do exactly what the cache would have done. It can replace `ch.repeat(len) + str;` with a presized string all…

What magic would enable that? I don't think the VM is likely to cache a string of 6 spaces, it has no way of knowing that would be a common parameter, and no heuristic to determine that it's likely.

It may specialize or inline, but that's a separate matter.

P.S. I think there's a bug here.

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

#66

Post by jamil7 »

moltar wrote: post #24

Never use store-bought bricks if you can replace them with an afternoon of brick making. https://youtu.be/D59v74k5flU

I knew which video it would be before clicking... But to your point they're often not really "store-bought" bricks though. More like bricks someone was giving away on the side of the road, you're free to use them to build your house but with no guarantees they work and the instructions are missing or incomplete. Oh and they're the wrong shaped brick but you only figure that out later.

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

#67

Post by xamuel »

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…

Well, one special edge-case would be where you only need to parse some extremely tiny subset of JSON (for example: you only need to parse dictionaries whose keys and values are positive integers, like {1:2,3:4}). Then, depending how expensive the full json parser is, it might be worth your while just writing the limited parser yourself.

Of course, you might say, inevitably feature-creep will expand the list of things your parser needs to parse, but that's not a law of physics. Sometimes in certain limited, well-defined projects, it really is true that YAGNI.

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

#68

Post by ori_b »

andrewstuart wrote: post #36
sparker72678 wrote: post #14

Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?

I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…

And when you run into a bug or design problem in a dependency of a dependency of a dependency?

It often takes less time to write some code than to understand someone else's code.

Most programmers I've worked with get lost easily when jumping through layers of other people's code. I certainly do.

Solid, well tested dependencies that solve hard problems are worthwhile. But dependencies have a cost in debuggability and maintenance, so it's worth using them with care. And often, they aren't worth the time, when compared to writing a dozen lines of code.

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

#69

Post by JadeNB »

lordnacho wrote: post #44

It'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. S…

> 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...

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

#70

Post by kjeetgill »

andrewstuart wrote: post #36
sparker72678 wrote: post #14

Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?

I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…

While I agree that if you think it'll just take an afternoon, for the sake of this article it had better!

But conceding that charitable assumption to the article, I agree with its basic premise: dependencies cost a lot of time in diffuse, non-codey ways.

There are AAA dependencies you pull into every project, but most other dependencies require a good degree of due diligence, evaluation, risk, and their own long-term maintainance.

Its not that it always tips the scales all the way to 'roll your own', but I think the cost of new dependencies is underrated.

Post reply on HN