Git Repositories as a Module System
-1 points by iamalnewkirk
-1 points by iamalnewkirk
A while back you expressed frustration at how quickly people dismissed AI writing, saying it was just another tool and it's the author's job to use it responsibly.
I think this piece would read a lot better if it didn't use AI.
Thanks for your feedback. I mean that sincerely. No snark. What I'm most interested in is sharing my ideas. If the writing style or tone or mechanism gets in the way of that, I want to know.
If you don't mind, could you share an example from the piece that uses AI, and explain how it. could be improved!
I could be wrong, but the first paragraph:
Every package manager you use daily shares the same architecture. A central registry. A manifest format. A publish step. An install step. npm, pip, cargo, brew. The ceremony differs, but the shape is identical. And for managing complex dependency trees across thousands of packages, that architecture earns its weight.
Smells like LLM-generated writing to me heavily; nouns as sentences, something that happens in a couple more places in the article, and in many articles I've read that have been written with LLM usage.
The whole text until the first header could be replaced with: "Package managers are the right solution in many scenarios, but sometimes you need only to pull some files from another Git repository with no package manage features such as dependency version resolution".
In my personal opinion, if a text smells of LLM, I stop reading. Unless a text is difficult to read because of excessive language errors, I tolerate much more untrained writing than LLM-smelling text.
I had my writing reviewed by professional editors for a few years. The best advice they gave me is that the less you write and the simpler you write, the fewer errors you're going to make. Writing less and simpler is hard, but doable. That first paragraph in your article uses "ceremony", "differ", "shape" (as a metaphor), "earns its weight"; which are uncommon expressions than are likely to be difficult for many of your readers. Fancy language is fancy, but unless using fancy language is your goal (which is a respectable goal: there's very little poetry I like, but I do enjoy some poetry!), fancy language likely conflicts with your other goals, such as communicating an idea.
What I think about when I edit is the most efficient article I've found about writing. "Avoid jargon and cliches" covers most of what I have mentioned here, but most people can benefit from reading all of its parts.
@koala Excellent feedback. Thank you very much for taking the time to explain your point of view. I'll definitely take it into consideration. I'll give the article a read as well.
@koala covered a good example of a direct replace, so I'll instead talk about top-level strategy of why AI is generally a bad example for blog posts.
A blog post generally has some mix of three goals:
AI-written articles cannot by definition do (3). For all I know, you copied a prompt output wholesale, so I have no idea about your credentials. I am also biased against any arguments it makes, so doing (2) is much harder. So the main place where AI might be useful is in (1). I imagine this is why your previous examples of "good use of AI as a tool" were all github readme docs, which are purely about information.
Generally, though, informational blog posts need to establish credentials (which github readmes do not). After all, we have a choice on whether or not to read it, so we need to get at least some initial buy-in to start! This all means that AI writing hurts more than it helps.
For blog posts, the best use of AI as a tool is for things that don't need credibility. Code scripts are a good example: you don't need to establish credibility because it either runs or it doesn't. Proofreading, critique-proofing, and brainstorming are also good uses.
I have been using “flag as off-topic” for slop posts. This isn’t quite off-topic, but I am not sure exactly what the best flag to use for that is. I understand policies for AI generated submissions are not in place yet or are only emerging, but at the moment I think we can still use our best judgement (and trust the moderators to use theirs).
How about not using any flag? Maybe just read and move on. How about not abusing the flagging system, selfishly and merely to signal your personal dislike for a submission? Deliberately misflagging something (out of spite) and then confessing to it, is wild.
git from doesn’t resolve dependencies. It doesn’t manage transitive installations. It doesn’t maintain a lock file or a dependency graph. If you need those things, use npm, pip, or cargo. They’re good at that job.
I think it might be better to just use git submodules at this point instead. Using submodules gets you tracking. Git anyway is hostile to the idea of cloning a few directories in a repo, so you have to clone everything anyway. The only way to do that on GitHub used to be via svn, but it is phased out now.
A module system must be able to fetch new changes, and deal with accidental local changes.
The problem with Git submodules is precisely the tracking bit (and the complex setup).
Sometimes you don't want or need that. Sometimes you want to use other repositories as a source or templates or seed, to be integrated into derivative repositories. Currently, there's not an easy way to do that, and this tool solves that.
--performruns arbitrary Bash. There’s no sandbox, no permissions dialog, no verification step. Runninggit from <untrusted-repo>with--performis the same threat model ascurl ... | bash.
So, Nix flakes but less secure?
this is hardly a nix flake... It doesn't do anything flakes do. It's more akin to a dotfile manager, like stow, but integrated into git.
The executing arbitrary bash from a .gitfrom is a odd choice to introduce here..
Exactly. One of my major use cases for this, even though it's not exactly advertised, is to have templated Git repositories.
The executing arbitrary bash from a .gitfrom is a odd choice to introduce here.
The .gitfrom lives in the source; it's a way for the owner to say, "here's what I want you to have".
Here's an analogy using Python:
Give me everything:
from math import *
Analogous to:
git from https://github.com/python/math
Give me what I asked for:
from math import sqrt, pi
Analogous to:
git from https://github.com/python/math --include sqrt --include pi
If there's some setup that should happen automatically, that's what --perform is for.
Nix flakes
I agree with @sigmonsez. Nothing like Nix flakes. Not in terms of functionality or sophistication. Lately, I've been on a kick to create small, powerful tools that do one thing well. Getting back to the Unix philosophy.