Taylor TroeshModify

2026-03-20 08:00:00

Hello. I'm hosting a writing contest with my friends at Quarter Mile. Please send us something! Don't overthink it -- they're just aliens, and you're only human.

2026-03-19 08:00:00

tl;dr:

1. Defer US taxes by reinvesting your taxable income into the economy as business expenses, depreciating assets, etc.
2. For your leveraged investments, pay yourself in refinanced cash when your investments appreciate and/or credit rates drop.

You can dodge defer US taxes if you reinvest your dollars into the economy. This is no loophole; the system is working as intended. Your government wants you to create taxable wealth.

Equity is taxable wealth that already exists. You cannot create wealth by purchasing $10k of AAPL equity. You can create wealth by investing $10k in an apple orchard.

But you must reinvest your dollars in a particular way that Uncle Sam understands. When you report business expenses on your tax return, you inform the IRS what you spent on enterprise. The US tax code rewards entrepreneurial pursuits which grow the economy. Uncle Sam happily forgoes $1 now for $11 next decade -- it's the same slice from a larger pie.

To perpetually defer taxes on your taxable wealth, keep reinvesting your surplus. The IRS forgoes $10 now for $110 next decade, $100 for $1,100, and so on.

If you aren't actually reinvesting capital, pay your damn taxes. Don't be an asshole.

Depreciation spreads business expenses over time. If you invest $100 in a lawnmower that earns $11 per year, this depreciation schedule will minimize your total taxable income each year:

But you can also ask the IRS to treat it as $10/year for 10 years rather than $11/year for 9 years. You might consider this schedule if your other investments lost $11 this year:

Let's say your other investments gain $89 this year, so you front-load the lawnmower depreciation schedule. You pay zero taxes this year, but you've increased your tax obligations in future years:

To defer taxes, deduct yesterday's expenses from today's revenue. Good accountants will massage depreciation schedules to match unexpected profits/losses.

Example: Instead of depreciating a building over 27.5 or 39 years, a cost segregation study could reclassify components (carpeting, fixtures, landscaping, certain electrical) into 5, 7, or 15-year assets. In this way, a $2M property could accrue $200K–$300K in depreciation deductions its first year.

Again, this is intentional. If you contribute more to the US economy than you siphon out, your government will happily pretend you're penniless.

A politician attracts investments into their constituency via tax incentives. Unfortunately, some tax incentives are loopholes which invite crooks to claim exemptions without truly contributing. It is difficult to distinguish whether a loophole is corrupt or negligent, and impossible to prosecute politicians either way.

Most investment money is borrowed (e.g. SBA loans, commercial real estate loans). Your government wants you to create wealth, so it loans money to banks at a magic interest rate. Banks may lend that money to you at a higher rate.

If you contribute loaned wealth to the US economy, you must siphon your dollars out in a way that Uncle Sam understands. One popular method is refinancing, i.e. paying off your old loan with a new loan and pocketing the cash difference. Loaned money isn't taxable income, so you can save/spend it without affecting your tax rate.

Disclaimer: Loans ain't free. Refinancing ain't easy.

Death is a popular escape from deferred taxes. When you die, your obligations to the government vanish. Your heirs inherit assets/property at market value. Their assets depreciate from new cost bases.

According to Modern Monetary Theory, taxes are a method of pulling dollars out of circulation. The government never actually needed your money anyway.

Your life on Earth continues long after you die. Every dollar you've spent, saved, borrowed, lent, donated, willed -- it all mattered. People will commute on the roads you paid for, or taste apples from your trees, or pollute the Pacific Ocean, or survive tuberculosis, or eat pasta, or overdose on fentanyl, or play chess, or gossip, or whatever people do.

2026-03-03 08:00:00

I've been a reluctant Bank of America customer for over a decade. My parents chose BofA, so I chose BofA. Migrating to Chase or Wells Fargo is more of the same -- not worth the switching cost.

Am I really a "customer" when they charge -0.01% interest to hold my money?

BofA is clunky. Their physical branches seem simultaneously overstaffed and understaffed. Everybody there is cordial yet confused. I would never visit their physical locations if their app worked, but alas, their app is crap. I cannot open/close accounts, I cannot reliably cash checks, I cannot easily transfer money -- the software might just be ornamental.

But it ain't 2010 anymore. We now have branchless banks like Ally, SoFi, and maybe even Robinhood. Online-only banking alternatives offer 3%+ APY in lieu of physical locations. According to science, paying region-locked human staffers to occupy an expensive retail space full of money costs a fortune.

Sometimes these banks are technically not banks -- they're "financial services companies with trusted banking partners".

I use Mercury for business banking. It's great. When I discovered that Mercury offers personal banking, I was cautiously optimistic. They built a successful B2B product, but companies usually botch expansions from B2B into B2C.

Oracle's graveyard of B2C products remains a trove of cautionary tales.

My wife and I opened a joint account in minutes. Mercury onboarded us individually and then instantly approved us. I transferred the money via their BofA Plaid integration -- no routing numbers needed, thank you sir. Smooth.

Bonus points: Mercury did not send me a trillion "PLEASE TAKE OUR SURVEY" emails.

I'm eager to test the following features after our money lands:

• enforce spending limits on debit cards
• automate stuff via the Mercury API
• schedule monthly rent payments to our landlord
• match receipts via email (for which I plan to automate forwarding from my FastMail account)
• filter transactions by merchant, user, etc.
• connect to the official Mercury MCP server

If you can survive without physical branches, consider parking your money in Mercury too.

2026-03-02 08:00:00

I had a nifty game idea while Ivan Reese was trying to explain Death Stranding 2 to me. Here's the gist:

• In the beginning, you control a lone robot in an isolated corner of a vast dark map.
• Your robot randomly follows roads. It passes refineries, mines, and shops. You cannot instruct the robot where to go, but you can instruct it to grab/drop resources as it meanders by.
• By transporting ore to refineries, and then trading refined metal at shops, you can purchase repair kits and other modules.
• Repair kits allow you to revive broken robots and recruit them to your team.
• Robots navigate the map according to their navigation module(s): some robots will follow mining routes, others will seek conflict, others will follow friends.
• Reprogram robot behavior by equipping new modules. You can acquire new modules via scavenging, engineering, trade, and theft.
• As you explore the map, you discover the Eastern forest kingdom and the Western seaside kingdom.
• The roads connecting these kingdoms are brimming with activity as military skirmishes ramp up into full-blown war.
• How will you participate in the conflict? Will you become a kingmaker? Broker peace? Rule the world?

In its current form, Last Mile is fun for almost five whole minutes. Try it yourself. There's definitely a great game somewhere in here, but I'm not sure if it's worth pursuing. I'd love to hear what y'all think! Feel free to email me at [email protected].

2026-03-01 08:00:00

I'm still thinking about those lil' fun langs. How do they work? What's inside them? Do I need my pancreas? What if I don't want to normalize my IR? Is laziness a virtue?

Haskell-esque languages may look alike, but they differ across many dimensions:

• strict vs. lazy
• curried vs. bland
• bootstrapped vs. hosted
• interpreted vs. compiled
• nominal vs. structural types
• pretty vs. ugly errors

Most implementations use standard compilation phases:

1. Lexing: Source → Token stream
2. Parsing: Tokens → Surface AST
3. Desugaring: Surface AST → Core AST
4. Type Inference: Core AST → Typed AST
5. Pattern Match Compile: Typed AST → Case trees
6. Normalization (ANF/K): Typed AST → Normalized IR
7. Optimization: Normalized IR → Normalized IR
8. Closure Conversion: Normalized IR → Closure-explicit IR
9. Code Generation: Closure IR → Target (asm/bytecode/C/LLVM)
10. Register Allocation: Virtual regs → Physical regs (if native)
11. Runtime System: GC, primitives, entry point

Strict vs. Lazy

In strict evaluation, arguments are evaluated before being passed to a function. In lazy evaluation, arguments are only evaluated if their value is actually needed; the result is cached, so the work happens at most once.

-- lazy eval returns `3` without applying `foo`
length [ 1, foo 2, 4 ]

Strict evaluation is the simple choice. If you want laziness, Peyton Jones's STG machine is the standard approach. MicroHs sidesteps the STG machine by compiling directly to combinatory logic with graph reduction.

Lazy evaluation also unlocks infinite collections — you can define an infinite list and consume only what you need.

Curried vs. Bland

In a curried language, f x y is ((f) x) y: two function applications. If your backend doesn't detect that f always takes two arguments (arity analysis), you pay for a heap allocation on every multi-argument call.

Bootstrapped vs. Hosted

I tried to teach myself to play the guitar. But I'm a horrible teacher — because I do not know how to play a guitar.

— Mitch Hedberg

Most compilers are written in an existing language (e.g. C, Rust, Haskell, OCaml) and lean on that host's ecosystem for parsing libraries, build tools, and package management.

A bootstrapped compiler compiles itself. You write the compiler in the language it compiles, then use an earlier version of the compiler (or a minimal seed runtime) to build the next version. Your language becomes self-sustaining; the compiler is its own test suite.

There are many exemplary self-hosted languages to study:

• MicroHs is a Haskell compiler that compiles Haskell to combinators. The combinator reducer is implemented in C. The compiler is written in Haskell and can compile itself. Bootstrapping requires only a C compiler -- no pre-existing Haskell installation.
• Ben Lynn starts with a minimal runtime in C (~350 LOC), then constructs increasingly capable compilers, each written in the subset that the previous one can compile. Each stage is ~100–300 LOC of the language being defined. The total chain is ~2000 LOC + 350 LOC C.

  C runtime (350 LOC)
    → compiler₁: lambda calculus + integers
    → compiler₂: + let, letrec, ADTs
    → compiler₃: + type inference
    → compiler₄: + pattern matching
    → compiler₅: + type classes
    → ...
    → compilerₙ: near-Haskell-98

• Newt is a dependently typed language whose compiler is written in Newt, targeting JavaScript. It bootstraps by keeping the generated JS checked in. This works best when your target is a high-level runtime (JS, JVM) rather than native code.

Interpreted vs. Compiled

An interpreter executes the program directly by walking its AST or stepping through bytecode. A compiler translates the program into another language (e.g. x86, C, JS) and lets that target handle execution.

The boundary here is blurry. Bytecode VMs compile to an intermediate form. "Transpilers" compile to source code rather than machine instructions.

Lil' fun langs are usually interpreters. Without compilation, you can skip closure conversion, register allocation, and runtime systems. The leap from interpreter to compiler costs ~500–2000 LOC.

Nominal vs. Structural Types

type Meters  = Int
type Seconds = Int

-- Nominal:     Meters ≠ Seconds  (different names)
-- Structural:  Meters = Seconds  (same shape)

Most ML-family languages are nominal for algebraic data types but structural for records (if implemented). Row polymorphism (EYG, Grace, Koka) is inherently structural -- it acts on "any record with at least these fields." Simple-sub goes further: union and intersection types, with principal inference intact.

Pretty vs. Ugly Errors

-- Ugly:
Error: type mismatch: int vs string

-- Pretty:
 3 │ let x = 1 + "hello"
   │             ^^^^^^^^
Error: I expected an `int` here, but got a `string`.
  The left side of `+` is `int`, so the right side must be too.

Pretty errors cannot be achieved with a coat of paint. To point at a line/region of code, you must thread source locations through every compiler phase. A minimum viable error system:

1. Source spans on every AST node. Every expression, pattern, and type carries { file, start_line, start_col, end_line, end_col }. This costs one extra field per node.
2. Preserve spans through desugaring. When you lower where to let, the new let node inherits the span of the where.
3. Preserve spans through type inference. When unification fails, you need the spans of both conflicting types.
4. Format errors with context. Show the source line, underline the relevant span, explain the mismatch.

Lexing

Optional enhancements:

• Layout/indentation sensitivity (Haskell-style offside rule): Ben Lynn implements this in later bootstrapping stages. MicroHs includes full layout parsing. Adds 100–300 LOC. The algorithm is well-described by the Haskell Report's Section 2.7.
• Unicode identifiers: Most small compilers skip this entirely. Koka supports it.
• Interpolated strings: Syntax like "hello ${name}" is not standard in ML-family, but some newer languages add it.

Parsing

Parsing converts the flat token stream into a tree. The surface syntax is parsed into a concrete syntax tree (CST) or directly into an abstract syntax tree (AST). ML-family languages have a well-behaved grammar that is almost LL(1).

Every subsequent phase transforms this type. In ML-family languages, the AST typically looks like:

type expr =
  | Lit of literal                    (* 42, 3.14, "hello", true *)
  | Var of name                       (* x *)
  | App of expr * expr                (* f x *)
  | Lam of name * expr                (* fun x -> e *)  (or \x -> e)
  | Let of name * expr * expr         (* let x = e1 in e2 *)
  | LetRec of name * expr * expr      (* let rec f = e1 in e2 *)
  | If of expr * expr * expr          (* if c then t else f *)
  | Tuple of expr list                (* (a, b, c) *)
  | Match of expr * branch list       (* match e with p1 -> e1 | ... *)
  | Ann of expr * type                (* (e : t) *)

Name Resolution & Desugaring

Before type inference, the surface AST is simplified:

1. Alpha-renaming: Every binder is assigned a unique identifier to eliminate shadowing. MinCaml's Rust port does this during type checking. Most do this while parsing or during a separate pass.
2. Fixity resolution: Infix operators are re-associated according to declared precedence and associativity. HaMLet does this as a separate pass. Many small compilers hardcode operator precedence in the parser.
3. Desugaring: Surface constructs are lowered into core constructs:
   • where clauses → let
   • Guards in pattern matching → nested if
   • do notation (monadic) → >>= chains
   • List comprehensions → concatMap
   • Operator sections → lambdas: (+ 1) becomes fun x -> x + 1
   • Record syntax → positional constructors + accessor functions
   • Type class instances → dictionary passing (elaboration)

Type Inference

This is the heart of an ML-family language. The "standard" algorithm is Hindley-Milner (HM) type inference, specifically Algorithm W or Algorithm J.

Core components:

1. Type representation: Types are terms built from type variables, type constructors, and function arrows: type ty = TVar of tvar | TCon of string | TArr of ty * ty | TTuple of ty list
2. Unification: Given two types, find the most general substitution that makes them equal. Implemented as a union-find structure over type variables with occurs-check.
3. Generalization: At let boundaries, free type variables in a type are universally quantified to produce a polymorphic type scheme: ∀α. α → α.
4. Instantiation: When a polymorphic name is used, its scheme is instantiated with fresh type variables.

-- Given:
let id = fun x -> x in (id 1, id true)

-- Type inference trace:
-- 1. id : α → α                (infer: x has fresh type α, body is x)
-- 2. generalize: id : ∀α. α → α    (α is free at let boundary)
-- 3. id 1:  instantiate α=β, unify β→β with int→γ, get int
-- 4. id true: instantiate α=δ, unify δ→δ with bool→ε, get bool
-- 5. result: (int, bool)

But fancy type system features aren't free:

Other strategies:

• Polymorphism: Monomorphic type inference only (no ∀ quantification). Every type is fully determined. This cuts the type checker to ~100 LOC by eliminating generalization and instantiation entirely. Functions like id x = x get a concrete type at each use site.
• Elaboration: Modern type checkers increasingly separate elaboration (translating surface syntax to a fully explicit core) from unification (solving type constraints). The Elaboration Zoo demonstrates this cleanly: each stage is a single Haskell file of 200–800 LOC, progressively adding features.
• Type class desugaring via dictionary passing: Haskell-style type classes are implemented by translating class constraints into explicit dictionary arguments. sort :: Ord a => [a] -> [a] becomes sort :: OrdDict a -> [a] -> [a]. Ben Lynn's compiler and MicroHs both use this approach.

Pattern Match Compilation

With types inferred, pattern matching can be compiled to efficient decision trees or case trees.

Key phases:

1. Exhaustiveness checking: Warn/error if a match doesn't cover all cases.
2. Redundancy checking: Warn if a pattern is unreachable.
3. Guard compilation: Guards add a "backtrack" obligation.
4. Nested pattern flattening: (Cons (x, Cons (y, Nil))) → sequence of tests.

The canonical reference is Compiling Pattern Matching to Good Decision Trees. Luc Maranget's algorithm produces provably optimal decision trees in terms of the number of tests. OCaml and Rust use this approach.

Normalization

-- Before (nested expression):
f (g x) (h y)

-- After (A-normal form):
let a = g x in
let b = h y in
f a b

Every intermediate value gets a name. Every function argument becomes trivial. Evaluation order is now explicit in the let chain.

Normalization strategies:

Optimization

With the program in normal form, optimization passes can simplify it. In small compilers, optimizations are kept minimal -- the goal is to not be embarrassingly slow, not to compete with GCC.

MinCaml's optimization passes (totaling ~300 LOC):

These six passes cover 80%+ of the optimization value for a small compiler. They are applied iteratively until a fixpoint is reached (typically 2–3 iterations).

Beyond the basics:

Closure Conversion

-- Before:
let f = \ x -> x + y

-- After:
let f = 
  { fun = \ env x -> x + env.y
  , env = { y = y } 
  }

The optimized IR still has functions with free variables. Closure conversion makes all functions "closed" -- because hardware doesn't understand lexical scoping. Every function becomes a pair: (code pointer, environment record). The environment captures the function's free variables at the point of definition.

Code Generation

Codegen is wholly determined by your choice of target:

Register Allocation

Programs use arbitrarily many variables, but CPUs have a fixed number of registers. Register allocation decides which variables live in registers and which spill into memory.

If you target native assembly, you implement this yourself. The backend handles this for you if you target C/LLVM/Cranelift/etc.

Runtime System

The minimal setup includes:

Lil' fun langs allocate frequently -- every closure, every cons cell, every partial application. Without reclamation, you run out of memory fast. You need to prevent garbage from accumulating:

If your language has algebraic effects (Eff, Frank, Koka, Ante), the runtime needs support for delimited continuations or a CPS-transformed calling convention. Effect handlers essentially require a second stack or a segmented stack to capture continuations. Koka handles this via evidence-passing; Eff and Frank use interpretation.

2026-02-26 08:00:00

That's right. My phone sends annoying text messages to my friends if I don't log a workout by 3PM.

Try it yourself. To add friends as spam targets, write "Tattle." somewhere in their contact notes. Use "Automations" in the Shortcuts app to trigger it on a recurring schedule.

It's strange how this motivates me -- I'm not seeking encouragement nor validation here. My brain simply converts the situation to "I must do pushups to save my friends from my spam robot".

Whatever works.