> This is largely a discoverability problem

In my experience it's not a discoverability problem at all. Not even a little bit. My problem with emacs batteries has always been stability between different combinations of packages. I know how to use dired, I know how to install elisp packages, I know how to write emacs lisp myself. The issue with emacs is that it's difficult to create large packages with "batteries" because any additional package added can bork some random, seemingly unrelated package. E.g. back in the day (maybe around ~2020s or a bit before?) I've been using Spacemacs without vim keybinding, and although batteries were included and I was happy, this issue I mentioned above was even bigger. Because I constantly had to deal with installing a package and discovering that it broke some unrelated LSP, programming, or autocomplete package. It gets quite a bit frustrating at some point. Since this LLM madness started, I never really installed anything LLM related to Emacs, and have been using other text editor for LLM related stuff, Emacs for everything else (especially if there is a strong Emacs package, e.g. agda2-mode is incredibly good, almost flawless!)

Again, just my humble two cents. Obvious Emacs is amazing, and in many ways it's still my go-to, I just think that the biggest issue for me has always been randomly broken packages. Maybe I'm a terrible elisp programmer, that's possible! But I've been using emacs everyday for decades, so idk...

In representation theory we reduce problems of algebra to problems of linear algebra. E.g. the standard example is to find representations of groups, this way we can represent group operations as matrix operations. We do this because (1) linear algebra is mathematically very well-understood, (2) in terms of applications, linear algebra is computationally fast, faster than implementing the group with code manually (at least, in general).

In the OP post, author reduces quiver (which is a particular kind of algebra) to linear algebra. Once this is done, the intention is to solve problems of quivers in the language of linear algebra.

https://en.wikipedia.org/wiki/Quiver_(mathematics)

https://ncatlab.org/nlab/show/quiver

A quiver is simply just the data of a category, i.e. a "category" without any of the laws, namely identity and composition.

They're not isomorphic to DAGs since Quivers can have multiple edges between the same set of vertices, directed multigraphs, if you will. There is also no requirement of acyclicity (DAGs are acyclic).

For example, in the category of Sets, vertices are sets and edges are functions between sets, so between e.g. N and N there will be infinitely many edges (all functions between natural numbers) with a particular distinguished identity edge that maps f(n) = n due to category laws. So if you turn the category of Sets to a quiver, you'll have infinitely many edges N -> N and one of them will happen to be the identity function `f(n) = n` but you "forgot" its "identity" relationship/law when you reduced the category to a quiver. This is not a graph, since within your data you need to express that there are other edges between N -> N for example `f(n) = 2*n` is another edge (we can call these multigraphs).

Sometimes I have a problem, I just generate bunch of "possible solutions" with a constraint solver (e.g. Minizinc) which generates GBs of CSVs describing bunch of solutions, then let DuckDB analyze which ones are suitable, DuckDB is amazing.

It all depends on how powerful computers you want to support, if you assume your users will allow WebGPU use and your application needs 2D or 3D graphics (or more niche, GPGPU compute) imho Godot engine is actually pretty good to develop any web app (not just games) since it can compile its shader language down to WebGPU. Again, you'll probably need to write most of the code in C++ and compile to WebAssembly, which is pretty doable with Godot. If you just need graphics and very light CPU processing, GDScript will be enough. Once you do this you still need to wrap the webpage as a desktop app, I think Chrome browser has tools that can help with that.

The other obvious way is to use something like Electron and writing most of the code in Javascript. This will probably get you far if you need something simple but the memory and CPU usage will be much higher than necessary. Since the app ends up being so bloated, I personally don't like things approach, but apps like VSCode exist.

* Creative writing: Gemini is the unmatched winner here by a huge margin. I would personally go so far as to say Gemini 2.5 Pro is the only borderline kinda-sorta usable model for creative writing if you squint your eyes. I use it to criticize my creative writing (poetry, short stories) and no other model understands nuances as much as Gemini. Of course, all models are still pretty much terrible at this, especially in writing poetry.

* Complex reasoning (e.g. undergrad/grad level math): Gemini is the best here imho by a tiny margin. Claude Opus 4.1 and Sonnet 4.5 are pretty close but imho Gemini 2.5 writes more predictably correct answers. My bias is algebra stuff, I usually ask things about commutative algebra, linear algebra, category theory, group theory, algebraic geometry, algebraic topology etc.

On the other hand Gemini is significantly worse than Claude and GPT-5 when it comes to agentic behavior, such as searching a huge codebase to answer an open ended question and write a refactor. It seems like its tool calling behavior is buggy and doesn't work consistently in Copilot/Cursor.

Overall, I still think Gemini 2.5 Pro is the smartest overall model, but of course you need to use different models for different tasks.

There are countless sources one can get a string from. Surely you don't think filesystems are the only source of strings?