curriculum

Give it some spin with your index finger. Imagine putting a coin between your index finger and thumb, heads side up, resting on your middle finger below — not too different than how most people start a coin flip. With your index finger, rotate the coin in its plane, so that it stays “heads up” but the head is rotating. Now try doing this and simultaneously flipping the coin by flicking it with your thumb at a point on the bottom, close to the edge. If you do it right, you’ll impart a spin. If you impart a modest spin, the coin will never actually flip over, but will just wobble, and will therefore land heads up. An observer will likely not know what you did, because it is hard for the eye to tell the difference between a flip and a wobble at high speeds.

I'm not sure if avoiding Home Manager is the right choice for everyone, but it worked well for me.

Home Manager isn't necessary for declarative management of the user environment -- Nix flakes can do this, too. A long time ago, I kept a single `flake.nix` in my home directory describing the packages that each of my machines needed, and ran `nix profile install .#packages.<machine>` to install them into my user profile. By doing things this way, I learned a lot about writing flakes, and this transferred to other places I used Nix.

What this doesn't do that Home Manager does is dotfile management, but that's actually why I avoided HM originally. First, HM's approach is a bit clunky for my taste: each change to the configuration must be followed by running `home-manager switch` for the changes to take effect. I found this to slow down the edit-and-test loop when making changes to my shell config, etc. Second, the idea of doing all configuration in the same Nix language is cool, but most of the documentation found online about configuring, etc., `git`, will refer to the tool's usual method of configuration.

So instead, I made a quick Python script that manages package installation with Nix, and dotfile management with GNU Stow. The dotfiles and Nix configuration all go into the same git repository in my home directory, so they are tracked together. I've been using this approach to manage several machines for a few years now, and it's been more than sufficient for my needs.

> Seems like a policy set with priorities other then environmental protections.

There are definitely other non-environmental considerations at play, the largest being that the increasing number of home solar installations has reduced revenue streams for utility companies, while at the same time their costs have increased due to grid maintenance and wildfire prevention projects (and lawsuit payouts). Most houses with solar are still heavy users of the grid, yet they pay very little towards its upkeep. This pushes the costs onto people without solar, who tend to be renters or low income households.

> Energy cost has long been viewed as a means to constrain consumption. This new approach seems to undermine that approach given the reduced cost per volume.

The idea that electricity consumption must be constrained makes sense when the electricity is generated by fossil fuels -- replacing a gas furnace with an electric heat pump when the electricity is made by burning coal is not a big improvement. But we're entering a world where most of the electricity is generated by clean solar, and constraining usage doesn't reduce emissions quite as much. In this world, a heat pump powered by solar is a real improvement over a gas furnace, environmentally-speaking. But a heat pump only beats a gas furnace in terms of cost to operate if the price of electricity comes down relative to the price of gas.

From that perspective, removing constraints on electricity usage is not a bug, but a feature.

I think the idea is that California has plenty of solar generation during the day (or is on track to have plenty); what it needs is storage for when the sun isn’t shining.

The new NEM (the Net Billing Tariff) shifts the incentives away from solar generation (which the utilities have a lot of) and towards energy storage. I am in the market for solar right now, and I’ve been running the numbers. Whereas I would have had the greatest ROI with a large solar panel array under the last NEM, I now get the largest ROI with a small solar array + a battery.

I can’t say that my ROI will be the same under NEM 3.0 as it was in the old NEM, but solar is not suddenly a bad investment, as some might claim. A small solar + battery setup will pay for itself in 5 years in my situation. A battery alone (no solar panels) pays for itself within a decade, since you can buy energy for “cheap” during super off peak and store it for use during peak hours, pinning your electricity costs to the lowest of the day.

This is all with existing rates. The upcoming shift to an Income Graduated Fixed Fee will likely come with reduced per-kilowatt-hour rates, which will reduce the ROI for home solar and batteries.

Not quite. Right now, (most) California residential electric bills are entirely volumetric, meaning that you pay for what you use — if you use zero, you pay (close to) zero. Under the new system, everyone’s bill will instead have a sizable fixed component (determined by household income) for being connected to the grid, and a volumetric component (determined by the amount that you use). The new price per kilowatt hour will be smaller than the existing rates.

My claim wasn't that an Income Graduated Fixed Charge would make your electric bill go down from what it currently is -- it could very well go up.

My claim is that, assuming an IGFC is implemented and the marginal cost of electricity goes down considerably, then a heat pump becomes cheaper to operate. You'll be paying the same fixed cost to be connected to the grid, whether you have a gas furnace or an electric heat pump. It might just be that the newly-lowered electric rates finally make a heat pump more cost-effective than a gas furnace.

California is moving towards a system which would introduce a monthly fixed cost based on your income, while simultaneously decreasing the cost of electricity per kWh (see: AB 205). Heat pumps become more attractive after such a change.

Along the same lines, asking

> How many words are in the sentence "This is a test of artificial intelligence"?

yields an answer of:

> There are 8 words in the sentence "This is a test of artificial intelligence."

(There are 7).

I think what you're referring to in your last paragraph is a CEREC crown, but it's not always cheaper. In my case, my insurance covers a lab-made crown with a $100 copay. It takes a few days to be made, so it's slightly inconvenient. Same-day CEREC crowns aren't covered by my insurance, and cost around $500-$800 at the dentists I went to.

I discovered this last year when I went to a new dentist and they recommended two CEREC crowns and a laser gum cleaning at a total cost of around $2000. This was surprising, because I thought my dental insurance was pretty good. Turns out, it is: the dentist was just electing to use more expensive methods that weren't covered by insurance and failed to tell me about the options. I did some research later and found that the laser cleaning was not demonstrably better than the traditional approach in terms of outcomes (though I think the gums are supposed to heal faster) and was not endorsed by the periodontist professional society. I saw some sources which said that the same-day CEREC crown is actually worse than the lab-made crown in terms of fit and durability.

Indeed, and this leads to another important interpretation: matrix multiplication is function evaluation.

Arbitrary functions which take in vectors and output vectors can be very complex and thus difficult to reason about. A useful simplifying assumption is that of linearity: that f applied to a linear combination is just a linear combination of f applied to each piece of the combination separately. Linear algebra, broadly speaking, is the study of functions of this kind and the properties that emerge from making the linearity assumption.

It turns out that, if we assume a function f is linear, all of the information about that function is contained in what it does to a set of basis vectors. We can in essence "encode" the function by a table of numbers (a matrix), where the kth column contains the result of f applied to the kth basis vector. In this way, given a basis, any linear transformation f has a matrix A which compactly represents it.

Since f is linear, to compute f(v) I could write v in my chosen basis then apply f to each basis vector and recombine. Alternatively, I could write the matrix A representing f in that basis, and then multiply Av. The two are equivalent: that is, Av = f(v). And so matrix-vector multiplication is "just" evaluating the function f.

As a counterpoint to your example of Seattle, Republican-led Fort Worth saw it's homicide numbers increase by 59% in 2020 (even more than Seattle) despite increasing their police budget over the same period:

https://www.star-telegram.com/news/local/crime/article248169...

It should be pointed out that you can install the nix package manager in Arch (or whatever other Linux, or macOS, etc.), so you can try out nix's declarative package management without actually switching to NixOS.

In my opinion the real downside of using <count>j and <count>k to move isn't the counting part, it's the fact that <count>k isn't a jump. That means it doesn't go into the jump list.

Sure, you can make a hotkey to launch any editor, but not every editor is as "pathologically configurable" as vim. The combination of vim being terminal-based, highly-configurable, and lightweight makes it nice to use in a variety of contexts.

Not yet! I just moved to 0.5 this weekend. But thanks for the link!

No galaxy brain here ;)

I generally don't use counts. If I want to go down a few lines, I don't count the number of lines and use 4j or whatever, I instead use / to search for the exact place I want to move to. This feels more natural and preserves the jump-list, so I can ctrl-o back to where I was.

Same if I want to delete a few words. I don't count how many I want to delete and do 4daw, instead I do daw and press . until I've deleted everything I want gone.

And I make heavy use of text objects when available. If I want to move to the next function, I use the keybinding for that instead of searching or counting lines.

There are, but they usually rely on regex or other brittle approaches, making it difficult to write well. And currently you'll need to use different plugins for different languages (e.g., jedi for python).

Treesitter builds the AST, making it easier to create robust text objects. And it provides a unified interface for a bunch of different languages, meaning that I don't need to have 10 different plugins, one for each language, just to get access to text objects.

It's a good question. I'm very critical of my tools and I'm a 10+ year vim user, so I've thought a lot about this.

vim's "killer feature" is its text editing language and modality. But plenty of other editors and IDEs offer vim emulation to varying degrees of success. So this can't be the reason to use (neo)vim-the-binary as my editor over, e.g., VSCode.

So for me the real advantage of vim is in its flexibility. I can make vim into whatever I want depending on the context. Because of this, I'm able to use the same vim in many different contexts, instead of having different tools for different tasks. Ironically, this is kind of like the emacs culture of doing everything inside of emacs.

For example, vim is my code editor, of course. But I also have a keybinding to pop up my wiki and immediately start editing a note in vim. I have another keybinding I use when I'm writing a long piece of text in a textbox (like now) -- the binding drops me into vim, I write my text, and when I exit the contents of the buffer are immediately copied to the clipboard for pasting into the textbox. In each of these contexts, I have access to the same familiar environment with all of my configuration, keybindings, etc.

I could probably wrangle VSCode into doing each of these things, but it would be clunky. Vim owes much of its flexibility to its lightweight terminal interface. I wouldn't want to open VSCode every time I want to write a quick note, for instance.

I'm most excited for the treesitter integration and its potential to amplify Vim's "killer feature": text editing as a language.

Vim's editing language feels most powerful when I'm using its text objects: "ciw" means "change in word", "cis" means "change in sentence", and so on. But Vim's built-in text objects are not always a perfect match for the code you're editing. Suppose you want to change the first argument of a function, for example; there's no built-in "first-argument" text object. But Treesitter integration makes it easy to create text objects that understand the AST. Without much effort, users will be able to make mappings like `cia1` to "change in argument 1", and these mappings will work across all languages with Treesitter support.

There's also something ritualistic about in-person lectures -- in a good way, like having a morning cup of coffee. We know that humans are not good at multi-tasking, so there is tremendous value in a dedicated time and place to think about one thing only in the presence of other people who are also thinking about that one thing.

Of course, it's easy to squander that opportunity by delivering a rote, feelingless lecture. And if you're just going to lay out the facts, why not record them? In that case, videos have many advantages. But a live lecture is also an opportunity to get people excited about what you're teaching.

Post-pandemic, my plan is to take a hybrid approach. Technical details, like proofs, belong in pre-recorded videos watched out-of-class. But the main conceptual thread should be delivered in live lecture, where I can give it the energy and life it deserves.