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

221–230 of 333 posts

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

#221

Post by nayuki »

soedirgo wrote: post #193
nayuki wrote: post #107

Earlier quoted context omitted.

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

Since we're in pedanticville, these aren't converses, but inverses. The converse goes "If you don't outsource X, then X is your core business".

Thanks, you are right. A converse is logically equivalent to an inverse, so I'm only half wrong. =)

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

#222

Post by klyrs »

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 do this all the time. My head tells me "five lines, tops" -- corresponding to about 10 minutes of "programming." Add in testing, bugs, another 10-20 lines of comments and docs, we're looking at an afternoon.

Never do I give that raw 10-minute estimate to anybody, because it can be wrong by a factor of 10.

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

#223

Post by methodin »

Time it takes to build something is not even remotely the best metric for value or ease. Programming is never a box and things that took one afternoon to write at first could be thousands of lines long a year from now. To me this is as horrible as advice as it is to use dependencies for everything.

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

#224

Post by dogma1138 »

fernandotakai wrote: post #161
dogma1138 wrote: post #148

Earlier quoted context omitted.

And what happens when your parsing needs to be expanded?

taking in consideration how business work, in a few years you are going to have a full parser in your hands.

With all the technical debt associated with it, which is the problem basing your project on a dependency that would allow you to easily scale and add features is a huge benefit.

This is like saying you should roll your own crypto because you only need to do a very limited sub set of crypto operations so why use something like NaCl or Tink.

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

#225

Post by flukus »

aliceryhl wrote: post #81
xamuel wrote: post #67

Earlier quoted context omitted.

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

And it's going to take more than an afternoon to evaluate these parsers. You have to look at the options, evaluate the API, evaluate if they're stable and supported, evaluate if they integrate well with you're project, evaluate any dependencies they might have, etc. Then you need a plan to manage these dependencies long term.

If you're needs can be solved adequately by strtok then that's a far simpler and more maintainable solution that can be knocked out in an afternoon.

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

#226

Post by dogma1138 »

Ma8ee wrote: post #167
dogma1138 wrote: post #148

Earlier quoted context omitted.

And what happens when your parsing needs to be expanded?

Then you reevaluate the situation. YAGNI is true here too.

YANGI is nice but when the PM asks you why it would take two months to accept a new JSON format from a client and you’ll answer well because we didn’t want to use an industry standard fully functional and vetted JSON parser so we essentially wrote our own edge case parser we both know how that conversation will end.

And YANGI doesn’t have anything against dependencies.

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

#227

Post by TheDong »

scarface74 wrote: post #213
TheDong wrote: post #151

Earlier quoted context omitted.

> I don’t have to care about how the underlying libraries work. I can treat them as a black box. When I wrote haskell, the majority of the libraries did just work, and I didn't have to dig into their code to find bugs often. When I wrote javascript, hundreds of the libraries I used did not just work. I usually had to care very much about their details because they were poorly implemented, full of bugs and incorrect a…

That’s also why I stay away from the clusterf%%% of front end development and JS if possible except for simple AWS Lambda scripts that have one dependency - AWS SDK. Any other scripting I do with Python. Any more complicated development it’s using a language with an ecosystem with adults - C# or Go.

Kinda ironic that you say "More generic is better" a few comments above, and then also cite Go in a positive light.

Rob pike espoused "A little copying is better than a little dependency", and go refuses to add suitable abstractions to build generic reusable pieces.

Go has a strong culture of doing exactly the sort of thing I was talking about, and you were arguing against.

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

#228

Post by sibane »

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?

It takes an afternoon to do after one week of research and exploratory coding.

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

#229

Post by nullc »

earthboundkid wrote: post #122

OP here: A lot of people are objecting, "What if you estimate wrong, and it takes more than an afternoon?" This objection is very bad. It is not possible to add a new dependency in less than afternoon because you need to evaluate alternatives, test it, learn how it works, make sure it's not accidentally GPL, etc. So there are not two methods, the less-than-an-afternoon method and the more-than-an-afternoon method. Th…

> But now you know what the dependency is really supposed to do and why it's non-trivial, so you're in an even better position to evaluate which ones are good.

I came in here to say this. If you think you're not qualified to write the function, you're probably also equally unqualified to choose someone else's implementation of it.

There is a lot of stuff out there-- stuff which is widely used-- which is not fit for your purposes, ... perhaps not for anyone's. And there is no replacement for a bit of domain expertise.

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

#230

Post by cogman10 »

ghj wrote: post #175
Ajedi32 wrote: post #169

Earlier quoted context omitted.

That would depend on the underlying implementation of the string object, no? (If the string is implemented as a linked list it's O(n)) Anyway, it makes no practical difference in this case, since the one they labeled "O(n)" is the naive implementation that most people would write if they implemented left-pad themselves.

I highly doubt js engines would compile a string down to a linked list. But you're right they might compile it to a circular buffer or deque which can have O(1) prepends. Quick googling shows that this optimization might exist but only for firefox and only if you use "unshift": https://lannonbr.com/blog/2020-01-27-shift-optimizations https://jandemooij.nl/blog/2017/12/06/some-spidermonkey-opti... But it's very unlike…

Depends on the form that `str = ch + str` takes inside the loop. But yeah, the way they wrote the code makes it less likely to work well.

    let padding = '';
    for (let i = 0; i
The above would probably get caught by the JIT and would essentially be optimized to what `ch.repeat(len) + str;` would do.
Post reply on HN