[throwsprtsdy]

> Your handrolled solution is likely worse than the library anyway

This assumption led to a lot of O(n^2) left-padding happening over the years, via left-pad from node.js.

Ideally libraries would be well-tested and of high quality, but at this point there may be too many of them to vet.

My own 2 cents is that if it's easier to implement the code from scratch than to evaluate and choose a library, perhaps the invent-it-here choice works best.

[danShumway]

Parent's comment is getting downvoted to all heck, but it is completely, obviously true in the Javascript ecosystem. If you're a competent-to-expert Javascript programmer, you will regularly run into libraries that are not coded to your standards.

And honestly, even throwing those libraries out, it's sometimes not even a question of doing a "better" job than the library. The library is designed for general-use, but my needs aren't always general-use. Sometimes libraries are good, but they're wasting time on stuff that I don't need.

This is the reason why every Unity game on the web takes 4-5 seconds to load, and my custom engine takes on the order of milliseconds to load. It's not because I'm a better programmer, it's not because Unity devs are crap, it's purely because I know exactly what my engine needs to do, and I don't waste time on anything that it doesn't need to do.

I can think of tons of examples where I've started out using an existing library and then realized that getting rid of abstraction made my code faster and easier to debug. Heck, I can think of tons of times where I've privately forked libraries and deleted codepaths or rewritten algorithms to make them more efficient for my use-cases. There are very few JS libraries that I regularly use where I have not at some point needed to care about their internals.

And I am definitely not a crazy, insane, masterful programmer. If I'm occasionally circumventing d3 internals or doing stuff manually, it's not because I'm special. People have this assumption that if something has a bunch of stars on Github, there's no way they could possibly code something more appropriate or efficient, and for a lot of people, that just isn't true.

[Paperweight]

"Surely this core cryptography library with 21 contributors and led by a superstar Node.JS dev with 9+ million weekly downloads and 1000+ dependants will be a great example to read and learn from..."

Opens source code.

Closes source code.

"Well, looks like I'm going to be a Rust developer from now on."

[NohatCoder]

Just don't ever look into the crates, as long as the lid stays on the crates are perfect, no reason to believe otherwise.

[slavik81]

I had the same experience, but I tried to help. Now my name is in the contributors list, but I still don't trust it. My changes have all been lost to rewrites, and I assume new bugs have replaced the old ones I fixed.

[alfiedotwtf]

Thanks for saying this. I’m in this camp too.

... but I think the majority are in the “I just need shit to work and develop fast” camp, and don’t care if it’s not optimal, so they can finish their current project and move on.

[_v7gu]

That’s just wrong. JS uses ropes for the string implementation, so even the inefficient left padding is O(n).

[throwsprtsdy]

You're right. I'd correct my original post if I could. I stand by my point but I chose a terrible example.

[jackcviers3]

That's because Node and JS are geared towards software engineers new to the field. The ecosystem is geared towards delivering things quickly and cheaply. Like most things, that will work 80% of the time. Most projects are shacks, not skyscrapers.

The problem is, 20% of projects are skyscrapers, and you can't build those out of pine. Sometimes, you can't build them out of standard steel and rear. You actually have to pick the correct raw materials, create a stable and maintainable architecture, adhere to strict regulatory standards, and use advanced tools to create a working edifice.

The software industry's current practices have encouraged a one-size-fits-all mentality, and that just means that it's almost time for another SLDC paradigm shift to swing the pendulum back the other way to achieve balance. It will happen, be patient.

[jolux]

If you're better at this than LAPACK to the extent that you do not even trust it to function correctly, more power to you.

[throwsprtsdy]

My point is not that I'm better at it than some specific library, it's that choosing a library would take more effort than writing some straightforward code.

EDITED TO ADD: In fact getting LAPACK into the build if it's not already there is more of a maintenance imposition than just writing a couple of lines of code for this.

[jolux]

Not if there already exist bindings in your language, which is the case more often than not these days.

[BubRoss]

I'm not going to integrate LAPACK for a single line expression.

[jolux]

LAPACK is the underlying library behind most linear algebra packages in other languages and furthermore it was just an example. My guess is that you probably don’t have just one line of matrix manipulation ever, in which case using a well established library is a good idea. If not, then sure. Do it yourself. But that’s still more code that you have to maintain now.

[username90]

> But that’s still more code that you have to maintain now.

10 lines of code is easier to maintain than a whole dependency.

[jolux]

That's arguable, because 10 lines of code almost never just stays 10 lines of code, and my point in the first place was more contesting that the dependency is hard to choose, or that there aren't solid proven libraries for this.

[jlokier]

A counterargument:

1 large, complex dependency (plus the 20 lines of wrapper code to transform your program's internal data to initialise and call the library) almost never just stays as 1 large, complex dependency (plus 20 lines of ...).

[kqr]

This is why it's important to add a comment to those 10 lines describing the choice, and urging future contributors to reevaluate the situation.

(Of course, one should always reevaluate the situation when making changes to code, but we all need a nudge sometimes when we're afraid of doing the wrong thing.)

[username90]

> 10 lines of code almost never just stays 10 lines of code

This is only true when you implement business logic, not when you implement algorithms.