[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."

[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.

[BubRoss]

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