Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never use a dependency that you could replace with an afternoon of programming

blog.carlmjohnson.net

Post reply on HN
Print view View original

291–300 of 333 posts

Re: Never use a dependency that you could replace with an afternoon of programming

#291

Post by imtringued »

KajMagnus wrote: post #273
jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

I think a JSON parser is not a good example though — takes longer than a few hours / an afternoon, to write a JSON parser, add tests, fix bugs, corner cases. More like a week, or weeks, ... ... Look, a tiny json parser — Not an afternoon project: https://github.com/rafagafe/tiny-json/blob/master/tiny-json.... And a question about small JSON parsers — didn't see any afternoon projects among the answers: https://stacko…

Same with CSV. It looks easy, but it isn't. I've never seen anyone who writes their own CSV parser actually implement features necessary to conform to the standard like quoting and escape sequences. The end result is software that breaks when delimiters or quotes appear in user input. Honestly, I prefer xlsx spreadsheets because of that. Nobody fools themselves into implementing the parser or serializer for the format themselves. The only tiny pitfall with them is when people create spreadsheets manually in excel and write numbers as text, but parsing strings to numbers is absolutely trivial. You have to do that with CSV anyway.

Re: Never use a dependency that you could replace with an afternoon of programming

#292

Post by imtringued »

layoutIfNeeded wrote: post #192
Ajedi32 wrote: post #169

Earlier quoted context omitted.

That would depend on the underlying implementation of the string object, no? (If the string is implemented as a linked list it's O(n)) Anyway, it makes no practical difference in this case, since the one they labeled "O(n)" is the naive implementation that most people would write if they implemented left-pad themselves.

String implemented as a linked list. You’re a webdev aren’t you?

Well, Haskell did it...

https://stackoverflow.com/questions/13865420/why-is-haskells...

Re: Never use a dependency that you could replace with an afternoon of programming

#293

Post by tome »

nayuki wrote: post #107
jdmichal wrote: post #34

My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…

> don't use a dependency to implement your core business In logic language, you're saying "If X is your core business, don't outsource X". > Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions…

Ha! I had exactly the same thought.

Re: Never use a dependency that you could replace with an afternoon of programming

#294

Post by swiley »

sparker72678 wrote: post #14

Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?

Most things really can be done in an afternoon if you’re in the right mood.

They just won’t have unit tests, and they’ll probably have lots of defects and other technical debt.

Re: Never use a dependency that you could replace with an afternoon of programming

#295

Post by tome »

OJFord wrote: post #197
nomel wrote: post #83

Earlier quoted context omitted.

> "This'll take an afternoon" - three weeks later...... > Programmers are notorious for this. From my experience with these personal failings, the problem usually comes from the question being phrased in the context like, "before you begin working on this, how long do you think this will this take you to complete?". If there's no opportunity to scope, with requires not insignificant work towards the solution, the est…

I recently read through the (free online) 'book' on Basecamp's 'shape up' methodology; I thought the 'hill chart' describes this really well - the work needs to be in progress going up the hill discovering what it's all about, before you get to the top and can accurately assess how much 'real work' (!) there is to do, and then it's all downhill from there.

> the (free online) 'book' on Basecamp's 'shape up' methodology

FTI: https://basecamp.com/shapeup

Re: Never use a dependency that you could replace with an afternoon of programming

#296

Post by jamil7 »

astura wrote: post #235
jamil7 wrote: post #66

Earlier quoted context omitted.

I knew which video it would be before clicking... But to your point they're often not really "store-bought" bricks though. More like bricks someone was giving away on the side of the road, you're free to use them to build your house but with no guarantees they work and the instructions are missing or incomplete. Oh and they're the wrong shaped brick but you only figure that out later.

What sorts of dependencies are you guys adding to your projects? I've never had these sorts of issues with external dependencies.

Ah I'm mostly joking. I haven't done much js work lately but sometimes wading through npm did feel like the above.

Re: Never use a dependency that you could replace with an afternoon of programming

#297

Post by withinboredom »

imtringued wrote: post #291
KajMagnus wrote: post #273

Earlier quoted context omitted.

I think a JSON parser is not a good example though — takes longer than a few hours / an afternoon, to write a JSON parser, add tests, fix bugs, corner cases. More like a week, or weeks, ... ... Look, a tiny json parser — Not an afternoon project: https://github.com/rafagafe/tiny-json/blob/master/tiny-json.... And a question about small JSON parsers — didn't see any afternoon projects among the answers: https://stacko…

Same with CSV. It looks easy, but it isn't. I've never seen anyone who writes their own CSV parser actually implement features necessary to conform to the standard like quoting and escape sequences. The end result is software that breaks when delimiters or quotes appear in user input. Honestly, I prefer xlsx spreadsheets because of that. Nobody fools themselves into implementing the parser or serializer for the forma…

It really is easy:

$csv = str_getcsv( $input );

But PHP makes everything easy :trollface:

Re: Never use a dependency that you could replace with an afternoon of programming

#299

Post by greyhair »

BigJono wrote: post #284
VHRanger wrote: post #75

Earlier quoted context omitted.

Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one…

This is pretty much spot on. Except you also missed the main cost, which is the insane amount of time it takes to learn the 85 dependencies on your project to an extent that you actually understand what your code is doing. Every single project I go into seems to have a smorgasboard of dependencies, then when I take the time to investigate one of them I find out it's being used incorrectly by at least 50% of the team…

But then lets talk about internal dependencies.

On a C code project for a large Fortune 100 company a half dozen years ago, I encountered a pesky header include that made no sense. And that header was part of a patch that I really did not want to pick up, so I started digging into it.

Turns out that they had some constant in the code, and the developer just did a grep for that value in the source tree, and that constant already existed in an existing header file, so they just included it.

And that CONSTANT_VALUE_STRING had nothing to do with the technology that the C source was addressing. So some lazy slacker pulled in a random header file that contained the proper constant value for an unrelated technology.

The dependency on that was pure lunacy on so many levels.

And that was an internal dependency, not an external library.

So the lesson here? Not all dangerous dependencies are external.

Re: Never use a dependency that you could replace with an afternoon of programming

#300

Post by greyhair »

kjeetgill wrote: post #70
andrewstuart wrote: post #36

Earlier quoted context omitted.

I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…

While I agree that if you think it'll just take an afternoon, for the sake of this article it had better! But conceding that charitable assumption to the article, I agree with its basic premise: dependencies cost a lot of time in diffuse, non-codey ways. There are AAA dependencies you pull into every project, but most other dependencies require a good degree of due diligence, evaluation, risk, and their own long-term…

But that analysis is part of the design process on the front end. You don't just 'take' libraries or utilities without evaluating them. And you don't just write bespoke libraries without thinking about the APIs.

So do your upfront work, by all means. It isn't an all or nothing decision.

Post reply on HN