Make is fine unless you want to build on Windows. Then you kind of need something else.
I agree, you kind of need something else instead of Windows if you want to build software.
It is the very slow process creation infrastructure that kills Make as a tool on Windows.
s/Make as a tool on //
Give me a Make that
Give me that, and... well, I'd probably still stick to current-day Make, because those improvements would cause my Makefiles to be backward incompatible. Make is just reliably available on pretty much any arbitrary system, unlike any candidate replacement.
DRY is from a time where one-letter variables were common.
That's absolutely not the case. Please look into the principle instead of assuming you know what it means.
Now I definitely know you haven’t seen a real professional codebase.
Extremely wrong. So much for your assumptions.
Professional git repos are full of one sentence commit messages with little to no explanation of what’s in the change set.
Yes, humans can communicate poorly, of course. But people letting the LLMs do it do not understand what is in the change, and the LLM certainly doesn't. There's no one at all to ask because no one understands what was changed or why.
I'll take “sometimes lazy but they wrote it and their understanding of it can be interrogated”, all week.
Yes. Except without attribution or record of provenance, and we get to charge you and everyone else arbitrarily for access! Are you excited now?
Working professionals are, if at all competent to be committing code to a professional code base, entirely capable of writing their own commit messages.
If they can't write the commit message, they can't sufficiently explain in writing the commit they just made to anyone. So, they should not be working professionally on a code base.
If they are capable of writing the commit message with their own understanding in their own words, but they choose not to communicate their understanding in the commit message? Also disqualifying, they should not be working professionally on a code base. Human communication is essential to this work.
That this is a controversial position, is a clear sign of the Slopocalypse.
But that has the same effect like DB_HOST="${DB_HOST:-localhost} (use the string if not set), which is more readable.
I disagree that the duplicate reference would be more readable. Instead, the reader needs (if they care about the meaning of the code) to double-check whether the two duplicate names are exactly the same, or whether they are subtly different. At which point the reader needs to wonder why the code isn't written using the form without the repeated name. So, that's not a readability improvement.
Related to that: Code with duplicate references in a single expression or statement leaves open the likelihood that one or more of them will contain a typo or an easily-overlooked difference, leading to bugs. DRY is a good principle to avoid that.
yall would be running cuck license Operating Systems if it werent for him and RMS
The best institutions outgrow the failings of their founders. Let's hope Free Software can.
Easier way to avoid waste of time: Stop wrestling with the unreliable word guessing plagiarism machine, and think for yourself.
Also, I’m hardly Mr Torvalds, I can barely get my machine to work properly.
Don't be too hard on yourself. Now that Torvalds has opened the gate to AI slop in Linux, he doesn't know how to get it working properly either.
In the workplaces where I've been pressured to use LLMs for coding, this would not faze them. Management would just say “See, waiting for reviews is taking longer, we can't afford it any more. No reviews, just productivity.”
Plummeting quality of the result is no barrier to a boss that just wants higher numbers to please their boss.
It may depend where the project is and what you want to bring with you.
If you're asking solely about the Git repository: you need to find exactly which commit is the latest one you want to bring, and specify that commit identifier (the hash of that commit) as the “starting point” when you create a new branch.
git branch […] []
https://git-scm.com/docs/git-branch
So, clone the repository locally however you need to do that. Then, in your local repository, modify what the branches point to:
e.g. If you determined the latest commit you want to bring, has commit identifier “deadbeefbad1dea”, you can create the branch named “before-the-slop”:
git branch before-the-slop deadbeefbad1dea
Now the new branch “before-the-slop” has all the commits up to that, and no further. That's what you'll base your fork on.
git branch before-the-slop
git rev-parse HEAD # → deadbeefbad1dea
Then rename the old “main” or whatever branch, to something like “sloppified-project-main” that gets it out of the way; rename your “before-the-slop” branch to “main”; and set “main” as the default branch in your repository.
git branch --move main sloppified-project-main
git branch --move before-the-slop main
git config set --local init.defaultBranch main
Some time later, when you've confirmed your repository is how you like it, delete the “sloppified-project-main” branch:
git branch --delete sloppified-project-main
and breathe easy.