sswatson

I’ve never used magit but my impression is that it’s similar to jj in the sense that it smooths out git’s rough edges in an elegant way and in the sense that it’s hard to properly appreciate without using it.

That being said, I also much prefer a UI layer (lazygit originally, now lazyjj), and personally I find the benefits of jj to be partly complementary to the UI ones.

That is, after getting used to jj, my problems with git are (1) the CLI ergonomics, and (2) the model is actually more complex than it needs to be, in a way that materially diminishes my experience. Only the first is addressed by lazygit (though maybe magit does both; not sure).

One other point: jj doesn’t actually impose a level-of-control tradeoff on the curation of commits. You can mimic the git workflow by modeling the working copy and staging area as commits (changes, in jj parlance), or you can experiment with any number of alternatives. What git gives you is the opinionated support for the working-copy-staging-area-commit approach.

Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win.

It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.

Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.

What does jjui have on lazyjj? Sincere question; I tried it, and I want to get it, and so far I don’t.

Good on you for spelling out this reasoning, but it is manifestly unsound. For a wide variety of values of X, people a few years ago had no reason to expect that LLMs would be capable of X. Yet here we are.

I don't agree. Many 3b1b videos provide a rigorous mathematical argument in the usual sense (i.e., they don't contain every conceivable detail — math papers don't do that either — but the gap from what is explained to rigorous-as-you-like is routine).

As a representative example, consider his video on the Basel problem. The video features geometric intuition, but it is intuition that drives a proof that is being presented. There's nothing hand-wavy about it.

You're conflating two points: (1) learning math requires work, not just watching videos, and (2) learning math requires proofs, not just intuition and analogies.

Both are true but only the first is pertinent, because 3b1b videos typically contain complete mathematical arguments, not just intuition.

I find this kind of advice to be a more scathing indictment of an interface than a critic could ever muster: asking users to forego available functionality so that some sense of order can be imposed.

No system is perfect, but there's nothing wrong with `jj edit` and `jj new`. Both commands are completely reasonable and do what you think they would do.

The linked article makes a specific carveout for Java, on the grounds that its SufficientlySmartCompiler is real, not hypothetical.

It’s well known and also wrong.

Delta’s airplanes also require a great deal of maintenance, and I’m sure they strive to have no more than are necessary for their objectives. But if you talk to one of Delta’s accountants, they will be happy to disabuse you of the notion that the planes are entered in the books as a liability.

Neither of those assertions means anything. For many years, people have been using them to make confident predictions about what AI systems will never be able to accomplish. Those predictions are routinely falsified within months.

Of course, some of those predictions may also turn out to be true. But either way, we have abundant empirical evidence that the reasoning is not sound.

1. Because no one knows how to do it. 2. Consider (a) a tool that can apply precise methods when they exist, and (b) a tool that can do that and can also imperfectly solve problems that lack precise solutions. Which is more powerful?

The author has exclusive claim to their own aesthetic sensibilities, of course, but the language in the piece suggests some degree of universality. Whereas in fact, effectively no one who is knowledgeable about math would share the view that noncommutative operations are ugly by virtue of being noncommutative. It’s a completely foreign idea, like a poet saying that the only beautiful poems are the palindromic ones.

As the name indicates, a demo is used for demonstration purposes. A personal tool is not a demo. I've seen a handful of folks assert this definition, and it seems like a very strange idea to me. But whatever.

Implicit in your claim about the cost of errors is the idea that LLMs introduce errors at a higher rate than human developers. This depends on how you're using the LLMs and on how good the developers are. But I would agree that in most cases, a human saying "this is done" carries a lot more weight than an LLM saying it.

Regardless, it is not good analysis to try to do something with an LLM, fail, and conclude that LLMs are stupid. The reality is that LLMs can be impressively and usefully effective with certain tasks in certain contexts, and they can also be very ineffective in certain contexts and are especially not great about being sure whether they've done something correctly.

Recently I've used Claude Code to build a couple TUIs that I've wanted for a long time but couldn't justify the time investment to write myself.

My experience is that I think of a new feature I want, I take a minute or so to explain it to Claude, press enter, and go off and do something else. When I come back in a few minutes, the desired feature has been implemented correctly with reasonable design choices. I'm not saying this happens most of the time, I'm saying it happens every time. Claude makes mistakes but corrects them before coming to rest. (Often my taste will differ from Claude's slightly, so I'll ask for some tweaks, but that's it.)

The takeaway I'm suggesting is that not everyone has the same experience when it comes to getting useful results from Claude. Presumably it depends on what you're asking for, how you ask, the size of the codebase, how the context is structured, etc.