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.
I use magit on a daily basis. And I do use tig occasionally (I don't like lazygit). Most of my magit workflows only requires a handful of keys (most are only two keys). If you've not tried Magit before, it's like vim for a git repo. tig is more barebones, but I could quickly configure it to be able to do most of the magit tricks I need.
Git cli is tedious. But like all cli operations the goal is always to script your workflow or alias the most used commands in something shorter. I'm sure that jj may have an easier learning curve. But some people do know how git works and like the level of control over commits.
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.
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.
Yeah, and back then people moved the goal posts too, saying Deep Blue was just "brute-forcing" chess (which isn't even true since it's not a pure minimax search).
Both of them contained a search algorithm that explored some moves from each considered position, usually not all moves. Both of them contained logic (learned or programmed) to evaluate moves and/or positions.
The differences between them are many, but brute force doesn't enter into it in either case.
We tried this experiment with humans, back in the 17th century, and only a few[1] out of millions managed it given a whole human lifetime each.
[1] Obviously Newton counts as one. Leibniz like Newton figured out calculus. Other people did important work in dynamics though no one else's was as impressive as Newton's. But the vast majority of human-level intelligences trained on texts prior to Newton did not create calculus or derive the equations of motion or come close to doing either of those things.
Newton did it at 23 and there would have been very few people with mathematical training. The LLM would be trained on the entirety of recorded human knowledge and mathematics up to that point, and would get to use a lot more energy so it still has a massive material advantage over young Isaac. Yet I don't believe calculus would magically appear in its response.
A good way to look at it is to compare it to today: LLMs are already trained and are operationalizing a lot more mathematical knowledge than any human, including experts.
Why are they not coming up with paradigm shift in knowledge expression/discovery like humans did back then?
LLMs have been trained on a lot more data than any single human (text wise at least) for years now and these sort of results have only been possible for the latest crop of models in the past few months. Models get better as they get better.
The argument is whether models of today, suitably trained on pre-17th century data (if comparable quantity was available) would be able to "invent" calculus et cetera.
If we believe today's models are sufficiently capable to have been able to do so, why are we not getting these types of results today compared to the entire world knowledge and especially math?
Are research mathematicians simply not prompting LLMs in the right way?
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 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.
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.
That goes in the same bucket as rebase. Until you know what it does, you'll be fine avoiding it.
Since people are sharing their experiences and my recent one is relevant to edit, I'll go:
Working on a feature recently, I ended up making 3 changes ("commits") on top of each other and hopping between them via jj edit.
The first change wasn't feature specific, it was extending the base project in preparation.
The second change just added a doc describing all the changes needed for the feature.
The third change removed the doc as parts were implemented, bit by bit.
As I progressed on the third change & found stuff I'd missed at the start of this process, I jumped back to edit the first change (maybe I had a bug in that base project extension) and the second change (oh hey, I found something else that needed to be done for the feature).
It sounds crazy compared to a git workflow, but at the end of the process I have 3 changes, all tested & working. If I was doing this with git, I'd have to rebase/squash to get the final changes into a neat clear history.
I suggested that since you seemed really concerned about editing the commit that you just told it to edit. Use 'edit' all you want if your goal is to edit commits, otherwise 'new' does what it seems like you're expecting...
edit is useful and there are good reasons to use it, 'never use edit' is like 'never use goto' i.e. false - but if you're just starting out, jj new/jj squash is the way to go indeed.
(my particular favorite reasons to use jj edit are git-native tools which expect to work with uncommitted files e.g. autoformatters, linters, etc. which have been scripted in CI/dev workflows such that they cannot accept a list of files as params)
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.
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.
Whoa whoa whoa let's not bring the accountants in!
Code isn't a liability b/c it costs money (though it does). Code is a liability like an unsafe / unproven bridge is a liability. It works fine until it doesn't - and at that point you're in trouble. Just b/c you can build lots of bridges now, doesn't mean each new bridge isn't also a risk. But if you gotta get somewhere now, conjuring bridges might be the way to go. Doesn't make each bridge not a liability (risky thing to rely on) or an asset (thing you can sell, use to build value)
Even proven code is a liability. The point of it being a liability is that it costs time and effort to maintain and update.
The same with the bridge. Even the best built and most useful bridge requires maintenance. Assuming changing traffic patterns, it might equally require upgrades and changes.
The problem with this whole “code is a liability” thing is that it’s vacuous. Your house is a liability. The bridge that gets you to work as a liability. Everything that requires any sort of maintenance or effort or upkeep or other future cost is ina sense a liability. This isn’t some deep insight though. This is like saying your bones could break so they are liability. OK, but their value drastically outweighs any liability they impose.
If Delta was going bankrupt it would likely be able to sell individual planes for the depreciated book value or close to it.
If a software company is going bankrupt, it’s very unlikely they will be able to sell code for individual apps and services they may have written for much at all, even if they might be able to sell the whole company for something.
The other half of the quote about liability is that the capabilities of the code are an asset. I don’t know if your bankrupt company would be able to sell their code, but they sure as hell couldn’t sell their capabilities without the code.
You're hinting at the underlying problem with the quote. "Asset" in the quote reads, at least to me, in the financial or accounting meaning of the term. "Liability" reads, again to me, in the sense of potential risk rather than the financial meaning. Its apples and oranges.
Liability is also an economic term. As in, "The bank's assets (debt) are my liability, and my assets (house) are the bank's liability."
I don't think it's a wrong quote. Code's behavior is the asset, and code's source is the liability. You want to achieve maximum functionality for minimal source code investment.
Sorry, my point wasn't that liability doesn't have a meaning in finance. My read of the quote is that it uses liability in the sense of risk not debt on a balance sheet.
I could always be wrong though, that was just my interpretation of it. I don't get how code could be a liability in the financial sense, but I do get how every line of code risks bugs and other issues.
Tech debt is not part of a financial account or disclosure though. Yes those are forms of debt, no they aren't financial debts or financial liabilities.
If we're bringing in other industries, you'd be wise to consider banking. Savings accounts are something most people would consider an asset, because it's money the bank has on hand and can use for loan purposes.
But it's the opposite, deposits are liabilities because they need interest paid out and can be withdrawn at any time.
Just because the company has a thing that could be assigned value doesn't make it automatically an asset.
Not a terrible example. The planes delta owns are delta’s assets; the planes the leasing company owns are the leasing company’s assets. The point is, the code and the planes are assets despite the maintenance required to keep them in revenue-generating state.
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?
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.