In a sense, money represents all the future goods and services it can buy, and those goods and services ultimately resolve down to someone's time and effort. Money was conceived as a formalization of IOU's, after all.

So it's similar to asking whether there's a limit to how much time and effort from (i.e. influence over) others one would want.

Must be proprietary, bc TOTP shouldn't be blocked by age of the device

speed up certain types of applications as long as application providers don't have to pay for special treatment

Maybe they mean by doing things like giving slight priority to real-time application traffic like VOIP over streaming over websites vs file transfers, like how home routers can?

Don't think that should be something to charge people more for, though. They're not even able to deliver on their own advertised speeds.

If you were reviewing a "non-trivial" PR from me, I'd recommend not squashing because I would've broken it up into readable atomic commits.

In the long run, nearly the same effect as 100% inheritance tax anyways.

The government won't know the cash has been removed from the economy, but it'll have been removed all the same.

You're getting a lot of conceptual definitions, but mechanically, it's just:

keeping state (data) and behavior (functions) that operate on that state, together

At minimum, that's it. All the other things (encapsulation, message passing, inheritance, etc) are for solidifying that concept further or for extending the paradigm with features.

For example, you can express OOP semantics without OOP syntax:

foo_dict.add(key, val)  # OOP syntax

dict_add(foo_dict, key, val)  # OOP semantics

A title as uninformative as the single . commit messages he suggests writing.

Bare minimums of typo, refactor, whitespace, comments are barely any effort -- less than the thought it takes to name variables and functions.

I really can't agree with completely meaningless messages like minor and .

Seems more applicable to an imperative style, and IMO even still the advice is too dependent on special/actual case details to be generally applicable as a "rule of thumb".

This is just one specific example amongst many of how redundant logic could be simplified because sometimes the branch is an implementation detail and you want to push it down, and sometimes it's not and you want to push it up.

Sounds like an externality that should be paid for as these things are manufactured

Unfair how? It's paid by employers, so kinda makes sense to me, i.e. employer caused the loss of livelihood, so they pay for the benefit to the recently unemployed.

This claim site's privacy policy seems to reserve their right to use your submitted data for marketing and promotional purposes...

to improve our marketing and promotional efforts

We want to provide you information that is valuable to you. If at any time you wish to be taken off our mailing lists ...

That route already exists today as "the web", where the "latest" JavaScript source is downloaded and JIT-ed by browsers. That ecosystem is also not the greatest example of stable and secure software.