On the COPIOUS engineering team, we focus on some pretty big questions:
What kinds of things are measurable?
What can be computed?
What is knowable?
These questions guide our estimating process, as well as our attitudes towards development, testing, deployment, automation, and support.
Many of the tools we work with day-in and day-out, though, aren’t quite as predictable as we’d like. Sometimes Ruby runs out of memory. Other times, Perl chokes on some unicode, or Android doesn’t want to work with Scala very well. Some languages and platforms still lack a comprehensive TDD framework, and others lack clear paths to debugging things that have gone wrong. When it comes to going “back to the drawing board” on a hard problem, one system of thought comes up more frequently than any other: functional programming.
Functional programming is a paradigm that emphasizes computability and limited side-effects. More specifically, Haskell is a purely-functional language — it implements a functional paradigm, and nothing else. This means we can prove how it’s going to behave with math — specifically with the lambda calculus and the Church-Turing Thesis. Given the same inputs in Haskell, we can safely assume the same outputs every time. Furthermore, any algorithm we design in this branch of math will probably be implementable on a less strict language.
This comes in handy when working with modern programming languages that try to be all things to all programmers. Functional programming emphasizes doing one thing at a time without side effects. If you can express yourself functionally, there’s a good chance you can express yourself predictably, so the next developer who picks up your build can know what to do with it.