Skip to content

Instantly share code, notes, and snippets.

Avatar

Justin Spahr-Summers jspahrsummers

View GitHub Profile
View types.markdown

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

@andymatuschak
andymatuschak / States-v3.md
Last active Jul 22, 2021
A composable pattern for pure state machines with effects (draft v3)
View States-v3.md

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,

@OlegIlyenko
OlegIlyenko / Event-stream based GraphQL subscriptions.md
Last active Jul 11, 2021
Event-stream based GraphQL subscriptions for real-time updates
View Event-stream based GraphQL subscriptions.md

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

  • query
  • mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

@nicklockwood
nicklockwood / gist:21495c2015fd2dda56cf
Last active Aug 13, 2020
Thoughts on Swift 2 Errors
View gist:21495c2015fd2dda56cf

Thoughts on Swift 2 Errors

When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.

So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.

Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?

I'm going to cover three things in this post:

View 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
@andymatuschak
andymatuschak / gist:2b311461caf740f5726f
Created Dec 28, 2014
A pragmatic and intentionally non-abstract solution to JSON decoding / initialization that doesn't require learning about five new operators.
View gist:2b311461caf740f5726f
struct User {
let id: Int
let name: String
let email: String?
}
extension User: JSONDecodable {
static func create(id: Int, name: String, email: String?) -> User {
return User(id: id, name: name, email: email)
}
@keithduncan
keithduncan / pipe_source.m
Last active May 24, 2016
Various options for streaming from the read end of a pipe until EOF
View pipe_source.m
/*
pipe_source.m
clang pipe_source.m -o pipe -framework Foundation -D [ USE_SOURCE | USE_IO | USE_FILEHANDLE [ FILEHANDLE_READABILITY | FILEHANDLE_WAIT ] ]
*/
#import <Foundation/Foundation.h>
int main(void) {
enum RunLoop {
@chriseidhof
chriseidhof / LICENSE
Last active Jul 16, 2019
A tiny networking library
View LICENSE
Copyright 2015 Chris Eidhof
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE
@airspeedswift
airspeedswift / GenericInfProb.swift
Last active Aug 29, 2015
Swift for…in generic inference prob
View GenericInfProb.swift
// original version with problem
struct A<T> {
func f<S: SequenceType where S.Generator.Element == T>(s: S) {
// error: cannot convert expression's type S to type S
for v in s {
print(v)
}
}
}