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

311–320 of 333 posts

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

#311

Post by rini17 »

acdha wrote: post #22
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?

That was my first thought: I've seen these projects before — they're where you find 5 slightly different implementations of similar logic, no logging or tests, failures as soon as someone uses Unicode, etc. and I get an order of magnitude performance improvement by replacing that code with an external module which has had the other 19 afternoons' worth of work it actually takes.

But that is with ample benefit of hindsight.

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

#312

Post by benibela »

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…

I needed a hashmap in FreePascal

I probably spend almost 2 months evaluating hashmaps.

There are a dozen separate maps in FreePascal standard library. But they all have some issues. Like a max key length of 255 chars, only working with orderable keys, not rehashing itself, treemap instead of a hashmap, or actually not working...

In the end I used a map from another library and modified it heavily. It also has a big issue of not really deleting items, only keeping a tombstone that is not removed until rehashing, but the advantage is that it keeps insertion order

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

#313

Post by therealdrag0 »

ChrisMarshallNY wrote: post #189

I tend to avoid dependencies, if at all possible. I wouldn't mind spending a week of programming to avoid some dependencies. Of course, there is no "one size fits all" rule, here. If it's a "one-off" internal tool, without much impact, then it would not be worth spending much time on, and a dependency might be exactly the right thing (famous last words). I'm pretty obsessive about quality, and like to ensure the best…

That's interesting. Kudos for your craftsmanship.

IME those who write code instead of using a dependency are those who DON'T seem to care about quality. They can't be bothered to see if the problem is already solved. They can't be bothered to design a good interface and extract the code into a re-usable module. Just just solve their own immediate problem, which then gets re-solved in different ways a dozen times in different projects in the company. This is what I find frustrating and what I find 3rd party dependencies protect against. They define a set of culturally accepted/known APIs/Functionality that is consistent and doesn't have to be relearned between repositories.

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

#314

Post by parliament32 »

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…

Everyone who's used NPM in production for a not-insignificant amount of time has realized just how bad nodejs dependency hell can be. Unfortunately, webdev-du-jour has decided pulling in a hundred npm packages is better than writing a few hundred lines of code.

I keep hoping things like [1] are a joke but I'm starting to suspect they're not.

[1]https://www.npmjs.com/package/is-odd

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

#315

Post by cjaybo »

Ajedi32 wrote: post #147
cogman10 wrote: post #132

Earlier quoted context omitted.

Too bad that's a flawed benchmarking methodolgy. JITs are notoriously hard to correctly profile and the benchmark lib isn't even sort of doing the right thing. For example, it's missing warmup. The results aren't being consumed in a way that wouldn't optimize them away. The framework itself imposes a pretty large amount of overhead (moreso than I'd expect from leftpad). It is somewhat likely that what they are measur…

Yeah benchmarks can be much more difficult to get right than it might seem at first glance. Good thing they didn't try to write their own benchmarking code, otherwise they might have fallen into those traps you just mentioned. Luckily, they didn't, and instead pulled in the the `benchmark` library as a development dependency. The author of said library works on V8, and already considered all those problems and much,…

> Luckily, they didn't, and instead pulled in the the `benchmark` library as a development dependency. The author of said library works on V8, and already considered all those problems and much, much, more[1].

This is the "benchmark lib" that was mentioned in the very first sentece of the comment you replied to.

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

#316

Post by ChrisMarshallNY »

therealdrag0 wrote: post #313
ChrisMarshallNY wrote: post #189

I tend to avoid dependencies, if at all possible. I wouldn't mind spending a week of programming to avoid some dependencies. Of course, there is no "one size fits all" rule, here. If it's a "one-off" internal tool, without much impact, then it would not be worth spending much time on, and a dependency might be exactly the right thing (famous last words). I'm pretty obsessive about quality, and like to ensure the best…

That's interesting. Kudos for your craftsmanship. IME those who write code instead of using a dependency are those who DON'T seem to care about quality. They can't be bothered to see if the problem is already solved. They can't be bothered to design a good interface and extract the code into a re-usable module. Just just solve their own immediate problem, which then gets re-solved in different ways a dozen times in d…

In my experience, I have seen some Jurassic-scale disasters, because of poor dependency choices.

I think a lot of people just google for dependencies, and then add the first one that has a slick Web site, without thinking much about the code they are adding.

I am not a "never dependency" person, but I am anal about quality. Totally obsessed. I feel that quality is something that many, many programmers eschew, in favor of bling and buzzwords.

For me, I won't put my seal on something until I have tested it six ways to Sunday. In some cases, it may be unit tests, but, more often, it is a test harness, which can be a much more ambitious project than a few XCTests[0]. In fact, I am running into a lot of folks that don't know what a test harness is; which is jaw-dropping.

Since I do a lot of device control stuff, unit tests are not particularly useful. In order to create unit tests that would be effective, I'd need to design a huge mock, and that would not be worth it; likely introducing more problems than it solves.

An example is that I am currently developing a cross [Apple] platform Bluetooth LE Central abstraction driver[1]. This needs to have test harnesses in all the target systems (iOS/iPadOS, MacOS, WatchOS and TVOS). I actually have it driving a released app[2] (which is really just a "productized" implementation of the iOS test harness), but I do not consider the module ready for release, as I have not completed all of the test harnesses. I am in the middle of the WatchOS harness now. I may "productize" the MacOS test harness. My test harnesses are really serious bits of code. Complete, ready-to-ship apps, for the most part. Going from a test harness to a shipping app isn't a big deal.

[0] https://medium.com/chrismarshallny/testing-harness-vs-unit-4...

[1] https://github.com/RiftValleySoftware/RVS_BlueThoth

[2] https://apps.apple.com/us/app/blue-van-clef/id1511428132

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

#317

Post by hungry_haibt »

Floegipoky wrote: post #146
hungry_haibt wrote: post #101

Earlier quoted context omitted.

Great rule. I was wondering, how do you manage updating the Jackson JSON parsing package. What if you have 100 such packages and they get updated weekly with breaking changes ?

> What if you have 100 such packages and they get updated weekly with breaking changes? The solution to that is simple, stop using node.js ;)

Only good solution in this thread :)

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

#318

Post by Domenic_S »

layoutIfNeeded wrote: post #192
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.

String implemented as a linked list. You’re a webdev aren’t you?

Haskell's default String implementation is a linked list; no need for the snark

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

#319

Post by benibela »

Ma8ee wrote: post #140
aliceryhl wrote: post #81

Earlier quoted context omitted.

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

No, I won't beat them. But if it a limited subset that I can implement with twenty lines straightforward code, that will often be cheaper. I've been on projects where they imported xml-parsers many times bigger than the rest of the whole codebase just to send a well formatted order number.

xml and json are different beasts

A json parser can probably be implemented in an afternoon. But a conformant xml parser can take months.

There are some weird things in xml, for example, this is correct xml:

    ]]]>>?>]>>?>
And for external entities, you need an http client in the xml parser, although it is probably better to not support that part of the standard.

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

#320

Post by benibela »

greggman3 wrote: post #143
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 really depends (haha) on what it is. I needed to copy a file in npm scripts. can't use `cp` because that fails on windows. I looked on npm to copy a file. First hit 197 dependencies, 1170 files, 47000 lines of JavaScript. all I needed was const fs = require('fs'); fs.copyFileSync(process.argv(2), process.args[3]); Taking 197 dependencies means 197 things that need updates several times a year at a minimum. Any of…

Copying a file is really hard to implement

Lots of things can go wrong when writing a file: https://danluu.com/deconstruct-files/

Post reply on HN