But it doesn't do that. "Imagine how you'll be wrong in the future" is just as shiftable as anything else, and has the distinct rhetorical advantage of being unfalsifiable.
The substantive difference is that you're asking me to dream up ridiculously improbable scenarios, which is probably the actual point. Just like "The End is Near Accept Jesus" guy on the street corner gets what he wants as soon as I engage.
To quote a famous movie about doomy AI scenarios: "the only winning move is not to play."
I think I'm coming across as confrontational, which is genuinely not my intention - sorry about that. Not trying to score points or anything, just encourage people to introspect a bit :)
I think your viewpoint is totally valid, and I'm not trying to argue against it.
The bar is high, but there's probably some combination of events (combined with a high confidence in my own lucidity over an extended period of time) that would convince me.
I'm not asking for justification, just for people to introspect about what, if anything, it would take for them to consider AI a serious threat. No justification needed, and really no need to post it here, just think about it and remember it in the future.
In other news, evangelical christians ask scientists to stop publishing about evolution.
We apparently have a moral obligation to protect existing power structures?
Tao should maybe consider there are people who are indifferent to, or actively want to tear down, his institutions; why should they cooperate in preserving them? Whatever happens has to be resilient in the face of defection; any scheme where everyone is expected to agree to not use AI in a way he doesn't like will not qualify.
I think he's in the "bargaining" stage of dealing with loss right now.
You have a practical obligation to obey existing power structures. That’s what makes it a power structure. What do you all think is happening here? There have been people who decided what math gets published for centuries.
> In other news, evangelical christians ask scientists to stop publishing about evolution.
not sure it's comparable, but the issue is that for a lot of those mathematical results, they don't really have utility by themselves. The utility is the new branches/understanding that's being developped.
This article doesn’t present much motivation for why you would do this.
To me it reads a bit like, how we built our office without desks: it turns out if you stack two chairs on top of each other, you can balance your laptop on the top and you’ll also have a shelf on the bottom for your things.
> it turns out if you stack two chairs on top of each other, you can balance your laptop on the top and you’ll also have a shelf on the bottom for your things.
But that sounds kinda unstable and doesn't really provide the full benefits we expect from a...
> This article doesn’t present much motivation for why you would do this.
For those working with databases, it's easy to come up with a bunch of reasons. ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
What if all we need is dumping a big old JSON in a container?
This idea is very enticing. The scale of this whole NoSQL thing is pretty telling.
The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
> ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
Hmm, neither of those been necessary for me. ORMs is a choice, you can choose not to and still have a proper design and architecture and not suffer from that choice. Requires you have programmers who know how to use SQL, which seems less and less common as the days go by though, so understandable most reach for an ORM.
Schema migrations that can "easily result" in data loss is even easier to avoid though. Don't drop the column/table in the same step you copy data to the new place, or do the migration via application code which gets cleaned up later, to catch most of the stuff before one bigger copy, and then the eventually DB cleanup.
Guess it depends on how careful you want to be, or how careful your agent lets you be, I guess. But it's definitely possible to avoid both of those "necessary evil", which I guess makes them just "evil".
> The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
This sound like: what if we dont actually need a table and instead we only care about four legs and a wooden plate.
It does take a few days to stop missing interactive rebase.
But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
> say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
This is the best pitch for jj I have seen yet. This should practically be the first text on their website.
jj just makes lots of git operations go from "technically possible if you're creative enough" to "<= 3 solutions, one of them probably being obvious". jj lowers the skill ceiling of git, and raises the floor.
How many of those do you need? How do find the correct arguments and git checkouts to do before? Are you sure you remembered to do everything? What if there are merge commits?
Why would I do a checkout before? I don't want to modify the worktree? Maybe I in fact also want to alter the worktree, but that's unrelated.
> Are you sure you remembered to do everything?
Am I sure I have all my files ordered? No. Does it matter? Also no. Are you sure you have no bug in your commits in JJ?
If I want git to alter some set of commit chains, I can tell it to. Actually I never needed to do that, because I don't work on several thousand branches at the same time. I prefer it to not alter unrelated branches automatically, just because some earlier commit changed that is in both. Such things actually undermines the trust I have in a tool, because it does things I haven't told it to do, even if I'm aware it does these things.
> What if there are merge commits?
Then I resolve them. Merge conflicts occur, because there is some actual conflicting change and often it is also semantic. These don't go a way by changing the VCS. On a theoretic basis, these require outside information(=decisions) that is not there yet. There are more often semantic conflicts, that are not syntactic, then there are the other way around. If you are referring to doing the same merge conflicts again, I can tell Git to resolve them automatically too, but it actually occurred too often, that this is not actually what I want, so I actually dislike that feature now.
Separate git rebase commands. JJ manipulates the whole DAG in singular operations, where as with git you're working one ref at a time. And carefully managing where one ref intersects with another, to rebase those commits only once, reusing the rewritten commits from the previous git rebase. With jj you just say "that thing, over there" and all descendant commits and bookmarks are updated, no matter what the shape is.
I do, but I don't really get it, because you did learn the jj command. I mean you could have learned jj first, I would understand that, but I presume that is not the case.
that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management.
I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO.
With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.
Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah.
But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going
back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.
> Along with the appropriate git stash and git stash pops
If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all.
> But if the cherry pick doesn’t cleanly apply at the current HEAD
If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use.
> then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick
You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work.
> though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem
It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that.
> so you lose your commit message
You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never.
> maybe detach your head
I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state.
> start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase
Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve.
> I’m usually going back to git reflog to try to find the last point where history made sense
Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert.
> But I said I didn’t want to think about this anymore.
If I may ask, how much time have you spent trying to learn use jj? I ask because I've seen a strong tendency for people to who have never used it to argue against it. I see much less arguments against it from people who understand both Git and jj well. But that's just my impression; I may of course be wrong.
Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later.
I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.
I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.
What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index".
I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it.
I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.
I loved the staging area in git. That was the biggest thing that held me back from adopting jj for a long time, thinking it was a huge step backwards.
It wasn’t. I was wrong.
The staging area is just a commit like any other, only due to git’s design it has to be special-cased everywhere. In jj it’s just a commit.
I do all my work on an unnamed commit on the tip of a branch. As I complete bits, I extract out cohesive sets of changes into new commits (split) or as patches of earlier commits (squash).
reply