We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they’re absolutely necessary or if they’re very focused and don’t try to do a million things. It’s not about size but complexity.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
And that’s one of the reasons microservices are a thing.
I also feel better when I use less libraries, even if that may seem irrational sometimes.
I think part of the library craze stems from people who really only want to use the programming language as a tool to get fast results (which is legitimate, of course).
For example in academic contexts you have a lot of scientists who use R with a whole truckload of libraries, often unnecessarily.
It reminds me of the plugin craze in the whole wordpress can of worms…
This is also why having a strong standard library and/or framework is so important to a language. Otherwise you’ll end up needing a third-party library for every little thing, each coming with their own programming paradigms and dozens of dependencies.
I disagree (mostly). What’s the difference between library and language built-in? PHP and C++ has a ton of built-ins. It doesn’t make it less complex than using library.
Problems that look simple at the first glance are in most cases are complex with too many edge cases.
I think I have never written a single utility function that had no non-obvious bug, and imagine that in more complex problems
Not to mention in many cases any function you write is possibly dangerous.
Just take a look how many things you have to consider when checking for odd number in JS:
The difference is I trust the language. That’s one source I have to trust. With libraries I have to trust a ton of sources.
What I do is look around at existing utility functions and then adapt them to my needs. The difference is I know exactly what I’m adding, and I know it doesn’t have dependencies, and when changes are made, I know what they are because I made them.
I’ve learned to be very judicious about using libraries only if they’re well established (unless I’m working on a personal project and don’t mind taking a chance with a smaller library). I do think one should think very carefully before adding a dependency, especially in webdev where you have a million bloated frameworks that have a handful of things you actually need. That being said, a trusted dependency is better than trying to reinvent (and maintain) the wheel.
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they’re absolutely necessary or if they’re very focused and don’t try to do a million things. It’s not about size but complexity.
And that’s one of the reasons microservices are a thing.
I also feel better when I use less libraries, even if that may seem irrational sometimes.
I think part of the library craze stems from people who really only want to use the programming language as a tool to get fast results (which is legitimate, of course).
For example in academic contexts you have a lot of scientists who use R with a whole truckload of libraries, often unnecessarily. It reminds me of the plugin craze in the whole wordpress can of worms…
This is also why having a strong standard library and/or framework is so important to a language. Otherwise you’ll end up needing a third-party library for every little thing, each coming with their own programming paradigms and dozens of dependencies.
NPM’s left-pad library has entered the chat
I disagree (mostly). What’s the difference between library and language built-in? PHP and C++ has a ton of built-ins. It doesn’t make it less complex than using library.
Problems that look simple at the first glance are in most cases are complex with too many edge cases.
I think I have never written a single utility function that had no non-obvious bug, and imagine that in more complex problems
Not to mention in many cases any function you write is possibly dangerous.
Just take a look how many things you have to consider when checking for odd number in JS:
https://www.npmjs.com/package/is-odd?activeTab=code
And of course most of that can be fixed be using strongly typed language.
The difference is I trust the language. That’s one source I have to trust. With libraries I have to trust a ton of sources.
What I do is look around at existing utility functions and then adapt them to my needs. The difference is I know exactly what I’m adding, and I know it doesn’t have dependencies, and when changes are made, I know what they are because I made them.
I’ve learned to be very judicious about using libraries only if they’re well established (unless I’m working on a personal project and don’t mind taking a chance with a smaller library). I do think one should think very carefully before adding a dependency, especially in webdev where you have a million bloated frameworks that have a handful of things you actually need. That being said, a trusted dependency is better than trying to reinvent (and maintain) the wheel.