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

241–250 of 333 posts

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

#241

Post by Ma8ee »

abiogenesis wrote: post #237
Ma8ee wrote: post #140

Earlier quoted context omitted.

No, I won't beat them. But if it a limited subset that I can implement with twenty lines straightforward code, that will often be cheaper. I've been on projects where they imported xml-parsers many times bigger than the rest of the whole codebase just to send a well formatted order number.

What do you mean by cheaper? By using a third party library you are writing twenty lines less code, so it's cheaper in that aspect. There are probably libraries that are faster than your twenty lines of un-optimized code, so it's cheaper as far as computing resources are considered too. The only time it could matter is when you ship the code to the client through the wire (such as a Javascript bundle).

It’s cheaper in the sense that it is faster to write and maintain those 20 lines of code. Because someone has to evaluate the library, understand it well enough to actually call it and then make sure it stays up to date. And often there are a few lines of code to translate your data into a form that the library requires etc.

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

#242

Post by JackFr »

majewsky wrote: post #212
JackFr wrote: post #139

Earlier quoted context omitted.

Well the good libraries have option flags that will allow you to handle JSON as found in the wild.

That's not JSON, though. It's absolutely something else. Maybe a JS snippet. Maybe YAML. Definitely not JSON, though. (Some JSON libraries do have option flags, but usually it's about whether, during deserializing into a known type, unknown fields are an error or silently ignored. Or whether C-style comments are an error or considered as whitespace.)

It may not be JSON but it’s out there in the wild. A lot.

Let’s say I’m scraping a website. I can:

1) complain to the owner that “it’s not JSON”.

2) write a parser for a syntax that has no spec, (it’s not JSON, but it sure looks an awful lot like JSON with unquoted keys.)

or

3) Set ALLOW_UNQUOTED_FIELD_NAMES to true in the Jackson library.

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

#243

Post by scarface74 »

Ma8ee wrote: post #233
scarface74 wrote: post #164

Earlier quoted context omitted.

If I am using code that someone else writes and maintains it is easier to maintain. But I can maintain code that uses Entity Framework (or Dapper) much easier than I can maintain code based on a custom ORM that the “architect“ wrote.

As long as it works and is well documented, yes. But the moment there’s a bug somewhere or the docs aren’t adequate for your needs, you are in much worse trouble.

Again my general rule - you (generic you) are no special snowflake. What are the chances that you come across a bug in a library that has had 2,176,677 (in the case of Dapper) or Entity Framework (supported by MS) that no one else has come across, found a workaround, and posted the answer somewhere on the Internet compared to your code where you didn’t think about a corner case?

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

#244

Post by markmark »

jonfw wrote: post #218
markstos wrote: post #113

Earlier quoted context omitted.

Only update dependencies when your code requires the new version, depends on a bug fix or it fixes a security vulnerability. Otherwise, continue using the same version. Have good test coverage to catch bugs that may originate in dependencies and subscribe to a third-party service to track vulnerabilities in your dependencies.

When you have a hundred dependencies- who is looking at the release notes to see what security vulnerabilities are being fixed?

Github can do it for you automatically.

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

#245

Post by foobarian »

fwip wrote: post #97

A huge benefit of using dependencies in your codebase is that other members of your team (including future members) have a good chance of already knowing how the dependency works, and how to use it. If I rewrite package Foob because it only takes me 3 hours to write (let's call it Boof), and my colleague Mary on another team also does so, then the chances that our needs, specific implementations & usage patterns are…

I had this experience with a particular React hook recently. We ended up with like 5 teams implementing very similar functionality, and then when developer #6 came along and tried to replace them all with a common implementation it broke 2 out of 5 use cases because of very subtle edge cases. I guess React runtime behavior is kind of high on the scale of how hard code is to reason about, so maybe this wouldn't happen in an easier codebase. But still a very instructive exercise.

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

#246

Post by earthboundkid »

lordnacho wrote: post #44

It's a matter of judgement, but here's a few observations: - With a little experience, you know what gets fiddly and what doesn't. Today for instance, I needed a way to remove tags in an SVG document, which looks a lot like HTML tags. I quickly ended up finding that Regex is not the solution (a well known guy on SO wrote an answer that looks like a huge warning sign). I also couldn't enumerate all the corner cases. S…

Specifically on the SVG filtering example, which I think is a good illustration of when to use or not use a dependency:

Writing an SVG (or at least XML) parser is a necessary task for writing a filter that doesn’t get stuck due to weirdo issues. That is way more than an afternoon of work! But once you have a parser, dropping tags you don’t want or transforming them somehow is totally an afternoonable task size. So, do use a dependency for SVG parsing, but don’t look for a special “SVG filter all” package. Just do the filtering yourself.

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

#247

Post by mjevans »

tluyben2 wrote: post #18
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?

That is the issue I have with it: ‘an afternoon’ is already way too vague. Make it ‘5 minutes’ (left pad etc) then I think it works out.

The issue I have with this is a lack of specification. Left pad _what_?

Numbers or ASCII-only-printing? OK that's a reasonable. Is there a desired overflow behavior?

Past that it becomes more an issue of where and why. The suddenly not-trivial example includes questions about fonts, layout, and multi-byte characters. Emoji, etc.

Incidentally, in pseudoscope:

Create a valid full-space pad string (termination / etc), then decrement back from the end of the source string and over-write the pad characters from the end to the start of the string, exiting either on no more pad characters or no more input.

A second algorithm might combine those two steps as one pass, fill the output buffer from back to front. Only for C style strings would this be an issue given the dynamic end point for the data structure.

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

#248

Post by phodge »

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?

Ironically, these days with front end development I'm finding it hard to accurately scope how long it will take to incorporate 3rd-party dependencies. The docs make it seem straightforward enough, but they don't cover how to use it correctly under TypeScript instead of ES, or how to use it with Angular instead of React, or how to build it with Rollup instead of webpack, and I often spend an entire day googling obscure blog posts on how to get a dependency working in my own ecosystem.

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

#249

Post by Igelau »

nullc wrote: post #234
Igelau wrote: post #196

BRB, going to go roll my own AES -- what could possibly go wrong?

> BRB, going to go roll my own AES -- what could possibly go wrong? Probably not much more than picking an AES library written from someone else. It's fairly unlikely that your custom AES would function at all unless it was functionally correct. Your bespoke AES will likely have timing sidechannels, but so will most AES you go pick off the shelf. (in fact, if you happen to need CBC mode, virtually any AES you pick of…

Yes, yes, yes, and yes, but the crucial difference is that vulnerabilities in the library are more likely to have the benefit of disclosure.

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

#250

Post by phpnode »

cogman10 wrote: post #166
Ajedi32 wrote: post #147

Earlier quoted context omitted.

Yeah benchmarks can be much more difficult to get right than it might seem at first glance. Good thing they didn't try to write their own benchmarking code, otherwise they might have fallen into those traps you just mentioned. Luckily, they didn't, and instead pulled in the the `benchmark` library as a development dependency. The author of said library works on V8, and already considered all those problems and much,…

You are making the assumption that the library doesn't have the flaws I mentioned. It does (You can go read the source yourself https://raw.githubusercontent.com/bestiejs/benchmark.js/2.1.... ) There's no portion of the code that does warmups. There's no portion of code that "blackholes" the results to keep the JIT from optimizing away the code under benchmark. There is a lot of code though... so that's... good? You…

> There's no portion of the code that does warmups.

This isn't true - Benchmark.js will repeatedly rerun benchmarks until it gathers statistically meaningful results.

> There's no portion of code that "blackholes" the results to keep the JIT from optimizing away the code under benchmark.

True, and there's actually nothing benchmark.js can do to ensure that doesn't happen in the general case but when this does happen the results are usually pretty obvious - we'd see billions of ops/sec. Incidentally the left-pad benchmarks do not suffer from this issue.

Post reply on HN