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 to make my own. I then thought using premade skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all.
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.
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.
A better way to view this is that if libraries are kept small, then you can pick a more granular set of dependencies than say a larger library that includes the kitchen sink.
I agree with most comments here that it's not a good idea to reinvent the wheel everywhere, but when all you want is a wheel, and not the entire car, it's ideal that we have a way to just include the wheel.
Every line of code you write is something you have to worry about. Every dependency you use is something that (in theory) other people are also worried about.
Charming quote. The same argument could be made about making your own food "from scratch." But it's not a solid refutation of the essay. Let's say that if one end of the spectrum is unlimited dependencies and complete indifference to the complexity and size of the project, and the other end of the spectrum is raising your own goats, there must be an ideal somewhere in the middle.
I completely agree, but the extremism in the essay is ridiculous. If I'm writing some software, I don't want to have to roll my own version of every little thing when there are battle tested libraries out there that already do it and benefit from many people using it. If my use case is vastly different, sure, but if it's the same use case as everyone else then I see little benefit.
if they are so battle-tested then they probably are not like the email gem that the author spoke of that was using 10mb more memory than necessary for dependencies...
node-land is also getting a bit silly this way... to say nothing of java etc...
since we are into silly quotes i'll riff and probably get this wrong but:
"you wanted a banana but you got the gorilla holding it and the whole jungle too"
joe armstrong (erlang) on Class-based OO inheritance etc...
That is 10 megabytes per ruby application per server. I don't know how many ruby instances there are in the world, but the total memory reduction across the world could easily be in the order of petabytes. Small change with large impact.
no disagreement - better to use someone elses - but if your using one tiny part of a gigantic library of functions, it may be more cost effective to find a better (smaller) library, or write your own.
"In Objectivist-C, software engineers have eliminated the need for object-oriented principles like Dependency Inversion, Acyclic Dependencies, and Stable Dependencies. Instead, they strictly adhere to one simple principle: No Dependencies."
If we’re talking recording, it doesn’t matter that much how exactly you arrive at some fixed audio sequence. Indeed, use loops or goats, borrow $xxxxx gear from friends, pull multi-terabyte libraries of perfectly sampled cello—as long as it floats your boat (and your target audience’s. If you make stock progressive house for clubs, goat involvement probably isn’t worth it). By way of knob tweaking and some applied randomness you arrive at a take you like and then you delete everything else and let the goat roam free.
Things are different if we’re talking live performance. You’d be fine with that multi-terabyte cello library on stage, but not if sampling plugin brought opaque nth-party dependencies you can’t vouch for and have no time to properly wrap your head around. You don’t want surprises and you want to know for sure there’s enough performance leeway on your concert laptop.
There are steps you’d take to reduce the error margin while you perform that have no parallels in software engineering realm. Maybe you’d bounce your cello loops to audio to never have that computation happening in real time. Maybe you’d bring analog synths, which are bulky and pricey but also simpler conceptually, self-sufficient, well-tested and never give blue screen of death.
Your song is essentially being created every moment your program is running or being developed. You’re putting even more trust in what you’re pulling—the black box abstraction boundaries around your dependencies can contract, the input you receive from audience is more direct, and importantly there’s no you actually playing instruments and directing the performance because the whole behavior is defined by algorithms that often end up partly delegated to dependencies.
that's a silly/wrongful quote IMO... I've produced/recorded music for over 20 years and loops from other people are not only cheating, they are not your damned recordings and you sound like every other loop-arranger out there... it's not really that difficult to record real-world sounds and guess what!? you can use those same audio tools (your daw + plugins etc) to manipulate and sweeten YOUR recordings just as easily as you do with others recordings aka loops.
making music with sample-pack loops is basically just dj'ing/remixing... which I also have done for over 20 years so I know the difference...
Using boughten drums is not cheating, as it's generally about the way you tune them and play them that make the difference, versus loop manipulation that literally is about modifying otherwise sample-for-sample copies...
Guitar tonality = 80% in the fingers and the ear/mind of the player... The pickups and amp/pre-amp combination DO make the other 20% perhaps...
As for making drums from goat-skins, well it's not exactly rocket science...
now, onto the the problem I have with the actual issue at hand: it's not like the author is saying to write your libraries in assembler. he's saying that maybe you don't need to include gems upon gems that themselves reference other gems, as the dependencies pileup and get ridiculous and the performance suffers, which is actually a major concern with Rails and other monolithic frameworks with single-threaded processing etc.
for crying out loud, he's even giving you permission to specify your behaviors with a ridiculously high-level concise language aka Ruby... how much more direct and obvious can a point be and still be missed?
>I've produced/recorded music for over 20 years and loops from other people are not only cheating, they are not your damned recordings and you sound like every other loop-arranger out there...
Actually there are songs using samples that are 10 times more original and unique than songs other people have totally recorded and played themselves.
You can be inventive and original using samples and you can be a copy-cat bore writing your own stuff.
For example, let's compare a cheesy, but still huge classic and immediately recognizable "U can't touch this" with tons of stupid-ass Michael Bolton cliched ballads or MOR rock.
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 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].
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
> 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 to make my own. I then thought using premade skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all.