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

81–90 of 333 posts

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

#81

Post by aliceryhl »

xamuel wrote: post #67
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…

There are fully correct JSON parsers you aren't going to beat, even if you implement a subset. [1]

[1]: https://branchfree.org/2019/02/25/paper-parsing-gigabytes-of...

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

#82

Post by ghj »

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…

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 any faster than just creating the padding with a loop or `new Array(len).fill(ch).join('')` or `ch.repeat(len)`

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

#83

Post by nomel »

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

> "This'll take an afternoon" - three weeks later...... > Programmers are notorious for this.

From my experience with these personal failings, the problem usually comes from the question being phrased in the context like, "before you begin working on this, how long do you think this will this take you to complete?". If there's no opportunity to scope, with requires not insignificant work towards the solution, the estimates will always be wrong. If I understand the actual scope of the problem, which means have the architecture mostly worked out, and have a bit of experience (and luck), my estimates can be pretty close, usually eaten up by that oh-so-seductive feature creep that ruins my work file balance.

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

#84

Post by andrewstuart »

VHRanger wrote: post #75
andrewstuart wrote: post #36

Earlier quoted context omitted.

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

Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one…

>> Found the NPM user.

Ya got me ... pypi, crates, NPM, gems, cpan I'll use em all! Shhhh.... if my employer finds out they'll fire me.

:-)

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

#85

Post by xxs »

jasonpeacock wrote: post #6

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

> This is horrible advice. There's a reason that you don't write your own hashtable implementations.

Of course you do and release(d) them as open source (public domain). Take Java - it has decent a HashMap but it's node based. It's memory inefficient to a point its nodes and arrays are top 3 of memory consumption. An array based hashtable takes around 3.6 times less memory for larger ones (on 4bytes compressed pointers) and over 10 times less for smaller ones. Perf. wise it's on par or better as well (nowadays architecture is heavily driven by locality and access patterns)

Also you make your code so it can switch between both on the fly, if need be.

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

#87

Post by SavageBeast »

Never having thought about it before, I realize I usually go the opposite way. By writing about a days worth of code on something - if only to realize its true scope - then going in search of a lib of some kind to handle the dirty bits.

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

#88

Post by nitwit005 »

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?

You can tell it won't take just an afternoon 30-60 minutes in.

Besides, in reality pulling in and using the dependency takes time as well. There's no real guarantee it's cheaper in terms of developer time.

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

#89

Post by Izkata »

xamuel wrote: post #67
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 example is more apt than intended: That's not valid json, which only allows string keys. If you use a library it'll either barf now or later when they fix it, so if you're forced to work with an API like that and can't change it, a custom parser is really the only way to go.

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

#90

Post by cogman10 »

reificator wrote: post #77
goldenkey wrote: post #61

Earlier quoted context omitted.

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.

> This code checks for ch !== 0, yet the Number type in JS has no repeat method. > Static typing would actually fix this kind of coding error. That's not a coding error, that's addressing an oddity of JS coercion rules that a less experienced developer could easily have missed. > if (!ch && ch !== 0) ch = ' ' That code says that if `ch` is falsey and not equal to 0, then set it to a space. The only arguable falsey va…

FYI, I edited the post after the bug was pointed out to eliminate it and bring this method up to parity with leftpad.
Post reply on HN