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

201–210 of 333 posts

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

#201

Post by idreyn »

A year ago I needed a min-heap to build a priority queue at work.

So first I grabbed 'heap' from npm (272k weekly downloads) and set it to work. But a few days later I realized my code was executing slower than expected because it sometimes needed to clone the data structure, and the clone instantiation would break the heap invariant in the array internals. It turned out there's been an issue open about this since early 2017.

Then I went for the 'collections' package (35k weekly downloads) and brought in its heap implementation. That worked like a charm for about six months until a bug came in that made it seem like a completely different package was breaking. After almost a whole day of debugging, it turns out that 'collections' silently shims the global Array.from function (scream emoji) without mimicking its behavior when dealing with non-Array iterables presented by the other package.

So finally I wrote my own heap -- well, I cribbed from Eloquent JavaScript [0] but I did have to briefly remember a little bit about how they're supposed to work. So while I don't totally buy the "Never..." rule in the post title, thinking more carefully about writing versus importing a dependency would have saved me a great deal of headache in this case.

[0] https://eloquentjavascript.net/1st_edition/appendix2.html

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

#202

Post by nothal »

jaggederest wrote: post #154
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…

core business = C outsource = O Object = x x ∉ C ↔ O(x) If the symbols don't show up: if-and-only-if x is not in C, O(x)

If I wanted to learn more about rigorous, non-elementary logic, do you have a recommended resource? I've taken a course in intro level probability theory which covered it generally and another course that built on it lightly but nothing rigorous and I am wooed by how concise things become in a logical form.

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

#203

Post by hinkley »

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…

Most of the people I find writing their on libraries are also the people that others avoid when they ask for help.

The support aspect of internal libraries, especially in the age of Stack Overflow, is widely overlooked by the very people who Must Be Stopped.

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

#204

Post by alephu5 »

rurp wrote: post #195

> Many times, the best approach is first searching online and reading the code to a few other solutions, then writing your own with the knowledge you’ve gained from seeing how they work. I think this is a great approach. Any general solution library will be much larger and more complex than one project's use case. Seeing how other people have solved a given problem can give a dev a nice jump start on creating a compa…

In my experience this is quite typical in the python community, I think it's a consequence of the batteries-included philosophy. Many people are very averse to using primitive data structures and operations to solve their problems, so working with a python codebase is like gluing libraries together

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

#205

Post by renewiltord »

nothal wrote: post #202
jaggederest wrote: post #154

Earlier quoted context omitted.

core business = C outsource = O Object = x x ∉ C ↔ O(x) If the symbols don't show up: if-and-only-if x is not in C, O(x)

If I wanted to learn more about rigorous, non-elementary logic, do you have a recommended resource? I've taken a course in intro level probability theory which covered it generally and another course that built on it lightly but nothing rigorous and I am wooed by how concise things become in a logical form.

A Tour Through Mathematical Logic. You don't have to do any proofs. If you learn Propositional Logic and First Order Logic you'll already have most of the tools to invent the rest.

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

#206

Post by akvadrako »

jaeming wrote: post #194

I once decided to write my own UI pagination component. I thought it would be fun and, why bring in a library for something so simple? Three years later, we now use this component for all our pagination. Probably four of us know it really well by now as it turns out, there have been many bugs around it. Turns out pagination was not such a trivial problem to solve when you consider all the edge-cases and crazy PM requ…

It does sound like you’re agreeing with the premise of the article.

Pagination is hard but it’s even harder to find a library that meets all your requirements and doesn’t have bugs.

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

#207

Post by nothal »

JackFr wrote: post #144
scarface74 wrote: post #131

Earlier quoted context omitted.

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…

I’ve worked with dozens of guys who loved to reinvent config and logging frameworks, because ... I don’t know why. I suppose because it was easier than working in the actual problem domain, which they knew little about and didn’t care to learn.

Herding devs to work on the boring-useful things instead of the interesting-solved things is slightly easier than herding cats.

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

#209

Post by loup-vaillant »

Those are reason why I like small "single" file libraries in C and C++ (one header, one source file): you know where the source code is, reviewing it is relatively painless, and adding it to your project is dead easy.

Yet I have seen people ignoring the benefits of a 2K lines dependency (in a single compilation unit), over an otherwise equivalent 20K lines dependency (in 100 compilation units) that requires the autotools. (The disadvantages of a particular lightweight dependency is a separate topic.)

You want your modules do be deep: minimum interface for maximum functionality. Dividing the size of an interface by 10 for the same functionality is a pretty sweet deal in most cases. In my opinion, that deal is often underrated.

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

#210

Post by pldr1234 »

Never take afternoon advice from a programmer about how to run a business.

Because at the end of the day, that's what team management and engineering teams are. Functional units of a business. And advice like the OP's will lead you to death by a million shed bikes.

But for side projects, sure, have fun with it.

Post reply on HN