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

171–180 of 229 posts

Re: Kill Your Dependencies

#171

Post by lmm »

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…

> I understand if you are relying on a large portion of a library and you need to use it, but why bring an entire library in for one function.

Why not? An extra 3MB of disk space? A few milliseconds more of compile time? Maven makes it very easy to work with dependencies (and you want to use maven anyway, even if you have no dependencies, so that you have a proper release process). At this point I think of basic utility libraries like guava-collections, commons-io, httpclient and junit as part of the standard library. If I need even one function from one of them I'll add the dependency. Better that than have two inconsistent ways of doing the same thing.

Re: Kill Your Dependencies

#173

Post by TazeTSchnitzel »

mwcampbell wrote: post #50

A 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…

PHP doesn't have tree-shaking, as it isn't compiled, but it does have autoloading: the source code files for classes are only loaded from disk when they're instantiated. This is probably similarly beneficial.

Re: Kill Your Dependencies

#174

Post by justaaron »

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…

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?

Re: Kill Your Dependencies

#175

Post by justaaron »

LukeB_UK wrote: post #140
gglitch wrote: post #138

Earlier quoted context omitted.

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...

Re: Kill Your Dependencies

#176

Post by justaaron »

ninjakeyboard wrote: post #166
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…

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:)

Re: Kill Your Dependencies

#177

Post by voltagex_ »

lmm wrote: post #168
ktRolster wrote: post #41

Earlier quoted context omitted.

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.

Eh, I am using reflection in a small (C#) project at work - I've had to implement a unit test system of sorts (yes, NIH, reinventing the wheel etc etc) and reflection lets me find all methods that return a particular type very easily. I agree it can become spaghetti very quickly but it is quite useful at times.

Re: Kill Your Dependencies

#178

Post by voltagex_ »

jbergknoff wrote: post #122
alexose wrote: post #119

Earlier quoted context omitted.

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

Yes, the npm "request" module is extremely bloated and badly written, to boot. https://www.npmjs.com/package/needle is a good alternative.

Can you elaborate? How do I know Needle is any better?

Re: Kill Your Dependencies

#179

Post by ktRolster »

the_af wrote: post #163
maxxxxx wrote: post #146

Earlier quoted context omitted.

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.

You're defining ideology too narrowly.....an ideology is a system of ideas and ideals. It doesn't have to be mistaken, and it can be completely justified and correct.

"I think Javascript is better because I prefer to use technologies I know" can be part of an ideology.

Re: Kill Your Dependencies

#180

Post by sotojuan »

jbergknoff wrote: post #122
alexose wrote: post #119

Earlier quoted context omitted.

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

Yes, the npm "request" module is extremely bloated and badly written, to boot. https://www.npmjs.com/package/needle is a good alternative.

Why not just use node-fetch? It's tiny.
Post reply on HN