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

211–220 of 229 posts

Re: Kill Your Dependencies

#211

Post by mbrock »

lmm wrote: post #170
mbrock wrote: post #23

Earlier quoted context omitted.

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.

Richard P. Gabriel's book Patterns of Software has a chapter about that. (It's free and out of print.)

Bluntly, it's kind of like: if you really understand a style of house building, you should be able to deliver it as a prefab. Maybe true in some way, but also neglects the drawbacks of standardized components.

Re: Kill Your Dependencies

#212

Post by mbrock »

sebcat wrote: post #210
jermo wrote: post #81

Earlier quoted context omitted.

The downside is that you bring in another layer of indirection and, as a result, greater cognitive load for yourself. Mycode -> facade -> library Navigating code becomes more cumbersome and stack traces longer. I do like this approach too but it isn't free.

There was a code base where people wrapped glibc-functions. Most of the time it was straight calls to the corresponding functions in glibc, but they were called x... instead, so malloc became xmalloc, free became xfree, &c. At one time there was a lot of zombie processes lingering for a long-ish time until the parent terminated and the zombies were reaped by init. I didn't bother to look at the implementation for xpo…

Heh. Well, yeah, abstract opinions are always suspicious. In your case, making a facade around standard POSIX functions does seem weird, especially if the facade is itself buggy! For something that needs to be portable across many platforms, such a facade could be very useful though.

Re: Kill Your Dependencies

#213

Post by zerd »

cwyers wrote: post #193
justaaron wrote: post #175

Earlier quoted context omitted.

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 (er…

10 megabytes of memory more than necessary! Because that's a massive waste of memory in 2016.

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.

Re: Kill Your Dependencies

#214

Post by the_af »

ktRolster wrote: post #179
the_af wrote: post #163

Earlier quoted context omitted.

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.

It was the OP, not me, that implied ideology is something negative and linked to poor justifications. For the record, I think ideology is (or can be) a good thing in politics, but a misappropriated term in technology.

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

But that's not what the OP said. Instead, it was "I think we should use Javascript because... uh... I dunno. Let's just do it!". That's not ideology by any possible meaning of the word.

Re: Kill Your Dependencies

#215

Post by kedean »

mbrock wrote: post #129
jermo wrote: post #81

Earlier quoted context omitted.

The downside is that you bring in another layer of indirection and, as a result, greater cognitive load for yourself. Mycode -> facade -> library Navigating code becomes more cumbersome and stack traces longer. I do like this approach too but it isn't free.

That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Hopefully a facade will introduce a small constant number of stack frames... Anyway, with something like Lodash for JavaScript, I'd even want to "facade" that into a project-specific utilities thing. Right now w…

>That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful.

Unless you're using Spring, of course, then all bets are off. That's the biggest downside of IOC containers, they tend to ruin the usefulness of stack traces and the "step in/step out" functions of the debugger.

Re: Kill Your Dependencies

#216

Post by Retric »

acdha wrote: post #183
Retric wrote: post #110

Earlier quoted context omitted.

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…

Tests just give you a bug report early, they don't fix the bug.

Re: Kill Your Dependencies

#217

Post by mathattack »

ben0x539 wrote: post #135
maxxxxx wrote: post #46

Earlier quoted context omitted.

Balance is good. Unfortunately ideologues have taken over software as they have taken over politics.

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"

Ideologies are rarely presented as such. I have seen places where they wrote databases from scratch, and rewrote Windows scrolling bars. Always 100 good reasons why using something else wasn't good enough. Other times I've seen people always want to buy the shiny nice toy rather than write a few lines of code themselves.

Re: Kill Your Dependencies

#218

Post by EvanPlaice »

cheapsteak wrote: post #184
endemic wrote: post #149

Earlier quoted context omitted.

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…

But... That would require you to read somebody else's code. /s

Classic case of NIH syndrome.

Re: Kill Your Dependencies

#219

Post by EvanPlaice »

dceddia wrote: post #114
mwcampbell wrote: post #98

Earlier quoted context omitted.

You're right; most of the languages and platforms used for developing applications don't have reliable support for tree-shaking or fine-grained static linking. But there's hope for some of them. When building Android applications, it's common to process the JVM bytecode with ProGuard before converting it to Dex bytecode. ProGuard includes a tree-shaking step. Sometimes it's necessary to tell ProGuard about specific c…

It looks like Webpack 2 will have support for tree-shaking: https://github.com/webpack/webpack/pull/861#issuecomment-149... There's also rollup.js (another module bundler) that supports tree-shaking: http://rollupjs.org/ Either way, it seems like the code needs to be using ES6 modules to make it all work.

JSPM already uses it for sfx builds

https://github.com/systemjs/builder/pull/205

ES6 modules allow devs to easily specify and import only the parts of a library that are being used. The bundler takes care of pulling in the necessary parts. No magic required.

Re: Kill Your Dependencies

#220

Post by EvanPlaice »

_0w8t wrote: post #102
ybx wrote: post #94

Earlier quoted context omitted.

> It could be that those who use large number of dependencies just prefer less dynamic languages when dependencies are very explicit and manageable. Tell that to anyone using NPM.

Clarification - my point was that a sane person prefers dependencies to be explicit and manageable. It is easier to create tools for that with static languages. As for NPM due to dynamic nature of JS the tooling is rather hard and just not there yet.

Dependencies (and their specific versions) are already managed explicitly via package.json.

The shift to a flat dependency hierarchy in NPMv3 will make managing dependencies of dependencies much more explicit and straightforward to manage.

JSPM already uses a flat structure and shows how simple dependency management can be.

I'm not sure what you mean by "the dynamic nature of the tooling". The JS development ecosystem doesn't attempt to provide an end-all-be-all monolithic core lib. It's a good thing and one of the primary reasons why advances in the JS evosystem are happening at breakneck pace.

Post reply on HN