Hacker News Reader

Comment by forgotmypw17 | Hacker News Reader

I avoid using third-party libraries for anything I can write myself.

1) I generally only need 10% of the library's functionality, and the rest is just extra weight.

2) I don't want to have to choose between freezing an old version of a library or having to update my code to integrate a new version.

3) For things that are not cryptography, I can usually write it better myself.

4) Third-party libraries typically do not prioritize accessibility or compatibility nearly as much as I do.

5) I have a much better sense of what the code is doing this way.

Edit: As jedberg helpfully pointed out, this post is not advice, and not intended to be treated as such.

View on HN

You're either one of the best developers in the world, or you think you are. If the former, then your system works well. If the latter, well, I'm glad it's been working for you so far, but I suspect you'll have trouble down the road.

And if you don't, it sounds like you'll never get your flywheel going so that you can stop working or work on something else.

I'm mostly saying, to people reading this, it would probably be unwise to follow this advice.

I agree with jedberg. Please do not treat my post as advice. Nowhere did I state that it is intended as such.

> You're either one of the best developers in the world

I'd say this is the approach used by anyone in the top 5% (give or take). Which is probably most of HN. You don't need to be Linus or Fabrice or DJB to know most programmers are bad at programming and realise you can do a better job.

Does that mean he writes his own kernel and C compiler? No, OP writes:

> I avoid using third-party libraries for anything I can write myself.

Which shows awareness of his current limits, another trait of good programmers.

I disagree. The more dependencies I remove, the less of a maintenance burden the code I maintain is. I am maintaining very large scale C++ code used in production every day by large multi-national companies. And have almost zero maintenance work.

> 3) For things that are not cryptography, I can usually write it better myself.

We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.

> 5) I have a much better sense of what the code is doing this way.

This is not scalable.

> I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.

Through practice.

But also, through realizing that when you look closely, many libraries are crap inside.

> This is not scalable.

I specialize in things which do not scale.

This feels to me like one of those "you have to learn these lessons to know how / when / why to apply the skill" types of things.

To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.

The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.

> To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.

This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable.

You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc.

One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.

To add to the list of red flags are libraries which expect me to write callbacks and which don’t give me any control over the control flow in my program. A lot of messaging systems like QPID Proton do this. It’s like the developers couldn’t anticipate that I might want to wait on input from more than one file descriptor so they didn’t bother to build input handling separately from the core protocol that processes the input and yields state changes. I see an awful lot of crappy libraries that follow this pattern. It’s typified by a function or functions that take a file name or url and that expects you to register callbacks for everything. Typically they spawn tons of threads to interleave input. Then you have to poll with timers in a separate thread if you ever want to respond to input from eg a serial port alongside messages. It’s way more complicated than it needs to be.

> We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.

It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News.

Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.

i don't think anyone is arguing for one liner dependencies here.

You're imagining you can get away with not understanding the third party code at all. That's never worked.

You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance.

And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.

> And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.

Fix them, I imagine. Which is easier if you're better at writing code than the author of whatever someone threw on (package manager of choice).

Can you give more details about what you work on? Would you try to write something like libjpeg or sqlite3 yourself, or are those foundational libraries exceptions? If you're a web and/or application developer, do you implement your own frameworks?

libjpeg? Absolutely, it’s not that difficult if you read the spec and can do a bit of math. sqlite3? No, DBs do nasty things with filesystems and I would rather just rely on them to get it right.

Libraries like libjpeg solve one non-trivial problem and have been around forever and don't change very quickly. An implementation can be done by hand but it usually doesn't make sense to do so because the library has been around and stable long enough to be able to presume that it does it in a more performant way and is aware of possible gotchas that it avoids. A database is a large enough project that writing one every time you need one doesn't make any sense. It's probably more work than whatever you are working on. Using one that has been around for a while and that doesn't change quickly makes sense.

Grabbing a quick javascript library to do something relatively trivial that is going to bring in megabytes of supporting libraries whose provenance is unknown and that change often is a completely different matter.

I've worked for you!

I worked at a Java shop where they built their own "ORM." I use that term loosely. I showed up there about 4 years after this decision and was amazed by the WTFs I saw. Example: They weren't using prepared statements. Instead, they had some half baked escaping system that would occasionally trigger syntax errors in production.

Reply on news.ycombinator.com