I wanted to cover how you’d do that in Linting because now that LLM’s are showing us how “fuzzy things can still give definitive steps to help, with options”

The cop-out is to be like “build it like Elm… I mean Rust even copied that style so it must be good”.

However, I’ve been reviewing JavaScript Linters lately, and the spectrum is pretty deep, but Flint in particular has a nice Elm-like error in interactive mode.

tl;dr; on Flint, it’s a hybrid JavaScript/TypeScript linter: the core and rules are written in TypeScript to make it easier to allow open source contributions, but plugins can be written in native code, like Biome/Oxlint are doing.

Here’s a screenshot attached of Flint finding a linting failure on a loop using for, citing what file, why the linter failed for this particular bit of code, a suggestion of what to do, and a link to learn more. That’s … amazing.

Now imagine if _every_ domain and infrastructure error you created had even one tenth of this meat embedded inside it, with ability to print for non-prod/local dev logging scenarios? Always inspiring to me to see how people interpret errors, specifically linter errors which can be quite fuzzy/squishy, open to interpretation, but need some kind of actionable step to fix it. I really like Flint’s approach here.

1. wrap native fetch with Neverthrow
2. provide nicer, Elm style return types
3. abstract away decoding/enoding for JSON
4. same, but for GraphQL + company’s rules around that

Learnings the past 3 days:

• Zod v3 to v4 has been a nightmare, so at first I just removed Zod and provided a decoder type interface instead b/c writing a Zod wrapper is like 1 line of code
• … but then I found out in v3.25.0 they name spaced the versions, making it easier for each to co-exist
• … so now I’m wondering if I should undo all my work of “abstracting away a Zod dependency
• but then I found out many are moving to Standard Schema and it’s not a too obtuse type to include, thus enabling me to be nice to ArkType and Effect-ts peoplez
• So now I think I can support Zod v4 internally, include an encoder interface for POST style operations, but still not exclude other schema libraries WHILE reserving the right to use Zod internally for various GraphQL schemas
• … but still requiring me to map those ZodErrors to my own type to not “leak Zod out”.

I really don’t like that last one. I may just not do it, install in a Zod v3 project, and “see what happens” in the unhappy paths.

Once done, I can wrangle the insane grossness that is Open Feature while dual-wielding Discriminated Unions of flame and frost brands.

Initial scare as the grease near the place where the 2 exhaust pipes went in burned off the grease I put in there and it smoked. Then some drops from the front drain plug. I’ve learned to tell the difference between “burning oil” smell, “burning coolant smell” and “omg I don’t know what that is burning” smell. I’m wondering if the crappy hex bolt I used didn’t have the flat head flange, thus not making a good water seal… so headed to Ace Hardware for the 20 billionth time. While scary, at least I can get parts within 15 minutes, cheap vs. online OEM which takes a week or more. Bought another one with a flat head I’ll try replacing later.

She “felt” like she’s running better. While I still can’t tell if the $200 suspension upgrade I did improved anything.

I did replace the bushings for them which was way easier than I thought.

Forks are messy af, tho; I’d say only coolant changes are messier. I could certainly tell the bike “liked” the oil change. Coolant’s hard to tell as it’s cooler today, but I know it was good for her. Cleaned the filter; it wasn’t very dirty but those “lifetime” filters need to be cleaned more often just in case, so hopefully she liked the fresh air from the box. The new rear brake lever I installed works. Friend crashed recently because of no good brakes so I tested her a few times “just in case”. (Bent because of crash at motorcross track)

The tires continue to be loved in the dirt; I can just feel the 400lbs “grab” easier and make me freak out less, which in turn makes me more confident, which in turn makes the bike drive better. They say tires can’t compensate for skill, but I don’t know man…

The turn signals and auxiliary lights are… screwed. I keep using epoxy on top of epoxy and it just never lasts. Duct tape, while visually awful, is functionally awesome.

Sadly, the rear sprocket didn’t fit, and just didn’t have the attention span to attempt to exchange online for whatever the right size is. However, testing her bigger, more highway focused sprocket on the motorcross track, she had torque, so… I’ll live.

Race is Friday. 24 hours, 500+ miles. So nervous my mechanic skills have “forgotten” something, or did something wrong I’ll later regret. Best way to learn is the hard way, no doubt, but… geez. I should have done this in my 20’s.

BTW, if you didn’t see it, here is my testing the new knobby tires on mountain, mud, and motorcross.

This is a series of posts I’m writing about using types as another tool in software development, Continuous Delivery, & keeping LLM’s honest. They’re also a design & refactoring tool, a communication tool, and reduce how many tests you have to write.

There are trade offs to types. More to read, comprehend, & you’re often thinking in 2 modes: types + code. Watch Amanda Laucher & Paul Snively from Strangeloop conference “Types vs. Tests”, you’ll how far you can push the types to the limit of your understanding. As a team, you need to decide if it’s worth getting that understanding for the benefits, or “doing something simpler for now”. No shame deciding to be pragmatic & ship code. Learning types will be iterative. You/your team can gradually increase their skill, bredth of use over time, over many releases. It can also be a line in the sand for a target demographic; go read Dom Syme’s stance against Dependent Types in F#.

Types aren’t as popular as infrastructure, IDE’s, tests, or language features. Community is a part of programming, but a small part. Historically (90’s, 2000’s), languages that had better type systems were not adopted for a variety of reasons. That has been slowly changing since the 2010’s, but super slowly. Wonderful resources online to learn w/tight communities. Despite positive impacts to design + software quality, that does not translate to job opportunities or perceived importance to engineering leadership except for rare language communities.

Types have same issues that other programming quality initiatives have; not the norm. We’ve known for decades about positive impacts of code review, automated tests, Continous Delivery, & past 10 years we now finally have mounting evidence supporting what we knew. Yet companies & clients, either ignore the science, don’t know about it, or don’t know how to balance those standard quality practices w/getting actual work done. You’ll have to navigate politics, project & product management, design & UX, sales & marketing of the techniques & implementation details… WHILE doing you’re engineering job. This is especially hard w/types as they’re niche.

Finally, code is continually created, by your team, others, & library authors. Much of if not typed, or not typed to a strong degree. You’ll have to interface with this code. So learning not only “what’s good” for your domain/your code, but also “how best to safely integrate to this other code” will present additional aspects & challenges.

You’ll be confused why everyone hasn’t adopted sum types; that never goes away, a true mystery of the universe.

I say all of this not to dissuade you, but to prepare you. Not all tradeoffs are the same; some are better than others, and types in my experience are worth it. The “hard to learn” is a great problem because this job attracts nerds & we learn everyday. It can be hard and lonely, but it’s worth it.

Card decks ordering details to follow.

This is a series of posts I’m writing about using types as another tool in software development, Continuous Delivery, & keeping LLM’s honest. They’re also a design & refactoring tool, a communication tool, and reduce how many tests you have to write.

Type Driven Development (TyDD) is a lot like Test Driven Development (TDD); a design technique that results in proofs for easy to change code later. In most languages, you’ll use together; more types in a better type system, more tests in a bad one. Here’s 4 ways to approach it.

We’ll be enforcing Secondary Accounts can only cancel their own Transactions, Primary Accounts can cancel any Transaction. I’m Primary, & my daughter, Sydney, is Secondary.

In TDD:

1. write our expectation

expect(
  canCanel(
    { accountType: 'primary', id: 'jesse' },
    { transactionID: '4', accountID: 'jesse' }
  )
).toBe(true)

2. implement the function in simplest way to make it pass

3. refactor or move into next test

1st: In good type systems, you just write code, fix the red, refactor. Each change that breaks the code, you let the compiler tell you what to fix. You keep the changes small.

2nd: The @ts-expect-error comment directive way allows you to write types and functions normally, but for unhappy paths you must use the comment above them:

1. create a failing type function

// fixtures
declare const jesseTransaction:
  Transaction<'transaction-123', 'jesse'>

declare const sydney:
  SecondaryAccount<'sydney'>

// @ts-expect-error Sydney must not cancel Jesse's transaction
cancelPayment(jesseTransaction, sydney)

2. simplest function to make it pass

// omitted input types for room
function cancelPayment():CancelledTransaction<TransactionIdentity>
  return {
    status: 'cancelled',
    transactionID: transaction.id,
  }
}

3. Now your @ts-expect-error comment will no longer be underlined red. Refactor types OR do happy paths without the comment (e.g. cancelPayment(jesseTransaction, jesse) )

Caveat: The comment must be above compiler error; if you multi-line your types like me, you may have to move it.

3rd: The type proof way is similiar:

1. write a failing proof

// fixtures
type JesseTransaction = Transaction<'1', 'jesse'>
type Primary = PrimaryAccount<'jesse'>

// function
type CanCancel<_Account, _Transaction,> = false

// failing proof
type _sydneyCantCancelJesseTransaction = Assert<
  CanCancel<
    MainPrimary, AliceTransaction
  >
>

2. make CanCancel pass by improving the type

// excluded TransactionOwner for space
type CanCancel< CandidateAccount, CandidateTransaction, > =
  CandidateAccount extends PrimaryAccount<string> ? true :
    CandidateAccount extends SecondaryAccount< infer AccountIdentity > ?
      Equal< AccountIdentity, TransactionOwner<CandidateTransaction> > : false

3. either refactor or move to additional proof tests

The fourth is just to intermingle 1 of the above 3 _while_ you do TDD. That’s what I do.

Part 26 will have final conclusions.