Development Central

Bill Sorensen's software development blog

Notes: Case Study: Algorithmic Trading in a Production Haskell Environment

Notes on a talk by John Lato of Tsuru Capital at Iowa Code Camp.

Coursera - financial modeling, etc. courses are available

Derivatives market is huge. (A quadrillion dollars!)

Create a model for the prices structure and derive a formula from the model.
Example: Black-Scholes Option Model - statistical volatility is the main variable, along with underlying price and time to maturity
Delta - underlying, Vega - volatility, Theta - time (The Greeks) (actually equations)
Wikipedia & Investipedia have articles on this.
Modeling is very math-y.

Algo Trading: Reality

  • Buggy 3rd party code
  • Out of spec implementations
  • Parsing

(Sound familiar?)
Can measure success: Are we making money?

1-2 GB/day for a small subset of the orderbook from the MarketFeed.

Knight Capital SEC article - how software deployment issues can cost your business money.

How Tsuru uses Haskell

  • Type system
  • Concurrency model
  • Foreign interface
  • Meta-programming


The Haskell Kool-Aid: If it compiles, it works! (Mostly true.)

Newtypes are "free," apply liberally. (Similar to units of measure in F#.)
  This way you don't apply the wrong function to a price, etc.
  Way to preserve invariants (can include constraints).

Coming to a strongly-typed functional language from a dynamic language is hard.
You have data, and you have functions. Model your data accurately.
If you have a Maybe Int, you can only use it with things that work with Maybe.
Rather than throwing exceptions, you create types that preserve invariants.

Parametric Polymorphism
Functions that work with, for instance, a list of any type
Can't alter your data, as they have no interface to interact with it
Similar to generics in C#/Java
Example: many :: Parser a -> Parser [a]
  (a is generic)
You can do a lot of this stuff in C# now, but it gets very verbose.
Type inference may infer a type more general than you thought, in which case you get code for free! (In functional languages.)
(In Haskell, it's considered good practice to write type signatures, at least for top-level functions.)

Concurrency
Immutable-by-default and lack of side effects are a big win
Some challenges remain (e.g. no mechanism for thread priority)
In F#, considered good practice to make a method pure unless good reason
Side effects are "Spooky action at a distance"
In Haskell, if something doesn't have IO (monad) in the signature, it doesn't do I/O.
Similar functionality to async/await. In functional languages, typically the syntax is very clean.

hackage.haskell.org - lots of code examples
ghc - compiler most people use - offers REPL, includes mem/perf profiler
Cabal - build system
learnyouahaskell.com
fpcomplete.com
ideone.com

github.com/johnLato

In Haskell, deep debugging can be hard. Traditional stack traces are tricky.

Testing
Have both unit tests and functional tests. (HUnit)
QuickCheck - Haskell (and more?) testing tool - generates random input
Checks results - good for catching corner cases
Also use a simulator in place of exchange, playing back feeds, etc.

Notes: Learn Every Programming Language

Notes on a talk by Patrick Delancy at Iowa Code Camp.

If you don't practice it, you lose it.

Why

The inability to learn programming languages could force you to change careers.
The idioms and concepts you learn will help you with your current language.

How

Start with the underlying principles. Understand the paradigms. The rest is just syntax.

Programming Paradigms (in order of complexity, low to high)

  1. Procedural
  2. Logical
  3. Functional
  4. Object Oriented

That's not the order in which we typically learn them.

Thinking Procedurally

  • Loops
  • Procedures/Functions/Subroutines
  • Global/Static Variables
  • Jump/Goto
  • Lexical Scoping
    • Text in your code defines variable scope
    • Not based on time (such as global after you define it)
    • Block scoping, function scoping, etc.

Thinking Objectively

  • Class/Entity
  • Abstraction
    • Making something simpler.
    • We don't have to understand how it works.
  • Encapsulation
    • An object, if it exists, should never be in an invalid state.
  • Inheritance
  • Polymorphism

Very domain-driven. Easy to translate the business needs.

Thinking Functionally

  • Functions as values
    • Lambdas, anonymous delegates
  • Pattern Matching
    • Regular expressions
    • Define shape of a value or object
    • Compiler can warn you of missing cases
  • Composition
    • Chaining function calls
  • Partial Application
  • Monad/Computation Expression
    • Binding functions together and defining how they behave
    • Helps to solve the problem of side effects (like I/O)
  • Closures
    • A function plus its referencing environment
    • Such as the memory address of a variable
    • Necessary evil (avoids globals)
  • Deconstruction
    • Pull out variables from object (often through pattern matching)
    • Lists are head + tail
  • Recursion
    • Tail recursion avoids running out of stack
  • Cons/Car/Cdr
    • Cons constructs a new value from two inputs
    • Linked lists
  • Etc.

What is the shape of the process?
Focus on behavior, not data.

Thinking Logically

  • Facts
  • Relationships
  • Goal-reduction

Classification
Languages don't fit into these buckets anymore.
They steal ideas from other paradigms.

Disfunctional

A coworker and I spent a total of at least 8 man-hours this week tracing down one threading bug. The original author was locking access to shared state, and got it almost right.

Writing thread-safe code that uses global mutable state is hard. It's much easier to avoid the problem entirely.

Functional programming emphasizes pure functions (the same inputs will always give the same output, with no side effects) and immutable types. If you write your code in that style, thread safety comes naturally.

Regardless of programming language, consider a more functional approach. Your future self will thank me.

For a good book on the subject, try Real-World Functional Programming: With Examples in F# and C#.

In the NOOO

I'm a signatory to the Manifesto for Not Only Object-Oriented Development.

# 11010100. :)

Speaking at CRineta

I'm giving a presentation on FSM.NET at the local users' group on Monday night. @dahlbyk is opening for me, so I've got a tough act to follow.

Meeting info

Important read for C++ programmers

Edward C++Hands

Long but excellent, IMHO.

The author, Bartosz Milewski, has a strong background in C++, but does have a commercial interest in Haskell.

FSM

My first open source project on GitHub is FSM.NET, a simple "stateless" finite-state machine library for .NET. It's also available through NuGet.

The library is written in F#, but is designed to be easily callable from C#. The project includes examples in both languages.