You're right that it's always been there, but wrong that you think it can be won. Every woman's gain is her son's loss, and every father's gain is his daughter's loss. It's an iterative game with a long term aggregate outcome for the society in question. You're framing it from the perspective of individuals. Women cannot win without men also winning and vice versa.
I don't even understand this at all. If you believe gender equality is an intrinsic good then any women's gain up to gender equality would be a gain for anyone who has that principle regardless of their gender.
Do you think that black emancipation from slavery was "white's loss". It's just such a nonsensical position to hold.
Not at all. What I mean is each sex has a vested interest in the well being of the other, since both of them have a vested interest in the well being in their children of either sex. If my wife gains from affirmative action while her 5 sons lose, it's a net loss to my wife. By the same token, emancipation of women is good for the man with 5 daughters.
The race comparison doesn't hold in quite the same way, because there isn't automatically a heredity line. One group can just exploit the other indefinitely.
> If you believe gender equality is an intrinsic good
First, I believe that women have privileged position compared to men. So tipping the scales in favor of women removes gender equality.
Second, comparison with black emancipation makes no sense. For evolutionarily foreseeable future, as long as humanity exists, so will men and women, and they need to get along with each other. Meanwhile you could imagine a perfectly functional world without emancipated black slaves.
If you can point a package manager at a git repo and use it like package, this is accidental convenience. Source code repositories should be factored as source code, with a build step to transform them into packages. For some languages that means compilation, for others it means transpiling, minifying, or just copying files. The resulting artifact is a different shape, designed for consumption.
If you use git for packages, then your repo becomes the package boundary. You no longer have the option of producing multiple packages from one repo, or even one package from multiple repos.
> If you use git for packages, then your repo becomes the package boundary. You no longer have the option of producing multiple packages from one repo, or even one package from multiple repos.
What does this even mean?
I'd argue that having the source to build the thing is more important than the artifacts. Release artifacts are more of a convenience. If the thing doesn't build from the source given, what use is it?
Exactly my point. You assume the source is the thing you want to consume, but it isn't. Package registries are much more than a convenience and packages don't necessarily map 1:1 with source code repositories. Nor should they need to. You shouldn't have to build every dependency and care where their source code is.
Sure you want the source available, otherwise it's closed source, but ideally you never need to look at it unless you're a contributor.
Correct way is to have everything as-if a source dependency, but a globally shared cache system that can automatically provide artifacts if that exact version of source has already been compiled.
Any system that can only consume manually built (and even in worst case, only tagged and globally pushed) dependencies is horrible for cross-module development, like large scale refactorings and the like.
This is exactly what I disagree with. It forces you to consider git your package boundary. You're now organising your source as if it was a package registry, when git can (and should) be orthogonal to that. Your problem with cross module development may even be because you're using git this way. If you want to do cross package development, having them in a monorepo and building two artifacts is the easy way. If that's not an option because the two packages need to be separate, you need a workflow that pulls the source together again.
To say nothing about hardcoded repo URLs (not resolvable identifiers), transient dependencies, URL schemes, and trying to pretend github is the only package source.
