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

Post by pests » Tue, Aug 11, 2020, 8:33 PM UTC

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…

Post by Ajedi32 » Tue, Aug 11, 2020, 8:35 PM UTC

cogman10 wrote: post #53

axlee wrote: post #28

Earlier quoted context omitted.

Is that really 5 minutes? (For when left-pad was relevant) var cache = [ '', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' ]; function leftPad (str, len, ch) { // convert `str` to a `string` str = str + ''; // `len` is the `pad`'s length now len = len - str.length; // doesn't need to pad if (len >= 1; // "double" the `ch` so this operation count grows logarithmically on `len` // each time `ch` is "doubled", the `len` w…

This is actually a great example of why you SHOULDN'T use left pad. I've not profiled it, but I'm going to guess that now-a-days this will be faster than the current implementation on npm. function leftPad (str, len, ch) { str += ''; len = len - str.length; if (len Why? because the VM is (very likely) going to do exactly what the cache would have done. It can replace `ch.repeat(len) + str;` with a presized string all…

Post by eberkund » Tue, Aug 11, 2020, 8:36 PM UTC

ori_b wrote: post #68

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

And when you run into a bug or design problem in a dependency of a dependency of a dependency? It often takes less time to write some code than to understand someone else's code. Most programmers I've worked with get lost easily when jumping through layers of other people's code. I certainly do. Solid, well tested dependencies that solve hard problems are worthwhile. But dependencies have a cost in debuggability and…

Post by yoz-y » Tue, Aug 11, 2020, 8:40 PM UTC

Post by yoz-y » Tue, Aug 11, 2020, 8:41 PM UTC

xxs wrote: post #85

jasonpeacock wrote: post #6

This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…

> This is horrible advice. There's a reason that you don't write your own hashtable implementations. Of course you do and release(d) them as open source (public domain). Take Java - it has decent a HashMap but it's node based. It's memory inefficient to a point its nodes and arrays are top 3 of memory consumption. An array based hashtable takes around 3.6 times less memory for larger ones (on 4bytes compressed pointe…