Comment by keyle | Hacker News Reader

Comment by keyle | Hacker News Reader

It seems there is one of those posts on HN every 6 weeks.

And yet there is no solutions besides yolo-live-with-it.

I thought it sucks too, I'm in the same boat, but I considered the opposite for a while: what if we didn't have all the code reuse and boatloads of libraries at our fingertips?

That would be a TON of code added to our applications and overall - shock full of bugs and lack of optimizations. These libraries, when popular are battle tested, cover much more grounds than we do today (but might need tomorrow) and have been looked at if slow.

This ecosystem relies mostly on everyone acting like adults; Libraries to respect semver and not making large, breaking API changes on minor versions; and an ecosystem that is "safe", where bad actors can't pretend to be someone else.

Ideally there would be an open "group" of people running penetration tests and security overview of most packages where the collective could donate against their work. Large donations would allow specifying which packages you'd want them to review, and fixes would flow money to the maintainers...

But I'm dreaming. We're all building on a gigantic pile of hacks written for someone's portfolio to get their next job, which won't be in the same language and the thing will become abandoned.

"And yet there is no solutions besides yolo-live-with-it."

There is a solution: Stop accounting for dependencies as zero cost. Start accounting for their costs, in their need to be updated, understood, and possibly significant overcompelexity for your needs, plus all these costs are transitive into the dependencies they pull in.

This is not a magic solution. It doesn't mean you just think these magic thoughts and all your problems go away. But if you actually do this, it will solve your problems. It will turn the wide wonderful world of existing libraries back into a benefit instead of so often a net loss.

I still use a lot of libraries, but I've been noticing lately I use more "fundamental" libraries. I use a YAML/JSON parser for my config, but I don't worry so much about all the fancy wrappers around config that try to make it super nice to have environment variables or maybe a config file or maybe map it to the command line or maybe get it from the network... I just use a config file parser and commit to having that. My dependency trees are not completely pristine exactly, but they end up with a lot of these sorts of things in them but not so much all-singing, all-dancing "frameworks" or text templating libraries that are so amazingly helpful that they have entire embedded scripting languages or other such things.

It’s all about balance. Use libraries where it makes sense (e.g., if I’m reading HDF5 files, I’m going to use the HDF5 library, not roll my own), but don’t forget that you (ostensibly) know how to program on your own and like implementing some things yourself (rather than just lashing together other people’s code). Using a language with a decent standard library helps.

A solution is vetting libraries, CI/CD only has access to internal repo, and libraries only get added to the internal repo after being validated.

This is part of my work for the last 10 years.

I only use whatever I feel like on personal projects and small prototypes.

> That would be a TON of code added to our applications

wait, doesn't using a library also add that code to your application?

And if the library has to cover more than your immediate needs, isn't is much much more code added?

I think they mean that it's code they're not having to write/test/maintain themselves because presumably if you pick a good enough library the quality of code/features are better then what one individual or team could do

While there are issues with this approach like the article outlines, personally I believe it to be better then the alternative of countless developers reimplementing the same feature sets over and over because honestly that just seems like a waste of human time and talent

You never actually need 90% of the functionality a library gives, though... With some notable exceptions (cryptography). Most times I've excised a library I've only needed to implement a small part of what it did.

That's true, and there may be valid reasons to remove a library and reimplement that 10% yourself such as for performance, stability or educational reasons. However if the library is performing as expected, does not using 90% of it make it any less valuable? If the problem has been solved in a satisfactory way and remaking it doesn't bring benefit or solve a problem then it seems wasteful to spend the human time to do so

Python: from module1 import function1

To further drive the point, almost everyone seems to be conveniently missing a great benefit of libraries: they tend to be greatly battle-tested, most of the successful ones.

The moment people start realising their own (and most likely crappy) implementation to solve problem Z and discover they didn't consider X or Y or W scenario and haven't even tested for those, most of them will hopefully understand what "balance" and "trade-off" actually mean.

Reply on news.ycombinator.com