Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kill Your Dependencies

mikeperham.com

Post reply on HN
Print view View original

21–30 of 229 posts

Re: Kill Your Dependencies

#21

Post by jvehent »

pcwalton wrote: post #14

A lot of apps (old-timey Windows apps, for example) have this philosophy, leading them to reinvent things like crypto and image decoding. Naturally, this leads to tons of bugs, including security bugs. I would revise this to: Don't bring in more code than you need. But if the choice is between writing something yourself and using someone else's well-tested, heavily-used library, always go for the latter.

This is pretty much what Rob Pike advocates in Go: "A little copying is better than a little dependency." http://go-proverbs.github.io/

Re: Kill Your Dependencies

#22

Post by jeffdavis »

Your app/library inherits the technical debt of all its dependencies.

There's a natural tension between code reuse and avoiding dependencies. If you can avoid a big dependency by writing a couple hundred lines of low-maintenance code, its probably worth it.

Re: Kill Your Dependencies

#23

Post by mbrock »

gravypod wrote: post #18

Yes, this is the sort of thing that scares me away from Ruby. I'm worried this sort of "screw it just add a library" is going to spread further in my language of choice: Java. In my time doing open source programming on the side, I've found that it has become more common with the advent of things like mvn and gradle to just slather on layers to your stack even for the simple tasks. Need a function to turn a byte buff…

There are ideas floating around that make it appealing to do just that. For example, the commons library might be considered "battle-tested," and who really knows what could happen with your own custom byte-buffer-to-string function? Maybe you missed something? Maybe there is some "best practice" that you didn't follow? Maybe the commons library is optimized? And writing your own thing doesn't add business value. Developer time is more expensive than dependencies. And so on.

Me, I very often prefer to write things myself, in a way that can get labelled as NIH. My inclination is based on bad experiences with trying to debug external libraries. Sometimes I look at open source library code and find staggering complexity that I have no need for. Yes, maybe the library is great, but if its combinatorial size is 10,000 times the functionality that we need, then depending on its correctness becomes scary to me. And when I need to customize it, due to some requirements alteration, I will find it difficult and tedious.

Black-box type libraries for isolated complicated tasks like codecs and crypto I will happily use.

Otherwise, I'm a fan of the "design patterns" approach to reuse, which is all about learning from others, but without creating reusable formal abstractions in library form. So if you teach me how to write an URL router, I can then use your insights without depending on your code base, and I can adapt the idea so it fits my application perfectly.

Re: Kill Your Dependencies

#24

Post by jerf »

brightball wrote: post #16

This should be one of the perks of Go since the compiler won't let you include anything that you aren't using.

That's an orthogonal issue. You won't accidentally bring in something completely unrelated because you forgot to remove it from the "include"s, but nothing technically stops you from having a deep dependency chain. Culturally the Go community is aware of the issue, though.

Still, it isn't hard to bring in a chain accidentally. I have a program than needs to do a query against the local LDAP system to extract members of a specified group. The LDAP library brings in five more libraries for parsing all the various bits of LDAP. Since this isn't C, I'm a bit less nervous about pulling in, say, a BER decoding library, because at least Go is generally memory-safe, but, still, that's a somewhat large stack for such a simple query. (Traditionally in C, you might as well just expect any library that decodes anything remotely binary-esque will have buffer overflows. C is a DSL for writing buffer overflows.)

And yet, I'd be insane to try to implement some sort of just-barely-minimal LDAP client to do it myself.

Looking at my local godoc instance's full set of packages that have gotten pulled in one way or another is still sort of intimidating. Some of them are cases where I'm just pulling in a subdir and got an entire large repo (the golang experimental repos do that a lot), but, still, I've got a lot of stuff in there. If you're a go programmer and you haven't run godoc locally and had a look at the packages page, have a look. You may be surprised.

Re: Kill Your Dependencies

#25

Post by BinaryIdiot »

This is a great read that can be applied to node.js very much. I've seen apps that include 10, maybe 20 dependencies but when you flatten out the full dependency tree? Thousands. It's incredible and if one of those dependencies screws up semantic versioning or just screws up in general it can be a nightmare to debug and fix.

This is why every 1.0 product I work on I include every dependency that speeds up my development. In 2.0 the first things to do is prune all unnecessary dependencies and start minor rewrites when a dependency can be done in house (yeah yeah reinventing the wheel is a problem but most npm dependencies are small and many can be recreated internally without issue).

This is even more important if you're creating a library / module. My msngr.js library uses zero dependencies and yet can make http calls in node and the browser because it was easy to implement the minimal solution I needed without bringing in dependencies to support a single way of calling http.

Re: Kill Your Dependencies

#26

Post by sksixk »

what's the point? none of them are realistic.

"no code" - well, it's there for a reason. "own it" - do i really want to write my own minimal implementation?

i understand that dependency is a pita but this post doesn't provide anything worthwhile.

Re: Kill Your Dependencies

#27

Post by jowiar »

I find dependencies to be a very good indicator for how my code should be modularized. That is, rather than pulling a boatload of dependencies into "the application", pull a couple dependencies into a module, and then depend on the module. It makes it very easy for dependencies to be a "well, it gets the job done for now, and I can reimplement that myself if that changes" sort of thing.

Re: Kill Your Dependencies

#28

Post by laumars »

This article would be more accurately written as "prefer the standard library over 3rd party solutions" since all the examples given still required dependencies, but ones that are shipped as part of the language runtime (Ruby in this case).

However when discussing languages with no specific standard library or languages who's standard library is missing feature y, then it's quite understandable to use a 3rd party battle tested dependency. In fact I'd go further and say it would be advisable to use a respected 3rd party library when dealing with code which handles security or other complex concepts with high failure rates.

Re: Kill Your Dependencies

#29

Post by bpicolo »

yoz-y wrote: post #8

> No code runs faster than no code. > No code has fewer bugs than no code. > No code uses less memory than no code. > No code is easier to understand than no code. The dependencies you decide to implement yourself in a minimal fashion are code though. I generally agree with the article, but in the end It Depends™

And are generally worse tested, worse supported, and you have to maintain it on your own

Re: Kill Your Dependencies

#30

Post by falcolas »

ninjakeyboard wrote: post #9

I'm not 100% sure I agree with this as stated. Sure if the functionality is in core lib, use it but... it depends... Consider these three statements: - No code runs faster than no code. - No code has fewer bugs than no code. - No code is easier to understand than no code. For a language like scala where there is no json processing in the standard lib, if there is a json library that is battle tested, then by removing…

> ... I've removed a whole bunch of code from my own library

You removed a bunch of code you understood, and added a bunch more code you don't understand, along with whatever technical debt, edge cases, and performance issues which are lingering in that library.

Adding a library is never removing code from your project, it's adding code you don't yet understand to your project. It can still be a net win, but it's not less code for you to maintain.

Post reply on HN