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,

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

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 

romainl

This gist is no longer maintained.

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

---

My Vim-related gists.

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.
    */

cfr

// Updated to Swift 1.2 and CocoaLumberjack 2.0.0-rc by Stan Serebryakov on 2015-02-16

import Foundation

extension DDLog {

    private struct State {
        static var logLevel: DDLogLevel = .Error
        static var logAsync: Bool = true
    }

andymatuschak

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

import UIKit

ZevEisenberg

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

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(.*) \(([^)]+)\) (.*)/

rnapier

// Based on https://gist.github.com/kristopherjohnson/adde22d2c53adfb756a1
// Warning, this is insanely slow to compile in Beta6 (can take several minutes)
// Remove some of the |> lines to speed things up
// For more on |>, see http://undefinedvalue.com/2014/07/13/fs-pipe-forward-operator-swift

infix operator |>   { precedence 50 associativity left }

// "x |> f" is equivalent to "f(x)"
public func |> <T,U>(lhs: T, rhs: T -> U) -> U {
  return rhs(lhs)