I prefer that, though (it’s in my calendar, but I don’t have to accept). I really can’t stand Outlook’s email-based calendar workflow.
I prefer that, though (it’s in my calendar, but I don’t have to accept). I really can’t stand Outlook’s email-based calendar workflow.
That’s only because the former already implies much of the latter, so they don’t need to repeat it
It refers to a male cousin that is NOT in the same paternal line, so maybe not too uncommon?
avoiding merge conflicts
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:
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.
Even better, learn how to avoid conflicts from happening in the first place!
What kind of quick one off scripts have large complex scopes where variable renames are difficult to track?
Besides, these days Python has great LSPs and typing features that can even surpass the traditional typed langs
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:
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.
Technically, anything can be “hacked”, but that’s the same kind of technically as “any car can be broken into”.
Just like there are ways to mitigate getting your car broken into, there are ways to mitigate getting your system compromised.
deleted by creator
If that’s what you’re looking for, then: https://gitless.com/
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 example doesn’t sound particularly difficult. I’m not saying it’d be trivial, but it should be approximately as difficult as writing a compiler. Seems like the real problem is not a technical one.
Wonder what makes it so difficult. “Cobol to Java” doesn’t sound like an impossible task since transpilers exist. Maybe they can’t get similar performance characteristics in the auto-transpiled code?
Dedicated incremental static type checkers for dynamic languages already exist. In particular, Pyright for Python is fantastic and in many ways surpasses the type systems of classic typed languages