No, the discussion started with a the article from Bun, stating that rust has some technical advantages for them. The response from the Zig creator is a bunch of personal attacks directed at one guy, like calling him a stinky manager. All of these are fully unrelated to which language is better for Bun.
This is like the textbook definition of an ad hominem.
Ad Hominem is only a fallacy when the speaker's personal qualities are irrelevant to the topic at hand. When one man has unilateral control over a project, you have to consider it as an extension of their personality.
To be pedantic the ad hominem fallacy is about trying to deny an argument by attacking the author, so in a discussion about zig Vs rust if Andrew isn't trying to enter the discussion and just argue "that guy was stinky, glad he is gone" is not really an ad hominem, just not classy let's say.
You're both right: the essay does not really contain ad hominem fallacies, but the essay itself is surely an ad hominem attack, on Jarred as a person. No judgment here, I don't know Jarred or Andrew at all, but like other commenters I did find the closing paragraphs saying the author has no ill-will towards Jarred quite unbelievable.
But he is. Both in the title, and in later half of the blog post, he directly enters that discussion. I'm not saying an ad hominem argument is always bad, but this clearly is one.
> This is like the textbook definition of an ad hominem.
No, it isn't at all. Ad hominem is only in effect and fallacious when the logic turns on the personal attack. "You're wrong because you're stupid" is ad hominem. "You're wrong and also you're stupid" is impolite, but logically fine.
To clarify, I think that the entire "History" section is unrelated to Andrew's argument, only the "Addressing the Blog Post" section actually contains arguments, and that section doesn't contain the rude comments, it's focused on technical decision-making.
Oh yes, I didn't clarify that I meant an argumentum ad hominem, which isn't the same thing as the informal fallacy of the same name. So yeah, I agree, this isn't directly fallacious.
prepending argumentum is literally just expanding the informal name for the fallacy to the full name of "an argument to the person", easily verifiable with one search query. unless you are saying that you were 1. originally just making your own contraction from argumentum ad hominem, 2. normally use latin in online forum comments, 3. often use ad hominem in your own speech to mean a different thing from the common parlance, i think this is an Obvious Fabrication (!!!)
Here it's a type of argument, and it's only sometimes a fallacy. Seems like this how it's defined most of the time, unless you explicitly look for "ad hominem fallacy". Ad hominem without any context can be vague, I guess, so I tried to be more explicit.
I don't know, maybe I'm wrong, English isn't my first language, but I think "Obvious Fabrication" (capital letters) is a bit silly.
> ad hominem, type of argument or attack that appeals to prejudice or feelings or irrelevantly impugns another person’s character instead of addressing the facts or claims made by the latter.
> Ad hominem arguments are often taught to be a type of fallacy, an erroneous form of argumentation, although this is not necessarily the case. A number of scholars have noted that questioning a person’s character is a fallacy only insofar as the person’s character is not logically relevant to the debate.
You are right! The link does discuss cases where it's not a fallacy - in those cases, it is instead a valid argument. Again, not what you said.
Well, this seems like a very dangerous way of using AI. If you keep pushing until you get back an answer that makes sense to you, you might just get your own believes fed back to you.
Yeah, when you had multiple agents working on the same machine, branch isolation was no longer sufficient.
A repository folder can only be on one branch at a time.
A worktree is basically equivalent to a cp -R + git branch, which allows this new workflow to occur.
I loved this particular historical insight as to why `git worktree` was added in 2015:
Before worktrees, kernel devs faced a major inconvenience when switching contexts, e.g., stopping feature work to fix an urgent bug on a release branch.
Running git stash and switching branches alters timestamps on thousands of files.
This forces `make` to perform a full re-compile, which can take up to an hour on large kernels.
Sadly worktrees do some stuff with the git folder that's made one development environment we inherited incompatible. Something about the .git folder not being a fully real .git folder maybe
Hah, I have a prototype of the same idea on my backburner! Excited to see this, though I don't understand some of their design choices. Will need to check out more closely.
I don't understand what docker problem would be solved by multiple git directories but not by multiple work trees?
Regardless of whether the former solves it, I was going to suggest you could use compose or whatever in your 'human' tree, and then tell the AI to use equivalent docker commands without using compose, so it gets anonymous/its own named containers, but you keep the convenience.
I use Conductor's spotlight (and a Pi extension I derived from it) but it's not perfect. Once a migration executes, I'm pretty much bound to it but at least once, I have just backed up the database before switching and then restored that.
I use a skill that basically boils down to 'keep track of ongoing work in a json file, create a new numbered clone for each separate thread of work, delete when done'. Worktrees are too opaque and not entirely isolated for my liking.
I've toyed around with worktrees but haven't found them very useful beyond that. I generally find it much easier to carefully prompt an agent so $TASK1 does not interfere with $TASK2
I tried them a while back and they were more annoying than anything. The only real use-case I have for them is stashing long-running changes that are not ready to be committed... but really probably should be anyways.
I set up multiple work trees in one vscode workspace last year and wrote in the agents.md how to merge branches - but I spend about a third of the time helping agents integrate and merge. I remember wishing the tooling would catch up
I used to create multiple local worktrees and mount the sub directories using Docker. This approach had significant limitations because many paths in the agent and .git files were hard-coded.
i have some fun experiments i'm doing with full virtualization middle ware of all sys calls for agents tools/shell commands/io, still far from daily driver, but allows me to do a very rich overlay / virtual file system tom foolery in place
“Before the Freedom of Information Act, I used to say at meetings, 'The illegal we do immediately; the unconstitutional takes a little longer.' But since the Freedom of Information Act, I'm afraid to say things like that.”
Great idea, to include learning into the regular work.
Can you explain how the lessons are generated?
It looks like there are no pre-generated lessons, they are created on the fly by the AI. Wouldn't it be possible to write a skill or similar that does the same with your existing coding agent?
After agent defined a general direction and send the proposed course via MCP, we search the internet to generate the structure of the course (what to include, what requirements are necessary etc.), then we give it access to a number of tools that create interactive materials in the course, to make learning more engaging.
We consulted behavioural scientists, and decided that the effortful activity of learning has to be separated from effortless-ish activity of AI-assisted coding, to make lessons more engaging. We also can control UI/UX much better than if lessons were delivered via CLI.
This is like the textbook definition of an ad hominem.