41–50 of 132 posts
The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled, there will be all that library code investment that will be sunk.
The first thing I look for when starting a new project is if I can't be served by the standard library in whatever lang I'm using, to find dependencies that don't also depend on a bunch of code that I will have to indirectly depend on. The code I wrote like that still runs like ten years later without much problems having to update it. The code I worked on which depended on whatever flavor of the year framework peopl…
Absolutely. This is where the real dependency bloat in ecosystems like npm come up. You may only include a handful of reasonable dependencies, but each of those have dozens of their own dependencies, and so on and so on.
However, I think the blog post reflects a strong desire of many developers (I am one of them.) Achieving this vision, at least in commercial software, can be a utopian dream.
It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…
Okay, now fast forward a few years: is the open source dependency still [original license flavor] or is the license now more restrictive? What about the the updated dependencies of this single, imported dependency?
Now suppose you have an executable that's made available: do you properly have the accompanying license files that (on a minimum) give attribution?
Generally speaking, we import dependencies to help make things better and to get back to get focusing on the main portion of our application. At the same time, each imported dependency has an ongoing management factor.
...and don't get me started on the diamond dependency problem which still exists despite any given package manager's best efforts and is one of the reasons we have SemVer which we hope is followed by the developers of that dependency.
It would be nice if there were a way to quantify the value of your dependencies. If you have a dependency with 1,000 LoC and your application is utilizing 800 of them, that seems like a good reason to use the dependency. You're (hopefully) getting unit tests, documentation, and public exposure of the code (bugfix opportunities) for "free" If you have a dependency with 1,000,000 LoC and you only need 1,000, that indic…
You're also exposing yourself to potentially needless breaking changes and many libraries that aren't well tested or don't have static types. Or growing in size because of optional dependencies but build tools and languages without builtin support for keeping unneeded optional dependencies out of the imported code.
I think this is actually good tip that doesn't get used enough. Logging dependencies and packages would probably also make it a lot easier to debug if you suspect a package is the source of a problem but don't know if you can touch it or not.
Is there a minimal replacement for log4j?
System.out.println, or some thin wrapper there-around. Most of what log4j does is stuff that arguably should be done outside of the application, such as log rotation and piping to file and what have you.
One other area that can be complicated surrounding dependencies is licensing. Specifically, you use a library imported from PIP/NPM/Maven/NuGet/etc. and maybe, if you are a diligent dev, you review the license. If you're lucky it's MIT or some other compatible version for your use case. But did you review the dependencies of this new dependency? What about their licenses? Okay, now fast forward a few years: is the op…
https://hg.sr.ht/~twic/lambda-property-matcher/rev/53ef7eb30...
One other area that can be complicated surrounding dependencies is licensing. Specifically, you use a library imported from PIP/NPM/Maven/NuGet/etc. and maybe, if you are a diligent dev, you review the license. If you're lucky it's MIT or some other compatible version for your use case. But did you review the dependencies of this new dependency? What about their licenses? Okay, now fast forward a few years: is the op…
Rather than reviewing any licenses, you should incorporate a license check in your build. I did this in a Gradle project recently, and it was pretty easy: https://hg.sr.ht/~twic/lambda-property-matcher/rev/53ef7eb30...