The Timeless Way of Building Erlang Apps: In Search of a Useful Pattern Language

San Francisco, USA
Mar 27, 2015

Garrett Smith / @gar1t

  • Software Patterns Today
  • Christopher Alexander’s Patterns
  • Applying Alexander’s Model to Erlang

Software Patterns

Goals of Software Patterns

  • Help developers leverage the expertise of other skilled architects (Booch)
  • Recurring solutions to common problems in software design
  • Speed up the development process

Inspiration for Patterns

Alexander On Patterns

  • Applied to towns, buildings, construction
  • Seeking “The Quality Without a Name”
  • Discovered, not prescribed
  • Informed by human emotions

Alexander On Software Patterns

But, speaking only about what appears in [Patterns of Software], I must confess to a slight — reluctant — skepticism. I have not yet seen evidence of this improvement in an actual program.
—Christopher Alexander

On Emotions

To [find good patterns] we must rely on feelings more than intellect.
— Christopher Alexander
Patterns made from thought, without feeling, lack empirical reality entirely.
— Christopher Alexander

On Architects

Patterns do not come only from the work of architects and planners... They come from the work of thousands of different people.
— Christopher Alexander

A Pattern Language for Erlang


  • Develop a useful pattern language for Erlang
  • Work within the spirit Alexander’s model
  • Foster a strong community with free and open participation


Creating a Pattern

  • Give it a name
  • Describe why it is good
  • Describe where it should be used

Acceptance Criteria

  • Should be used somewhere — something you can point to
  • Should occur repeatedly and over enough time to inform experience
  • Must feel good (human emotion)

Pattern Organization

  • Erlang/OTP Construct
  • Function Type
  • Process/Behavior Type
  • Application Level Facility
  • Distributed Facility
  • Principles

Pattern Examples

Pattern: Supervisor

  • Scope: Erlang/OTP Construct
  • What: Process dedicated to starting, supervising, and restarting processes
  • Why Good: Recover from process crashes
  • Where Used: When you need fault tolerance

Pattern: Message Handler

  • Scope: Function Type
  • What: Function that is called to handle a received message
  • Why Good: Simplifies handling a message as details are handled by a dispatcher
  • Where Used: When any non-trivial pre-dispatch and post-dispatch logic is required

Pattern: Task

  • Scope: Process/Behavior Type
  • What: A process that is expected to stop after performing some task
  • Why Good: Handles short lived work autonomously
  • Where Used: When short lived work needs to be performed autonomously

Pattern: Cleanup Crew

  • Scope: Application Level Facility
  • What: A process that “cleans up” after other processes
  • Why Good: Removes the burden of clean up from the other processes
  • Where Used: When clean up tasks need to be performed

Pattern: Crash By Default

  • Scope: Principle
  • What: Rather than try to handle exceptions by default, don’t handle them and allow the process to crash
  • Why Good: Dramatically simplifies code
  • Where Used: Everywhere

Closing Thoughts

  • Just starting! It’s a wild wild west!
  • Give Alexander’s model a fighting chance
  • This is hard
  • See what happens!


Yell at me on Twitter!