|
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’stalk 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.
|