headbee

This is pretty close to type branding (newtype wrapping for the Haskell-inclined), though using template literal types is pretty novel. Normal brands look something like this:

    type Brand<BaseType, Brand> = BaseType & { readonly __brand__: Brand };
    type FooId = Brand<string, 'FooId'>;
    function fooBar(asdf: FooId | 'foobar'): void { }

fooBar will only accept the literal string 'foobar' or a true FooId, but not any arbitrary string. FooId would then come from a function that validates strings as FooIds, or some other part of the app that is an authoritative source for them. Brands extend their BaseType so they can be used anywhere their BaseType is used, but not the inverse

Yes, and they're truly phenomenal pieces of music journalism in an era where many of the music blogs have withered or degraded.

It opens up a huge toolbox of tools that work with Functors and Applicative to make parsing easier, and proves that using those tools will work predictably.

I think you were originally correct and that `Record<string, number>` was not a good example. I would guess that union literals and primitives are handled differently by the compiler in this case, perhaps because a record with keys of every possible string is impossible it may have a special condition to skip some typing rules. In fact, `Record<number, number>` is assignable to `Record<string, number>`.

I believe that would be covariant: `'home' | 'work'` is a subtype of `string`, and `Record<'home' | 'work', number>` is assignable to `Record<string, number>` so the subtype relationship is preserved.

Carhartt is a very trendy street wear brand in addition to their (still very trendy and brandy) workwear.

I had read this article more as a "from-first-principles" example, but it's a good note for people who might be unfamiliar with practical Haskell. Using an effects system also promotes the domain DSL from an initial-tagless language (only the interpreter is extensible) to a tagless-final language (both the language and the interpreter are extensible).

It may be worth noting that effectful, polysemy, and the other "new kids" of effects systems are not the only option: record-of-functions, mtl, and type-class effects aren't cutting edge, but they're a little more approachable from an OOP dependency injection pattern.

I don't host it, per-se: I use VimWiki, and occasionally Obsidian for the pretty graph. VimWiki even has a static site generator, but I use Pandoc for that. For search I use FZF and ripgrep.

I can attest to this and took all of my notes on paper in college. However, once I started a real job I realized that this strategy doesn't scale to all situations. In college, I needed to be able to recall all of the information I had ingested: it was low-write, high-read. In the workplace, there's much more information, but I'm unlikely to need most of it: it's high-write, low-read. I need to be able to reference the information, but not necessarily recall it. Taking paper notes became too much of a burden and I moved to a wiki of markdown notes.

Not directly as far as I know, but federal taxes are the other mechanism by which money can exit the economy. I should have stated as such.

After the Federal Reserve adds money to the economy, they usually want to take some of it back out. They take money out either by selling bonds or through taxes. The goal of removing money from the economy is sometimes to control inflation, but it's debated whether "printing money" actually affects inflation.

I see this argument made assuming that REST service creators are not aware of L3 REST but the fact that it never caught on is at least some proof of its ill-fitness to the general problem. Nowadays we have many more options that do what L3 REST tries to do (OData, GraphQL, etc) and most APIs at least conform to L2 REST. This is a classic case of friction between design intention and actual user experience: there was a push-door with a handle, and users aren't using the handle, they're just pushing it.

It's good for IoT and automation because it's fundamentally a framework for discrete functional reactive programming. It could be good for any context where you need to tie together a bunch of events from different contexts that all depend on each other to drive some other behavior. You can design design nodes and flows that minimize state and keep it local.

If the oleophobic coating is intact (and good quality) it should come off with just a clean cloth.

Using soap on surfaces that have an oleophobic coating can degrade the quality of the coating. This is even worse with dish soap.