Skip to content

Instantly share code, notes, and snippets.

@arosien
Created September 2, 2012 18:07
Show Gist options
  • Save arosien/3602430 to your computer and use it in GitHub Desktop.
Save arosien/3602430 to your computer and use it in GitHub Desktop.
thinking in types
  • screenshot of eclipse type inference
  • one-to-one principle: one type used per function signature
  • Rather than thinking about how to jam our ideas into the trappings of the language--class hierarchies and such--we "merely" work with the things as types, transforming them with commonly known functions like map, fold, and so on, then adding context and effects to them in a few well-known ways (dependency-injection = Reader, accumulate logging information = Writer/Logger, perform a transformation using the current state and produce a new state = State, etc.).
  • tension between not explicitly typing, because the compiler can properly infer, and being able to inspect the type, via the editor via the compiler
  • adding more types potentially creates N more adapters to that type, so you want to minimize the amount of new methods signatures you will maybe need to adapt, so having a set of reusable (semantically and structurally well-known) methods reduces the cost of new classes, otherwise we'd just be using lists everwhere

Meta: composition

  • fp folks always talk about composition. what's the big deal?
  • examples of non-composable
  • what you get "for free" with composition
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment