Joined 19 years ago
They played tricks with the “unanimous consent” procedure where senators didn’t know it was happening until after it was too late to object. Multiple senators said afterwards that they were opposed to it.
Garfield’s version seems more complicated since you have to calculate the area of a trapezoid instead of the area of a square, but conceptually they are the same.
It didn't go away, though. It got archived and that archive is still up and running today. Those links you put all over the place should still be working.
> If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.
That's not an accurate representation of what DannyBee said. Moreover, what DannyBee did say is in line with what Google itself said was its goal when the service launched: https://support.google.com/code/answer/56511
"One of our goals is to encourage healthy, productive open source communities. Developers can always benefit from more choices in project hosting."
> Effectively, Google harnessed users for it's own purposes without their consent by means of deception.
This does not appear to be a good faith argument.
None of what DannyBee said in their comment aligns with that interpretation. Neither does that interpretation line up with Google's publicly stated goals when they launched Google Code.
“The market can stay irrational longer than you can stay solvent”
For a concrete example, before Paramount+ launched I predicted that it would be dead in less than a year.
Clearly I was wrong because it’s still going 2 years later. I still think it will die relatively soon, but predicting exactly when is virtually impossible.
They would have to earn $10 million dollars or more in annual revenue to be affected.
I misremembered; it’s 16, not 15
From a consumer perspective it really is a no-win situation. The agreements are specifically designed to make the process as one sided as possible.
Dependency injection makes code easier to test, and I’m a big fan of dependency injection.
What I’m opposed to is the frameworks that automate (and often hide) the construction of the dependencies.
As someone else said in this thread “explicit is better than implicit”.
They optimize for the wrong thing; making code easier to write but harder to read and edit.
Writing code is a one time cost whereas reading and editing it is an ongoing effort, so dependency injection frameworks are optimizing for the uncommon case at the expense of the common case.
Compile-time dependency injection frameworks are a big improvement over runtime dependency injection frameworks because you can at least read the generated code, but they are still a lot worse than manual dependency injection when it comes to editing code.