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

181–190 of 229 posts

Re: Kill Your Dependencies

#181

Post by babebridou »

LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

The idea in the OP is that if you're going to use the Amen Break, don't require "Hiphop-all", "Breakbeat-all" or, hell, if we're going by some of the Wikipedia examples, "Futurama-all".

Just import "AmenBrother-drums" or something and start from there, because obviously you're not going to use Zoidberg's leftmost tentacle in your cool new sound.

https://en.wikipedia.org/wiki/Amen_break

Re: Kill Your Dependencies

#182

Post by davexunit »

nextos wrote: post #142
davexunit wrote: post #60

Earlier quoted context omitted.

In Nix, it's very easy to make a minimal mutt variant by removing the python input.

Yes, but these things shouldn't be happening. Default builds of packages should be kept more minimal. I understand it's hard with Nix philosophy, and things are improving with different package outputs. For the record, python was pulled indirectly via the gnupg dependency I think.

It's a difference in philosophy. I think packages by default should be full-featured, and minimal variants can be created for those that want it.

Re: Kill Your Dependencies

#183

Post by acdha »

Retric wrote: post #110
acdha wrote: post #108

Earlier quoted context omitted.

That's an argument for having an effective review and testing process. Change is inevitable and it's better to be good at doing it routinely than putting it off until an emergency.

This is overhead for every update of every library. In theory it's a great idea and expensive idea, so of course nobody does it. There are two mindsets in coding, this code needs to work right now and this code needs to work in 20 years. Linking code is very likely to break in the second time frame. Public API's are generally unstable, services goes away, and people break things. But, if all you need is a toy demo th…

I'm talking about integration tests, not 100% coverage of someone else's code. If you need e.g. image decoding, you need to be able to update libjpeg, etc. ASAP after a security patch – and that only requires a simple integration test covering known input / output for the subset of features you support. Since it's automated, there's very little difference between multiple small releases and infrequent large ones from this perspective.

As for your second point, I think you're overly focused on the wrong area. Both linked and static code demonstrably have many problems over that time period – if you recompile, you have to maintain an entire toolchain and every dependency over a long period; if you don't, you're almost certainly going to need to deal with changing system APIs, hardware, etc. — linking doesn't do a thing to make a 20-year old Mac app harder to run. In both cases, emulation starts to look quite appealing – IBM has, what, half a century with that approach? – and once you're doing that the linker is a minor bit of historical truvia.

Re: Kill Your Dependencies

#184

Post by cheapsteak »

endemic wrote: post #149
LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

I don't think that's what he's advocating: he's just saying that every dependency you have is another thing you have to worry about, so why not try to limit them as much as possible? Obviously it's impractical sometimes, and that's OK, as long as you understand the consequences.

Every dependency you have is another thing that people besides yourself can worry about with you or for you

Need to do X? If you write your own library that does X, chances are you'll be the only one to ever work on it. Need a new feature? You have to stop working on your actual project and implement that feature. Found a bug? No one else will fix it for you.

If you depend on a library that thousands of other people also use that does X, if you do find a feature you need that it doesn't have, open a ticket, someone will likely do that work for you. More often than not, that feature already exists, all you have to do is read the docs. If you find a bug, report it and and wait for it to get fixed, but there's also nothing stopping you from fixing it yourself and submitting a pull request.

Re: Kill Your Dependencies

#185

Post by reedlaw »

LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

The idealized goat farmer will make a better musician than the one who simply uses others' samples. To bring the analogy back home, the programmer who understands silicon and circuits is better equipped than the one who relies on massive dependencies.

Re: Kill Your Dependencies

#186

Post by dec0dedab0de »

justaaron wrote: post #176
ninjakeyboard wrote: post #166

Earlier quoted context omitted.

Regardless of how perfectly this does or doesn't match the context, I approve as an electronic musician and programmer and I will use this quote forever! Thankyou! www.soundcloud.com/decklyn

as an excuse for not doing original recordings? collage art is collage art, not painting... sorry:)

yet, both are valid ways to express yourself.

Re: Kill Your Dependencies

#187

Post by JBReefer »

reedlaw wrote: post #185
LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

The idealized goat farmer will make a better musician than the one who simply uses others' samples. To bring the analogy back home, the programmer who understands silicon and circuits is better equipped than the one who relies on massive dependencies.

I don't think many embedded systems engineers could write a PaaS

Re: Kill Your Dependencies

#188

Post by rhapsodyv »

diggan wrote: post #2

As everything, I think a bit of balance is needed. You're doing a quick MVP to demonstrate that your idea is working? Fuck it, just throw in dependencies for everything, just care about solving the problem you're trying to solve and proving/disproving your point. Once you verified it, then go and kill your dependencies. But don't do it just because you want to do it. If in the end the users doesn't benefit from you o…

Perfect. Get things done fast. Prove your product. If it succeed, you will have time to tune every aspect and invent your own wheel that fit your needs. But until that, RAM is a lot cheaper than your own time writing from scratch your version of things that are very stable and largely used.

But, the advice is really important for gem writters. As a gem author, I think you really need think a little more about our dependencies as you do with our public interface.

Re: Kill Your Dependencies

#189

Post by voltagex_ »

JBReefer wrote: post #187
reedlaw wrote: post #185

Earlier quoted context omitted.

The idealized goat farmer will make a better musician than the one who simply uses others' samples. To bring the analogy back home, the programmer who understands silicon and circuits is better equipped than the one who relies on massive dependencies.

I don't think many embedded systems engineers could write a PaaS

I used to think embedded systems (software) engineers were the be-all-and-end-all until I started looking into how my router worked (or didn't work - dhcpd had crashed).

How can you take Buildroot [1] and break it so badly? A mishmash of Broadcom SDK and ODM Makefiles that will only compile on RHEL5 on a Tuesday [2].

1: https://buildroot.org/

2: https://dlink-gpl.s3.amazonaws.com/GPL1500418/DIR890A1_GPL10... - ~450MB compressed / 1.2GB uncompressed.

Re: Kill Your Dependencies

#190

Post by BurningFrog »

LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

'If you wish to make an apple pie from scratch, you must first invent the universe.'

  — Carl Sagan
Post reply on HN