~samhh/writings

7e79be382260f1f485f9178d99fba420c272c18f — Sam A. Horvath-Hunt 3 years ago 1b0bbaa
Add slug/date/title metadata
M published/20200221-fp-ts-composition.md => published/20200221-fp-ts-composition.md +6 -0
@@ 1,3 1,9 @@
---
slug: "fp-ts-composition"
date: "2020-02-21"
title: "Composition in fp-ts"
---

Preface: All functions should strive to be pure, meaning they perform no side effects - all this means is that you take some data and return some data, and you don’t do anything outside the confines of said data. This post is written with this context in mind.

The most fundamental aspect of FP that brings it all together is the idea of function composition - composing functions together like LEGO. Firstly, let’s look at it quickly in abstract:

M published/20200330-js-fp-jargon.md => published/20200330-js-fp-jargon.md +6 -0
@@ 1,3 1,9 @@
---
slug: "js-fp-jargon"
date: "2020-03-30"
title: "Functional programming jargon for JavaScript devs"
---

If you're looking into functional programming for the first time, the terminology can be really overwhelming. I think one of the easiest ways to learn is to try and map the terms to concepts that you likely already know and then branch out from there.

All of these terms have _laws_ that express limitations which ensure that all instances behave reasonably. We shan't go over them here, but it's good to know that - even if we're not ready to look into them yet - they exist, that there is a rich mathematical backing to these concepts. If this piques your curiosity at all, the best resource is probably [Typeclassopedia on HaskellWiki](https://wiki.haskell.org/Typeclassopedia).

M published/20200602-function-domain.md => published/20200602-function-domain.md +6 -0
@@ 1,3 1,9 @@
---
slug: "function-domain"
date: "2020-06-02"
title: "Function domain"
---

Functional programming is, funnily enough, all about functions. As such, it's good to refine how we write them. This post is all about the domains of our functions.

## What's the domain?