Each of the following surprised me, and has its own section in this post:

If you’re short on time, skip to the last section, since what TypeScript does is most interesting.

Key:

When “or” means “intersection”

Here’s an Erlang function that:

Mnemonic: “a” for “argument”, “r” for “return”

func('a1') -> 'r1';
func('a2') ->…

<: vs rho

Brian McKenna’s “Row Polymorphism Isn’t Subtyping” is about the distinction between row polymorphism and subtyping. Several re-readings led me to convince myself I understood, then a real-world bug to lead me to a stronger conclusion on why the distinction matters.

To help cement my understanding or misunderstanding, I’ll

Note: Good background easy reads: TypeScript’s subtyping and Elm’s extensible records (row polymorphism lite).

How exactly Row Polymorphism is not Subtyping

If I interpret McKenna correctly, he’s saying that all and only type systems with subtyping…


There’s normally a tight connection between programming and proving: this is known as “Propositions as Types.” I found one aspect of the correspondence troubling, went down a rabbit hole, and came back less troubled.

Our most popular logical systems all include exfalso, a.k.a. The Principle of Explosion which is the principle that a contradiction implies anything at all. That is, forall B, if false then B.Which seems really surprising on the face of it: where did B come from?! I'll share my exploration of this question and an attempt at an answer.

Warning: There’s nothing practical in this post.

Exfalso…


There are many places where you can find arguments that DSLs (domain-specific languages) or “language oriented programming” are good. But I haven’t found much on what makes them bad.

My experiences with DSLs tend to be negative. There are cases where I know exactly what I want the computer to do. I could write it in minutes in any “real” programming language, but struggle to express or approximate it in the DSL.

Here are some examples of “bad” DSLs:

And here are sufficient conditions for a DSL to be bad:


An illustration of Russell’s paradox from an article on the topic: https://medium.com/@jiwonjessicakim/russells-paradox-f8897
image from https://medium.com/@jiwonjessicakim/russells-paradox-f8897

I’ll present four puzzles and two solutions about classes and types.

These are just puzzles I find fun, but reading this might have the happy side effect of getting you out of a TypeScript jam in the future. All four puzzles have come up in real-life situations that I’ve been asked about.

Puzzle 1

TypeScript has a neat feature, type-level typeof. It's probably inspired by the distinct value-level JS feature also called typeof:

typeof null;       // "object" 
typeof class A {}; // "function"

TypeScript’s type-level typeof thing gives you an alias for the type of the variable thing:

const thing = 3…


enum Shape { Line = 0 }; enum Shape { Dot = 0 }; const x: Shape.Dot = Shape.Line;

TypeScript, like many programming languages provides enums, which enable you to enumerate the values a type may have.

TS enums look like this:

enum Direction {
UP,
DOWN
}
function move(direction: Direction) {}move(Direction.UP);

I’ll go into:

Note: TS is a fantastic programming language, and enum may have been a good choice back in 2011 when good alternatives did not exist.

Alternative 1: String Unions

This solution uses a union of string literal types.

type Direction = "UP" | "DOWN";
function move(direction: Direction) {
switch (direction) {
case "UP"…


Here are two tables that show the similarities and differences between MobX Observables and Rx Observables:

Similarities

Similarities

Differences

Differences

ALSO:


There are a ton of libraries for doing asynchronous effects in Redux apps. Some see this as a bad thing, but I love the intellectual curiosity and willingness to explore in the JavaScript community.

There wasn’t a Redux effects library that met my needs, so I ended up making something new. I’ll share the ideas I borrowed from other effects libraries and how they are used in redux-funk.

For some background, there’s a Stack Overflow post that goes into why you’d want a tool for asynchronous effects in Redux apps.

Redux Loop—Declarative effects in reducers

The example below demonstrates some of the great ideas in…


I’ve noticed that Redux apps often embed ad-hoc finite state machines, with information about the current status spread out throughout reducers. I wrote a small helper for working with finite state machines in Redux called redux-machine. In this post, I’ll go into:

redux-machine Example

This is a very simple example of a state machine for working with data fetching, which will help show how to use redux-machine:

finite state machine for handling API call state in Redux

In words:


a chill monkey

I’ll go into:

Traditional Monkey Patching and why it is Dangerous

“Monkey patching” in JavaScript refers to adding properties to a prototype separately from where the class is first defined. This is an example of monkey-patching `Array` to add a `last` method, which returns the last item in the array:

Max Heiber

Views are my own

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store