Not surprising that PDF comments were being used as a task list/tracker. In the same manner, Google Docs supports "@-mentions", "assign to", and "resolved" functionality for comments.
All you can do is send feedback to Adobe somehow and hope they add that feature back in. In the meantime, best to find an alternative workflow.
No, not like that -- you misunderstand. I'm not talking about actively avoiding conflicts. Coordinating to avoid merge conflicts is the same work as resolving a merge conflict anyway, just at a different time.
I'm talking about creating practices and environments where they're less likely to happen in the first place, never incurring the coordination cost at all.
One example at the individual level is similar to what you mentioned, but there's more to it. E.g. atomically renaming and moving in separate commits, so git's engine better understands how the code has changed over time and can better resolve merges without conflict.
But there're other levels to it, too. A higher-order example could be a hot module where conflicts frequently occur. Sure, atomic commits and all that can help "recover" from conflict more easily, but perhaps if the hot module were re-designed so that interface boundaries aligned with the domains of changes that keep conflicting, future changes would simply not conflict anymore.
IMO the latter has an actual productivity benefit for teams/orgs. Some portion of devs just aren't going to be that git proficient, and in this case, good high level organization is saving them from losing hours to incorrect conflict resolutions that can cause lost work, unintended logical conflicts (even though not lexical conflict), etc. Plus, it implies abstraction boundaries better match the changes demanded by the domain, so the code is likely easier to understand, too.
It's kind of difficult to explain in the same way git is difficult to grok on the first try.
Perhaps it's convincing enough to just say:
Git is the fundamentally better at resolving merges/rebases without conflicts than older VCS that don't maintain a commit tree data structure.
Even within just git, using one diff algorithm vs another can mean the difference between git successfully merging vs failing and showing you a conflict
Software is flexible -- there are endless permutations to how it can be structured. Everything else being equal, some code/commit structures are more prone to conflicts than others
I.e. whether a conflict will happen is not some totally unpredictable random event. It's possible to engineer a project's code & repo so that conflicts are less common.
Thank goodness for the Hippocratic origins of healthcare. Wish I could throw his words back at him so he could hear how insane it sounds in the context of healthcare. Just imagine:
You think a doctor sits back and says, 'Gosh, how can we get the price of saving this patient's life down?' No, it's like, 'How high a price can I get and maximize the profit for my shareholder?'"
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:
It's got formatting and locked areas to help layman usage, but it's ofc still a spreadsheet UI and not a dedicated app. A bit of math proficiency and spreadsheet formula knowledge helps.
Could be replicated on other spreadsheet software like Excel or Calc, although Sheets solves a lot of problems at once, like accessibility, sync, versioning, sharing, etc
It's difficult to consider them pollution even if we were to accept the subjective opinion on displeasing aesthetics.
The pollution we're all concerned about tends to be:
Physically harmful
Difficult to confine/localize/avoid/reverse
An externality the economy doesn't sufficiently account for
A burden that's unevenly/unfairly distributed across society
Even light pollution, which is arguably barely physically harmful, has all of the remaining qualities (or nearly) for sure.
If these qualities even apply wind generators at all, they do so very weakly. They can be moved/unbuilt, the "free market" is pricing them cheaper by the day, and if you really don't like looking at them, it's not impractical to avoid them.
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.
Maybe have ocean voyaging ships (e.g. container ships) do controlled release of brine through their journey?
Though probably no way of achieving this via current economic and legal systems. Even if attempted today, ships would probably be incentivized to dump the entire payload the moment they cross into internal waters.
Hedy is a language specifically designed for learning. The things it does to ease the learning curve:
Comes with an online lesson program, so no setup (try it now!)
Has "levels" built-in to the language itself, to slowly introduce concepts and avoid accidentally running into harder/advanced things and getting stuck
As levels advance, it slowly becomes Python, a very popular and ubiquitous programming language, so no "switching to the real thing later".
Is textual, so also no "switching to the real thing later" -- it's "real" from the start
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.