andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

lelandbatey

Description

This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.

The script is here:

#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"

Results

natecook1000

extension NSTimer {
    /**
    Creates and schedules a one-time `NSTimer` instance.
    
    - Parameters:
        - delay: The delay before execution.
        - handler: A closure to execute after `delay`.
    
    - Returns: The newly-created `NSTimer` instance.
    */

raphaelschaad

//
//  RSTimingFunction.h
//
//  Created by Raphael Schaad on 2013-09-28.
//  This is free and unencumbered software released into the public domain.
//


#import <UIKit/UIKit.h>

ZevEisenberg

osascript -e 'tell application "iOS Simulator" to quit'
osascript -e 'tell application "Simulator" to quit'
xcrun simctl erase all

romainl

This gist is no longer maintained.

See https://github.com/romainl/vim-rnb for an up-to-date version.

---

My Vim-related gists.

andymatuschak

//
//  CollectionViewDataSource.swift
//  Khan Academy
//
//  Created by Andy Matuschak on 10/14/14.
//  Copyright (c) 2014 Khan Academy. All rights reserved.
//

import UIKit

praeclarum

//
//  ArrayDiff.swift
//
//  Created by Frank A. Krueger on 6/30/15.
//  Copyright © 2015 Krueger Systems, Inc. All rights reserved.
//  License: MIT http://opensource.org/licenses/MIT
//

import Foundation

cabeca

#!/usr/bin/env ruby

device_types_output = `xcrun simctl list devicetypes`
device_types = device_types_output.scan /(.*) \((.*)\)/

runtimes_output = `xcrun simctl list runtimes`
runtimes = runtimes_output.scan /(.*) \(.*\) \((com.apple[^)]+)\)$/

devices_output = `xcrun simctl list devices`
devices = devices_output.scan /\s\s\s\s(.*) \(([^)]+)\) (.*)/

gist:8a163db3f7f3d81d5296

Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
If you remove possibilities (for example, Swift removes the possibility of things being nil unless