It could be even simpler.

Self care is _hard_ for ADHD people. (diet, exercise, hygiene etc..). All these combined together could grind you down into an early grave.

>pattern of many consumer applications degrading in UI functionality and coherence after a certain point?

Sadly they think they are making it better. Most of the time chasing fads.

Sometimes introducing dark patterns, for reasons.

I mean, Apple (and MS) had been dumbing down their OS in the name of usability and security for a while now.

Very interesting. I took a brief look.

What would be the effective use cases for this? - Obviously, for start up scripts (like lua was used with C/C++ traditionally)

I am interested in the the potential of a REPL running in my app which could dynamically execute Lua code. Like nrepl for clojure and Swank/Slime for common lisp.

Is that on the cards here?

I guess people have different working styles.

If you commit early and often, yes this could turn annoying really fast. May be GP works with local-changes/git-index for a bit and commits when somewhat satisfied.

Ok. What can I do with an M4 MBP, with 48G memory?

I am getting ~10 tok/s in M5 Pro with 48 GB with Qwen 3.8 27B. It's workable but very annoying. Also, it's really noisy. On my RTX 5900 I am getting ~200 tok/s and that makes the model truly usable and useful. Though the limit on context size is a huge issue for more serious work.

Yes! I do pretty much the same in Mac.

Multiple desktops(spaces) each with one window of browser (Zen) and one window of cmux and an Emacs frame. One desktop for one task.

CMux has good native AI Agent notifications. So it works well in that capacity too.

Sometimes I wish there is some automatic tiling, but there is nothing good in Mac for that (I tried a couple of 3rd party software, but didn't work out)

I am still wondering about the effectiveness of using grep/awk (and ad-hoc python scripts) in code bases, as opposed to more sophisticated LSP and the like?

Proof happens before compilation, and doesn't require compilation. You can follow the Verus tutorials for the specifics, but you can use it as a standalone verifier or as a compilation "stage" where it'll run its verification and then conditionally continue on to compilation.

Their tutorial seems ok: https://verus-lang.github.io/verus/guide/overview.html

But if you want a more complete tutorial on this concept using similar tools (so what you learn from them will transfer well to Verus, even if you need to learn Verus or Rust specific details) check out Dafny or SPARK/Ada. The latter is mature and used in some parts of the software industry today. The former, I don't know if anyone actually uses it in production though theoretically you can (it generates code in several languages, I have not used it for that myself, just in an instructional capacity).

There is a big difference in there I think.

'for' loop is mutating.

Using 'reduce', you can do the same functionally. In some (somewhat) purely functional languages, there is no choice.

Talking about un-guessable, misleading function names,

C++ std::remove.

I would never have guessed what it does exactly. (It moves elements that match the filter to the front, and moves the end-marker forward. Leaves all the elements in the collection. You need to erase them yourself. )

It returns the new end marker

Oh it's a bit like unordered-delete when using an arena. I guess I would have expected an ordered-delete instead