If there is an analogue in the standard library you should have a compelling reason to use an alternative. Wish this could be filed under "common" sense. Thanks for articulating and presenting this principle, among others. Great writeup.
Kill Your Dependencies
161–170 of 229 posts
Re: Kill Your Dependencies
#162So to summarize, to get rid of an extra 10 (or even 100) megs in Ruby (or 0 megs in some other languages) of memory usage (and disk usage don't forget!) spend weeks rewriting, testing, and integrating your own code instead of using already written, tested, and integrated code. Now, that I've clarified the article's point, how can anyone not follow this "best-practices" advice?
Re: Kill Your Dependencies
#163Earlier quoted context omitted.
Are there really people out there whose decisionmaking process goes like "well we don't really need this library, but I'm gonna depend on it anyway to further the ideology of our movement"
I know plenty of people who want to port everything to JavaScript. When you ask "Why?" they don't know. That's an ideology.
In what sense are technical preferences you cannot explain or justify an "ideology"? Ideology is not unjustified/mistaken belief. Maybe you mean cargo culting in technology, of which there is sadly a lot? Or maybe even "let's do this in JavaScript, because it's the only tech I know and I can't be bothered to learn something new"? That happens, but it's not ideological.
Re: Kill Your Dependencies
#164A large number of dependencies is only a problem in environments that aren't amenable to per-function static linking or tree-shaking. These include dynamically typed languages like Python, Ruby, and JavaScript (except when using the Google Closure Compiler in advanced mode), but also platforms like the JVM and .NET when reflection is allowed. Where static linking or tree-shaking is feasible, the run-time impact of br…
It helps somewhat, but I feel that the "only is a problem" assertion is too strong.
Tree shaking doesn't help you when you are pulling in every HTTP client in existence transitively. It is still code that is being run, so can't be automatically optimized away, but it is unnecessary.
Re: Kill Your Dependencies
#165How long did it take anyone to realize this nightmare?
Since we are on the path to major discoveries, let's talk about runtime, runtime-dependencies and all that.
Every Ruby app ever created is stuck somewhere on the time axis, before its origin.
Re: Kill Your Dependencies
#166I 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…
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
Re: Kill Your Dependencies
#167This 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 developm…
The worst offender, IMO, is request. I've seen more than a few projects pull it in just to make a single HTTP call. Just look at its package.json: https://github.com/request/request/blob/master/package.json
Could you elaborate on why you view this list of dependencies as a problem?
I've been using request and its many transitive dependencies for years without hitting any real problems due to this.
Re: Kill Your Dependencies
#168Earlier quoted context omitted.
This is pretty much what Rob Pike advocates in Go: "A little copying is better than a little dependency." http://go-proverbs.github.io/
Nice list. He clearly doesn't like reflection: > Clear is better than clever. > Reflection is never clear. Of course, everything has its place, even reflection.
Reflection is a sign that your system is inadequate. In some (maybe even all) languages it may be necessary, but for a language designer it is a failure.
Re: Kill Your Dependencies
#169I find this argument sort related to the framework vs library and opinionated vs agnostic. Being an old fart Java developer I generally prefer things where you can plugin your own implementation (ie agnostic). That is there is an extreme for killing your dependencies of either extreme copy'npaste OR which every library offers a plugin SPI (ie inversion of control) (or a combo of both). The problem with the dependency…
You're probably more experienced in java development than me. But maybe a good rule of thumb is that most Java libraries shouldn't use reflection or dynamically loaded classes (i.e. using Class.forName or ClassLoader). That rules out most dependency injection frameworks.
Java makes plugin-like scenarios very hard. The kind of thing you'd do with a typeclass in languages that have them. There's OSGi (the horror, the horror) which maybe-kinda-sorta-works, or there's the SPI where you put the class name in a .service file (which will then be instantiated though... reflection). When those are the alternatives, DI frameworks aren't so bad.
Re: Kill Your Dependencies
#170Yes, 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…
Urgh. I find design patterns the worst approach. It's just copy-paste at a slightly higher level. If you really understand a pattern, you should be able to express it formally - i.e. as code.