I describe my setup and how to use it on a fresh MacBook here: https://github.com/agrounds/dotfiles

Well I do need some way to install multiple python versions in parallel, and ideally the correct python version would be used in each project automatically. I used to use pyenv for this, which puts shims in your path so that it can determine which python executable to run on the fly, but I found that it was sometimes very slow, and it didn’t work seamlessly with other tools. Specifically pipenv seemed to ignore it, so I’d have to use a workaround to point pipenv to the path to the pyenv-installed python executable.

When one tool does both python installs and dependency/venv management, then it can make these work seamlessly together, and I don’t need to screw up my path to make the version selection work either.

This is one of uv’s selling points. It will download the correct python version automatically, and create the venv using it, and ensure that venv has your dependencies installed, and ensure that venv is active whenever you run your code. I’ve also been bit by the issue you’re describing many times before, and previously had to use a mix of tools (eg pyenv + pipenv). Now uv does it all, and much better than any previous solution.

I can’t speak for Scala 3 as I haven’t used it at all. If they’ve limited the power of implicits to a few more structures usages it would be a great benefit to the language.

It converts your markdown files to static HTML, understands Obsidian-specific markdown features, and just looks really nice IMO.

For publishing, I use Cloudflare pages to host the static HTML and Cloudflare workers to build the HTML whenever I push a commit to the GitHub repo hosting my markdown files. Quartz has documentation showing you how to set this up, and it’s all within the free offerings of Cloudflare.

Signed, a dev who would never willingly choose Java over Kotlin for anything ever again.

For a long time prior to E&M, mathematicians had used an informal notion of “natural” or “canonical” mapping, which meant something like one special mapping out of several available ones. Especially important is the idea of natural isomorphisms. Just knowing that two objects are isomorphic is often not good enough to prove results about them because you have to make a choice about which isomorphism of several you’re using, and you might have to make such an arbitrary choice about infinitely many pairs of objects all at once. Having a canonical choice solves this problem.

Prior to E&M, mathematicians couldn’t formalize this idea of canonical choice. They would hand wave about how natural their choice of isomorphism was and how this allowed them to avoid making arbitrary choices. Then E&M defined categories, functors, and natural transformations to formalize this idea of naturality. Their motivation was algebraic topology, but the abstractions they defined turned out to be extremely broadly useful across all much of mathematics.

[1] https://www.ams.org/journals/tran/1945-058-00/S0002-9947-194...

Also, n-spheres are commonly just called spheres for brevity. So when I say “the fundamental problem of homotopy theory is to compute the homotopy groups of spheres,” I am referring to all homotopy groups of all (n-)spheres simultaneously.

> I don’t see how any of this is limited to spheres.

In fact you’re right, homotopy theory is not just limited to spheres! However, if we could readily compute the homotopy groups of spheres, then we would be able to compute the homotopy groups of any “reasonable space.” Here I’m referring to CW complexes [1] which are a very broad class of spaces that, up to homotopy equivalence, probably includes any space you care to think of. It is for this reason that the problem of computing the homotopy groups of spheres is so fundamental to homotopy theory more broadly.

[1] https://en.wikipedia.org/wiki/CW_complex

[1] https://en.wikipedia.org/wiki/Homotopy#Homotopy_equivalence

[2] https://en.wikipedia.org/wiki/Retraction_(topology)

Also note that every algebraically complete field is infinite. So the finite fields used in CS applications such as cryptography are never algebraically complete.