Functional Geekery Episode 129 - Eric Normand

In this episode I talk with Eric Normand. We talk his podcast “Thoughts on Functional Programming”; his in-progress book “Grokking Simplicity“; Actions, Calculations, and Data; trying to bury mutation and side-effects; Property-Based testing; and more.

Our Guest, Eric Normand

@ericnormand on Twitter
PurelyFunctional.tv
LispCast.com
Thoughts on Functional Programming
Grokking Simplicity

Conference Announcements

Lambda Days 2020 will be on the 13th and 14th of February in Kraków, Poland. Visit https://www.lambdadays.org/lambdadays2020 to find out more and to register.

Code BEAM SF is taking place on March 6th and 6th. For more information visit: https://codesync.global/conferences/code-beam-sf/.

Elm in the Spring will be taking place May 1st. Check in at https://www.elminthespring.org/ to keep updated as more information gets announced.

If you have a conference related to functional programming, contact me, and I will be happy to announce it.

Announcements

Some of you have asked how you can support Functional Geekery, in that vein, Functional Geekery now has a Patreon Page.

If that is one of the ways you would like to show your support, you can find out more at https://www.patreon.com/fngeekery.

Topics [@2:32]

Welcome back Eric
What Eric has been up to since Episode 117
PurelyFunctional.tv
Grokking Simplicity
What prompted the Thoughts on Functional Programming podcast
Started from Eric’s talk at Lambdup 2017
Being told it is much easier to edit existing text than write new text
Trying to start a literature around functional programming
Figuring out the format/layout of the book
“Just imagine each page as a slide”
The target audience for the book
“Functional programming is programming without side effects”
Not being able to recommend any books on getting started with functional programming
Actions, Calculations, and Data
Actions (Impure “Function”) – Depend on when, or how many times, they are run
Side-effects also being the reason we write programs
Calculations (Pure “Functions”) – Same arguments, same answer no matter how many times you run it
Data – completely inert
Data can be interpreted in multiple ways
Other side of Data is that it requires at least some interpretation
How to help distinguish Actions from Calculations
Haskell‘s IO type containing all side-effects as brilliant
The illusion that we are not doing any mutability at the machine level
Blurry line between Actions and Calculations in some cases
Any conventions for later readers to hint at Actions vs Calculations
Selling the separation of Calculations from Actions
Spending time on showing how Actions “contaminate” Calculations
The idea that “You could abstract away the mutation”
Thinking you are going to bury and covering up the problem
“Can you construct a User from an ID without hitting the database”
Needing mocks as a possible signal of being an Action instead of a Calculation
PurelyFunctional.tv videos
Thoughts on Functional Programming podcast
Property-Based Testing videos
Beginning Property-Based Testing course
Intermediate Property-Based Testing course
Advanced Property-Based Testing course
Property-Based testing
QuickCheck
Next course likely building a web-app in Clojure
Bag of Tricks for Property-Based testing
Developing for Stateful Systems
Model-based Property testing
Taking a Stateful test to a Parallel test to a Distributed Test
TSSIMPLICITY discount code for 50% off

As always, a giant Thank You goes to David Belcher for the logo design.