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

261–270 of 333 posts

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

#261

Post by jyunkess »

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…

That's true.

Beside _lifetime support_, working on that core business feature make us _understand_ deeply about the that feature.

I've seen people integrate dependency for their core business. It helped to get started fast, but will create a blockage that required understanding deeper to overcome

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

#262

Post by karmakaze »

scarface74 wrote: post #131
VHRanger wrote: post #75

Earlier quoted context omitted.

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…

I could say all of the same things about the in house tools that the “architect” wrote three jobs ago - including the bespoke ORM, object mapper, and logging framework. Or two jobs ago where two developers who had worked at the company for 10 and 15 years respectively were maintaining a bespoke 15 year old EHR written in PowerBuilder and depended on SQL Server 2003 - in 2016. Every company thinks they are their own s…

Funny you should bring up these as examples. I've made (1) and (3) using an existing object mapper. They were made out of limitations with JPA/Hibernate and for higher-level functionality in logging. The ORM was never sent to prod. The logging events were gold. Specific events were 'major' and filtering on a user ID in a narrow timespan could show the expected/unexpected events for the traces as a sequence diagram through all the microservice layers. Clicking on an event then searched Loggly for all logs for trace-id at time. It got to the point that non-techs were answering customer issues with it and we hardly had to check/wait for Loggly to answer.

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

#263

Post by BenoitEssiambre »

Carmack weights in: https://twitter.com/ID_AA_Carmack/status/1293311943995002881

"This HN discussion https://news.ycombinator.com/item?id=24123878 is topical for me: at this very moment, I am implementing C++ MFCC code myself, because my attempt to integrate Kaldi (on windows) was unpleasant. It already took more than an afternoon, but I learned good things! \ I'm more sympathetic to the Use-All-The-Dependencies crowd than some might suppose. It definitely isn't my way, but I see them as a fellow subclass of programmer, evolved for other environments. It is amazing what can be cobbled together in a weekend now. \ The old Knuth vs McIlroy story is relevant: http://leancrew.com/all-this/2011/12/more-shell-less-egg/

Generally, use-the-tools is correct, but sometimes you really do want a Knuth (or maybe a Carmack)." "

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

#264

Post by andrewstuart »

BenoitEssiambre wrote: post #263

Carmack weights in: https://twitter.com/ID_AA_Carmack/status/1293311943995002881 "This HN discussion https://news.ycombinator.com/item?id=24123878 is topical for me: at this very moment, I am implementing C++ MFCC code myself, because my attempt to integrate Kaldi (on windows) was unpleasant. It already took more than an afternoon, but I learned good things! \ I'm more sympathetic to the Use-All-The-Dependencies crow…

When Carmack speaks it's worth listening to.

However in almost all cases, you - the reader - cannot achieve in an afternoon what Carmack can achieve in an afternoon.

Few developers have the ability to build an alternative to a speech recognition dependency.

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

#265

Post by nullc »

Shank wrote: post #253
nullc wrote: post #229

Earlier quoted context omitted.

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

Not a lot of people can correctly write cryptography code on the first try, but we definitely advocate for people pulling well known cryptography libraries and using them instead of building their own, for obvious reasons. Not many people are qualified to write a lot of things, but are capable of making sound dependency judgements with heuristics. The trick is to use good heuristics and to not use a library for every…

It's my experience that people very often do not make sound dependency judgements on cryptography dependencies.

They probably do better than writing it on their own, but that isn't necessarily saying much-- and I think the difference isn't actually that great (essentially the thing they pick will often tend to have same flaws as what they would have written, because essentially we're drawing from the same distribution).

I agree that heuristics could help but not much time is spent discovering and socializing what those are, particularly to the extent that they are domain specific.

Naive heuristics can also backfire. E.g. it can be easy to mistake contentious behaviour with flaws and end up preferring code that has absolutely zero mitigations against an attack over code that discloses the limitations of their mitigations.

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

#266

Post by jdmichal »

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

I agree with this statement also. By writing code to do JSON parsing, JSON parsing is now part of your business.

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

#267

Post by kseifried »

Dunning-Kreuger, the long and short of it is many problem appear "simple" and take an afternoon.. right? For something that converts a date from ISO format to American (M-D-Y) sure it might be simple, but anything that listens or talks to the network (DNS? APIs? etc.) I guarantee you didn't think of all the corner cases.

Also all those afternoons add up.

Also the comment "You’ll know exactly how it works and what its shortcomings are."

Hahahahaha. no. If that was true bugs wouldn't be a thing.

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

#268

Post by cellular »

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…

But "it's a good problem to have"!

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

#269

Post by unishark »

mcqueenjordan wrote: post #5

Avoiding dependencies is a noble goal, and something to be valued, but this simple rule is too simplistic. The problem lies in the fact that there are a great many things I can hack together in an afternoon to "replace" some kind of external dependency, but the quality discrepancy of these hacks is highly variant. My understanding of what can or should be done in an afternoon might differ with my colleagues'. Unfortu…

> The problem lies in the fact that there are a great many things I can hack together in an afternoon to "replace" some kind of external dependency, but the quality discrepancy of these hacks is highly variant.

Perhaps it's a domain-specific thing, but when someone uses the words "hack together" I imagine it means using dependencies without really understanding what's going on in them, precisely to avoid figuring out how to code a solution properly.

Writing it yourself obviously needs to also imply doing it correctly. Even if that means you must learn a bit about what is the right way to do it (a side benefit, though usually viewed as a downside).

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

#270

Post by AtlasBarfed »

moron4hire wrote: post #240

Especially when it comes to JavaScript, I tend to follow "never use a dependency that you could replace in a month ". Here is something that has happened to me more times than I care to count: I have a dependency on some library. It's working well for me. I build some sort of small project with it, like the info website for my mother's business. Doesn't need to be updated very often, just needs to be there and have h…

JavaScript, capitalizing the W in "worse is better".
Post reply on HN