FP for Sceptics: ADTs in Practice

In previous post we defined ADTs as

Algebraic Data Types (or ADTs) model the flow of a program (or a system) in terms of data & functions that describe the complete behaviour and states the data can go through.

In this post, we will work through defining ADTs for an API service.

How to design ADT for a request-response flow?

API service will return User's Information by:

  • Extracting user id & password from the request
  • Checks them against an authorization service
  • Retrieves User's Information from database
  • Returns User Information in response

Read more…

FP for Sceptics: Introduction to ADTs (Algebraic Data Types)

Algebraic Data Types (or ADTs) model the flow of a program (or a system) in terms of data & functions that describe the complete behaviour and states the data can go through.

Let's take an example to grok the concept better.

Example: Area of a rectangle

Calculate the area of a rectangle from a list of positive integers

Here's a possible algorithm:

  • Take a list of integers (positive & negative)
  • Filter for positive integers ie., remove negative integers
  • Create pairs from the filtered list
  • Apply equation for area of rectangle

Read more…

Elegance of Monadic Composition

Functional programming has many interesting concepts but it can be hard to find practical applications for it in everyday work. In this post, I will explain how Monadic Composition can be used write elegant and easy to understand code.

Consider an API Donatron that accepts donations. The API's algorithm is as follows:

  1. Accepts donations as list of strings
  2. Should have a few valid integer donations
    • Else goto 6. Response: No Valid Ints
  3. Should have a few donations of value 10 or above
    • Else goto 6. Response: No Acceptable Donations Found
  4. Valid donations to external service should succeed
    • Else RuntimeException
  5. Log all accepted submissions
  6. Log Response
  7. Return Response

End goal is to be able to execute Donatron.donate function and get correct response.

Read more…

Elements of Coding Style

Rules of Software Engineering

There are three important rules in Software Engineering.

  • Rule 1: Easy to understand. Anyone should be able to pick up the code and start working on it.
  • Rule 2: Easy to debug. If the code breaks, it should be easy to quickly investigate & identify where is the issue.
  • Rule 3: Shipping is the most important feature. No matter how correct or elegant your code is, if you can't ship working code on time then why bother?

Having said that, Rule 3 should rarely be in opposition to Rule 1 & 2. If you have to veto Rule 1 & 2 to ship your feature, then something's horribly wrong in your code & process. Complexity in code is a given and it is an engineer's responsibility to figure out how best to contain the damage and stop it from affecting the rest of the system.

Less elegant yet easy to understand & easier to debug should be the minimum expectation from all code shipped.

Read more…

Type Driven Development

Introduction

In our project workflow, we break down features to implement into tickets and developers pick them off one by one; Pretty standard & typical Agile/Kanban workflow. However while working on a feature recently, we came across on an interesting problem where our standard workflow didn't work out. Rather than trying to explain it in vague terms, I am going to start with a story.

TLDR

In case you don't want to dive in just yet, here is the idea we will cover in this post.

Think about the behaviour of your program in terms of data types & functions signatures. Next step is to prove or derive a function that composes all of the types & signatures to implement the feature. Then carry on to implement each of the individual functions with the guarantee that all functions will compose together.

Read more…

Cats Effect's IO

Cats Effect's Fibers/IOs run on a thread pool created over VM. They are essentially Green Threads that are created over the thread pool. Unlike async frameworks, IO.flatmaps does not include _asynchronous boundary. This means that essentially all of nested flatmaps are run within a single fiber. IO has mechanism to introduce asynchronous boundary but this has to be done manually by the developer via IO.shift. Operations such as race, parMapN or parTraverse inherently introduce asynchronous boundary.

~ 14th May, 22:11