Early computers were described using mathematical notation and theoretical constructions, which were then translated by enterprising machinists into custom built calculation engines. The first computer programmers using these machines built applications directly in hardware by plugging together wires and sockets in varying configurations. Even with these short-comings, the value of general purpose computing machines was evident. As companies began to realize the utility of computing, they saw computing as a means for differentiating themselves from their competitors. ...

In a purely functional language — like lambda calculus — programs are expressed as nested function calls. Repetition in such an environment requires that nesting of function calls continues until some condition is met. During the repetition, each function passes its result to the next function in the nested chain and this repetition is completed when a test for some condition passes. The repetitive behaviour I’ve just described is recursion: ...

Evaluating lambda functions requires using lots of brackets, which can be tedious and are a major source of error for evaluating expressions by hand. To simplify expressions, you can omit brackets when it is clear what the intention of the function is. Particularly, a function application can omit the brackets surrounding each individual parameter and assume the function is applied to the nearest argument. So, instead of expressing a function of three arguments as ...

Lambda calculus provides some of the foundational structures that functional programming is built from. It therefore seems fitting to start my journey through functional programming with a thorough examination of lambda calculus. This first post will introduce Lambda calculus with references to the book An Introduction to Functional Programming Through Lambda Calculus. Syntax The complete syntax for Lambda calculus is surprisingly small and comprehensible. This section lists the syntax in its entirety, while following sections break the syntax down to explain each part. ...

A principle is a concept or value that is a guide for behaviour or evaluation. — Wikipedia This post presents a principled approach to architecture. These principles specify what I believe is important about architecture, without diving into any details about how an architect should work. No matter how an architect works day-to-day, by following principles, you can be sure you are providing value in the right areas. As usual, this post is personal opinion, and I’m interested in hearing any differing or similar opinions in the comments. ...

Three common terms come up whenever we talk about functions: domain, range, and codomain. This post clarifies what each of those terms mean. Before we start talking about domain and range, lets quickly recap what a function is: A function relates each element of a set with exactly one element of another set (possibly the same set). Math is Fun That is, a function relates an input to an output. But, not all input values have to work, and not all output values. For example, you can imagine a function that only works for positive numbers, or a function that only returns natural numbers. To more clearly specify the types and values of a functions input and output, we use the terms domain, range, and codomain. ...

One proposed benefit of following a microservice architecture is that each service can be developed, released, and supported independently. In theory this allows development teams to work with less coordination and less overhead, leading to faster development times. In practice, this is difficult to achieve without some guidelines that make it work. The book The Tao of Microservices provides two such guidelines — transport independence, and pattern matching — that create an environment allowing you to compose services. Service composition is the holy grail of microservices, allowing you to build progressively more complex functionality safely and efficiently. This post discusses how transport independence and pattern matching allow you to compose services, what service composition means in terms of functions, and how you can use this composition to build complex services additively. ...

I’m documenting my journey from functional neophyte to (hopefully) functional programmer by writing a series of blog posts on the topic. So far I’ve covered what functional programming is and why you would want to learn about it. In this post, I’m going to describe the resources I will be using to become functionally fluent. Although I have previously said I’m learning about functional programming, I should be more specific. I do already have some middling experience with Clojure and Lisp, but I have too many battle scars from running dynamic languages in production to go down that path again. At this point in my career, my experience dictates that any new code I write will be statically typed. Because of this bias, I’m going to approach learning functional programming through the lens of statically typed functional languages. My learning plan will reflect that and help narrow the scope of this project. ...

I previously talked about what functional programming is by comparing it to other programming paradigms. This post expands on that post to talk specifically about practical differences between functional programming and the paradigm most of us are intimately familiar with — imperative. This post is punctuated with some quotes from the book An Introduction to Functional Programming Through Lambda Calculus. It’s worth noting that each of these practical differences are enabled because of the power of referential transparency. ...

Having covered what functional programming is, I wanted to spend a minute or two discussing why I want to learn functional programming in the first place. I’m sure we have all heard vague things about “side-effects”, “immutability”, and “composition”, but I wanted to dive a bit deeper on the topic to describe what — to me — is important about functional programming. Referential Transparency The key differentiating feature of (pure) functional programs is that they provide referential transparency. An expression is said to be referentially transparent if it can be replaced with its corresponding value without changing the program’s behaviour. ...