The article didn't mention Python's atomic refcounts. They're very bad for cache usage as they're constantly invalidating cache.

The only version of Python that uses atomic reference counting is the very new free threaded version.

Non-atomic refcounts invalidate cache as well, they're just not as expensive.

> It's 2025 and the closest I can find is a dictation app on my newest phone that uses online AI service, yet it's still not that great [...]

> Is there anything equally effective for any of you nowadays?

I'm not affiliated in any way. You might be interested in the "Futo Keyboard" and voice input apps - they run completely offline and respect your privacy.

The source code is open and it does a good job at punctuation without you needing to prompt it by saying, "comma," or, "question mark," unlike other voice input apps such as Google's gboard.

https://keyboard.futo.org/

Thanks for that suggestion.

I know and like Futo, very interesting project. Unfortunately multilang models are not great in my case. Still not bad for an offline tool, but far from "forget it's there, just use it" vibe I had with Dragon.

Funny thing is that I may have missgonfigured something in futo, because my typing corrections are phonetical :) so I type something in Polish and get autocorrect in English composed of different letters, but kind of similar sounding word.

In case you didn't know: `git rebase --update-refs` or to make this the default behavior: `git config --global rebase.updateRefs true`.

These are called stacked branches in git. You're possibly looking for:

    git rebase --update-refs

... or a GUI like Git Cola that does this for you by default.

> This post misses the IMO best indentation scheme for lisp [...]

Likewise, a lispier(?) and more compact compromise?:

    (define (match:element variable restrictions)
        (define (ok? datum)
            (every 
                (lambda (restriction)
                    (restriction datum))
                restrictions))
        (define (element-match data dictionary succeed)
            (and 
                (ok? data)
                (let ((vcell (match:lookup variable dictionary)))
                    (if vcell
                        (and 
                            (equal? (match:value vcell) data)
                            (succeed dictionary))
                        (succeed (match:bind variable data dictionary))))))
        element-match)

It becomes much harder to notice if you have closed all the right matching parens, and hence where a token after the closing paren belongs. When the closing paren is exactly below the opening paren, on the same column, it becomes much easier to see the structure. It's a very good thing for students who just learn Lisp.

But all the cool kids are using paredit or parinfer which means you don't actually ever write the closing parens yourself.

Counting parens is silly when the editor can do it for you.

Likewise, it's better to optimize for experienced readers than it is to optimize for students.

Some time ago parinfer (https://news.ycombinator.com/item?id=42766205) took some attention as a more pythonesque approach to matching presentation and meaning. I liked it, but it seems that it didn’t catch on, alas.

How do you know it didn't catch on? It depends on Lisp! The fraction of programmers using parinfer is bounded by the fraction of Lisp programmers. (I think I might have seen some fledgling experiment with parinfer for other languages, though.)

I'm highly resistant to novelty in this area, yet even I am using parinfer. A crappy implementation in Vim, at that, which only works in One direction: indent -> parens, and can get into an infinite loop fighting with Vim's undo.

Well from what I see on the emacs corners of the internet, not so much discussion.

Also I recently read on an HN thread I started: it was taken out of Calva due to bugs no one fixed.

More specifically, everyone is using some variant of rainbow-parens

Paredit has lots of great ways to do that sort of thing, though, while keeping things balanced. In emacs with paredit, providing a prefix argument to open paren lets you surround n sexps in the new parens. There's also slurp and barf to move sexps in and out of parens.

Editing for lisp mirrors the language as a whole in that there's a learning curve, but once you've climbed it, it's a joy to work with. Because the syntax is so uniform, all you need is a handful of extensions/commands for full blown structural editing.

I get by splendidly in emacs with nothing but paredit and convenient keybindings(not a huge fan of paredit defaults).

You need to clarify your example, because it appears that you are inserting `+` and `3` between existing parens rather than shifting them.

But regardless, I think the answer you are looking for is:

Some of the coolest kids of all use rainbow delimiters so that they can easily identify the matching closing paren with their eyes!

I tried, I'd need to crank the font size up to 14+ to discern the difference ;)

Writing code is usually easier than reading!

In Rust I came to the opposite conclusion.

One webserver framework, Axum, has the trait IntoResponse which is returned by something that implements Handler. A lot of things implement IntoResponse and/or Handler. In plain English you have handlers, these are parts of code that get selectively invoked for a request. The handlers return data that can be made into responses. It's powerful, but if something doesn't fit exactly, the Rust compiler throws gibberish errors at you. It's finnicky as hell.

But once you have written something that works, it is beautiful to read.

So it's difficult to write such code, and if it's easy for you then it's because you mastered the art.

If you're not used to the language, the conceptual models of the codebase you are working on, or you're working with obfuscated code. Otherwise it should be much faster to read and understand the code somebody else wrote than to write it from scratch?

No, I mean, in general, including languages which I work with for 20-25 years. Reading code is still harder than writing.

I can certainly think of examples where reading code is harder than writing it, but given that much of my professional role has been dissecting the horrible code written by other people in order to figure out not only what it does, but also what it was supposed to do, I simply disagree. Reading code is just more boring than writing it.

Here is a truly brilliant game. It's Google Bard vs. Chat GPT. Hilarity ensues.

https://www.youtube.com/watch?v=FojyYKU58cw

Qt5 to Qt6 is nothing like Python2 to Python3.

The lessons from (Qt3 to Qt4 and) Qt4 to Qt5 have been learned and moving a large project from Qt5 to Qt6 is not that hard comparatively. There are a few minor deprecated APIs to handle and it's relatively easy over all.

I even have a stable project that is compatible with Qt5 and Qt6 [1] all in a single code base (particularly thanks to the effort of the qtpy[2] library). It's not that hard, and my opinion includes C++ in that assessment.

[1] https://github.com/git-cola/git-cola/

[2] https://github.com/spyder-ide/qtpy

> The lessons from (Qt3 to Qt4 and) Qt4 to Qt5 have been learned

Have the lessons been learned ? They say this all the time when they release a "new" version.

While I mostly wrote `mutuple` for fun, it's also a proof of concept for solving a tricky pickling problem in the jsonpickle[1] library: restoring object graphs that contain tuples with back-references to the same tuple.

I'm pretty sure there are better ways of handling this edge case, but, hey, it works and was a pretty fun experiment.

[1] https://github.com/jsonpickle/jsonpickle/pull/491

If you're into this kinda thing and are in python land you might also appreciate my friend's project in a similar vein

https://github.com/ugtar/pg_temp

Thanks for the feedback on the animations. I didn't want to keep too large of a .gif in the repo but that's the only format that's straightforward enough to have displayed inline so I had to keep the animation terse (and admittedly a bit too fast).

It is indeed using fzf in a specialized way so that it only searches for git worktrees and nothing more. The use case I have is that I have dozens or hundreds of repos in various locations on disk and this tool makes it easy to instantly jump into any of them.

That's why it's called "gcd" -- git + cd.