In DDD, the model is loaded before any business logic is executed
That's really not a DDD requirement. Having a domain model does not require you to preload data to run business logic. For example, you can easily have business logic that only takes as input a value object and triggers a usecase, and you do not need to preload anything to instantiate a value.
They used it because it was an established term
My graph theory is a bit fuzzy but I think that the definition of a branch in a directed graph corresponds to the path between two nodes/vertices. This means that by definition any path from the root node to any vertex is itself a branch.
I don't think Git invented this concept, nor did any other version control system.
I know that “branch” helps intuitively and visually when it’s actually an offshoot with one root and a dangling tip, like an actual tree branch…
I think that your personal definition of a branch doesn't correspond to what graph theory calls a branch. Anyone please correct me if I'm wrong.
From the article:
By library, I mean any software that can be run by the user: shared objects, modules, servers, command line utilities, and others. By service, I mean any software which the user can't run on their own; anything which depends (usually through an API) on a service provider for its functionality.
It looks like the blogger took a page out of Humpty Dumpty's playbook and tried to repurpose familiar keywords that refer to widely established concepts by assigning them entirely different meanings that are used by no one except the author. I'd also go as far as stating these redefinitions make no sense at all.
Perhaps the blogger might even have a point to make, but stumbling upon these semantics screwups is a major turndown, and in my case led me to just stop reading the blog post on the spot.
Taking UK as an example, you can call yourself civil engineer all day long without having to worry any legal consequences because there simply is no such thing as a licensing system for engineers.
Britain's Engineering Council disagrees.
https://www.engc.org.uk/international-activity/access-to-practise-in-the-uk/
I’m not sold on user replaceable phone batteries, but USB-C was a long time coming.
As someone who had a perfectly fine Android smartphone die because its battery went dead, and had to replace it with an off-brand one to keep it ticking... I can assure you that the lack of support for user-replaceable phone batteries is forcing people to throw away perfectly good hardware.
There are parallels to be drawn between licensed professionals (like doctors, CPAs, lawyers, civil engineers) that they all have time under a professional and the professional then signs off and bears some responsibility vouching for a trainee.
We need to keep in mind that the main value proposition of these licenses is to bar people from practicing. There is no other purpose.
In some activities this gatekeeping mechanismo is well justified: a doctor who kills people out of incompetence should be prevented from practicing, and so do accountants who embezzle and civil engineers who get people killed by designing and building subpar things.
Your average software developers doesn't handle stuff that gets people killed. Society gains nothing by preventing a software developer from implementing a button in a social network webapp.
You can always find a new shitshow
Having to deal with different volumes and types of shit can be a very welcomed move. Perfect is the enemy of good.
They force you think of o(n) and train you better than anything else on how to write your functions (but not how to organise them).
I agree. I think it's all about blind spots. A software engineer spends most of the time reading code, and the changesets they write most of the time are not algorithms or any fancy iteration beyond doing a vanilla for loop over a collection. leetcode-type exercises tend to invert that tendency, and present us with challenges which we would only rarely tackle. It's a good exercise in the sense that it forces a type of usecase we don't often use. Still, their practical usefulness beyond coding crossword puzzles is very limited.
I'm not sure you understand that what a union does or does not do is completely irrelevant and besides the point. Python's protocols add support for structural subtyping, and enable both runtime and build-time type checks without requiring major code changes. Don't you understand what that means?
OP makes a valid point, and a strong one to boot.
Other than name calling, do you have anything to add?