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

71–80 of 229 posts

Re: Kill Your Dependencies

#71

Post by [deleted] »

amelius wrote: post #34
edgyswingset wrote: post #20

Earlier quoted context omitted.

> Don't bring in more code than you need. I see it as a sliding scale. If I'm parsing 1 string with the same date format into 1 object, I'm not going to pull in some general purpose time parsing library - I'll write the 10 lines of code myself, a few unit tests, and be happy. If in the future I start having to deal with different date strings and some need to do more than just throw up a single date on a page somewhe…

You could also use the third party library for your unit tests.

[deleted]

Re: Kill Your Dependencies

#72

Post by nickpsecurity »

ktRolster wrote: post #43
pcwalton wrote: post #39

Earlier quoted context omitted.

I pretty squarely disagree with Rob Pike on that one. Copying is how you introduce bugs and insulate yourself from upstream bugfixes. I'm suggesting that you should try to remove code first, add a dependency on well-trusted code if that doesn't work, and only copy/reinvent as a last resort.

> I pretty squarely disagree with Rob Pike on that one. TBH that's kind of an indication that you should rethink your position. Rob Pike has a lot of experience, he's seen a lot, and he knows what he's doing. I'm not saying you're wrong, just that you shouldn't snap to the defensive position.

For me, that means I listen carefully for wisdom but have to speak louder when countering their occasional bullshit. Copying is considered a code smell by the likes of Fowler due to the problems it leads to. Also leads to bloat and performance issues. Better to cleanly, simply package up reusable solutions to problems like JSON or protocols (eg HTTP) then just keep importing the same one. You get lean apps plus a greater understanding of what they're doing.

And so does the person you hire down the line to extend that app. Never forget that part when talking copying and tweaking code. :)

Re: Kill Your Dependencies

#73

Post by lotyrin »

surfmike wrote: post #56

if you're running multiple rails processes on a server like this, couldn't you somehow do the initialization in one process, then fork off the new processes? wouldn't that prevent the base libraries from being copied in memory?

Yes. Many app servers do this. (Not being super familiar with the Ruby ecosystem, I am not sure specifically which ones.)

Re: Kill Your Dependencies

#74

Post by nickpsecurity »

pcwalton wrote: post #51
maxxxxx wrote: post #44

Earlier quoted context omitted.

The keyword is "well-tested, heavily used library'. Especially in the web area I see a lot of imported libraries from github or wherever for doing simple things. In the end you end up with dozens of dependencies you don't know how and when to update. My rule of thumb is if the stuff we need can be reduced to a few functions, it's better to copy so you at least know which code you are using and don't have thousands of…

Copying doesn't make anything better; it just insulates you from upstream bug fixes. If copying is better than adding a line to your Gemfile or whatever, then that's a usability bug in your package manager. The entire reason for package managers' existence is to provide an easier-to-use, more reliable alternative to copying.

Thought they also eased deployment and updates.

Re: Kill Your Dependencies

#75

Post by pcwalton »

moron4hire wrote: post #69
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.

So many libraries in the wild aren't "well-tested, heavily used", though, and sometimes it is really hard to differentiate between popular and good. At the end of the day, the only person who is responsible for the quality of your proje t is you . You have to figure out which parts of your project are key to your operation and which are just window dressing. If your job is to make a blogging platform, I would expect…

> If a person was secure in their knowledge of their skills, their ability to understand problems and fix them, then there should be nothing to fear from a dozen or a million different libraries doing the same thing and running into one or two of them on one's next project.

I actually do fear a million reimplementations of, say, RSA.

Re: Kill Your Dependencies

#76

Post by Rafert »

Excellent article. I tried to develop on GitLab once but the sheer amount of gems it pulls in (~100 directly declared, 350+ including dependencies if I remember correctly) with a bunch of installation problems made me decide it was not worth the hassle.

Re: Kill Your Dependencies

#77

Post by jpulec »

skewart wrote: post #49
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.

"But if the choice is between writing something yourself and using someone else's well-tested, heavily-used library, always go for the latter." Absolutely. However, there are plenty of situations where what you pull down from npm or rubygems isn't actually all that well-written or well-tested. When I first started programming I kind of had this impression that if an open source library is published on a package repo…

I feel like I relearn this lesson at least once a month.

Re: Kill Your Dependencies

#78

Post by gravypod »

mbrock wrote: post #23
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. Dev…

I agree completely. I'm not the one who will sit down and attempt to implement my own RSA, or hashing algorithms.

It's like pornography. I don't know how to define it, but I definitely know when I see it.

There are correct times to use libraries. But pulling a 15meg for some simple functionality is not a good practice in my opinion.

Re: Kill Your Dependencies

#79

Post by skewart »

ktRolster wrote: post #37
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.

As an architect, you need to be able to do a cost/benefit analysis of each option. That is what software architects do, why they have experience. For example: How much time will it take to implement each option? How much time will it take in the future to support it? What security risk does each option incur? What is the risk of the project being abandoned? What is the risk of the project changing in non-backwards co…

One thing I've gotten into the habit of doing is looking around the commit history and issue list for any package I import. Was it something somebody wrote in a hurry and hasn't really touched since? Is it something that has a solid set of regular contributors? Are there a lot of outstanding issues relative to how heavily used it is?

I also spend more time actually reading through specs to see how well they exercise the code.

That's probably standard procedure for a lot of people, but it's something that I had to learn to always do.

Re: Kill Your Dependencies

#80

Post by 15155 »

ktRolster wrote: post #43
pcwalton wrote: post #39

Earlier quoted context omitted.

I pretty squarely disagree with Rob Pike on that one. Copying is how you introduce bugs and insulate yourself from upstream bugfixes. I'm suggesting that you should try to remove code first, add a dependency on well-trusted code if that doesn't work, and only copy/reinvent as a last resort.

> I pretty squarely disagree with Rob Pike on that one. TBH that's kind of an indication that you should rethink your position. Rob Pike has a lot of experience, he's seen a lot, and he knows what he's doing. I'm not saying you're wrong, just that you shouldn't snap to the defensive position.

An appeal to authority? To Patrick Walton?
Post reply on HN