James Cook @falsifian@mastodon.sdf.org

@cadadr@weirder.earth @operand When it comes to C, it is very platform dependent. E.g. if you're using the GNU toolchain (autotools, pkg-config, and lib-something, I forgot), it's actually fairly straightforward to include dependencies. But the main problem there is, the way C and C++ handle modules of programs is.. well, I don't want to say broken, given the age of languages, but definitely outdated.

IIRC it was also fairly straightforward on Windows as well, but I only coded on windows as a kid back in 2005, so I can't speak to that.

For other languages, package managers actually aren't the newest thing. CPAN for Perl and CTAN for TeX predate stuff like NPM by a decade and change.

IIRC you'd mostly use your distro's packages, or use your IDE on Windows to get libraries, or if you were a serious developer, you'd use the language package manager, say cpan. But the end user or even the beginner coder hardly ever heard of these tools, let alone needing them.

What really changed circa early 2010s was, we went from the package manager / repo as a curated community run place which keeps tabs on what's published to a wild west where shit comes directly from git repos of random coders. In my experience this was driven by node.js and especially npm, which brought in a lot of non-programmers who did not really know the technical implications of the decisions they were making into this packaging space.

This was on the one hand good ofc, democratising programming a bit, but also lead to a cultural shift towards some pretty horrid programming and software distribution practices (e.g. the infamous node_modules, there's a reason you don't have infamous vendor/ for ruby, or infamous ~/perl5 for perl).

In that culture we got used to "reinventing the wheel", "release early release often", "move fast break things"; these were like shibboleths of Node.js "subculture" back then.

We also got the tiny libraries with this development. Like, it was common, say if you were a C++ dev, to use boost or Qt for most of the functions that STD didn't include. Python always had a huge stdlib, and while Perl didn't have it as large, it was still pretty large. Ruby, well, you either did Rails with it or Textmate extensions, so that was okay, and even then the core libs are way much richer than what the 0.x releases of Node.js by Ryan included. If you needed to do something with images, you used ImageMagick, not a bunch of tiny libraries that adhere to a made-up-after-the-fact so-called "unix philosophy".

So people, instead of bothering to come together and create a stdlib and utility libraries for this new programming language (basically, it's JS but it's not really the browser JS), started packaging up little bits of functionality into tiny packages, and because a lot of people using these were amateurs and/or beginners, they didn't have the experience of how to integrate others' code or maintain software. Node.js immediately got corporate attention tho, and this meant that this amateur culture that's constantly "reinventing the wheel" without any engineering skills suddenly become commercialised. Joyent bought node.js, Ryan disappeared, Isaac became the maintainer, and these problematic practices ossified in the node community.

Then this ofc became the way of doing things in the start-up coding culture, which to this day is where mainstream programming culture is created, and inevitably seeped into other programming language communities, and became the default attitude. Move fast and break things, tiny isolated and "opinionated" libraries, version numbers going up like covid cases.

But the thing is this attitude is error prone and tiresome, like physically tiresome. You never know where to start, docs are out of date at the day of release---if they exist at all---, tools that you need to be transparent are fresh and buggy in day to day use, eveything is ad-hoc and barely compatible if ever at all, every package is opinionated, and tiny, and developed by a single guy who has 100 other packages that they maintain.

If you're developing something like boost, django, image-magick or similar, you can afford to build a team and infrastructure around it, like a bugzilla or debbugs, source code hosting, mailing lists or an IRC channel, etc. But if you're the sole dev of a 100 packages whose average content is 100--500 lines of code, you can't afford that, so you're beholden to forge silos like Github.

These existed before too, like SourceForge or whatnot, but the difference was, your program needed 1 or 2 major libraries, and then a few utility libraries here and there to make things more comfortable. With node.js mainly, we got a culture of use libraries as much as you can, tho. The idea was, if you avoid writing code, you'd avoid bugs, but the reality was, those bugs were moved to libraries and the glue code that made the 100 libraries work together.

An exception was CPAN ofc, because they did have a lot of packages and a culture of smaller (but not as small) libraries. What they did differently tho, was distributed, community run, constant testing of all packages. You can trust a package from CPAN because 100s of people test it and test results make it back to CPAN. I didn't really use CPAN a lot so idk the specifics, but Perl-Testers is a unique beautiful thing that I wish every language had: https://qa.perl.org/cpan-testers/

So all this stuff lead to the current situation that's "enjoyed" by not only the Node ecosystem, but by other languages, distros, and even tools like Docker today. There's no QA, everything is either a corporate git repo or an unemployed maintainers github, and it's considered okay to rely on this stuff because... well, because we kinda found ourselves inside this situation and whole generations of programmers were raised in it. And when you want to introduce QA or a CoC or what not, you're a gatekeeper, anti-progress, anti-innovation, or whatever other nonsense SV nerds come up with.

So when you say

the tools represent a certain kind of culture wrt dependency management, and automatically including transitive dependencies is an anti-pattern.

you're extremely on point, really hit the nail on the head, so to speak: this entire culture that was emerging early 2010s got mainstreamed by the tools developed around it and ossified as we neared 2020s, and know-how and techniques developed over the 90s and '00s were stigmatised (with a lot of ageism too) and forgotten, and now programming using 3rd party libraries became a minefield.