Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fall back to git too often.
For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.
This is an interesting opinion.
I feel we are nowhere near the terminal state for programming languages. Just as we didn't stop inventing math after arithmetic, we will always need to invent higher abstractions to help us reason beyond what is concrete (for example, imaginary numbers). A lot of electrical engineering wouldn't be possible to reason about without imaginary numbers. So new higher abstractions -- always necessary, in my opinion.
That said, I feel your finer point resonates -- about how new languages might not need to be constrained to the limitations of human ergonomics. In fact, this opens up new space of languages that can transcend human intuition because they are not written for humans to comprehend (yet are provably "correct").
As engineers, we care about human intuition because we are concerned about failure modes. But what if we could evolve along a more theoretical direction, similar to the one Haskell took? Haskell is basically "executable category theory" with some allowances for humans. Even with those tradeoffs, Haskell remains hard for most humans to write, but what if we could create a better Haskell?
Then farther along, what if we created a LEAN-adjacent language, not for mathematical proofs, but for writing programs? We could throw in formal methods (TLA+) type thinking. Today formal methods give you a correctness proof, but are disconnected to implementation (AWS uses TLA+ for modeling distributed systems, but the final code was not generated from TLA+, so there's disconnect). What if one day we can write a spec, and it generates a TLA+ proof, which we can then use to generate code?
In this world, the code generator is simply a compiler -- from mathematically rigorous spec to machine code.
(that said, I have to check myself. I wonder what this would look like in a world full of exceptions, corner cases, and ambiguities that cannot be modeled well? Tukey's warning comes to mind: "Far better an approximate answer to the right question, than an exact answer to the wrong question")
1. Memory safety 2. Better metaprogramming capabilities 3. Algebraic effects 4. Solver/prover awareness
Even if LLMs become capable of writing all code, I think there's a good chance that we'd want those LLMs writing code in a language with memory safety and one amenable to some sort of verification.
Using Rust as an example: Rust aims to provide memory safety at the expensive of developer ergonomics. Personally, I shy away from Rust because I don’t like fighting the borrow checker.
However, with AI agents, Rust could make a lot more sense. Strict errors at compile time are helpful to an agent, which is more than happy to smash its head against the wall until it reaches a working solution.
Following this logic, we could see languages develop that are extremely impractical for humans to use yet provide benefits like memory safety or correctness. But these languages might not look anything like the languages we’re currently used to.
You're right in principle, but it just seems JJ is a solution in search of a problem.
Tools that integrate with git specifically can be tough though, yeah. Some do Just Work, and some very much do not.
I’ve found a “we use jj not git for this project” in Claude.md makes falling back to git rare, but I also tend to incorporate version control into slash commands or skills directly rather than let Claude decide what to do.
A 'commit' 'happens' when you leave a change in jj, i.e. by moving to a new or existing change; that's when you'd run pre-commit hooks.
# Version Control
- IMPORTANT: YOU MUST assume we use Jujutsu ("jj") for version control. Check by running `jj root` (or look for a `.jj/` directory) to confirm.
- If I say "commit", "branch", "squash", etc., assume jj equivalents first.
- You can ignore any `git add` command, since jj always auto-adds.
- Use `jj` commands instead of `git`. Never run `git` in a jj repository.
- ALWAYS prefer jj change IDs over commit SHAs. jj change IDs are stable.
- jj doesn't usually require named branches
- If you need named branches, use `jj bookmark`, but you must manually update the bookmark after making new commits, since they won't automatically get updated
- When reading data from jj, always use `--ignore-working-copy` to avoid snapshotting the working copy (which is slow and unnecessary for read operations). But when writing (commit, squash, rebase, etc.), you MUST NOT use `--ignore-working-copy`.
- If you get "Error: The working copy is stale", run `jj workspace update-stale` firstIt might be ok for human use, but I have definitely seen agents in one workspace start encroaching on another workspace's turf. (Rare, but it's a huge pain to fix when it happens.)