<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/stylesheet.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <atom:link rel="self" type="application/atom+xml" href="https://feeds.transistor.fm/thoughts-on-functional-programming-podcast-by-eric-normand" title="MP3 Audio"/>
    <atom:link rel="hub" href="https://pubsubhubbub.appspot.com/"/>
    <podcast:podping usesPodping="true"/>
    <title>The Eric Normand Podcast</title>
    <generator>Transistor (https://transistor.fm)</generator>
    <itunes:new-feed-url>https://feeds.transistor.fm/thoughts-on-functional-programming-podcast-by-eric-normand</itunes:new-feed-url>
    <description>An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand of LispCast. Formerly known as Thoughts on Functional Programming.</description>
    <copyright>© 2018-2022 Eric Normand</copyright>
    <podcast:guid>67e0577e-4aff-55ea-87e1-35bf8557833a</podcast:guid>
    <podcast:locked owner="eric@lispcast.com">no</podcast:locked>
    <language>en-us</language>
    <pubDate>Tue, 09 Apr 2024 12:19:26 +0000</pubDate>
    <lastBuildDate>Tue, 02 Dec 2025 20:29:09 +0000</lastBuildDate>
    <link>https://ericnormand.me/podcast</link>
    <image>
      <url>https://img.transistor.fm/qsojM14FGQQhObLqpwbUCV7__Hy90SRK-1bY3L2rAAM/rs:fill:0:0:1/w:1400/h:1400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQzMzgvMTU2ODQ4/NjQ0MC1hcnR3b3Jr/LmpwZw.jpg</url>
      <title>The Eric Normand Podcast</title>
      <link>https://ericnormand.me/podcast</link>
    </image>
    <itunes:category text="Education">
      <itunes:category text="How To"/>
    </itunes:category>
    <itunes:category text="News">
      <itunes:category text="Tech News"/>
    </itunes:category>
    <itunes:type>episodic</itunes:type>
    <itunes:author>Eric Normand</itunes:author>
    <itunes:image href="https://img.transistor.fm/qsojM14FGQQhObLqpwbUCV7__Hy90SRK-1bY3L2rAAM/rs:fill:0:0:1/w:1400/h:1400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQzMzgvMTU2ODQ4/NjQ0MC1hcnR3b3Jr/LmpwZw.jpg"/>
    <itunes:summary>An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand of LispCast. Formerly known as Thoughts on Functional Programming.</itunes:summary>
    <itunes:subtitle>An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand of LispCast.</itunes:subtitle>
    <itunes:keywords></itunes:keywords>
    <itunes:owner>
      <itunes:name>Eric Normand</itunes:name>
    </itunes:owner>
    <itunes:complete>No</itunes:complete>
    <itunes:explicit>No</itunes:explicit>
    <item>
      <title>All about the stratified design lens</title>
      <itunes:title>All about the stratified design lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">fd12672d-5627-4877-a1bc-103f34fe9501</guid>
      <link>https://ericnormand.me/podcast/stratified-design-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the stratified design lens, which talks about how and why we split things into layers.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the stratified design lens, which talks about how and why we split things into layers.</p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Sep 2023 15:15:51 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2d6d4240/5dbe11ce.mp3" length="11890215" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>744</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the stratified design lens, which talks about how and why we split things into layers.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the time lens</title>
      <itunes:title>All about the time lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">7d794f98-c5eb-4c32-a6b3-ee1215cbaad9</guid>
      <link>https://ericnormand.me/podcast/time-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the time lens, and I posit a law about representing time in complex domains.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the time lens, and I posit a law about representing time in complex domains.</p>]]>
      </content:encoded>
      <pubDate>Tue, 19 Sep 2023 16:02:58 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5c6d932f/264f514e.mp3" length="10169464" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>636</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the time lens, and I posit a law about representing time in complex domains.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the volatility lens</title>
      <itunes:title>All about the volatility lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">51f88d09-093a-4549-a24c-64cffe5d4ef5</guid>
      <link>https://ericnormand.me/podcast/volatility-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the volatility lens, which seeks to help us write code that deals with a changing world.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the volatility lens, which seeks to help us write code that deals with a changing world.</p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Sep 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8c553b66/30e5e02f.mp3" length="17713216" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1108</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the volatility lens, which seeks to help us write code that deals with a changing world.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the architecture lens</title>
      <itunes:title>All about the architecture lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">40e469cf-389f-4c1c-9bf2-fc261d94a111</guid>
      <link>https://ericnormand.me/podcast/architecture-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the architecture lens, its questions, and its goal of modeling architectural domains to manage complexity.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the architecture lens, its questions, and its goal of modeling architectural domains to manage complexity.</p>]]>
      </content:encoded>
      <pubDate>Mon, 31 Jul 2023 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/083558bb/5811fe64.mp3" length="23358578" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1460</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the architecture lens, its questions, and its goal of modeling architectural domains to manage complexity.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the executable specification lens</title>
      <itunes:title>All about the executable specification lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">4a17f6ad-fbbe-4d72-b1ff-68f581b8a84b</guid>
      <link>https://ericnormand.me/podcast/executable-specification-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the executable specification lens, its questions, and its goal of getting to runnable, testable code as quickly as possible.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the executable specification lens, its questions, and its goal of getting to runnable, testable code as quickly as possible.</p>]]>
      </content:encoded>
      <pubDate>Mon, 24 Jul 2023 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5dba18d9/0223ae5f.mp3" length="14677997" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>918</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the executable specification lens, its questions, and its goal of getting to runnable, testable code as quickly as possible.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the composition lens</title>
      <itunes:title>All about the composition lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c2a110fb-f6fb-4509-86c6-d74d0702cef1</guid>
      <link>https://ericnormand.me/podcast/composition-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the composition lens, its questions, and its goal of figuring what's true when you perform multiple operations in a row.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the composition lens, its questions, and its goal of figuring what's true when you perform multiple operations in a row.</p>]]>
      </content:encoded>
      <pubDate>Mon, 10 Jul 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8c79003a/c067b65f.mp3" length="13178346" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>824</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the composition lens, its questions, and its goal of figuring what's true when you perform multiple operations in a row.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the operation lens</title>
      <itunes:title>All about the operation lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">63041611-7403-4c3c-a26d-3dc979d10cdf</guid>
      <link>https://ericnormand.me/podcast/operation-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the operation lens, its questions, and its goal of capturing the use cases of your software.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the operation lens, its questions, and its goal of capturing the use cases of your software.</p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Jul 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fd70197c/0ad7d49b.mp3" length="18872621" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1180</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the operation lens, its questions, and its goal of capturing the use cases of your software.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Data lens</title>
      <itunes:title>Data lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d55985f3-31b1-4958-977c-2665bb6e0fed</guid>
      <link>https://ericnormand.me/podcast/data-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the data lens, its questions, and its goals of capturing relationships among data values in data.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the data lens, its questions, and its goals of capturing relationships among data values in data.</p>]]>
      </content:encoded>
      <pubDate>Mon, 26 Jun 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f8ab4e17/a521b737.mp3" length="22363410" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1398</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the data lens, its questions, and its goals of capturing relationships among data values in data.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about the domain lens</title>
      <itunes:title>All about the domain lens</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">43701c12-333e-4855-a5a1-845bb6400af5</guid>
      <link>https://ericnormand.me/podcast/domain-lens</link>
      <description>
        <![CDATA[<p>In this episode, I introduce the domain lens, its questions, and its goal.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I introduce the domain lens, its questions, and its goal.</p>]]>
      </content:encoded>
      <pubDate>Mon, 19 Jun 2023 15:01:39 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/6cf225ce/5ff69c8e.mp3" length="19094135" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1194</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I introduce the domain lens, its questions, and its goal.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How does executable specifications compare with other modeling paradigms?</title>
      <itunes:title>How does executable specifications compare with other modeling paradigms?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">33905fc2-e61a-4582-abfa-507d085a6d93</guid>
      <link>https://ericnormand.me/podcast/compare-executable-specifications</link>
      <description>
        <![CDATA[<p>In this episode, I compare executable specifications to UML, DDD, and software design.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I compare executable specifications to UML, DDD, and software design.</p>]]>
      </content:encoded>
      <pubDate>Mon, 12 Jun 2023 15:10:55 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8f570d1a/a5f6d180.mp3" length="22473815" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1405</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>In this episode, I compare executable specifications to UML, DDD, and software design.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the title of my new book?</title>
      <itunes:title>What is the title of my new book?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">0cf14721-398c-4446-82b2-9bc86660d2f8</guid>
      <link>https://ericnormand.me/podcast/what-is-the-title-of-my-new-book</link>
      <description>
        <![CDATA[<p>I've found a better title for my book: Executable Specifications. Listen to find out why it's better.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>I've found a better title for my book: Executable Specifications. Listen to find out why it's better.</p>]]>
      </content:encoded>
      <pubDate>Mon, 05 Jun 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/afc6cf54/fa954fe4.mp3" length="7128403" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>446</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>I've found a better title for my book: Executable Specifications. Listen to find out why it's better.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are the domain modeling lenses?</title>
      <itunes:title>What are the domain modeling lenses?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">0bca6194-2d6b-4a67-99f9-6f7630dc142c</guid>
      <link>https://ericnormand.me/podcast/what-are-the-domain-modeling-lenses</link>
      <description>
        <![CDATA[<p>I'm organizing my new book in terms of lenses. Each lens focuses our attention on one important aspect of software design. In this episode, I briefly introduce each lens.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>I'm organizing my new book in terms of lenses. Each lens focuses our attention on one important aspect of software design. In this episode, I briefly introduce each lens.</p>]]>
      </content:encoded>
      <pubDate>Mon, 29 May 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/47dd7fcc/6b5c9712.mp3" length="20119832" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1258</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>I'm organizing my new book in terms of lenses. Each lens focuses our attention on one important aspect of software design. In this episode, I briefly introduce each lens.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is domain modeling evolving these days?</title>
      <itunes:title>How is domain modeling evolving these days?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">05e92b1a-9d73-4d50-9722-397790af57ce</guid>
      <link>https://ericnormand.me/podcast/how-is-domain-modeling-evolving</link>
      <description>
        <![CDATA[<p>I talk about the progress I've made on my book and why I'm throwing it away and starting over.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>I talk about the progress I've made on my book and why I'm throwing it away and starting over.</p>]]>
      </content:encoded>
      <pubDate>Mon, 22 May 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/34965975/75784dac.mp3" length="19510036" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1220</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>I talk about the progress I've made on my book and why I'm throwing it away and starting over.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why don't I encounter more type errors when programming in Clojure?</title>
      <itunes:title>Why don't I encounter more type errors when programming in Clojure?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">29b6d13f-6196-4936-99c4-29a3275d9d29</guid>
      <link>https://ericnormand.me/podcast/why-no-type-errors-in-clojure</link>
      <description>
        <![CDATA[<p>I give another reason why I don't encounter so many type errors in Clojure.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>I give another reason why I don't encounter so many type errors in Clojure.</p>]]>
      </content:encoded>
      <pubDate>Mon, 15 May 2023 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/89caf874/787a402b.mp3" length="6978808" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>437</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>I give another reason why I don't encounter so many type errors in Clojure.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the "reify to an interpreter" refactoring?</title>
      <itunes:title>What is the "reify to an interpreter" refactoring?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e95a0bc4-4b04-4541-a155-7f4024f6d5e0</guid>
      <link>https://ericnormand.me/podcast/what-is-reify-to-interpreter-refactoring</link>
      <description>
        <![CDATA[<p>Watch the creation of a simple refactoring to turn functions into data.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>Watch the creation of a simple refactoring to turn functions into data.</p>]]>
      </content:encoded>
      <pubDate>Mon, 08 May 2023 19:50:26 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2d3d7c19/a61f83d0.mp3" length="6916097" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>433</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>Watch the creation of a simple refactoring to turn functions into data.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How to teach an essential skill in domain modeling?</title>
      <itunes:title>How to teach an essential skill in domain modeling?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">f2776b0f-24ae-48f1-89a4-66ff4b55891f</guid>
      <link>https://ericnormand.me/podcast/how-to-teach-an-essential-skill-in-domain-modeling</link>
      <description>
        <![CDATA[<p>One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?</p>]]>
      </content:encoded>
      <pubDate>Mon, 24 Apr 2023 15:11:41 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1dd543d1/291c8e61.mp3" length="11584701" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>725</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is an isomorphism?</title>
      <itunes:title>What is an isomorphism?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">76b6851d-6974-47bc-999d-3be25c852384</guid>
      <link>https://ericnormand.me/podcast/what-is-isomorphism</link>
      <description>
        <![CDATA[<p>An isomorphism is a one-to-one mapping from two sets, and encoding your domain model involves finding a mapping between the real world and your code. So does domain modeling involve isomorphism?</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>An isomorphism is a one-to-one mapping from two sets, and encoding your domain model involves finding a mapping between the real world and your code. So does domain modeling involve isomorphism?</p>]]>
      </content:encoded>
      <pubDate>Mon, 17 Apr 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b2ccc9cc/8b4adc8d.mp3" length="4987189" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>312</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>An isomorphism is a one-to-one mapping from two sets, and encoding your domain model involves finding a mapping between the real world and your code. So does domain modeling involve isomorphism?</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Applying domain modeling to an existing data structure</title>
      <itunes:title>Applying domain modeling to an existing data structure</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">7ac237e4-45ff-41c3-a74e-623fc594679a</guid>
      <link>https://ericnormand.me/podcast/applying-domain-modeling-to-existing-data-structure</link>
      <description>
        <![CDATA[<p>Domain modeling also works after you've already got lots of code. How can we apply domain modeling analysis to existing data structures?</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>Domain modeling also works after you've already got lots of code. How can we apply domain modeling analysis to existing data structures?</p>]]>
      </content:encoded>
      <pubDate>Mon, 10 Apr 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1614307d/07c9d2c5.mp3" length="9405906" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>584</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>Domain modeling also works after you've already got lots of code. How can we apply domain modeling analysis to existing data structures?</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the commutative property?</title>
      <itunes:title>What is the commutative property?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">5aba492c-a3bc-43ff-9179-f337a54c970b</guid>
      <link>https://ericnormand.me/podcast/what-is-the-commutative-property</link>
      <description>
        <![CDATA[<p>We discuss the commutative property, why we use it, and three different possible meanings.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>We discuss the commutative property, why we use it, and three different possible meanings.</p>]]>
      </content:encoded>
      <pubDate>Mon, 20 Feb 2023 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bcde4f09/0f003d47.mp3" length="6154860" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>381</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>We discuss the commutative property, why we use it, and three different possible meanings.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why is the associative property important?</title>
      <itunes:title>Why is the associative property important?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">3a66b849-5ea0-4027-8009-40b7ea650104</guid>
      <link>https://ericnormand.me/podcast/why-is-the-associative-property-important</link>
      <description>
        <![CDATA[<p>We look at several examples where the associative property gives us expressive power.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>We look at several examples where the associative property gives us expressive power.</p>]]>
      </content:encoded>
      <pubDate>Mon, 13 Feb 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/29cbb55a/9a650e2a.mp3" length="12073152" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>751</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>We look at several examples where the associative property gives us expressive power.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the process for coming up with a good conceptual model?</title>
      <itunes:title>What is the process for coming up with a good conceptual model?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">8cc1ca96-1736-41d6-bf62-da5a1468209d</guid>
      <link>https://ericnormand.me/podcast/process-for-conceptual-modeling</link>
      <description>
        <![CDATA[<p>We describe a three-step process for discovering conceptual models.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>We describe a three-step process for discovering conceptual models.</p>]]>
      </content:encoded>
      <pubDate>Mon, 30 Jan 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/6d6a566e/dfcd87a8.mp3" length="14282464" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>889</itunes:duration>
      <itunes:summary>
        <![CDATA[<p>We describe a three-step process for discovering conceptual models.</p>]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the closure property?</title>
      <itunes:title>What is the closure property?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b95f15e3-9099-4c9b-b6ce-bedbf5feccb8</guid>
      <link>https://ericnormand.me/podcast/what-is-the-closure-property</link>
      <description>
        <![CDATA[I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.]]>
      </description>
      <content:encoded>
        <![CDATA[I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.]]>
      </content:encoded>
      <pubDate>Mon, 23 Jan 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fedb8ebd/c40eceb9.mp3" length="7497432" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>465</itunes:duration>
      <itunes:summary>I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.</itunes:summary>
      <itunes:subtitle>I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>All about level three, algebraic modeling</title>
      <itunes:title>All about level three, algebraic modeling</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e0809878-4021-4abc-8918-da6e1cb5d349</guid>
      <link>https://ericnormand.me/podcast/all-about-level-three-algebraic-modeling</link>
      <description>
        <![CDATA[What do I mean by algebra? And how do we get from level 0 to level 3?]]>
      </description>
      <content:encoded>
        <![CDATA[What do I mean by algebra? And how do we get from level 0 to level 3?]]>
      </content:encoded>
      <pubDate>Mon, 09 Jan 2023 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5375d6e0/de738d4a.mp3" length="12167620" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>757</itunes:duration>
      <itunes:summary>What do I mean by algebra? And how do we get from level 0 to level 3?</itunes:summary>
      <itunes:subtitle>What do I mean by algebra? And how do we get from level 0 to level 3?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do we need to model time?</title>
      <itunes:title>Why do we need to model time?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">421b89e1-5930-452c-b3bb-96858685d87e</guid>
      <link>https://ericnormand.me/podcast/why-do-you-need-to-model-time</link>
      <description>
        <![CDATA[All sophisticated models need to include time. We discuss two main ways to do that.]]>
      </description>
      <content:encoded>
        <![CDATA[All sophisticated models need to include time. We discuss two main ways to do that.]]>
      </content:encoded>
      <pubDate>Mon, 26 Dec 2022 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a996204a/2c553421.mp3" length="10591498" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>659</itunes:duration>
      <itunes:summary>All sophisticated models need to include time. We discuss two main ways to do that.</itunes:summary>
      <itunes:subtitle>All sophisticated models need to include time. We discuss two main ways to do that.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do you make a function total?</title>
      <itunes:title>How do you make a function total?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">ca5725da-89e5-4468-ad99-ee6b19d14e7e</guid>
      <link>https://ericnormand.me/podcast/how-do-you-make-a-function-total</link>
      <description>
        <![CDATA[It is easier to reason about total functions. And you can make any pure function total using three techniques!]]>
      </description>
      <content:encoded>
        <![CDATA[It is easier to reason about total functions. And you can make any pure function total using three techniques!]]>
      </content:encoded>
      <pubDate>Mon, 19 Dec 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1285309d/cc1457d5.mp3" length="11665715" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>726</itunes:duration>
      <itunes:summary>It is easier to reason about total functions. And you can make any pure function total using three techniques!</itunes:summary>
      <itunes:subtitle>It is easier to reason about total functions. And you can make any pure function total using three techniques!</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a mutation function?</title>
      <itunes:title>What is a mutation function?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">1aa5a8c8-5851-44e7-975a-ea936ccbc5ee</guid>
      <link>https://ericnormand.me/podcast/what-is-a-mutation-function</link>
      <description>
        <![CDATA[Mutation functions let you represent changing state over time. They are easily reified, used as reducing functions, and can operate on nested data.]]>
      </description>
      <content:encoded>
        <![CDATA[Mutation functions let you represent changing state over time. They are easily reified, used as reducing functions, and can operate on nested data.]]>
      </content:encoded>
      <pubDate>Mon, 12 Dec 2022 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/cc97479c/3d2257b3.mp3" length="5923440" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>367</itunes:duration>
      <itunes:summary>Mutation functions let you represent changing state over time. They are easily reified, used as reducing functions, and can operate on nested data.</itunes:summary>
      <itunes:subtitle>Mutation functions let you represent changing state over time. They are easily reified, used as reducing functions, and can operate on nested data.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Signature-Driven Development?</title>
      <itunes:title>What is Signature-Driven Development?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b7f54eab-d711-4a71-a918-66ee65dbb973</guid>
      <link>https://ericnormand.me/podcast/what-is-signature-driven-development</link>
      <description>
        <![CDATA[Signature-Driven Development means starting with function signatures before you
implement them. I also discuss why we implement the hardest function first.]]>
      </description>
      <content:encoded>
        <![CDATA[Signature-Driven Development means starting with function signatures before you
implement them. I also discuss why we implement the hardest function first.]]>
      </content:encoded>
      <pubDate>Tue, 06 Dec 2022 15:36:10 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/147c895d/5b1d6c7c.mp3" length="10842020" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>674</itunes:duration>
      <itunes:summary>Signature-Driven Development means starting with function signatures before you
implement them. I also discuss why we implement the hardest function first.</itunes:summary>
      <itunes:subtitle>Signature-Driven Development means starting with function signatures before you
implement them. I also discuss why we implement the hardest function first.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What's the problem with using arrays for pizza toppings? </title>
      <itunes:title>What's the problem with using arrays for pizza toppings? </itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d22cf900-87aa-4586-aa7f-b86f4e555978</guid>
      <link>https://ericnormand.me/podcast/problem-with-arrays-for-toppings</link>
      <description>
        <![CDATA[]]>
      </description>
      <content:encoded>
        <![CDATA[]]>
      </content:encoded>
      <pubDate>Mon, 28 Nov 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8c0aa9d5/6e760ef2.mp3" length="6716832" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>416</itunes:duration>
      <itunes:summary>
        <![CDATA[]]>
      </itunes:summary>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is deferring decisions about our domain a good idea?</title>
      <itunes:title>Is deferring decisions about our domain a good idea?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">2cf6b030-1721-405b-a6c0-4a6713731ece</guid>
      <link>https://ericnormand.me/podcast/deferring-decisions-business-layer</link>
      <description>
        <![CDATA[I wonder when to deal with business rules. Do they belong in the domain layer?]]>
      </description>
      <content:encoded>
        <![CDATA[I wonder when to deal with business rules. Do they belong in the domain layer?]]>
      </content:encoded>
      <pubDate>Mon, 21 Nov 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b10ffdd4/6e0c028e.mp3" length="5456006" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>338</itunes:duration>
      <itunes:summary>I wonder when to deal with business rules. Do they belong in the domain layer?</itunes:summary>
      <itunes:subtitle>I wonder when to deal with business rules. Do they belong in the domain layer?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can domain modeling be taught?</title>
      <itunes:title>Can domain modeling be taught?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">f5f31ea2-84ee-4337-bc05-bdabbc581963</guid>
      <link>https://ericnormand.me/podcast/can-domain-modeling-be-taught</link>
      <description>
        <![CDATA[I answer a listener's questions about whether domain modeling is a skill that can be taught.]]>
      </description>
      <content:encoded>
        <![CDATA[I answer a listener's questions about whether domain modeling is a skill that can be taught.]]>
      </content:encoded>
      <pubDate>Mon, 14 Nov 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9fa965de/c4246f06.mp3" length="8707778" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>541</itunes:duration>
      <itunes:summary>I answer a listener's questions about whether domain modeling is a skill that can be taught.</itunes:summary>
      <itunes:subtitle>I answer a listener's questions about whether domain modeling is a skill that can be taught.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why domain modeling?</title>
      <itunes:title>Why domain modeling?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">f029e3d4-a86f-4179-b6a5-90f1b12f9fb3</guid>
      <link>https://ericnormand.me/podcast/why-domain-modeling</link>
      <description>
        <![CDATA[We explore why focusing on the domain model can improve your software quality.]]>
      </description>
      <content:encoded>
        <![CDATA[We explore why focusing on the domain model can improve your software quality.]]>
      </content:encoded>
      <pubDate>Mon, 07 Nov 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4e9c06a3/349313d8.mp3" length="5805414" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>359</itunes:duration>
      <itunes:summary>We explore why focusing on the domain model can improve your software quality.</itunes:summary>
      <itunes:subtitle>We explore why focusing on the domain model can improve your software quality.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do we evaluate a data model?</title>
      <itunes:title>How do we evaluate a data model?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">7dde2e02-6208-444e-ad30-aca912ba5364</guid>
      <link>https://ericnormand.me/podcast/how-do-we-evaluate-a-data-model</link>
      <description>
        <![CDATA[We talk about how you can evaluate the two parts of a domain model.]]>
      </description>
      <content:encoded>
        <![CDATA[We talk about how you can evaluate the two parts of a domain model.]]>
      </content:encoded>
      <pubDate>Mon, 31 Oct 2022 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1dc74aaa/aabf1882.mp3" length="29879447" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1864</itunes:duration>
      <itunes:summary>We talk about how you can evaluate the two parts of a domain model.</itunes:summary>
      <itunes:subtitle>We talk about how you can evaluate the two parts of a domain model.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a domain model and how do we think about them?</title>
      <itunes:title>What is a domain model and how do we think about them?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">ceb34d77-48d5-419e-b43e-3c03af7b71db</guid>
      <link>https://ericnormand.me/podcast/what-is-a-domain-model-and-how-do-we-think-about-them</link>
      <description>
        <![CDATA[In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.]]>
      </content:encoded>
      <pubDate>Mon, 24 Oct 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/48c7216c/8ba90c38.mp3" length="23690068" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1477</itunes:duration>
      <itunes:summary>In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.</itunes:summary>
      <itunes:subtitle>In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>When do we want to refer to things by name?</title>
      <itunes:title>When do we want to refer to things by name?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c189d437-4b8c-4974-b715-43192262371d</guid>
      <link>https://ericnormand.me/podcast/domain-modeling-name-vs-reference</link>
      <description>
        <![CDATA[In a domain model, when should we refer to things by name, and when should we nest a subcomponent?]]>
      </description>
      <content:encoded>
        <![CDATA[In a domain model, when should we refer to things by name, and when should we nest a subcomponent?]]>
      </content:encoded>
      <pubDate>Mon, 17 Oct 2022 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/16f5f146/a6ef912f.mp3" length="11409078" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>710</itunes:duration>
      <itunes:summary>In a domain model, when should we refer to things by name, and when should we nest a subcomponent?</itunes:summary>
      <itunes:subtitle>In a domain model, when should we refer to things by name, and when should we nest a subcomponent?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Collections in domain models</title>
      <itunes:title>Collections in domain models</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">804326e5-fac4-4fb4-8bea-beedb3942731</guid>
      <link>https://ericnormand.me/podcast/collections-in-domain-models</link>
      <description>
        <![CDATA[When do we use collections in domain models, and how do we think about the states they represent?]]>
      </description>
      <content:encoded>
        <![CDATA[When do we use collections in domain models, and how do we think about the states they represent?]]>
      </content:encoded>
      <pubDate>Mon, 10 Oct 2022 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4e7aa447/fdc1089b.mp3" length="17313974" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1079</itunes:duration>
      <itunes:summary>When do we use collections in domain models, and how do we think about the states they represent?</itunes:summary>
      <itunes:subtitle>When do we use collections in domain models, and how do we think about the states they represent?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Layout of Domain Modeling book</title>
      <itunes:title>Layout of Domain Modeling book</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">9f52e703-a3ab-42c8-942d-b077fe18e912</guid>
      <link>https://ericnormand.me/podcast/layout-of-domain-modeling-book</link>
      <description>
        <![CDATA[In this episode, I talk about the three parts of my book, which mirror the three levels of domain modeling.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, I talk about the three parts of my book, which mirror the three levels of domain modeling.]]>
      </content:encoded>
      <pubDate>Mon, 03 Oct 2022 15:41:38 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ea82c4e8/9dec6b63.mp3" length="24162253" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1507</itunes:duration>
      <itunes:summary>In this episode, I talk about the three parts of my book, which mirror the three levels of domain modeling.</itunes:summary>
      <itunes:subtitle>In this episode, I talk about the three parts of my book, which mirror the three levels of domain modeling.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The power of runnable specifications</title>
      <itunes:title>The power of runnable specifications</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">afed54fb-a4c6-45a2-819d-f244b3d4f726</guid>
      <link>https://ericnormand.me/podcast/power-of-runnable-specifications</link>
      <description>
        <![CDATA[I talk about the advantages of writing a spec directly in your production language.]]>
      </description>
      <content:encoded>
        <![CDATA[I talk about the advantages of writing a spec directly in your production language.]]>
      </content:encoded>
      <pubDate>Mon, 29 Aug 2022 10:42:06 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5afc8084/5d9f908d.mp3" length="14139980" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>879</itunes:duration>
      <itunes:summary>I talk about the advantages of writing a spec directly in your production language.</itunes:summary>
      <itunes:subtitle>I talk about the advantages of writing a spec directly in your production language.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a domain model?</title>
      <itunes:title>What is a domain model?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">83129fbd-5765-4675-bb5d-507f4b9ad2b0</guid>
      <link>https://ericnormand.me/podcast/what-is-a-domain-model</link>
      <description>
        <![CDATA[In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.]]>
      </content:encoded>
      <pubDate>Mon, 22 Aug 2022 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4871e353/4dbb9100.mp3" length="9801655" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>608</itunes:duration>
      <itunes:summary>In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.</itunes:summary>
      <itunes:subtitle>In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a high-level language?</title>
      <itunes:title>What is a high-level language?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">900d566c-4210-40ee-8ccd-132522e51d16</guid>
      <link>https://ericnormand.me/podcast/high-level-language</link>
      <description>
        <![CDATA[We've all heard the term _high-level language_. Initially, it referred to the
step from assembly languages to compiled languages. But it has another
definition, which has to do with how well the language lets you think.]]>
      </description>
      <content:encoded>
        <![CDATA[We've all heard the term _high-level language_. Initially, it referred to the
step from assembly languages to compiled languages. But it has another
definition, which has to do with how well the language lets you think.]]>
      </content:encoded>
      <pubDate>Mon, 15 Aug 2022 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/df2a5980/b03db40f.mp3" length="6681816" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>413</itunes:duration>
      <itunes:summary>We've all heard the term _high-level language_. Initially, it referred to the
step from assembly languages to compiled languages. But it has another
definition, which has to do with how well the language lets you think.</itunes:summary>
      <itunes:subtitle>We've all heard the term _high-level language_. Initially, it referred to the
step from assembly languages to compiled languages. But it has another
definition, which has to do with how well the language lets you think.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Rewrites</title>
      <itunes:title>Rewrites</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c8f42153-9b4d-4e3b-a078-58a44c381029</guid>
      <link>https://ericnormand.me/podcast/rewrites</link>
      <description>
        <![CDATA[How is Smalltalk so small? Four rewrites.]]>
      </description>
      <content:encoded>
        <![CDATA[How is Smalltalk so small? Four rewrites.]]>
      </content:encoded>
      <pubDate>Mon, 08 Aug 2022 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/493d9140/064a1883.mp3" length="9258152" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>574</itunes:duration>
      <itunes:summary>How is Smalltalk so small? Four rewrites.</itunes:summary>
      <itunes:subtitle>How is Smalltalk so small? Four rewrites.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is the abstract stuff at the top or the bottom?</title>
      <itunes:title>Is the abstract stuff at the top or the bottom?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">1bad0d3b-081e-4d09-98de-7d5c4003536f</guid>
      <link>https://ericnormand.me/podcast/abstract-concrete-spectrum</link>
      <description>
        <![CDATA[I explore a new perspective about what abstraction means and how it can cause problems.]]>
      </description>
      <content:encoded>
        <![CDATA[I explore a new perspective about what abstraction means and how it can cause problems.]]>
      </content:encoded>
      <pubDate>Sun, 24 Apr 2022 19:29:34 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/79d61c1b/47653889.mp3" length="13924020" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>866</itunes:duration>
      <itunes:summary>I explore a new perspective about what abstraction means and how it can cause problems.</itunes:summary>
      <itunes:subtitle>I explore a new perspective about what abstraction means and how it can cause problems.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The Christopher Alexander Effect</title>
      <itunes:title>The Christopher Alexander Effect</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">48f2a2af-ebc5-472a-962a-baae0e37373a</guid>
      <link>https://lispcast.com/the-christopher-alexander-effect/</link>
      <description>
        <![CDATA[Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.]]>
      </description>
      <content:encoded>
        <![CDATA[Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.]]>
      </content:encoded>
      <pubDate>Mon, 07 Feb 2022 12:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/12ffb0bc/b44d51e1.mp3" length="13090807" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>814</itunes:duration>
      <itunes:summary>Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.</itunes:summary>
      <itunes:subtitle>Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>My feelings about static vs dynamic typing</title>
      <itunes:title>My feelings about static vs dynamic typing</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b08b24ac-fd24-40b5-a068-9f56b6fb4a8e</guid>
      <link>https://lispcast.com/my-feelings-about-static-vs-dynamic-typing/</link>
      <description>
        <![CDATA[<p>Can't we all just get along?</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>Can't we all just get along?</p>]]>
      </content:encoded>
      <pubDate>Mon, 31 Jan 2022 16:23:53 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c24c59f8/5c16755f.mp3" length="85575386" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2137</itunes:duration>
      <itunes:summary>Can't we all just get along?</itunes:summary>
      <itunes:subtitle>Can't we all just get along?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Computer Science as Empirical Inquiry: Symbols and Search</title>
      <itunes:title>Computer Science as Empirical Inquiry: Symbols and Search</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d1ebf4bd-c9bb-4222-b859-21afc8e15d5b</guid>
      <link>https://lispcast.com/computer-science-as-empirical-inquiry-symbols-and-search/</link>
      <description>
        <![CDATA[<p>In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.</p>]]>
      </content:encoded>
      <pubDate>Mon, 10 Jan 2022 12:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b3b97ccd/066612e2.mp3" length="299000170" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>7473</itunes:duration>
      <itunes:summary>In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.</itunes:summary>
      <itunes:subtitle>In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How far can we stretch technical debt?</title>
      <itunes:title>How far can we stretch technical debt?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c690cb23-3da0-4068-b893-8d0ffb6ab2f7</guid>
      <link>https://lispcast.com/how-far-can-we-stretch-technical-debt/</link>
      <description>
        <![CDATA[Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.]]>
      </description>
      <content:encoded>
        <![CDATA[Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.]]>
      </content:encoded>
      <pubDate>Mon, 15 Nov 2021 12:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/19263ee5/1d7486e7.mp3" length="59771222" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1492</itunes:duration>
      <itunes:summary>Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.</itunes:summary>
      <itunes:subtitle>Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How to avoid premature optimization?</title>
      <itunes:title>How to avoid premature optimization?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">250a33f1-e31c-42ba-87e1-7601067fac7f</guid>
      <link>https://lispcast.com/how-to-avoid-premature-optimization/</link>
      <description>
        <![CDATA[I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.]]>
      </description>
      <content:encoded>
        <![CDATA[I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.]]>
      </content:encoded>
      <pubDate>Mon, 08 Nov 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d36825e5/f81f05dd.mp3" length="77296823" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1930</itunes:duration>
      <itunes:summary>I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.</itunes:summary>
      <itunes:subtitle>I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is domain modeling?</title>
      <itunes:title>What is domain modeling?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">bfd04557-dcb4-4366-84d3-42cf7c475a77</guid>
      <link>https://lispcast.com/what-is-domain-modeling/</link>
      <description>
        <![CDATA[I begin exploring the process of domain modeling with a definition.]]>
      </description>
      <content:encoded>
        <![CDATA[I begin exploring the process of domain modeling with a definition.]]>
      </content:encoded>
      <pubDate>Mon, 01 Nov 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/46c253d2/21ac685d.mp3" length="52319549" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1306</itunes:duration>
      <itunes:summary>I begin exploring the process of domain modeling with a definition.</itunes:summary>
      <itunes:subtitle>I begin exploring the process of domain modeling with a definition.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Computer Programming as an Art</title>
      <itunes:title>Computer Programming as an Art</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c5960f9d-0dfd-4c64-bd31-8634e4a69091</guid>
      <link>https://lispcast.com/computer-programming-as-an-art/</link>
      <description>
        <![CDATA[I read from the 1974 Turing Award Lecture by Don Knuth.]]>
      </description>
      <content:encoded>
        <![CDATA[I read from the 1974 Turing Award Lecture by Don Knuth.]]>
      </content:encoded>
      <pubDate>Mon, 27 Sep 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/230b119c/ca1cde24.mp3" length="194534240" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>4861</itunes:duration>
      <itunes:summary>I read from the 1974 Turing Award Lecture by Don Knuth.</itunes:summary>
      <itunes:subtitle>I read from the 1974 Turing Award Lecture by Don Knuth.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Programmer as Navigator</title>
      <itunes:title>Programmer as Navigator</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c5a8b8fb-3324-47b6-b837-3f2ab96a30f8</guid>
      <link>https://lispcast.com/programmer-as-navigator/</link>
      <description>
        <![CDATA[We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.]]>
      </description>
      <content:encoded>
        <![CDATA[We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.]]>
      </content:encoded>
      <pubDate>Mon, 30 Aug 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d8092867/f03ddf94.mp3" length="171633240" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>4289</itunes:duration>
      <itunes:summary>We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.</itunes:summary>
      <itunes:subtitle>We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The Humble Programmer</title>
      <itunes:title>The Humble Programmer</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">4ddc5cea-8a16-4da5-9af4-935c4afb3933</guid>
      <link>https://lispcast.com/the-humble-programmer/</link>
      <description>
        <![CDATA[We read from and comment on Edsger Dijkstra's 1972 Turing Award Lecture called The Humble Programmer. Is the problem with programming that we don't recognize our own limitations? We'll explore that and more.]]>
      </description>
      <content:encoded>
        <![CDATA[We read from and comment on Edsger Dijkstra's 1972 Turing Award Lecture called The Humble Programmer. Is the problem with programming that we don't recognize our own limitations? We'll explore that and more.]]>
      </content:encoded>
      <pubDate>Mon, 02 Aug 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c4eb78a7/4f4122c7.mp3" length="327027587" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>8174</itunes:duration>
      <itunes:summary>We read from and comment on Edsger Dijkstra's 1972 Turing Award Lecture called The Humble Programmer. Is the problem with programming that we don't recognize our own limitations? We'll explore that and more.</itunes:summary>
      <itunes:subtitle>We read from and comment on Edsger Dijkstra's 1972 Turing Award Lecture called The Humble Programmer. Is the problem with programming that we don't recognize our own limitations? We'll explore that and more.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What's the relationship between abstraction and generality?</title>
      <itunes:title>What's the relationship between abstraction and generality?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e3a1f4ad-7049-4b2e-b606-5388947cc867</guid>
      <link>https://lispcast.com/whats-the-relationship-between-abstraction-and-generality/</link>
      <description>
        <![CDATA[Do abstract and general mean the same thing? I don't think so. I've actually stopped using the term 'abstraction' because it's so laden with semantic baggage. We explore what they do mean in different contexts, and why abstract is not a relative term.]]>
      </description>
      <content:encoded>
        <![CDATA[Do abstract and general mean the same thing? I don't think so. I've actually stopped using the term 'abstraction' because it's so laden with semantic baggage. We explore what they do mean in different contexts, and why abstract is not a relative term.]]>
      </content:encoded>
      <pubDate>Mon, 19 Jul 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4392d8cb/b1b47935.mp3" length="40731980" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1016</itunes:duration>
      <itunes:summary>Do abstract and general mean the same thing? I don't think so. I've actually stopped using the term 'abstraction' because it's so laden with semantic baggage. We explore what they do mean in different contexts, and why abstract is not a relative term.</itunes:summary>
      <itunes:subtitle>Do abstract and general mean the same thing? I don't think so. I've actually stopped using the term 'abstraction' because it's so laden with semantic baggage. We explore what they do mean in different contexts, and why abstract is not a relative term.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why is data so powerful?</title>
      <itunes:title>Why is data so powerful?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">69b7ed12-4fa0-43e5-87a3-764ce0c9bf2d</guid>
      <link>https://lispcast.com/why-is-data-so-powerful/</link>
      <description>
        <![CDATA[In this episode, we explore why Clojure's stance of not wrapping data much is so powerful in the world we live in.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, we explore why Clojure's stance of not wrapping data much is so powerful in the world we live in.]]>
      </content:encoded>
      <pubDate>Mon, 12 Jul 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b4fc99a3/f4dc9f94.mp3" length="20497187" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>510</itunes:duration>
      <itunes:summary>In this episode, we explore why Clojure's stance of not wrapping data much is so powerful in the world we live in.</itunes:summary>
      <itunes:subtitle>In this episode, we explore why Clojure's stance of not wrapping data much is so powerful in the world we live in.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What if data is a really bad idea?</title>
      <itunes:title>What if data is a really bad idea?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">ce957e61-eb9b-4caf-ba77-ff2a3b34c7c8</guid>
      <link>https://lispcast.com/what-if-data-is-a-really-bad-idea/</link>
      <description>
        <![CDATA[<p>In this episode, I read from and discuss a comment thread between Rich Hickey and Alan Kay.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I read from and discuss a comment thread between Rich Hickey and Alan Kay.</p>]]>
      </content:encoded>
      <pubDate>Mon, 05 Jul 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9a10d97d/ae674609.mp3" length="132080788" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>3300</itunes:duration>
      <itunes:summary>In this episode, I read from and discuss a comment thread between Rich Hickey and Alan Kay.</itunes:summary>
      <itunes:subtitle>In this episode, I read from and discuss a comment thread between Rich Hickey and Alan Kay.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>On the criteria to be used in decomposing systems into modules</title>
      <itunes:title>On the criteria to be used in decomposing systems into modules</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">62f71774-9c67-40c7-80c3-58637499551c</guid>
      <link>https://lispcast.com/on-the-criteria-to-be-used-in-decomposing-systems-into-modules-2/</link>
      <description>
        <![CDATA[<p>In this episode, I read from David Parnas's important paper on modularity.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I read from David Parnas's important paper on modularity.</p>]]>
      </content:encoded>
      <pubDate>Mon, 28 Jun 2021 15:21:30 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3f220770/0faca03b.mp3" length="108847504" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2719</itunes:duration>
      <itunes:summary>In this episode, I read from David Parnas's important paper on modularity.</itunes:summary>
      <itunes:subtitle>In this episode, I read from David Parnas's important paper on modularity.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is missing from Stratified Design?</title>
      <itunes:title>What is missing from Stratified Design?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">96f393ba-e6c4-4c6b-80e3-eb89e5fc106d</guid>
      <link>https://lispcast.com/what-is-missing-from-stratified-design/</link>
      <description>
        <![CDATA[In this episode, I explore the notion of fit and how it is missing from the Stratified Design paper.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, I explore the notion of fit and how it is missing from the Stratified Design paper.]]>
      </content:encoded>
      <pubDate>Mon, 14 Jun 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/143ef128/c54b5339.mp3" length="48241320" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1204</itunes:duration>
      <itunes:summary>In this episode, I explore the notion of fit and how it is missing from the Stratified Design paper.</itunes:summary>
      <itunes:subtitle>In this episode, I explore the notion of fit and how it is missing from the Stratified Design paper.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Generality in Artificial Intelligence</title>
      <itunes:title>Generality in Artificial Intelligence</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e09fb06f-8d72-44f8-986d-6b70680e6a9a</guid>
      <link>https://lispcast.com/generality-in-artificial-intelligence/</link>
      <description>
        <![CDATA[In this episode, I read and comment on excerpts from John McCarthy's 1971 Turing Award Lecture.]]>
      </description>
      <content:encoded>
        <![CDATA[In this episode, I read and comment on excerpts from John McCarthy's 1971 Turing Award Lecture.]]>
      </content:encoded>
      <pubDate>Mon, 07 Jun 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/cbf3f456/2d596173.mp3" length="196882220" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>4920</itunes:duration>
      <itunes:summary>In this episode, I read and comment on excerpts from John McCarthy's 1971 Turing Award Lecture.</itunes:summary>
      <itunes:subtitle>In this episode, I read and comment on excerpts from John McCarthy's 1971 Turing Award Lecture.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Some Comments from a Numerical Analyst</title>
      <itunes:title>Some Comments from a Numerical Analyst</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b58c7900-c996-4d15-aafe-abbed31720f9</guid>
      <link>https://lispcast.com/some-comments-from-a-numerial-analyst/</link>
      <description>
        <![CDATA[<p>In this episode, I read and comment on an excerpt from the 1970 Turing Award Lecture by James Wilkinson.</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>In this episode, I read and comment on an excerpt from the 1970 Turing Award Lecture by James Wilkinson.</p>]]>
      </content:encoded>
      <pubDate>Mon, 31 May 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e9dd15aa/da5af8ff.mp3" length="167701373" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>4190</itunes:duration>
      <itunes:summary>In this episode, I read and comment on an excerpt from the 1970 Turing Award Lecture by James Wilkinson.</itunes:summary>
      <itunes:subtitle>In this episode, I read and comment on an excerpt from the 1970 Turing Award Lecture by James Wilkinson.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Don't overcomplicate the onion architecture</title>
      <itunes:title>Don't overcomplicate the onion architecture</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b2b834f7-1cd8-483b-a7b8-71321d6e1a3d</guid>
      <link>https://lispcast.com/dont-overcomplicate-the-onion-architecture/</link>
      <description>
        <![CDATA[When using the onion architecture, you need to consider the dependencies (actions depend on calculations), but also you need to consider the semantic dependencies (the domain should not know about the database).]]>
      </description>
      <content:encoded>
        <![CDATA[When using the onion architecture, you need to consider the dependencies (actions depend on calculations), but also you need to consider the semantic dependencies (the domain should not know about the database).]]>
      </content:encoded>
      <pubDate>Mon, 24 May 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d2485718/eb4a8ad1.mp3" length="52009452" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1298</itunes:duration>
      <itunes:summary>When using the onion architecture, you need to consider the dependencies (actions depend on calculations), but also you need to consider the semantic dependencies (the domain should not know about the database).</itunes:summary>
      <itunes:subtitle>When using the onion architecture, you need to consider the dependencies (actions depend on calculations), but also you need to consider the semantic dependencies (the domain should not know about the database).</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is Haskell the best procedural language?</title>
      <itunes:title>Is Haskell the best procedural language?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">8e7ccd36-c49b-435e-9df3-4fc85132c902</guid>
      <link>https://lispcast.com/is-haskell-the-best-procedural-language/</link>
      <description>
        <![CDATA[Functional programming is a mindset that distinguishes actions, calculations, and data. That's where it derives its power. Simply applying the discipline of 'only pure functions' lets you programming using a procedural mindset and still think you're doing functional programming.]]>
      </description>
      <content:encoded>
        <![CDATA[Functional programming is a mindset that distinguishes actions, calculations, and data. That's where it derives its power. Simply applying the discipline of 'only pure functions' lets you programming using a procedural mindset and still think you're doing functional programming.]]>
      </content:encoded>
      <pubDate>Mon, 17 May 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c4656c81/09c5ebec.mp3" length="49004455" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1223</itunes:duration>
      <itunes:summary>Functional programming is a mindset that distinguishes actions, calculations, and data. That's where it derives its power. Simply applying the discipline of 'only pure functions' lets you programming using a procedural mindset and still think you're doing functional programming.</itunes:summary>
      <itunes:subtitle>Functional programming is a mindset that distinguishes actions, calculations, and data. That's where it derives its power. Simply applying the discipline of 'only pure functions' lets you programming using a procedural mindset and still think you're doing</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Do forces really exist?</title>
      <itunes:title>Do forces really exist?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">69e2d9eb-fc9d-4d07-b282-a279e34a62e0</guid>
      <link>https://lispcast.com/do-forces-really-exist/</link>
      <description>
        <![CDATA[Force is an important concept in Newtonian mechanics. But do forces really exist? In fact, it is an abstraction invented by Newton. The insight revolutionized physics and universalized his model. What can we learn from it?]]>
      </description>
      <content:encoded>
        <![CDATA[Force is an important concept in Newtonian mechanics. But do forces really exist? In fact, it is an abstraction invented by Newton. The insight revolutionized physics and universalized his model. What can we learn from it?]]>
      </content:encoded>
      <pubDate>Mon, 10 May 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3754b68d/9a70f00a.mp3" length="48832944" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1219</itunes:duration>
      <itunes:summary>Force is an important concept in Newtonian mechanics. But do forces really exist? In fact, it is an abstraction invented by Newton. The insight revolutionized physics and universalized his model. What can we learn from it?</itunes:summary>
      <itunes:subtitle>Force is an important concept in Newtonian mechanics. But do forces really exist? In fact, it is an abstraction invented by Newton. The insight revolutionized physics and universalized his model. What can we learn from it?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Could we build Newtonian mechanics on purpose?</title>
      <itunes:title>Could we build Newtonian mechanics on purpose?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">4fe2a6ec-4300-4776-90de-b740e36ae0eb</guid>
      <link>https://lispcast.com/could-we-build-newtonian-mechanics-on-purpose/</link>
      <description>
        <![CDATA[One of the greatest domain models ever built was Newtonian mechanics. Why did it take physics, as a field, thousands of years to figure it out? What can we learn from Newtonian mechanics to help us model our own domains?]]>
      </description>
      <content:encoded>
        <![CDATA[One of the greatest domain models ever built was Newtonian mechanics. Why did it take physics, as a field, thousands of years to figure it out? What can we learn from Newtonian mechanics to help us model our own domains?]]>
      </content:encoded>
      <pubDate>Mon, 03 May 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7a1d898c/beae49de.mp3" length="31886831" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>795</itunes:duration>
      <itunes:summary>One of the greatest domain models ever built was Newtonian mechanics. Why did it take physics, as a field, thousands of years to figure it out? What can we learn from Newtonian mechanics to help us model our own domains?</itunes:summary>
      <itunes:subtitle>One of the greatest domain models ever built was Newtonian mechanics. Why did it take physics, as a field, thousands of years to figure it out? What can we learn from Newtonian mechanics to help us model our own domains?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is domain modeling related to Starbucks?</title>
      <itunes:episode>181</itunes:episode>
      <podcast:episode>181</podcast:episode>
      <itunes:title>How is domain modeling related to Starbucks?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">aca5abc4-1bf1-4060-b095-d3a5e5ff53ae</guid>
      <link>https://lispcast.com/how-is-domain-modeling-related-to-starbucks/</link>
      <description>
        <![CDATA[<p>We discuss two phases of domain modeling, one easy and one difficult.</p><p>https://lispcast.com/how-is-domain-modeling-related-to-starbucks/</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>We discuss two phases of domain modeling, one easy and one difficult.</p><p>https://lispcast.com/how-is-domain-modeling-related-to-starbucks/</p>]]>
      </content:encoded>
      <pubDate>Mon, 26 Apr 2021 12:22:38 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/aed5650c/608cef2f.mp3" length="35859227" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>894</itunes:duration>
      <itunes:summary>We discuss two phases of domain modeling, one easy and one difficult.

https://lispcast.com/how-is-domain-modeling-related-to-starbucks/</itunes:summary>
      <itunes:subtitle>We discuss two phases of domain modeling, one easy and one difficult.

https://lispcast.com/how-is-domain-modeling-related-to-starbucks/</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is design a noun or a verb?</title>
      <itunes:episode>180</itunes:episode>
      <podcast:episode>180</podcast:episode>
      <itunes:title>Is design a noun or a verb?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">20d74c79-52a2-4bd2-a433-ed46298c9344</guid>
      <link>https://lispcast.com/is-design-a-noun-or-a-verb/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-design-a-noun-or-a-verb/">https://lispcast.com/is-design-a-noun-or-a-verb/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-design-a-noun-or-a-verb/">https://lispcast.com/is-design-a-noun-or-a-verb/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 29 Mar 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e8bec470/c3fbb0ce.mp3" length="43523666" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1086</itunes:duration>
      <itunes:summary>If design is a false nominalization, then we should look at the process of design instead of pontificating on what makes good design.</itunes:summary>
      <itunes:subtitle>If design is a false nominalization, then we should look at the process of design instead of pontificating on what makes good design.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Has software design taken a wrong turn?</title>
      <itunes:episode>179</itunes:episode>
      <podcast:episode>179</podcast:episode>
      <itunes:title>Has software design taken a wrong turn?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d5140331-9db8-4915-8881-ef4c9e2c04d9</guid>
      <link>https://lispcast.com/has-software-design-taken-a-wrong-turn/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/has-software-design-taken-a-wrong-turn/">https://lispcast.com/has-software-design-taken-a-wrong-turn/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/has-software-design-taken-a-wrong-turn/">https://lispcast.com/has-software-design-taken-a-wrong-turn/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 22 Mar 2021 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9aae0ffa/aebb9b81.mp3" length="45747473" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1142</itunes:duration>
      <itunes:summary>I analyze two similar definition of software design, one from OOP and one from FP. We see that each is talking about making the code more flexible. But design shouldn't focus on the code alone. In this episode, I explore what it should focus on instead.</itunes:summary>
      <itunes:subtitle>I analyze two similar definition of software design, one from OOP and one from FP. We see that each is talking about making the code more flexible. But design shouldn't focus on the code alone. In this episode, I explore what it should focus on instead.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Form and Content in Computer Science</title>
      <itunes:episode>178</itunes:episode>
      <podcast:episode>178</podcast:episode>
      <itunes:title>Form and Content in Computer Science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">2c83a4b2-8b97-43fd-8079-98fe16529b57</guid>
      <link>https://lispcast.com/form-and-content-in-computer-science/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/form-and-content-in-computer-science/">https://lispcast.com/form-and-content-in-computer-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/form-and-content-in-computer-science/">https://lispcast.com/form-and-content-in-computer-science/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 08 Feb 2021 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/21c23888/c75c2b40.mp3" length="207965460" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>5197</itunes:duration>
      <itunes:summary>In this episode, I excerpt and discuss the 1969 ACM Turing Award Lecture by Marvin Minsky.</itunes:summary>
      <itunes:subtitle>In this episode, I excerpt and discuss the 1969 ACM Turing Award Lecture by Marvin Minsky.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>One Man's View of Computer Science</title>
      <itunes:episode>177</itunes:episode>
      <podcast:episode>177</podcast:episode>
      <itunes:title>One Man's View of Computer Science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">bafd7aca-03b7-41a4-b183-0f3d1d4712e2</guid>
      <link>https://lispcast.com/one-mans-view-of-computer-science/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/one-mans-view-of-computer-science/">https://lispcast.com/one-mans-view-of-computer-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/one-mans-view-of-computer-science/">https://lispcast.com/one-mans-view-of-computer-science/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Jan 2021 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/77eeda0d/daf1aee0.mp3" length="235016863" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>5873</itunes:duration>
      <itunes:summary>In this episode, I read from One Man's View of Computer Science, the 1968 ACM Turing Lecture by Richard Hamming.</itunes:summary>
      <itunes:subtitle>In this episode, I read from One Man's View of Computer Science, the 1968 ACM Turing Lecture by Richard Hamming.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Computing Then and Now</title>
      <itunes:episode>176</itunes:episode>
      <podcast:episode>176</podcast:episode>
      <itunes:title>Computing Then and Now</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">11350664-8e95-41d0-a998-06af657c60a5</guid>
      <link>https://lispcast.com/computing-then-and-now/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/computing-then-and-now/">https://lispcast.com/computing-then-and-now/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/computing-then-and-now/">https://lispcast.com/computing-then-and-now/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 18 Jan 2021 18:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/0b11302c/35ad8e7e.mp3" length="220698608" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>5515</itunes:duration>
      <itunes:summary>In this episode, we read excerpts of Maurice Wilke's 1967 ACM Turing Award lecture titled 'Computing Then and Now'.</itunes:summary>
      <itunes:subtitle>In this episode, we read excerpts of Maurice Wilke's 1967 ACM Turing Award lecture titled 'Computing Then and Now'.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The Synthesis of Algorithmic Systems</title>
      <itunes:episode>175</itunes:episode>
      <podcast:episode>175</podcast:episode>
      <itunes:title>The Synthesis of Algorithmic Systems</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">a4499eea-2f0b-42c6-ba3f-f28421ca36ad</guid>
      <link>https://lispcast.com/the-synthesis-of-algorithmic-systems/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-synthesis-of-algorithmic-systems/">https://lispcast.com/the-synthesis-of-algorithmic-systems/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-synthesis-of-algorithmic-systems/">https://lispcast.com/the-synthesis-of-algorithmic-systems/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Jan 2021 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/19b7a454/fdedf8db.mp3" length="166444407" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>4159</itunes:duration>
      <itunes:summary>In this episode, I read excerpts from Alan Perlis's Turing Award Lecture called 'The Synthesis of Algorithmic Systems'.</itunes:summary>
      <itunes:subtitle>In this episode, I read excerpts from Alan Perlis's Turing Award Lecture called 'The Synthesis of Algorithmic Systems'.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is Clojure a language for hipsters?</title>
      <itunes:episode>174</itunes:episode>
      <podcast:episode>174</podcast:episode>
      <itunes:title>Is Clojure a language for hipsters?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">1b20d7f3-ef9b-4d83-9fa8-9c9e27a66948</guid>
      <link>https://lispcast.com/is-clojure-a-language-for-hipsters/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-clojure-a-language-for-hipsters/">https://lispcast.com/is-clojure-a-language-for-hipsters/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-clojure-a-language-for-hipsters/">https://lispcast.com/is-clojure-a-language-for-hipsters/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 14 Dec 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9b90e6c0/59b3a815.mp3" length="29828315" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>744</itunes:duration>
      <itunes:summary>In this episode, I contemplate whether I am an early adopter or a pragmatist, and how that influenced my choice of Clojure. Does Clojure appeal to early adopters? Has it crossed the chasm?</itunes:summary>
      <itunes:subtitle>In this episode, I contemplate whether I am an early adopter or a pragmatist, and how that influenced my choice of Clojure. Does Clojure appeal to early adopters? Has it crossed the chasm?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Lambda: The Ultimate GOTO</title>
      <itunes:episode>173</itunes:episode>
      <podcast:episode>173</podcast:episode>
      <itunes:title>Lambda: The Ultimate GOTO</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">94b26d66-b56e-4be2-9fc2-c99597152174</guid>
      <link>https://lispcast.com/lambda-the-ultimate-goto/</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/lambda-the-ultimate-goto/">https://lispcast.com/lambda-the-ultimate-goto/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/lambda-the-ultimate-goto/">https://lispcast.com/lambda-the-ultimate-goto/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 07 Dec 2020 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e81a8808/830cf04b.mp3" length="244122046" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>6101</itunes:duration>
      <itunes:summary>In this episode, I read from Lambda: The Ultimate GOTO. We learn whether avoiding GOTOs makes your code better and how to make function calls fast.</itunes:summary>
      <itunes:subtitle>In this episode, I read from Lambda: The Ultimate GOTO. We learn whether avoiding GOTOs makes your code better and how to make function calls fast.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can Programming Be Liberated from the von Neumann Style?</title>
      <itunes:episode>172</itunes:episode>
      <podcast:episode>172</podcast:episode>
      <itunes:title>Can Programming Be Liberated from the von Neumann Style?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">09ba0936-904e-40cf-a8dc-2dccfcc71454</guid>
      <link>https://share.transistor.fm/s/7c419e55</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-programming-be-liberated-from-the-von-neumann-style/">https://lispcast.com/can-programming-be-liberated-from-the-von-neumann-style/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-programming-be-liberated-from-the-von-neumann-style/">https://lispcast.com/can-programming-be-liberated-from-the-von-neumann-style/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 09 Nov 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7c419e55/e0080038.mp3" length="276473813" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>6910</itunes:duration>
      <itunes:summary>In 1977, John Backus presented an algebraic vision of programming that departed from the von Neumann fetch-and-store semantics. This seminal paper has influenced functional programming in many ways. In this episode, I read excerpts from and comment on John Backus's 1977 Turing Award Lecture paper Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs.</itunes:summary>
      <itunes:subtitle>In 1977, John Backus presented an algebraic vision of programming that departed from the von Neumann fetch-and-store semantics. This seminal paper has influenced functional programming in many ways. In this episode, I read excerpts from and comment on Joh</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Do we use metacircular evaluators in real life?</title>
      <itunes:episode>171</itunes:episode>
      <podcast:episode>171</podcast:episode>
      <itunes:title>Do we use metacircular evaluators in real life?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">51bc4711-2b08-4e41-bfc8-1bbef890f5c1</guid>
      <link>https://share.transistor.fm/s/f569b4d5</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-we-use-metacircular-evaluators-in-real-life/">https://lispcast.com/do-we-use-metacircular-evaluators-in-real-life/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-we-use-metacircular-evaluators-in-real-life/">https://lispcast.com/do-we-use-metacircular-evaluators-in-real-life/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 19 Oct 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f569b4d5/7224dbf5.mp3" length="32695078" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>815</itunes:duration>
      <itunes:summary>In SICP, the authors define a metacircular evaluator of Scheme written in Scheme to change the semantics of the language. Do we do stuff like that in real life? In this episode, I explore this listener question.</itunes:summary>
      <itunes:subtitle>In SICP, the authors define a metacircular evaluator of Scheme written in Scheme to change the semantics of the language. Do we do stuff like that in real life? In this episode, I explore this listener question.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The Next 700 Programming Languages</title>
      <itunes:episode>170</itunes:episode>
      <podcast:episode>170</podcast:episode>
      <itunes:title>The Next 700 Programming Languages</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">029c6881-17f3-46f8-8429-902836032f67</guid>
      <link>https://share.transistor.fm/s/9be9e6d2</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-next-700-programming-languages/">https://lispcast.com/the-next-700-programming-languages/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-next-700-programming-languages/">https://lispcast.com/the-next-700-programming-languages/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 12 Oct 2020 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9be9e6d2/31f22030.mp3" length="157630896" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>3939</itunes:duration>
      <itunes:summary>In this episode, I excerpt and comment on a seminal paper in programming language design, from all the way back in 1966, called The Next 700 Programming Languages.</itunes:summary>
      <itunes:subtitle>In this episode, I excerpt and comment on a seminal paper in programming language design, from all the way back in 1966, called The Next 700 Programming Languages.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What makes some API's become DSL's?</title>
      <itunes:episode>169</itunes:episode>
      <podcast:episode>169</podcast:episode>
      <itunes:title>What makes some API's become DSL's?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">daf2abf5-e774-4e97-b3ce-8595370d323c</guid>
      <link>https://share.transistor.fm/s/774f7341</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-makes-some-apis-become-dsls/">https://lispcast.com/what-makes-some-apis-become-dsls/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-makes-some-apis-become-dsls/">https://lispcast.com/what-makes-some-apis-become-dsls/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Aug 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/774f7341/61471bd1.mp3" length="55415662" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1383</itunes:duration>
      <itunes:summary>What causes an API to cross the line into becoming a DSL? Is it really a 'I'll know it when I see it' situation? I've been searching for an answer for years. And I think I found it in a paper I read recently for this podcast: Lisp: A language for stratified design. In this episode, we go over the main factor that makes an API a DSL: the closure property.</itunes:summary>
      <itunes:subtitle>What causes an API to cross the line into becoming a DSL? Is it really a 'I'll know it when I see it' situation? I've been searching for an answer for years. And I think I found it in a paper I read recently for this podcast: Lisp: A language for stratifi</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is software design?</title>
      <itunes:episode>168</itunes:episode>
      <podcast:episode>168</podcast:episode>
      <itunes:title>What is software design?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">673eff30-0930-45bb-80fb-b3b6d8ede1d2</guid>
      <link>https://share.transistor.fm/s/0ffd441c</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-design-definition/">https://lispcast.com/what-is-software-design-definition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-design-definition/">https://lispcast.com/what-is-software-design-definition/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 27 Jul 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/0ffd441c/fded6c1b.mp3" length="46635226" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1164</itunes:duration>
      <itunes:summary>I've never been satisfied with the standard definition of 'software design'. Is the term useful? What could it mean that is useful? In this episode, I talk about some definitions that I don't agree with and explain my definition.</itunes:summary>
      <itunes:subtitle>I've never been satisfied with the standard definition of 'software design'. Is the term useful? What could it mean that is useful? In this episode, I talk about some definitions that I don't agree with and explain my definition.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why Functional Programming Matters</title>
      <itunes:episode>167</itunes:episode>
      <podcast:episode>167</podcast:episode>
      <itunes:title>Why Functional Programming Matters</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">5e7338a8-d101-4779-9028-130237a46352</guid>
      <link>https://share.transistor.fm/s/c58abf8e</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-functional-programming-matters/">https://lispcast.com/why-functional-programming-matters/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-functional-programming-matters/">https://lispcast.com/why-functional-programming-matters/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 13 Jul 2020 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c58abf8e/b3889a8a.mp3" length="145905999" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>3646</itunes:duration>
      <itunes:summary>In this episode, I read excerpts from Why Functional Programming Matters by John Hughes. Does it answer the question of what is functional programming and why is it powerful?</itunes:summary>
      <itunes:subtitle>In this episode, I read excerpts from Why Functional Programming Matters by John Hughes. Does it answer the question of what is functional programming and why is it powerful?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>My response to Out of the Tar Pit</title>
      <itunes:episode>166</itunes:episode>
      <podcast:episode>166</podcast:episode>
      <itunes:title>My response to Out of the Tar Pit</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">8947310b-5e59-43f9-8e53-6d57827cf01c</guid>
      <link>https://share.transistor.fm/s/215bbb14</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/my-response-to-out-of-the-tar-pit/">https://lispcast.com/my-response-to-out-of-the-tar-pit/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/my-response-to-out-of-the-tar-pit/">https://lispcast.com/my-response-to-out-of-the-tar-pit/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 29 Jun 2020 00:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/215bbb14/b0b8dc99.mp3" length="90132074" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2251</itunes:duration>
      <itunes:summary>Out of the Tar Pit came out 14 years ago and it was a big influence on my thinking. I've thought a lot about it and I want to share some extensions and refinements of the ideas in the paper. Specifically, I hope to present a more objective definition of complexity and refine the idea of Essential vs. Accidental complexity.</itunes:summary>
      <itunes:subtitle>Out of the Tar Pit came out 14 years ago and it was a big influence on my thinking. I've thought a lot about it and I want to share some extensions and refinements of the ideas in the paper. Specifically, I hope to present a more objective definition of c</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Out of the Tar Pit</title>
      <itunes:episode>165</itunes:episode>
      <podcast:episode>165</podcast:episode>
      <itunes:title>Out of the Tar Pit</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">f23b3401-4dcb-4417-81a3-64f4b8a79831</guid>
      <link>https://share.transistor.fm/s/c56e5d19</link>
      <description>
        <![CDATA[<p>For audio, video, and links: <a href="https://lispcast.com/out-of-the-tar-pit/">https://lispcast.com/out-of-the-tar-pit/</a></p><p><br></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and links: <a href="https://lispcast.com/out-of-the-tar-pit/">https://lispcast.com/out-of-the-tar-pit/</a></p><p><br></p>]]>
      </content:encoded>
      <pubDate>Mon, 22 Jun 2020 09:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c56e5d19/3d0d1751.mp3" length="202614824" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>5063</itunes:duration>
      <itunes:summary>In this episode, I read excerpts from Out of the Tar Pit, a classic paper in the functional programming community.</itunes:summary>
      <itunes:subtitle>In this episode, I read excerpts from Out of the Tar Pit, a classic paper in the functional programming community.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is software architecture?</title>
      <itunes:episode>164</itunes:episode>
      <podcast:episode>164</podcast:episode>
      <itunes:title>What is software architecture?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">24bd36b6-be3a-41ff-9d1b-cf1430cca42a</guid>
      <link>https://share.transistor.fm/s/00cf21f3</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-architecture/">https://lispcast.com/what-is-software-architecture/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-architecture/">https://lispcast.com/what-is-software-architecture/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 16 Mar 2020 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/00cf21f3/323c0f8d.mp3" length="64739649" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1616</itunes:duration>
      <itunes:summary>I try to define software architecture, both in the large and in the small.</itunes:summary>
      <itunes:subtitle>I try to define software architecture, both in the large and in the small.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The Early History of Smalltalk</title>
      <itunes:episode>163</itunes:episode>
      <podcast:episode>163</podcast:episode>
      <itunes:title>The Early History of Smalltalk</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">a389194d-dbaa-4072-a225-e06201fd274f</guid>
      <link>https://share.transistor.fm/s/8c333592</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-early-history-of-smalltalk/">https://lispcast.com/the-early-history-of-smalltalk/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-early-history-of-smalltalk/">https://lispcast.com/the-early-history-of-smalltalk/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Feb 2020 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8c333592/adaf8d02.mp3" length="285065015" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>7125</itunes:duration>
      <itunes:summary>We read one of the great articles by Alan Kay, inventor of Smalltalk.</itunes:summary>
      <itunes:subtitle>We read one of the great articles by Alan Kay, inventor of Smalltalk.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Lisp: A language for stratified design</title>
      <itunes:episode>162</itunes:episode>
      <podcast:episode>162</podcast:episode>
      <itunes:title>Lisp: A language for stratified design</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">112e0f3a-8250-49d6-9c42-6d4faa9c12ef</guid>
      <link>https://share.transistor.fm/s/4e36ae9b</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/lisp-a-language-for-stratified-design/">https://lispcast.com/lisp-a-language-for-stratified-design/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/lisp-a-language-for-stratified-design/">https://lispcast.com/lisp-a-language-for-stratified-design/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 20 Jan 2020 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4e36ae9b/abd55f56.mp3" length="144475985" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>3610</itunes:duration>
      <itunes:summary>In this first episode of season 3, we analyze a great paper called Lisp: A language for stratified design.</itunes:summary>
      <itunes:subtitle>In this first episode of season 3, we analyze a great paper called Lisp: A language for stratified design.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Year-end update 2019</title>
      <itunes:episode>161</itunes:episode>
      <podcast:episode>161</podcast:episode>
      <itunes:title>Year-end update 2019</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">11e47a66-ec09-4d9f-a501-3de630e53233</guid>
      <link>https://share.transistor.fm/s/109d10f9</link>
      <description>
        <![CDATA[<p>Show notes:</p><p>For audio, video, and text transcripts: <a href="https://lispcast.com/year-end-update-2019/">https://lispcast.com/year-end-update-2019/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>Show notes:</p><p>For audio, video, and text transcripts: <a href="https://lispcast.com/year-end-update-2019/">https://lispcast.com/year-end-update-2019/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 12 Dec 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/109d10f9/1e5c9372.mp3" length="29878339" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>745</itunes:duration>
      <itunes:summary>I'm taking a break to retool for Season 3, which will start in the new year. I also give an update on Grokking Simplicity. I am working on Chapter 7.</itunes:summary>
      <itunes:subtitle>I'm taking a break to retool for Season 3, which will start in the new year. I also give an update on Grokking Simplicity. I am working on Chapter 7.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Are monads practical?</title>
      <itunes:episode>160</itunes:episode>
      <podcast:episode>160</podcast:episode>
      <itunes:title>Are monads practical?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">bbb528a2-d1bd-42c2-9d5d-0be7fd50de95</guid>
      <link>https://share.transistor.fm/s/9dde5f63</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/are-monads-practical/">https://lispcast.com/are-monads-practical/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/are-monads-practical/">https://lispcast.com/are-monads-practical/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 05 Dec 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9dde5f63/1dd2453b.mp3" length="54532361" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1361</itunes:duration>
      <itunes:summary>Bruno Ribeiro asked a great question about the practical uses of monads. Are they useful? Why are they used so much in Haskell? In this episode, we briefly go over the history of monads in Haskell and how they allow you to do imperative programming in a pure functional language.</itunes:summary>
      <itunes:subtitle>Bruno Ribeiro asked a great question about the practical uses of monads. Are they useful? Why are they used so much in Haskell? In this episode, we briefly go over the history of monads in Haskell and how they allow you to do imperative programming in a p</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Where does structural similarity come from?</title>
      <itunes:episode>159</itunes:episode>
      <podcast:episode>159</podcast:episode>
      <itunes:title>Where does structural similarity come from?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">f593c016-4d39-4eee-b245-8650cd502033</guid>
      <link>https://share.transistor.fm/s/58aa98f3</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/where-does-structural-similarity-come-from/">https://lispcast.com/where-does-structural-similarity-come-from/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/where-does-structural-similarity-come-from/">https://lispcast.com/where-does-structural-similarity-come-from/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/58aa98f3/a1c24f29.mp3" length="21811773" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>543</itunes:duration>
      <itunes:summary>In a recent episode, I said structural similarity comes from the algebraic properties of the relationships between things. But that's not the case. Rotislav mentioned in the comments that it actually comes from the structure in the relationships. I explore that idea in this episode.</itunes:summary>
      <itunes:subtitle>In a recent episode, I said structural similarity comes from the algebraic properties of the relationships between things. But that's not the case. Rotislav mentioned in the comments that it actually comes from the structure in the relationships. I explor</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Do you need immutability for functional programming?</title>
      <itunes:episode>158</itunes:episode>
      <podcast:episode>158</podcast:episode>
      <itunes:title>Do you need immutability for functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">29ade075-8763-46dc-b7e2-9588e5b76996</guid>
      <link>https://share.transistor.fm/s/ddd7bb14</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-you-need-immutability-for-functional-programming/">https://lispcast.com/do-you-need-immutability-for-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-you-need-immutability-for-functional-programming/">https://lispcast.com/do-you-need-immutability-for-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 21 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ddd7bb14/f31d132c.mp3" length="26094393" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>650</itunes:duration>
      <itunes:summary>Of course immutable data structures are great, but are they necessary for FP? Short answer is: no. There's a lot of functional ideas and perspectives that can be applied even if you don't have them. And you can always make things immutable through discipline. In this episode, we explore those two ideas.</itunes:summary>
      <itunes:subtitle>Of course immutable data structures are great, but are they necessary for FP? Short answer is: no. There's a lot of functional ideas and perspectives that can be applied even if you don't have them. And you can always make things immutable through discipl</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Algebra is about composition</title>
      <itunes:episode>157</itunes:episode>
      <podcast:episode>157</podcast:episode>
      <itunes:title>Algebra is about composition</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">3f6a2a9d-229e-441e-ad5a-ec2bb9d085d8</guid>
      <link>https://share.transistor.fm/s/90eb3e1d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebra-is-about-composition/">https://lispcast.com/algebra-is-about-composition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebra-is-about-composition/">https://lispcast.com/algebra-is-about-composition/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 18 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/90eb3e1d/4561eaf1.mp3" length="23046417" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>574</itunes:duration>
      <itunes:summary>When we look at the definitions of algebraic properties, we often see that we are defining how things compose. This is one of the main advantages of using algebraic properties to constrain our operations. If we define how they should compose before we implement them (as a unit test, for instance) we can guarantee that things will compose.</itunes:summary>
      <itunes:subtitle>When we look at the definitions of algebraic properties, we often see that we are defining how things compose. This is one of the main advantages of using algebraic properties to constrain our operations. If we define how they should compose before we imp</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What do product and sum types have to do with data modeling?</title>
      <itunes:episode>156</itunes:episode>
      <podcast:episode>156</podcast:episode>
      <itunes:title>What do product and sum types have to do with data modeling?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e9474935-bc13-474a-9970-ebde54a56841</guid>
      <link>https://share.transistor.fm/s/fd5088aa</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-do-product-and-sum-types-have-to-do-with-data-modeling/">https://lispcast.com/what-do-product-and-sum-types-have-to-do-with-data-modeling/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-do-product-and-sum-types-have-to-do-with-data-modeling/">https://lispcast.com/what-do-product-and-sum-types-have-to-do-with-data-modeling/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 14 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fd5088aa/994be2ef.mp3" length="30852711" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>769</itunes:duration>
      <itunes:summary>Product and sum types allow us to exactly model any number of states with a lot of flexibility.</itunes:summary>
      <itunes:subtitle>Product and sum types allow us to exactly model any number of states with a lot of flexibility.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can you have a clean domain model?</title>
      <itunes:episode>155</itunes:episode>
      <podcast:episode>155</podcast:episode>
      <itunes:title>Can you have a clean domain model?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">a177946d-c319-4a7e-9d54-94accba92058</guid>
      <link>https://share.transistor.fm/s/32e25553</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-have-a-clean-domain-model/">https://lispcast.com/can-you-have-a-clean-domain-model/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-have-a-clean-domain-model/">https://lispcast.com/can-you-have-a-clean-domain-model/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/32e25553/8a31921c.mp3" length="54283763" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1355</itunes:duration>
      <itunes:summary>I was asked a great question by a listener about whether it's always possible to find a good domain model. Sometimes, the business rules are so messy, how can we find something clean and stable? In this episode, I explore how we can find a stable and clean domain model within the chaos.</itunes:summary>
      <itunes:subtitle>I was asked a great question by a listener about whether it's always possible to find a good domain model. Sometimes, the business rules are so messy, how can we find something clean and stable? In this episode, I explore how we can find a stable and clea</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is abstraction?</title>
      <itunes:episode>154</itunes:episode>
      <podcast:episode>154</podcast:episode>
      <itunes:title>What is abstraction?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e76bc109-4be4-4dc5-a04d-dbeb47a8c1d3</guid>
      <link>https://share.transistor.fm/s/3cbdac71</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-abstraction-2/">https://lispcast.com/what-is-abstraction-2/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-abstraction-2/">https://lispcast.com/what-is-abstraction-2/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 07 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3cbdac71/e83c1190.mp3" length="33663769" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>840</itunes:duration>
      <itunes:summary>We use the term 'abstraction' all the time. But what does it mean? If it's such an important concept, we should have a clear idea of its meaning. In this episode, I go over two related definitions from two important sources.</itunes:summary>
      <itunes:subtitle>We use the term 'abstraction' all the time. But what does it mean? If it's such an important concept, we should have a clear idea of its meaning. In this episode, I go over two related definitions from two important sources.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why does stratified design work?</title>
      <itunes:episode>153</itunes:episode>
      <podcast:episode>153</podcast:episode>
      <itunes:title>Why does stratified design work?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">6da15ee5-ec23-4ccc-a764-b98e0c593a28</guid>
      <link>https://share.transistor.fm/s/42cd94e8</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-does-stratified-design-work/">https://lispcast.com/why-does-stratified-design-work/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-does-stratified-design-work/">https://lispcast.com/why-does-stratified-design-work/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 04 Nov 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/42cd94e8/2f7ab7b0.mp3" length="33396971" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>833</itunes:duration>
      <itunes:summary>Stratified design is one where you build more specific things on top of more general things, typically with many layers. But why is this powerful? In this episode, we explore why it's sometimes easier to solve a more general problem than a specific one.</itunes:summary>
      <itunes:subtitle>Stratified design is one where you build more specific things on top of more general things, typically with many layers. But why is this powerful? In this episode, we explore why it's sometimes easier to solve a more general problem than a specific one.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why are algebraic properties important?</title>
      <itunes:episode>152</itunes:episode>
      <podcast:episode>152</podcast:episode>
      <itunes:title>Why are algebraic properties important?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">345d8fd3-820f-4aa8-a633-9dc0ae240a7d</guid>
      <link>https://share.transistor.fm/s/2e48df86</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-algebraic-properties-important/">https://lispcast.com/why-are-algebraic-properties-important/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-algebraic-properties-important/">https://lispcast.com/why-are-algebraic-properties-important/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 31 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2e48df86/e3918525.mp3" length="35308421" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>881</itunes:duration>
      <itunes:summary>We often write software to automate an existing physical process. But what makes this possible? When translating from physical to digital, something must be preserved. In this episode, we look into what is preserved across that translation and why algebraic properties might help us find it.</itunes:summary>
      <itunes:subtitle>We often write software to automate an existing physical process. But what makes this possible? When translating from physical to digital, something must be preserved. In this episode, we look into what is preserved across that translation and why algebra</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Functional programming is a set of skills</title>
      <itunes:episode>151</itunes:episode>
      <podcast:episode>151</podcast:episode>
      <itunes:title>Functional programming is a set of skills</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">3ab3b110-80e4-4eaa-84ea-080015d84fb2</guid>
      <link>https://share.transistor.fm/s/66af19a4</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/functional-programming-is-a-set-of-skills/">https://lispcast.com/functional-programming-is-a-set-of-skills/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/functional-programming-is-a-set-of-skills/">https://lispcast.com/functional-programming-is-a-set-of-skills/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 28 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/66af19a4/6f9e9e27.mp3" length="50046793" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1249</itunes:duration>
      <itunes:summary>Definitions of functional programming disagree with each other and often don't encompass the broad range of languages and practices we find in industry. The definitions also make it seem incompatible with other paradigms, such as object-oriented and procedural. However, if you look at FP as a set of skills, both problems are solved. We can find skills that functional programmers tend to use and not be incompatible. In this episode, I explore some important, high-level skills that functional programmers employ.</itunes:summary>
      <itunes:subtitle>Definitions of functional programming disagree with each other and often don't encompass the broad range of languages and practices we find in industry. The definitions also make it seem incompatible with other paradigms, such as object-oriented and proce</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The commercialization of computers</title>
      <itunes:episode>150</itunes:episode>
      <podcast:episode>150</podcast:episode>
      <itunes:title>The commercialization of computers</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">5b8b6d09-59ad-4fc8-b412-88899161075d</guid>
      <link>https://share.transistor.fm/s/11cc5d96</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-commercialization-of-computers/">https://lispcast.com/the-commercialization-of-computers/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-commercialization-of-computers/">https://lispcast.com/the-commercialization-of-computers/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 24 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/11cc5d96/1d7881a2.mp3" length="57113543" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1426</itunes:duration>
      <itunes:summary>Computer commercialization set research back decades and we still haven't recovered. I explore why that is and end on some hopeful notes.</itunes:summary>
      <itunes:subtitle>Computer commercialization set research back decades and we still haven't recovered. I explore why that is and end on some hopeful notes.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Two kinds of data modeling</title>
      <itunes:episode>149</itunes:episode>
      <podcast:episode>149</podcast:episode>
      <itunes:title>Two kinds of data modeling</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">e51a6f54-739f-4259-bfa0-611c95465950</guid>
      <link>https://share.transistor.fm/s/5344dcce</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/two-kinds-of-data-modeling/">https://lispcast.com/two-kinds-of-data-modeling/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/two-kinds-of-data-modeling/">https://lispcast.com/two-kinds-of-data-modeling/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 21 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5344dcce/033c3a93.mp3" length="41786357" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1043</itunes:duration>
      <itunes:summary>Through conversations, I've realized that there's two kinds of data modeling that are distinct. They have their own constraints and needs and, consequently, their own techniques. In this episode, I explore what makes them different.</itunes:summary>
      <itunes:subtitle>Through conversations, I've realized that there's two kinds of data modeling that are distinct. They have their own constraints and needs and, consequently, their own techniques. In this episode, I explore what makes them different.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are product and sum types?</title>
      <itunes:episode>148</itunes:episode>
      <podcast:episode>148</podcast:episode>
      <itunes:title>What are product and sum types?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">c120212a-a5d5-4e44-aca7-e7ba5f07433e</guid>
      <link>https://share.transistor.fm/s/34a0a53b</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-product-and-sum-types/">https://lispcast.com/what-are-product-and-sum-types/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-product-and-sum-types/">https://lispcast.com/what-are-product-and-sum-types/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 17 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/34a0a53b/7c2ab5e4.mp3" length="55491605" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1385</itunes:duration>
      <itunes:summary>Product and sum types are collectively known as 'algebraic data types'. These are two ways of putting types together to make bigger types. Product types multiply their states, while sum types add them. With these two 'operations', we can precisely target a desired number of states. In this episode, we explore how we can eliminate corner cases with algebraic data types.</itunes:summary>
      <itunes:subtitle>Product and sum types are collectively known as 'algebraic data types'. These are two ways of putting types together to make bigger types. Product types multiply their states, while sum types add them. With these two 'operations', we can precisely target </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do I prefer Clojure to Haskell?</title>
      <itunes:episode>147</itunes:episode>
      <podcast:episode>147</podcast:episode>
      <itunes:title>Why do I prefer Clojure to Haskell?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d2cb541e-0598-4cea-b1eb-b79a9cc34c88</guid>
      <link>https://share.transistor.fm/s/0a2837c4</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-i-prefer-clojure-to-haskell/">https://lispcast.com/why-do-i-prefer-clojure-to-haskell/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-i-prefer-clojure-to-haskell/">https://lispcast.com/why-do-i-prefer-clojure-to-haskell/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 14 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/0a2837c4/399be9e9.mp3" length="116217387" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2903</itunes:duration>
      <itunes:summary>I prefer Clojure to Haskell. It's probably mostly due to accidents of history: getting in Lisp at an earlier age, spending more time with Lisp, and only having one Haskell job. But I do have some philosophical differences with the Haskell philosophy as it relates to Haskell as an engineering tool. In this episode, I go over four of them, and try to relate them with anecdotes.</itunes:summary>
      <itunes:subtitle>I prefer Clojure to Haskell. It's probably mostly due to accidents of history: getting in Lisp at an earlier age, spending more time with Lisp, and only having one Haskell job. But I do have some philosophical differences with the Haskell philosophy as it</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do I like Denotational Design?</title>
      <itunes:episode>146</itunes:episode>
      <podcast:episode>146</podcast:episode>
      <itunes:title>Why do I like Denotational Design?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">b4aa862b-6d14-4d1d-8930-d51b75b5428d</guid>
      <link>https://share.transistor.fm/s/375a27df</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-i-like-denotational-design/">https://lispcast.com/why-do-i-like-denotational-design/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-i-like-denotational-design/">https://lispcast.com/why-do-i-like-denotational-design/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 10 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/375a27df/f49ecf41.mp3" length="72949081" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1822</itunes:duration>
      <itunes:summary>Denotational Design is a abstraction design process created by Conal Elliott. I like it because it really asks you to step back and design the meaning of the abstractions before you implement them. In this episode, I talk about why I like it, what it is (step-by-step), and why it's not about static types.</itunes:summary>
      <itunes:subtitle>Denotational Design is a abstraction design process created by Conal Elliott. I like it because it really asks you to step back and design the meaning of the abstractions before you implement them. In this episode, I talk about why I like it, what it is (</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the difference between a domain model and business rules?</title>
      <itunes:episode>145</itunes:episode>
      <podcast:episode>145</podcast:episode>
      <itunes:title>What is the difference between a domain model and business rules?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">d69e5b00-8a50-49ab-8982-fa635a904533</guid>
      <link>https://share.transistor.fm/s/67e003fe</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-difference-between-a-domain-model-and-business-rules/">https://lispcast.com/what-is-the-difference-between-a-domain-model-and-business-rules/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-difference-between-a-domain-model-and-business-rules/">https://lispcast.com/what-is-the-difference-between-a-domain-model-and-business-rules/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 07 Oct 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/67e003fe/9640a876.mp3" length="56757463" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1417</itunes:duration>
      <itunes:summary>Business rules are different from your domain model. What goes where? I hope to tease apart this important yet subtle distinction in this episode.</itunes:summary>
      <itunes:subtitle>Business rules are different from your domain model. What goes where? I hope to tease apart this important yet subtle distinction in this episode.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Where does the power of Nil Punning come from?</title>
      <itunes:episode>144</itunes:episode>
      <podcast:episode>144</podcast:episode>
      <itunes:title>Where does the power of Nil Punning come from?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">0f11fa5a-1860-4e5d-a47a-af9bf254ee45</guid>
      <link>https://share.transistor.fm/s/48c05233</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/power-of-nil-punning/">https://lispcast.com/power-of-nil-punning/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/power-of-nil-punning/">https://lispcast.com/power-of-nil-punning/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 30 Sep 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/48c05233/c81a762d.mp3" length="42706979" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1066</itunes:duration>
      <itunes:summary>Nil punning does give power to Lispers. But where does the power come from? Is it that nil really is a great value? Or is it more about the design choices made? In this episode, we explore this question.</itunes:summary>
      <itunes:subtitle>Nil punning does give power to Lispers. But where does the power come from? Is it that nil really is a great value? Or is it more about the design choices made? In this episode, we explore this question.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Nil Punning?</title>
      <itunes:episode>143</itunes:episode>
      <podcast:episode>143</podcast:episode>
      <itunes:title>What is Nil Punning?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">7d1d370e-d90a-4aa5-931a-bdd5c1995f8a</guid>
      <link>https://share.transistor.fm/s/d12e6016</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-nil-punning/">https://lispcast.com/what-is-nil-punning/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-nil-punning/">https://lispcast.com/what-is-nil-punning/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 26 Sep 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d12e6016/7edb9c21.mp3" length="56056957" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1399</itunes:duration>
      <itunes:summary>Nil punning is a feature of Lisp. It began when nil was both the empty list and the false value. Two meanings for the same thing led to the idea of punning. Lispers liked it. And now, Clojure carries the tradition forward. In Clojure, nil has different meanings in different contexts. Is it good? Is it bad? We explore it in this episode.</itunes:summary>
      <itunes:subtitle>Nil punning is a feature of Lisp. It began when nil was both the empty list and the false value. Two meanings for the same thing led to the idea of punning. Lispers liked it. And now, Clojure carries the tradition forward. In Clojure, nil has different me</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the Curse of Lisp?</title>
      <itunes:episode>142</itunes:episode>
      <podcast:episode>142</podcast:episode>
      <itunes:title>What is the Curse of Lisp?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">93a68f21-2cc4-4232-8c4b-74c38285ba9f</guid>
      <link>https://share.transistor.fm/s/ba87afbf</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: https://lispcast.com/what-is-the-curse-of-lisp/</p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: https://lispcast.com/what-is-the-curse-of-lisp/</p>]]>
      </content:encoded>
      <pubDate>Mon, 23 Sep 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ba87afbf/9b2e90da.mp3" length="60416987" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1508</itunes:duration>
      <itunes:summary>What happens when your language is so powerful that small, independent teams can solve their problems without libraries? Does everyone flock to it? Or do you just get a lack of libraries?</itunes:summary>
      <itunes:subtitle>What happens when your language is so powerful that small, independent teams can solve their problems without libraries? Does everyone flock to it? Or do you just get a lack of libraries?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is an abstraction barrier?</title>
      <itunes:episode>141</itunes:episode>
      <podcast:episode>141</podcast:episode>
      <itunes:title>What is an abstraction barrier?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">a868ebbd-f744-490e-be51-fa539a001597</guid>
      <link>https://share.transistor.fm/s/fff71544</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-abstraction-barrier/">https://lispcast.com/what-is-an-abstraction-barrier/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-abstraction-barrier/">https://lispcast.com/what-is-an-abstraction-barrier/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 19 Sep 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fff71544/6deebd4c.mp3" length="50276981" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1255</itunes:duration>
      <itunes:summary>Structure and Interpretation of Computer Programs talked about abstraction barriers as a way to hide the intricacies of data structures made out of cons cells. Is this concept still useful in a world of literal hashmaps with string keys? I say, yes, but in a much more limited way than before. In this episode, we go into what abstraction barriers are, why (and why not) to use them, and the limits of their usefulness.</itunes:summary>
      <itunes:subtitle>Structure and Interpretation of Computer Programs talked about abstraction barriers as a way to hide the intricacies of data structures made out of cons cells. Is this concept still useful in a world of literal hashmaps with string keys? I say, yes, but i</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>In the onion architecture, how do you make business decisions that rely on information from actions?</title>
      <itunes:episode>140</itunes:episode>
      <podcast:episode>140</podcast:episode>
      <itunes:title>In the onion architecture, how do you make business decisions that rely on information from actions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">46c0d3a6-4927-4a2c-8fe8-067ffe7c070d</guid>
      <link>https://share.transistor.fm/s/81a5d60f</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/in-the-onion-architecture-how-do-you-make-business-decisions-that-rely-on-information-from-actions/">https://lispcast.com/in-the-onion-architecture-how-do-you-make-business-decisions-that-rely-on-information-from-actions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/in-the-onion-architecture-how-do-you-make-business-decisions-that-rely-on-information-from-actions/">https://lispcast.com/in-the-onion-architecture-how-do-you-make-business-decisions-that-rely-on-information-from-actions/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 16 Sep 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/81a5d60f/d72576a9.mp3" length="47350883" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1182</itunes:duration>
      <itunes:summary>I've gotten several questions about how to do X or Y in the Onion Architecture. It seems like giving the architecture a name has miscommunicated how simple it is. It's just function calls that at some point are all calculations. In this episode, I try to deconstruct what makes the onion architecture work. Spoiler: it's just function calls.</itunes:summary>
      <itunes:subtitle>I've gotten several questions about how to do X or Y in the Onion Architecture. It seems like giving the architecture a name has miscommunicated how simple it is. It's just function calls that at some point are all calculations. In this episode, I try to </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can you use types with Data Orientation?</title>
      <itunes:episode>139</itunes:episode>
      <podcast:episode>139</podcast:episode>
      <itunes:title>Can you use types with Data Orientation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=2012</guid>
      <link>https://share.transistor.fm/s/35083ac5</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-use-types-with-data-orientation/">https://lispcast.com/can-you-use-types-with-data-orientation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-use-types-with-data-orientation/">https://lispcast.com/can-you-use-types-with-data-orientation/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 12 Sep 2019 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/35083ac5/48e26d6f.mp3" length="33311703" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>831</itunes:duration>
      <itunes:summary>Are types compatible with data orientation? The short answer is ‘yes’. Types trade freedom of movement for clarity.</itunes:summary>
      <itunes:subtitle>Are types compatible with data orientation? The short answer is ‘yes’. Types trade freedom of movement for clarity.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the benefit of data orientation?</title>
      <itunes:episode>138</itunes:episode>
      <podcast:episode>138</podcast:episode>
      <itunes:title>What is the benefit of data orientation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=2010</guid>
      <link>https://share.transistor.fm/s/a4c120ba</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-benefit-of-data-orientation/">https://lispcast.com/what-is-the-benefit-of-data-orientation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-benefit-of-data-orientation/">https://lispcast.com/what-is-the-benefit-of-data-orientation/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 09 Sep 2019 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a4c120ba/a77a60f1.mp3" length="20462151" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>509</itunes:duration>
      <itunes:summary>Data orientation allows freedom of movement between layers of meaning. Each interpretation adds a layer of meaning. If the data were hidden, we would not be able to freely interpret it how we want. In this episode, we explore an example of what it means to move up and down the layers of meaning.</itunes:summary>
      <itunes:subtitle>Data orientation allows freedom of movement between layers of meaning. Each interpretation adds a layer of meaning. If the data were hidden, we would not be able to freely interpret it how we want. In this episode, we explore an example of what it means t</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Data Orientation?</title>
      <itunes:episode>137</itunes:episode>
      <podcast:episode>137</podcast:episode>
      <itunes:title>What is Data Orientation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=2008</guid>
      <link>https://share.transistor.fm/s/1bf42a5b</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-data-orientation/">https://lispcast.com/what-is-data-orientation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-data-orientation/">https://lispcast.com/what-is-data-orientation/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 05 Sep 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1bf42a5b/dc9bdfc8.mp3" length="32053209" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>799</itunes:duration>
      <itunes:summary>We often talk about data orientation in functional programming circles. It basically means programming with data, without hiding your data. Our software is information systems, so why not treat the data in the raw? In this episode, we dive into what is data, what data orientation is all about, and how you program with it.</itunes:summary>
      <itunes:subtitle>We often talk about data orientation in functional programming circles. It basically means programming with data, without hiding your data. Our software is information systems, so why not treat the data in the raw? In this episode, we dive into what is da</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a total function?</title>
      <itunes:episode>136</itunes:episode>
      <podcast:episode>136</podcast:episode>
      <itunes:title>What is a total function?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=2003</guid>
      <link>https://share.transistor.fm/s/f4ffcf50</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-total-function/">https://lispcast.com/what-is-a-total-function/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-total-function/">https://lispcast.com/what-is-a-total-function/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 02 Sep 2019 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f4ffcf50/9c7a7537.mp3" length="75713109" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1891</itunes:duration>
      <itunes:summary>Total functions are functions that give you a valid return value for every combination of valid arguments. They never throw errors and they don’t require checks of the return value. Total functions help you write more robust code and simpler code, free from defensive checks and errors.</itunes:summary>
      <itunes:subtitle>Total functions are functions that give you a valid return value for every combination of valid arguments. They never throw errors and they don’t require checks of the return value. Total functions help you write more robust code and simpler code, free fr</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a continuation?</title>
      <itunes:episode>135</itunes:episode>
      <podcast:episode>135</podcast:episode>
      <itunes:title>What is a continuation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=2000</guid>
      <link>https://share.transistor.fm/s/f36b3a28</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-continuation/">https://lispcast.com/what-is-a-continuation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-continuation/">https://lispcast.com/what-is-a-continuation/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 29 Aug 2019 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f36b3a28/775ba6cd.mp3" length="41867564" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1044</itunes:duration>
      <itunes:summary>Continuations are a cool feature you often find in functional languages. In this episode, we look at what they are, why you’re probably already using them, and the cool things you can do with them.</itunes:summary>
      <itunes:subtitle>Continuations are a cool feature you often find in functional languages. In this episode, we look at what they are, why you’re probably already using them, and the cool things you can do with them.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What kind of software is functional programming not suited for?</title>
      <itunes:episode>134</itunes:episode>
      <podcast:episode>134</podcast:episode>
      <itunes:title>What kind of software is functional programming not suited for?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/what-kind-of-software-os-functional-programming-not-suited-for/</guid>
      <link>https://share.transistor.fm/s/a224a331</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-kind-of-software-is-functional-programming-not-suited-for/">https://lispcast.com/what-kind-of-software-is-functional-programming-not-suited-for/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-kind-of-software-is-functional-programming-not-suited-for/">https://lispcast.com/what-kind-of-software-is-functional-programming-not-suited-for/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 26 Aug 2019 11:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a224a331/69473dfb.mp3" length="47907917" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1195</itunes:duration>
      <itunes:summary>Functional programming cannot be suited for everything, right? Well, let’s not be so sure. Functional programming, like imperative programming and object-oriented programming, is a paradigm. It is a fundamental way to approach software. There are many languages that fall within the umbrella of FP. It is quite possible that everything we know how to do in software, we know how to do well with FP, the same way we know how to do it with imperative and with OOP.</itunes:summary>
      <itunes:subtitle>Functional programming cannot be suited for everything, right? Well, let’s not be so sure. Functional programming, like imperative programming and object-oriented programming, is a paradigm. It is a fundamental way to approach software. There are many lan</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Grokking Simplicity Launch</title>
      <itunes:episode>132</itunes:episode>
      <podcast:episode>132</podcast:episode>
      <itunes:title>Grokking Simplicity Launch</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1994</guid>
      <link>https://share.transistor.fm/s/1e869b45</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/grokking-simplicity-launch/">https://lispcast.com/grokking-simplicity-launch/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/grokking-simplicity-launch/">https://lispcast.com/grokking-simplicity-launch/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 22 Aug 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1e869b45/ad102fb2.mp3" length="25666463" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>639</itunes:duration>
      <itunes:summary>My new book, Grokking Simplicity, all about functional programming, is now available in early access. The first three chapters are ready to read. Go to https://lispcast.com/gs, add the book to the cart, and use discount code MLNORMAND for 50% off.</itunes:summary>
      <itunes:subtitle>My new book, Grokking Simplicity, all about functional programming, is now available in early access. The first three chapters are ready to read. Go to https://lispcast.com/gs, add the book to the cart, and use discount code MLNORMAND for 50% off.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Monads in the real world</title>
      <itunes:episode>133</itunes:episode>
      <podcast:episode>133</podcast:episode>
      <itunes:title>Monads in the real world</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1985</guid>
      <link>https://share.transistor.fm/s/0e44eebd</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/monads-in-the-real-world/">https://lispcast.com/monads-in-the-real-world/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/monads-in-the-real-world/">https://lispcast.com/monads-in-the-real-world/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 22 Aug 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/0e44eebd/79af3eb9.mp3" length="42136157" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1051</itunes:duration>
      <itunes:summary>Monads are real, y’all. They are all around us. In this metaphor-free episode, I’ll share two real-world monads you interact with all the time. No burritos or space suits, I promise! Plus, we’ll see why monads are useful in Haskell.</itunes:summary>
      <itunes:subtitle>Monads are real, y’all. They are all around us. In this metaphor-free episode, I’ll share two real-world monads you interact with all the time. No burritos or space suits, I promise! Plus, we’ll see why monads are useful in Haskell.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the difference between parallelism and concurrency?</title>
      <itunes:episode>131</itunes:episode>
      <podcast:episode>131</podcast:episode>
      <itunes:title>What is the difference between parallelism and concurrency?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1980</guid>
      <link>https://share.transistor.fm/s/97b1adb6</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-difference-between-parallelism-and-concurrency/">https://lispcast.com/what-is-the-difference-between-parallelism-and-concurrency/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-difference-between-parallelism-and-concurrency/">https://lispcast.com/what-is-the-difference-between-parallelism-and-concurrency/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 19 Aug 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/97b1adb6/e6dce735.mp3" length="16128005" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>401</itunes:duration>
      <itunes:summary>My favorite definitions of parallelism and concurrency come from Brian Goetz. They are not the traditional ones, which focus mostly on # of cores. In modern computing, we are sharing so many resources, parallelism and concurrency need to account for that. In this episode, we go over those definitions.</itunes:summary>
      <itunes:subtitle>My favorite definitions of parallelism and concurrency come from Brian Goetz. They are not the traditional ones, which focus mostly on # of cores. In modern computing, we are sharing so many resources, parallelism and concurrency need to account for that.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do you develop algebraic thinking?</title>
      <itunes:episode>130</itunes:episode>
      <podcast:episode>130</podcast:episode>
      <itunes:title>How do you develop algebraic thinking?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1977</guid>
      <link>https://share.transistor.fm/s/9c95d191</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-develop-algebraic-thinking/">https://lispcast.com/how-do-you-develop-algebraic-thinking/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-develop-algebraic-thinking/">https://lispcast.com/how-do-you-develop-algebraic-thinking/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 15 Aug 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9c95d191/2d360b46.mp3" length="61903523" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1545</itunes:duration>
      <itunes:summary>A few people have asked me how to develop Level 3 thinking. I’m not sure. But I’ve got some directions to try. In this episode, I go over 3 and a half ways to develop algebraic thinking.</itunes:summary>
      <itunes:subtitle>A few people have asked me how to develop Level 3 thinking. I’m not sure. But I’ve got some directions to try. In this episode, I go over 3 and a half ways to develop algebraic thinking.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is an algebra?</title>
      <itunes:episode>129</itunes:episode>
      <podcast:episode>129</podcast:episode>
      <itunes:title>What is an algebra?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/what-is-an-algebra/</guid>
      <link>https://share.transistor.fm/s/7383cd76</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-algebra/">https://lispcast.com/what-is-an-algebra/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-algebra/">https://lispcast.com/what-is-an-algebra/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 12 Aug 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7383cd76/933ccf1a.mp3" length="42935709" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1071</itunes:duration>
      <itunes:summary>Level 3 of functional thinking is all about algebraic thinking. But what do I mean by algebra? In this episode, I try to distill down the characteristics of an algebra and explore why algebras are worth developing.</itunes:summary>
      <itunes:subtitle>Level 3 of functional thinking is all about algebraic thinking. But what do I mean by algebra? In this episode, I try to distill down the characteristics of an algebra and explore why algebras are worth developing.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a calculation?</title>
      <itunes:episode>128</itunes:episode>
      <podcast:episode>128</podcast:episode>
      <itunes:title>What is a calculation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1963</guid>
      <link>https://share.transistor.fm/s/d4c11644</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-calculation/">https://lispcast.com/what-is-a-calculation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-calculation/">https://lispcast.com/what-is-a-calculation/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 05 Aug 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d4c11644/bd374ee7.mp3" length="41541422" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1036</itunes:duration>
      <itunes:summary>Level 1 of functional thinking is to distinguish between actions, calculations, and data. But what is a calculation? In this episode, we go over what it is, how to recognize them, and how to implement them. By the end, you should understand why they are so important to functional programming.</itunes:summary>
      <itunes:subtitle>Level 1 of functional thinking is to distinguish between actions, calculations, and data. But what is a calculation? In this episode, we go over what it is, how to recognize them, and how to implement them. By the end, you should understand why they are s</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is so great about object oriented programming?</title>
      <itunes:episode>127</itunes:episode>
      <podcast:episode>127</podcast:episode>
      <itunes:title>What is so great about object oriented programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/what-is-so-great-about-object-oriented-programming/</guid>
      <link>https://share.transistor.fm/s/4258e35d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-so-great-about-object-oriented-programming/">https://lispcast.com/what-is-so-great-about-object-oriented-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-so-great-about-object-oriented-programming/">https://lispcast.com/what-is-so-great-about-object-oriented-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 01 Aug 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4258e35d/6f2045bc.mp3" length="49229026" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1228</itunes:duration>
      <itunes:summary>Because I promote functional programming, people often take what I say to mean that I don’t like OO. However, I think there’s a lot of cool stuff in OO. In this episode, I go over three or four things I think OO does really well.</itunes:summary>
      <itunes:subtitle>Because I promote functional programming, people often take what I say to mean that I don’t like OO. However, I think there’s a lot of cool stuff in OO. In this episode, I go over three or four things I think OO does really well.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why should you throw away all of your code?</title>
      <itunes:episode>126</itunes:episode>
      <podcast:episode>126</podcast:episode>
      <itunes:title>Why should you throw away all of your code?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1943</guid>
      <link>https://share.transistor.fm/s/1ecfbaa9</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-should-you-throw-away-all-of-your-code/">https://lispcast.com/why-should-you-throw-away-all-of-your-code/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-should-you-throw-away-all-of-your-code/">https://lispcast.com/why-should-you-throw-away-all-of-your-code/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 01 Aug 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1ecfbaa9/eb9298a9.mp3" length="17859956" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>444</itunes:duration>
      <itunes:summary>You should throw away your code and try again, because it will make you a better programmer to try the same problem multiple times. Each time you can try a new style or approach to solving it. That’s how you get better.</itunes:summary>
      <itunes:subtitle>You should throw away your code and try again, because it will make you a better programmer to try the same problem multiple times. Each time you can try a new style or approach to solving it. That’s how you get better.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Data Modeling?</title>
      <itunes:episode>125</itunes:episode>
      <podcast:episode>125</podcast:episode>
      <itunes:title>What is Data Modeling?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1941</guid>
      <link>https://share.transistor.fm/s/eb9312d0</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-data-modeling/">https://lispcast.com/what-is-data-modeling/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-data-modeling/">https://lispcast.com/what-is-data-modeling/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 29 Jul 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/eb9312d0/f38dee9e.mp3" length="25188913" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>627</itunes:duration>
      <itunes:summary>Data Modeling is a common technique in functional prgramming. It means capturing the essence of the concepts of your domain, their attributes, and their relationships in data.</itunes:summary>
      <itunes:subtitle>Data Modeling is a common technique in functional prgramming. It means capturing the essence of the concepts of your domain, their attributes, and their relationships in data.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is an action? (better edit)</title>
      <itunes:episode>124</itunes:episode>
      <podcast:episode>124</podcast:episode>
      <itunes:title>What is an action? (better edit)</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/what-is-an-action/</guid>
      <link>https://share.transistor.fm/s/ff29e31f</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-action/">https://lispcast.com/what-is-an-action/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-action/">https://lispcast.com/what-is-an-action/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 25 Jul 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ff29e31f/3c1740b4.mp3" length="46151721" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1152</itunes:duration>
      <itunes:summary>Functional programmers divide up their code into three categories: actions, calculations, and data. Actions are everything that can have an effect on the world, or anything that can be affected. In this episode, we go deep into what it means to be an action.</itunes:summary>
      <itunes:subtitle>Functional programmers divide up their code into three categories: actions, calculations, and data. Actions are everything that can have an effect on the world, or anything that can be affected. In this episode, we go deep into what it means to be an acti</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is tail recursion?</title>
      <itunes:episode>123</itunes:episode>
      <podcast:episode>123</podcast:episode>
      <itunes:title>What is tail recursion?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1929</guid>
      <link>https://share.transistor.fm/s/59ef6d69</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-tail-recursion/">https://lispcast.com/what-is-tail-recursion/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-tail-recursion/">https://lispcast.com/what-is-tail-recursion/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 22 Jul 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/59ef6d69/58db8ba5.mp3" length="37236271" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>929</itunes:duration>
      <itunes:summary>Tail recursion is a kind of recursion that won’t blow the stack, so it’s just about as efficient as a while loop. Unfortunately, not all platforms support tail call removal, which is necessary for making tail recursion efficient. We talk about what it is and how to do it, even if your language doesn’t support it.</itunes:summary>
      <itunes:subtitle>Tail recursion is a kind of recursion that won’t blow the stack, so it’s just about as efficient as a while loop. Unfortunately, not all platforms support tail call removal, which is necessary for making tail recursion efficient. We talk about what it is </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is memoization?</title>
      <itunes:episode>122</itunes:episode>
      <podcast:episode>122</podcast:episode>
      <itunes:title>What is memoization?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1926</guid>
      <link>https://share.transistor.fm/s/48377fd1</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-memoization/">https://lispcast.com/what-is-memoization/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-memoization/">https://lispcast.com/what-is-memoization/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 18 Jul 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/48377fd1/d49cf24c.mp3" length="28463737" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>709</itunes:duration>
      <itunes:summary>Memoization is a higher order function that caches another function. It can turn some slow functions into fast ones. It saves the result of a function call after the first time to the cache, so if you call the function again with the same arguments, it will find it in the cache.</itunes:summary>
      <itunes:subtitle>Memoization is a higher order function that caches another function. It can turn some slow functions into fast ones. It saves the result of a function call after the first time to the cache, so if you call the function again with the same arguments, it wi</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How does making something first class give you power?</title>
      <itunes:episode>121</itunes:episode>
      <podcast:episode>121</podcast:episode>
      <itunes:title>How does making something first class give you power?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/how-does-making-something-first-class-give-you-power/</guid>
      <link>https://share.transistor.fm/s/3eb39dea</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-does-making-something-first-class-give-you-power/">https://lispcast.com/how-does-making-something-first-class-give-you-power/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-does-making-something-first-class-give-you-power/">https://lispcast.com/how-does-making-something-first-class-give-you-power/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 15 Jul 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3eb39dea/19a9167a.mp3" length="22952398" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>572</itunes:duration>
      <itunes:summary>Often, functionality starts off as code. It’s if statements and imperative ideas. But, over time, you notice patterns. Those patterns can be reified as data. And that gives us tremendous power. How so? We explore it in this episode.</itunes:summary>
      <itunes:subtitle>Often, functionality starts off as code. It’s if statements and imperative ideas. But, over time, you notice patterns. Those patterns can be reified as data. And that gives us tremendous power. How so? We explore it in this episode.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is there a silver bullet for software? (part 2)</title>
      <itunes:episode>120</itunes:episode>
      <podcast:episode>120</podcast:episode>
      <itunes:title>Is there a silver bullet for software? (part 2)</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1916</guid>
      <link>https://share.transistor.fm/s/ae52c682</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-a-silver-bullet-for-software-part-2/">https://lispcast.com/is-there-a-silver-bullet-for-software-part-2/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-a-silver-bullet-for-software-part-2/">https://lispcast.com/is-there-a-silver-bullet-for-software-part-2/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 11 Jul 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ae52c682/f31cc8ed.mp3" length="30055651" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>749</itunes:duration>
      <itunes:summary>We continue this exploration with the notion that maybe practices such as Agile, Design Thinking, etc., give us a means for eliminating essential complexity that we thought was necessary. Do we really need to implement everything? Maybe not.</itunes:summary>
      <itunes:subtitle>We continue this exploration with the notion that maybe practices such as Agile, Design Thinking, etc., give us a means for eliminating essential complexity that we thought was necessary. Do we really need to implement everything? Maybe not.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is there a silver bullet for software development? (part 1)</title>
      <itunes:episode>119</itunes:episode>
      <podcast:episode>119</podcast:episode>
      <itunes:title>Is there a silver bullet for software development? (part 1)</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1914</guid>
      <link>https://share.transistor.fm/s/385323ba</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-a-silver-bullet-for-software-development-part-1/">https://lispcast.com/is-there-a-silver-bullet-for-software-development-part-1/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-a-silver-bullet-for-software-development-part-1/">https://lispcast.com/is-there-a-silver-bullet-for-software-development-part-1/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 08 Jul 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/385323ba/0c8821c7.mp3" length="45032707" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1124</itunes:duration>
      <itunes:summary>In The Mythical Man-Month, Fred Brooks argues that there is no improvement that can give us an order of magnitude increase in productivity. His main point is that most of what’s left to improve is essential complexity. But is that true? Can we throw in the towel and declare there is nothing left to improve?</itunes:summary>
      <itunes:subtitle>In The Mythical Man-Month, Fred Brooks argues that there is no improvement that can give us an order of magnitude increase in productivity. His main point is that most of what’s left to improve is essential complexity. But is that true? Can we throw in th</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why getters and setters are terrible</title>
      <itunes:episode>118</itunes:episode>
      <podcast:episode>118</podcast:episode>
      <itunes:title>Why getters and setters are terrible</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1900</guid>
      <link>https://share.transistor.fm/s/dfce1929</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-getters-and-setters-are-terrible/">https://lispcast.com/why-getters-and-setters-are-terrible/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-getters-and-setters-are-terrible/">https://lispcast.com/why-getters-and-setters-are-terrible/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 04 Jul 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/dfce1929/1e788925.mp3" length="32504325" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>810</itunes:duration>
      <itunes:summary>Getters and setters kick the domain modeling can down the road. They leave the real design work to some other part of the code. They don’t do enough to protect the semantic integrity of the object. They’re terrible.</itunes:summary>
      <itunes:subtitle>Getters and setters kick the domain modeling can down the road. They leave the real design work to some other part of the code. They don’t do enough to protect the semantic integrity of the object. They’re terrible.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why taming complex software?</title>
      <itunes:episode>117</itunes:episode>
      <podcast:episode>117</podcast:episode>
      <itunes:title>Why taming complex software?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1898</guid>
      <link>https://share.transistor.fm/s/d2a23a59</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-taming-complex-software/">https://lispcast.com/why-taming-complex-software/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-taming-complex-software/">https://lispcast.com/why-taming-complex-software/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 01 Jul 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d2a23a59/9f242256.mp3" length="49990037" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1248</itunes:duration>
      <itunes:summary>My book is called Taming Complex Software. What’s that all about? In this episode, I go into why complexity is a major problem and how functional programming can help.</itunes:summary>
      <itunes:subtitle>My book is called Taming Complex Software. What’s that all about? In this episode, I go into why complexity is a major problem and how functional programming can help.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>3 Examples of algebraic thinking</title>
      <itunes:episode>116</itunes:episode>
      <podcast:episode>116</podcast:episode>
      <itunes:title>3 Examples of algebraic thinking</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1896</guid>
      <link>https://share.transistor.fm/s/f8aeb3d1</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/3-examples-of-algebraic-thinking/">https://lispcast.com/3-examples-of-algebraic-thinking/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/3-examples-of-algebraic-thinking/">https://lispcast.com/3-examples-of-algebraic-thinking/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 27 Jun 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f8aeb3d1/3275ae73.mp3" length="61696285" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1540</itunes:duration>
      <itunes:summary>In a recent episode, I said algebraic thinking was the third level of functional thinking. In this episode, I give some concrete examples.</itunes:summary>
      <itunes:subtitle>In a recent episode, I said algebraic thinking was the third level of functional thinking. In this episode, I give some concrete examples.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a higher-order function?</title>
      <itunes:episode>115</itunes:episode>
      <podcast:episode>115</podcast:episode>
      <itunes:title>What is a higher-order function?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1816</guid>
      <link>https://share.transistor.fm/s/9802a780</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-higher-order-function/">https://lispcast.com/what-is-a-higher-order-function/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-higher-order-function/">https://lispcast.com/what-is-a-higher-order-function/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 24 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9802a780/0ff72791.mp3" length="36832359" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>919</itunes:duration>
      <itunes:summary>Higher-order functions are used a lot in functional programming. They are functions that take other functions as arguments or return functions as return values, or both. You’ll probably be familiar with map, filter, and reduce, which are higher-order functions. In this episode, we go kind of deep on them.</itunes:summary>
      <itunes:subtitle>Higher-order functions are used a lot in functional programming. They are functions that take other functions as arguments or return functions as return values, or both. You’ll probably be familiar with map, filter, and reduce, which are higher-order func</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The 3 levels of functional thinking</title>
      <itunes:episode>114</itunes:episode>
      <podcast:episode>114</podcast:episode>
      <itunes:title>The 3 levels of functional thinking</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1814</guid>
      <link>https://share.transistor.fm/s/89d9ee69</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-3-levels-of-functional-thinking/">https://lispcast.com/the-3-levels-of-functional-thinking/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-3-levels-of-functional-thinking/">https://lispcast.com/the-3-levels-of-functional-thinking/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 20 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/89d9ee69/41412a69.mp3" length="36014265" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>898</itunes:duration>
      <itunes:summary>I’ve noticed that people go through a certain journey when learning functional programming. I’ve classified it into three levels: 1) Distinction between Actions, Calculations, and Data; and learning to use them effectively 2) Higher-order thinking; and building abstractions from higher-order functions 3) Algebraic thiking; building coherent models with a focus on composition. This is a work in progress and I’d love your input.</itunes:summary>
      <itunes:subtitle>I’ve noticed that people go through a certain journey when learning functional programming. I’ve classified it into three levels: 1) Distinction between Actions, Calculations, and Data; and learning to use them effectively 2) Higher-order thinking; and bu</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is functional thinking?</title>
      <itunes:episode>113</itunes:episode>
      <podcast:episode>113</podcast:episode>
      <itunes:title>What is functional thinking?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1812</guid>
      <link>https://share.transistor.fm/s/bbb4b302</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-functional-thinking/">https://lispcast.com/what-is-functional-thinking/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-functional-thinking/">https://lispcast.com/what-is-functional-thinking/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 17 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bbb4b302/6a990e02.mp3" length="27673699" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>690</itunes:duration>
      <itunes:summary>My book is coming out soon in early access. It’s called ‘Taming Complex Software: A Friendly Guide to Functional Thinking’. But what is ‘functional thinking’? In this episode, I explain the term and why I’m no longer redefining ‘functional programming’.</itunes:summary>
      <itunes:subtitle>My book is coming out soon in early access. It’s called ‘Taming Complex Software: A Friendly Guide to Functional Thinking’. But what is ‘functional thinking’? In this episode, I explain the term and why I’m no longer redefining ‘functional programming’.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>We make information systems</title>
      <itunes:episode>112</itunes:episode>
      <podcast:episode>112</podcast:episode>
      <itunes:title>We make information systems</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1808</guid>
      <link>https://share.transistor.fm/s/a13caa96</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/we-make-information-systems/">https://lispcast.com/we-make-information-systems/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/we-make-information-systems/">https://lispcast.com/we-make-information-systems/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 13 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a13caa96/9778a4b5.mp3" length="27273281" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>680</itunes:duration>
      <itunes:summary>I often have to remind myself that we make information systems when we are programming for a business. My natural tendency, due to years of education, is to begin by creating a simulation. But this is not what we need to do. Instead of simulating a shopper going through a store, we need to model the information transfers that were captured in the pre-digital information system of pen-and-paper inventory and order management.</itunes:summary>
      <itunes:subtitle>I often have to remind myself that we make information systems when we are programming for a business. My natural tendency, due to years of education, is to begin by creating a simulation. But this is not what we need to do. Instead of simulating a shoppe</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How to distinguish between commutativity and associativity</title>
      <itunes:episode>111</itunes:episode>
      <podcast:episode>111</podcast:episode>
      <itunes:title>How to distinguish between commutativity and associativity</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1803</guid>
      <link>https://share.transistor.fm/s/c6a38518</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-distinguish-between-commutativity-and-associativity/">https://lispcast.com/how-to-distinguish-between-commutativity-and-associativity/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-distinguish-between-commutativity-and-associativity/">https://lispcast.com/how-to-distinguish-between-commutativity-and-associativity/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 10 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c6a38518/91b595b8.mp3" length="44698459" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1115</itunes:duration>
      <itunes:summary>You confuse them a lot, and it’s not your fault. They are similar in that they are both about order. Associativity is about the order of operations, and commutativity is about the order of arguments. We go through some examples to help clear up the distinction.</itunes:summary>
      <itunes:subtitle>You confuse them a lot, and it’s not your fault. They are similar in that they are both about order. Associativity is about the order of operations, and commutativity is about the order of arguments. We go through some examples to help clear up the distin</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why side-effecting is not all bad</title>
      <itunes:episode>110</itunes:episode>
      <podcast:episode>110</podcast:episode>
      <itunes:title>Why side-effecting is not all bad</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1801</guid>
      <link>https://share.transistor.fm/s/d5586487</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-side-effecting-is-not-all-bad/">https://lispcast.com/why-side-effecting-is-not-all-bad/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-side-effecting-is-not-all-bad/">https://lispcast.com/why-side-effecting-is-not-all-bad/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d5586487/2581079e.mp3" length="25693241" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>640</itunes:duration>
      <itunes:summary>We run our software for its effects, so effects are necessary. We can’t write 100% pure code. But I contend that some effecting code is better than others. In other words, there is a spectrum from bad effecting code to good effecting code. Even if you can’t turn an action completely into a calculation, you should still strive to minimize implicit inputs and outputs.</itunes:summary>
      <itunes:subtitle>We run our software for its effects, so effects are necessary. We can’t write 100% pure code. But I contend that some effecting code is better than others. In other words, there is a spectrum from bad effecting code to good effecting code. Even if you can</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is an inverse, and why is it useful?</title>
      <itunes:episode>109</itunes:episode>
      <podcast:episode>109</podcast:episode>
      <itunes:title>What is an inverse, and why is it useful?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1799</guid>
      <link>https://share.transistor.fm/s/866a64db</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-inverse-and-why-is-it-useful/">https://lispcast.com/what-is-an-inverse-and-why-is-it-useful/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-an-inverse-and-why-is-it-useful/">https://lispcast.com/what-is-an-inverse-and-why-is-it-useful/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Jun 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/866a64db/e381e4de.mp3" length="19067601" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>474</itunes:duration>
      <itunes:summary>Inverses are everywhere. They let us undo an action. For instance, I can open a door and close it. Why do we want to do this? Because there are things I can do with the door open, and other things I can do with it closed. We need this same flexibility in our computer programs.</itunes:summary>
      <itunes:subtitle>Inverses are everywhere. They let us undo an action. For instance, I can open a door and close it. Why do we want to do this? Because there are things I can do with the door open, and other things I can do with it closed. We need this same flexibility in </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What makes a repl?</title>
      <itunes:episode>108</itunes:episode>
      <podcast:episode>108</podcast:episode>
      <itunes:title>What makes a repl?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1792</guid>
      <link>https://share.transistor.fm/s/fff53e56</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-makes-a-repl/">https://lispcast.com/what-makes-a-repl/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-makes-a-repl/">https://lispcast.com/what-makes-a-repl/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 30 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fff53e56/e9836823.mp3" length="32126987" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>801</itunes:duration>
      <itunes:summary>There’s a lot of discussion on Twitter about whether Node has a repl or Python has a repl. Do they have repls? How can we tell? Well, my opinion is that what’s important is how it’s used, not a set of features.</itunes:summary>
      <itunes:subtitle>There’s a lot of discussion on Twitter about whether Node has a repl or Python has a repl. Do they have repls? How can we tell? Well, my opinion is that what’s important is how it’s used, not a set of features.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is Haskell faster than C?</title>
      <itunes:episode>107</itunes:episode>
      <podcast:episode>107</podcast:episode>
      <itunes:title>How is Haskell faster than C?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1790</guid>
      <link>https://share.transistor.fm/s/e6a8f332</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-haskell-faster-than-c/">https://lispcast.com/how-is-haskell-faster-than-c/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-haskell-faster-than-c/">https://lispcast.com/how-is-haskell-faster-than-c/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 27 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e6a8f332/be1abc2e.mp3" length="35078983" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>875</itunes:duration>
      <itunes:summary>Haskell is very competitive with C, and on some benchmarks, it is faster. How is that possible? With all that Haskell does on top of the raw C code, how can it possibly be faster? In this episode, I talk about two advantages of Haskell that can make it faster than C.</itunes:summary>
      <itunes:subtitle>Haskell is very competitive with C, and on some benchmarks, it is faster. How is that possible? With all that Haskell does on top of the raw C code, how can it possibly be faster? In this episode, I talk about two advantages of Haskell that can make it fa</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a functor?</title>
      <itunes:episode>106</itunes:episode>
      <podcast:episode>106</podcast:episode>
      <itunes:title>What is a functor?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1788</guid>
      <link>https://share.transistor.fm/s/891f15fe</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-functor/">https://lispcast.com/what-is-a-functor/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-functor/">https://lispcast.com/what-is-a-functor/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 23 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/891f15fe/5cd98deb.mp3" length="38302907" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>955</itunes:duration>
      <itunes:summary>Functors are an operation that has a structure preserving property. But what is that? Are these things practical? Does it have anything to do with the real world? Of course! To be useful, it must derive from real-world things we see all around us. This one is an assembly line. How? That’s what this episode is all about.</itunes:summary>
      <itunes:subtitle>Functors are an operation that has a structure preserving property. But what is that? Are these things practical? Does it have anything to do with the real world? Of course! To be useful, it must derive from real-world things we see all around us. This on</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why am I podcasting about functional programming?</title>
      <itunes:episode>105</itunes:episode>
      <podcast:episode>105</podcast:episode>
      <itunes:title>Why am I podcasting about functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1786</guid>
      <link>https://share.transistor.fm/s/a84d9aba</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-am-i-podcasting-about-functional-programming/">https://lispcast.com/why-am-i-podcasting-about-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-am-i-podcasting-about-functional-programming/">https://lispcast.com/why-am-i-podcasting-about-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 20 May 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a84d9aba/d0fa0267.mp3" length="27440076" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>684</itunes:duration>
      <itunes:summary>I received a negative YouTube comment. Normally, I ignore those, but this one insulted you, my audience. So I address it. Why am I podcasting about functional programming? What teaching techniques do I employ to help people learn?</itunes:summary>
      <itunes:subtitle>I received a negative YouTube comment. Normally, I ignore those, but this one insulted you, my audience. So I address it. Why am I podcasting about functional programming? What teaching techniques do I employ to help people learn?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is your layer of indirection actually useful?</title>
      <itunes:episode>104</itunes:episode>
      <podcast:episode>104</podcast:episode>
      <itunes:title>Is your layer of indirection actually useful?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1780</guid>
      <link>https://share.transistor.fm/s/33567bba</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-your-layer-of-indirection-actually-useful/">https://lispcast.com/is-your-layer-of-indirection-actually-useful/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-your-layer-of-indirection-actually-useful/">https://lispcast.com/is-your-layer-of-indirection-actually-useful/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 16 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/33567bba/96d203dd.mp3" length="39960807" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>997</itunes:duration>
      <itunes:summary>There’s a cliche: any problem can be solved with another layer of indirection. That’s true, but does your brilliant idea for a new layer of indirection actually solve a problem? In this episode, we explore this question and develop a rule of thumb for evaluating layers of indirection.</itunes:summary>
      <itunes:subtitle>There’s a cliche: any problem can be solved with another layer of indirection. That’s true, but does your brilliant idea for a new layer of indirection actually solve a problem? In this episode, we explore this question and develop a rule of thumb for eva</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What a monoid is and why monoids kick monads’ butt</title>
      <itunes:episode>103</itunes:episode>
      <podcast:episode>103</podcast:episode>
      <itunes:title>What a monoid is and why monoids kick monads’ butt</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1778</guid>
      <link>https://share.transistor.fm/s/87831475</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-a-monoid-is-and-why-monoids-kick-monads-butt/">https://lispcast.com/what-a-monoid-is-and-why-monoids-kick-monads-butt/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-a-monoid-is-and-why-monoids-kick-monads-butt/">https://lispcast.com/what-a-monoid-is-and-why-monoids-kick-monads-butt/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/87831475/49eaaebd.mp3" length="69501963" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1735</itunes:duration>
      <itunes:summary>Everyone talks about monads but monoids are where it’s at. Monoids are simple and make distributed computation a breeze. In this episode, we learn the two properties that make an operation a monoid, and how to use it do distributed computation.</itunes:summary>
      <itunes:subtitle>Everyone talks about monads but monoids are where it’s at. Monoids are simple and make distributed computation a breeze. In this episode, we learn the two properties that make an operation a monoid, and how to use it do distributed computation.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do you implement lazy evaluation?</title>
      <itunes:episode>102</itunes:episode>
      <podcast:episode>102</podcast:episode>
      <itunes:title>How do you implement lazy evaluation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1776</guid>
      <link>https://share.transistor.fm/s/94ef2264</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-implement-lazy-evaluation/">https://lispcast.com/how-do-you-implement-lazy-evaluation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-implement-lazy-evaluation/">https://lispcast.com/how-do-you-implement-lazy-evaluation/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 09 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/94ef2264/741babea.mp3" length="30397189" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>758</itunes:duration>
      <itunes:summary>Lazy evaluation is easily implemented in any language that can create first-class computations. That means functions or objects. In this episode, I explain how to implement a Delay, which is a reusable lazy component that is common in functional programming languages.</itunes:summary>
      <itunes:subtitle>Lazy evaluation is easily implemented in any language that can create first-class computations. That means functions or objects. In this episode, I explain how to implement a Delay, which is a reusable lazy component that is common in functional programmi</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is lazy evaluation?</title>
      <itunes:episode>101</itunes:episode>
      <podcast:episode>101</podcast:episode>
      <itunes:title>What is lazy evaluation?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1767</guid>
      <link>https://share.transistor.fm/s/d232be67</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-lazy-evaluation/">https://lispcast.com/what-is-lazy-evaluation/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-lazy-evaluation/">https://lispcast.com/what-is-lazy-evaluation/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 06 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d232be67/735730ad.mp3" length="31845875" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>794</itunes:duration>
      <itunes:summary>Lazy evaluation is a common technique in functional programming for separating two concerns: how you generate a value from whether/when you actually generate it. We look at the two different kinds of laziness and the benefits it gives you.</itunes:summary>
      <itunes:subtitle>Lazy evaluation is a common technique in functional programming for separating two concerns: how you generate a value from whether/when you actually generate it. We look at the two different kinds of laziness and the benefits it gives you.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is recursion like a for loop?</title>
      <itunes:episode>100</itunes:episode>
      <podcast:episode>100</podcast:episode>
      <itunes:title>How is recursion like a for loop?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1763</guid>
      <link>https://share.transistor.fm/s/5dd4e272</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-recursion-like-a-for-loop/">https://lispcast.com/how-is-recursion-like-a-for-loop/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-recursion-like-a-for-loop/">https://lispcast.com/how-is-recursion-like-a-for-loop/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 02 May 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5dd4e272/f5840c7c.mp3" length="26081019" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>650</itunes:duration>
      <itunes:summary>People think recursion is hard but it’s no harder than a for loop. In fact, it’s got the same parts, they’re just not laid out in the same way. In this episode, we look at how you can spot those three parts in any recursive function.</itunes:summary>
      <itunes:subtitle>People think recursion is hard but it’s no harder than a for loop. In fact, it’s got the same parts, they’re just not laid out in the same way. In this episode, we look at how you can spot those three parts in any recursive function.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do programmers put up with so much pain?</title>
      <itunes:episode>99</itunes:episode>
      <podcast:episode>99</podcast:episode>
      <itunes:title>Why do programmers put up with so much pain?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1761</guid>
      <link>https://share.transistor.fm/s/fee4fef0</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-programmers-put-up-with-so-much-pain/">https://lispcast.com/why-do-programmers-put-up-with-so-much-pain/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-programmers-put-up-with-so-much-pain/">https://lispcast.com/why-do-programmers-put-up-with-so-much-pain/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 29 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fee4fef0/fc2334d1.mp3" length="31686685" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>790</itunes:duration>
      <itunes:summary>If you’re using a less popular language, it may seem like there is a ton of pain there. But there’s pain everywhere. Every stack has its own problems. The key is you need to pick the pain you want to live with.</itunes:summary>
      <itunes:subtitle>If you’re using a less popular language, it may seem like there is a ton of pain there. But there’s pain everywhere. Every stack has its own problems. The key is you need to pick the pain you want to live with.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can you always find a layer of meaning in which your problem is easier?</title>
      <itunes:episode>98</itunes:episode>
      <podcast:episode>98</podcast:episode>
      <itunes:title>Can you always find a layer of meaning in which your problem is easier?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1750</guid>
      <link>https://share.transistor.fm/s/7ab9efac</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-always-find-a-layer-of-meaning-in-which-your-problem-is-easier/">https://lispcast.com/can-you-always-find-a-layer-of-meaning-in-which-your-problem-is-easier/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-always-find-a-layer-of-meaning-in-which-your-problem-is-easier/">https://lispcast.com/can-you-always-find-a-layer-of-meaning-in-which-your-problem-is-easier/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 25 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7ab9efac/b0e9cc20.mp3" length="28328755" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>706</itunes:duration>
      <itunes:summary>I’ve always found switching languages to be educational. I learn a lot. It always makes me wonder what I might learn from a non-existing language that I would bring back to my favorite languages.</itunes:summary>
      <itunes:subtitle>I’ve always found switching languages to be educational. I learn a lot. It always makes me wonder what I might learn from a non-existing language that I would bring back to my favorite languages.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is point-free style?</title>
      <itunes:episode>97</itunes:episode>
      <podcast:episode>97</podcast:episode>
      <itunes:title>What is point-free style?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1748</guid>
      <link>https://share.transistor.fm/s/5196f02c</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-point-free-style/">https://lispcast.com/what-is-point-free-style/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-point-free-style/">https://lispcast.com/what-is-point-free-style/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 22 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5196f02c/1dc847f0.mp3" length="53670575" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1340</itunes:duration>
      <itunes:summary>Point-free style is a way of defining functions with a very simple constraint: you cannot name arguments or intermediate values. How can you possibly do that? Well, with higher-order functions, of course. For instance, with function composition, you can define a new function without naming the arguments. Some languages, like the APL family, or Haskell, let you do this very easily.</itunes:summary>
      <itunes:subtitle>Point-free style is a way of defining functions with a very simple constraint: you cannot name arguments or intermediate values. How can you possibly do that? Well, with higher-order functions, of course. For instance, with function composition, you can d</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is referential transparency?</title>
      <itunes:episode>96</itunes:episode>
      <podcast:episode>96</podcast:episode>
      <itunes:title>What is referential transparency?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1745</guid>
      <link>https://share.transistor.fm/s/7d4dc84f</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-referential-transparency/">https://lispcast.com/what-is-referential-transparency/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-referential-transparency/">https://lispcast.com/what-is-referential-transparency/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 18 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7d4dc84f/a6db31e4.mp3" length="42622887" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1063</itunes:duration>
      <itunes:summary>Referential transparency is a term you’ll hear a lot in functional programming. It means that an expression can be replaced by its result. That is, 5+4 can be replaced by 9, without changing the behavior of the program. You can extend the definition also to functions. So you can say + is referentially transparent, because if you call it with the same values, it will give you the same answer.</itunes:summary>
      <itunes:subtitle>Referential transparency is a term you’ll hear a lot in functional programming. It means that an expression can be replaced by its result. That is, 5+4 can be replaced by 9, without changing the behavior of the program. You can extend the definition also </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why you shouldn’t hide your data</title>
      <itunes:episode>95</itunes:episode>
      <podcast:episode>95</podcast:episode>
      <itunes:title>Why you shouldn’t hide your data</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1739</guid>
      <link>https://share.transistor.fm/s/5c2dd622</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-you-shouldnt-hide-your-data/">https://lispcast.com/why-you-shouldnt-hide-your-data/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-you-shouldnt-hide-your-data/">https://lispcast.com/why-you-shouldnt-hide-your-data/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 15 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5c2dd622/464ccc7e.mp3" length="84042109" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2099</itunes:duration>
      <itunes:summary>In OOP, we wrap our data in an interface, which is called implementation-hiding or data-hiding. In functional programming, we don’t do that. We use our data in the nude. We pass the data around and allow the context to interpret the data as it seens fit. In this episode, we look at this significant difference between OOP and FP and how to do it.</itunes:summary>
      <itunes:subtitle>In OOP, we wrap our data in an interface, which is called implementation-hiding or data-hiding. In functional programming, we don’t do that. We use our data in the nude. We pass the data around and allow the context to interpret the data as it seens fit. </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are higher-order functions?</title>
      <itunes:episode>94</itunes:episode>
      <podcast:episode>94</podcast:episode>
      <itunes:title>What are higher-order functions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1737</guid>
      <link>https://share.transistor.fm/s/3decf6dd</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-higher-order-functions/">https://lispcast.com/what-are-higher-order-functions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-higher-order-functions/">https://lispcast.com/what-are-higher-order-functions/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 11 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3decf6dd/0049cebe.mp3" length="48666097" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1214</itunes:duration>
      <itunes:summary>Higher-order functions are functions that take a function as an argument and/or return a function. We use them a lot in functional programming. They are a way to define reusable functionality, as we do with map, filter, and reduce.</itunes:summary>
      <itunes:subtitle>Higher-order functions are functions that take a function as an argument and/or return a function. We use them a lot in functional programming. They are a way to define reusable functionality, as we do with map, filter, and reduce.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is function composition?</title>
      <itunes:episode>93</itunes:episode>
      <podcast:episode>93</podcast:episode>
      <itunes:title>What is function composition?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1735</guid>
      <link>https://share.transistor.fm/s/4c5db513</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-function-composition/">https://lispcast.com/what-is-function-composition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-function-composition/">https://lispcast.com/what-is-function-composition/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 08 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4c5db513/1147607f.mp3" length="44877883" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1120</itunes:duration>
      <itunes:summary>Function composition is taking the return value of one function and passing it as an argument to another function. It’s common enough that functional programmers have turned it into its own operation. In this episode, we go deep into why it’s important and how you can use it and write it yourself.</itunes:summary>
      <itunes:subtitle>Function composition is taking the return value of one function and passing it as an argument to another function. It’s common enough that functional programmers have turned it into its own operation. In this episode, we go deep into why it’s important an</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What does it mean for a function to have a zero?</title>
      <itunes:episode>92</itunes:episode>
      <podcast:episode>92</podcast:episode>
      <itunes:title>What does it mean for a function to have a zero?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1730</guid>
      <link>https://share.transistor.fm/s/ca604f7b</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-a-function-to-have-a-zero/">https://lispcast.com/what-does-it-mean-for-a-function-to-have-a-zero/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-a-function-to-have-a-zero/">https://lispcast.com/what-does-it-mean-for-a-function-to-have-a-zero/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 04 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ca604f7b/485bc668.mp3" length="29411349" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>733</itunes:duration>
      <itunes:summary>Some functions have a special value that will stop computation. For instance, multiplication will stop if you multiply zero by anything. We can use this property to our advantage.</itunes:summary>
      <itunes:subtitle>Some functions have a special value that will stop computation. For instance, multiplication will stop if you multiply zero by anything. We can use this property to our advantage.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is a function’s identity?</title>
      <itunes:episode>91</itunes:episode>
      <podcast:episode>91</podcast:episode>
      <itunes:title>What is a function’s identity?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1728</guid>
      <link>https://share.transistor.fm/s/41e3178d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-functions-identity/">https://lispcast.com/what-is-a-functions-identity/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-a-functions-identity/">https://lispcast.com/what-is-a-functions-identity/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 01 Apr 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/41e3178d/72605531.mp3" length="23142597" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>576</itunes:duration>
      <itunes:summary>Some functions have identities, which are values that tell you where to start calculating. In this episode, we look at what identities are, some examples of them, and how you can use them in your own code.

Transcript
Eric Normand: Is a function’s identity? By the end of this episode, you’ll know what an identity is and how to use them in your code. My name is Eric Normand. I help people thrive with functional programming.
This is an important topic because many common operations, operations we use every day, have identities. You might not know that term, but you’ve definitely used them. It’s a fundamental idea from algebra, and it tells us where to start an operation.
Basically, it’s the value you start with. When you’re counting, you’re going to start at zero. You don’t start at one. Before you start counting, you’re at zero, then the first thing you count down when it gets to one.
Counting is just adding one each time. Zero is the identity value of addition. Multiplication also has an identity value, it’s one. If you multiply one times anything, you get that number. Same thing with adding zero. If you add zero to anything, you get the number back. That’s what an identity means.
There’s other identities all around. If you’re adding letters to the end of a string, you’re going to start with an empty string. If you’re adding elements to an array, you’re going to start with an empty array.
The same property holds, if you stake a string and you concatenate on an empty string to the end, you get the same string out. The same thing if you take an empty array and you concatenate them, you’re going to get the original array out.
You can look at all sorts of operations and try to find if they have an identity. The ones that have an identity tend to be the more algebra feeling ones. I’m talking about hash map merge.
If you merge two hash maps, basically copying the keys and values from one into the other, the identity is the empty map. Another property of the identity is it has to work in both sides.
With addition, you can say, 10 plus 0 or 0 plus 10. The identity works in both positions. Same with hash map merge. If I have an empty hash map and I merge on a non-empty hash map, I get that non-empty hash map out. If I reverse the direction, and I start with a non-empty hash map and I merge in an empty hash map, I get the non-empty hash map out.
Another way to look at identities is that they are the empty value. That’s the empty array, the empty hash map, zero empty string. Whatever kinds of data structures you’re looking at, there’s going to be some empty version of it.
It’s important to remember that the identity is a property of the operation. It’s not a property of the data type. I said data types have their empty version of the data type, but the identity is a property of the function, the operation on it.
That’s why it’s not part of the data type. That’s why with addition, you have a different identity from multiplication. It’s about the property. Additions identity is zero, and multiplications identity is one. It’s not a property of numbers or integers or anything like that.
What’s cool about this is when you’re coding, making new functions, you can make an identity value. You could either start with an existing data structure that already has an identity and reuse that, or you can make a value that represents this place to start.
When I say, “Start,” that’s what you would initialize your variables to start at. Just like you usually initialize a number to zero or you initialize an array to an empty array, you would initialize your new type that you’re making to this identity value.
The reason you might want</itunes:summary>
      <itunes:subtitle>Some functions have identities, which are values that tell you where to start calculating. In this episode, we look at what identities are, some examples of them, and how you can use them in your own code.

Transcript
Eric Normand: Is a function’s iden</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do promises make async JavaScript better than callbacks?</title>
      <itunes:episode>90</itunes:episode>
      <podcast:episode>90</podcast:episode>
      <itunes:title>Why do promises make async JavaScript better than callbacks?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1726</guid>
      <link>https://share.transistor.fm/s/2b986af9</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-promises-make-async-javascript-better-than-callbacks/">https://lispcast.com/why-do-promises-make-async-javascript-better-than-callbacks/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-promises-make-async-javascript-better-than-callbacks/">https://lispcast.com/why-do-promises-make-async-javascript-better-than-callbacks/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 28 Mar 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2b986af9/8a6c6604.mp3" length="29739681" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>741</itunes:duration>
      <itunes:summary>Promises are more popular than ever. They make our code better than callbacks. But why? In this episode, I dive deep into why promises are better than callbacks, and it’s not just about indentation.</itunes:summary>
      <itunes:subtitle>Promises are more popular than ever. They make our code better than callbacks. But why? In this episode, I dive deep into why promises are better than callbacks, and it’s not just about indentation.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are first-class functions?</title>
      <itunes:episode>89</itunes:episode>
      <podcast:episode>89</podcast:episode>
      <itunes:title>What are first-class functions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1721</guid>
      <link>https://share.transistor.fm/s/7debe9d5</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-first-class-functions/">https://lispcast.com/what-are-first-class-functions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-first-class-functions/">https://lispcast.com/what-are-first-class-functions/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7debe9d5/1359bd3f.mp3" length="37031075" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>924</itunes:duration>
      <itunes:summary>First-class functions are functions that can be treated like any other value. You can pass them to functions as arguments, return them from functions, and save them in variables. In this episode, we talk about why they are important for functional programming and what features we require of them</itunes:summary>
      <itunes:subtitle>First-class functions are functions that can be treated like any other value. You can pass them to functions as arguments, return them from functions, and save them in variables. In this episode, we talk about why they are important for functional program</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Where to find time to learn functional programming?</title>
      <itunes:episode>88</itunes:episode>
      <podcast:episode>88</podcast:episode>
      <itunes:title>Where to find time to learn functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1717</guid>
      <link>https://share.transistor.fm/s/7d7843a5</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/where-to-find-time-to-learn-functional-programming/">https://lispcast.com/where-to-find-time-to-learn-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/where-to-find-time-to-learn-functional-programming/">https://lispcast.com/where-to-find-time-to-learn-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 21 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7d7843a5/e9e991a6.mp3" length="48884991" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1220</itunes:duration>
      <itunes:summary>It can be really hard to find time to learn a new language or new paradigm. How can you find the time you need? In this episode, I share 5 tips for setting yourself for success when you’re learning functional programming.</itunes:summary>
      <itunes:subtitle>It can be really hard to find time to learn a new language or new paradigm. How can you find the time you need? In this episode, I share 5 tips for setting yourself for success when you’re learning functional programming.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Do locks slow down your code?</title>
      <itunes:episode>87</itunes:episode>
      <podcast:episode>87</podcast:episode>
      <itunes:title>Do locks slow down your code?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1714</guid>
      <link>https://share.transistor.fm/s/fc611924</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-locks-slow-down-your-code/">https://lispcast.com/do-locks-slow-down-your-code/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/do-locks-slow-down-your-code/">https://lispcast.com/do-locks-slow-down-your-code/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 18 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fc611924/4b76b67a.mp3" length="51749599" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1291</itunes:duration>
      <itunes:summary>Yes. Locks slow down your code. But they enable your code to be correct! It’s a tradeoff, but who would ever trade correctness for a little speed? In this episode, we look at the tradeoff, how to make locks less of a speed tradeoff, and some alternatives.</itunes:summary>
      <itunes:subtitle>Yes. Locks slow down your code. But they enable your code to be correct! It’s a tradeoff, but who would ever trade correctness for a little speed? In this episode, we look at the tradeoff, how to make locks less of a speed tradeoff, and some alternatives.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is idempotence?</title>
      <itunes:episode>86</itunes:episode>
      <podcast:episode>86</podcast:episode>
      <itunes:title>What is idempotence?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1711</guid>
      <link>https://share.transistor.fm/s/ec8f6555</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-idempotence/">https://lispcast.com/what-is-idempotence/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-idempotence/">https://lispcast.com/what-is-idempotence/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 14 Mar 2019 05:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ec8f6555/0dc71d0b.mp3" length="36305113" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>905</itunes:duration>
      <itunes:summary>Idempotence means duplicates don’t matter. It means you can safely retry an operation with no issues. The classic example is the elevator button: you press it twice and it does not call two elevators. We explore why we would want that property in an email server.</itunes:summary>
      <itunes:subtitle>Idempotence means duplicates don’t matter. It means you can safely retry an operation with no issues. The classic example is the elevator button: you press it twice and it does not call two elevators. We explore why we would want that property in an email</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is commutativity and why is it so useful in distributed systems?</title>
      <itunes:episode>85</itunes:episode>
      <podcast:episode>85</podcast:episode>
      <itunes:title>What is commutativity and why is it so useful in distributed systems?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1704</guid>
      <link>https://share.transistor.fm/s/f04c9514</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-commutativity-and-why-is-it-so-useful-in-distributed-systems/">https://lispcast.com/what-is-commutativity-and-why-is-it-so-useful-in-distributed-systems/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-commutativity-and-why-is-it-so-useful-in-distributed-systems/">https://lispcast.com/what-is-commutativity-and-why-is-it-so-useful-in-distributed-systems/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f04c9514/7b2f9943.mp3" length="52473543" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1310</itunes:duration>
      <itunes:summary>Commutativity is an algebraic property that means that order doesn’t matter. Because network messages arrive out of order, it’s the perfect property for distributed systems. In this episode, you’ll learn what it is (with some real world examples), why it’s useful, and 3 ways you can make an existing operation commutative.</itunes:summary>
      <itunes:subtitle>Commutativity is an algebraic property that means that order doesn’t matter. Because network messages arrive out of order, it’s the perfect property for distributed systems. In this episode, you’ll learn what it is (with some real world examples), why it’</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is associativity and why is it useful in parallel programming?</title>
      <itunes:episode>84</itunes:episode>
      <podcast:episode>84</podcast:episode>
      <itunes:title>What is associativity and why is it useful in parallel programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1702</guid>
      <link>https://share.transistor.fm/s/6a733ffb</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-associativity-and-why-is-it-useful-in-parallel-programming/">https://lispcast.com/what-is-associativity-and-why-is-it-useful-in-parallel-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-associativity-and-why-is-it-useful-in-parallel-programming/">https://lispcast.com/what-is-associativity-and-why-is-it-useful-in-parallel-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 07 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/6a733ffb/dededf8e.mp3" length="51580703" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1287</itunes:duration>
      <itunes:summary>Associativity is an algebraic property that enables us to easily break up a job into smaller jobs, do the jobs, then recombine the results. Associativity is the essence of composition. In this video, we go over what associativity is, why we want to use it, when to use it, and 3 keys for making an operation associative.</itunes:summary>
      <itunes:subtitle>Associativity is an algebraic property that enables us to easily break up a job into smaller jobs, do the jobs, then recombine the results. Associativity is the essence of composition. In this video, we go over what associativity is, why we want to use it</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are timelines and what do they have to do with functional programming?</title>
      <itunes:episode>83</itunes:episode>
      <podcast:episode>83</podcast:episode>
      <itunes:title>What are timelines and what do they have to do with functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1686</guid>
      <link>https://share.transistor.fm/s/9742f7b0</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-timelines-and-what-do-they-have-to-do-with-functional-programming/">https://lispcast.com/what-are-timelines-and-what-do-they-have-to-do-with-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-timelines-and-what-do-they-have-to-do-with-functional-programming/">https://lispcast.com/what-are-timelines-and-what-do-they-have-to-do-with-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 04 Mar 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9742f7b0/1e0a59d7.mp3" length="61926795" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1546</itunes:duration>
      <itunes:summary>Timelines are a system I developed for modeling time in a distributed system. You will find timelines whenever you have multiple machines, multiple processes, multiple threads, or multiple async callback chains. Since virtually all software is distributed these days, modeling time is more important than ever. Functional programming may not have all the answers, but it is asking the right questions. In this episode, we go over what timelines are and how you can start to use them to model time in your software.</itunes:summary>
      <itunes:subtitle>Timelines are a system I developed for modeling time in a distributed system. You will find timelines whenever you have multiple machines, multiple processes, multiple threads, or multiple async callback chains. Since virtually all software is distributed</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Cheap or free functional programming for your team</title>
      <itunes:episode>82</itunes:episode>
      <podcast:episode>82</podcast:episode>
      <itunes:title>Cheap or free functional programming for your team</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1681</guid>
      <link>https://share.transistor.fm/s/f82c12ec</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/cheap-or-free-functional-programming-for-your-team/">https://lispcast.com/cheap-or-free-functional-programming-for-your-team/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/cheap-or-free-functional-programming-for-your-team/">https://lispcast.com/cheap-or-free-functional-programming-for-your-team/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 28 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f82c12ec/d5a42fcb.mp3" length="51667969" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1289</itunes:duration>
      <itunes:summary>Hiring an on-site trainer can be expensive. But training itself doesn’t have to be expensive. In this episode, we go over 7 ways you can start training right away without breaking your budget.</itunes:summary>
      <itunes:subtitle>Hiring an on-site trainer can be expensive. But training itself doesn’t have to be expensive. In this episode, we go over 7 ways you can start training right away without breaking your budget.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is recursion and when should I use it?</title>
      <itunes:episode>81</itunes:episode>
      <podcast:episode>81</podcast:episode>
      <itunes:title>What is recursion and when should I use it?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/what-is-recursion-and-when-should-i-use-it/</guid>
      <link>https://share.transistor.fm/s/ffafb741</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-recursion-and-when-should-i-use-it/">https://lispcast.com/what-is-recursion-and-when-should-i-use-it/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-recursion-and-when-should-i-use-it/">https://lispcast.com/what-is-recursion-and-when-should-i-use-it/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ffafb741/0c22c55e.mp3" length="37387019" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>932</itunes:duration>
      <itunes:summary>Recursion is associated strongly with functional programming. We do use recursion more than imperative programmers do. But we also use iteration. In this episode, we talk about what recursion is, how to use it, when to use it, and when not to use it.</itunes:summary>
      <itunes:subtitle>Recursion is associated strongly with functional programming. We do use recursion more than imperative programmers do. But we also use iteration. In this episode, we talk about what recursion is, how to use it, when to use it, and when not to use it.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are side-effects?</title>
      <itunes:episode>80</itunes:episode>
      <podcast:episode>80</podcast:episode>
      <itunes:title>What are side-effects?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1675</guid>
      <link>https://share.transistor.fm/s/4c279dcf</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-side-effects/">https://lispcast.com/what-are-side-effects/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-side-effects/">https://lispcast.com/what-are-side-effects/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 21 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/4c279dcf/2dbce257.mp3" length="17881815" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>445</itunes:duration>
      <itunes:summary>In functional programming, people often use the term side-effect. But what does it mean? Side-effect is any external effect a function has besides its return value.</itunes:summary>
      <itunes:subtitle>In functional programming, people often use the term side-effect. But what does it mean? Side-effect is any external effect a function has besides its return value.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are concurrency and parallelism?</title>
      <itunes:episode>79</itunes:episode>
      <podcast:episode>79</podcast:episode>
      <itunes:title>What are concurrency and parallelism?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1671</guid>
      <link>https://share.transistor.fm/s/19e761e1</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-concurrency-and-parallelism/">https://lispcast.com/what-are-concurrency-and-parallelism/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-concurrency-and-parallelism/">https://lispcast.com/what-are-concurrency-and-parallelism/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 18 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/19e761e1/8a13208c.mp3" length="26467685" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>659</itunes:duration>
      <itunes:summary>What are concurrency and parallelism? What’s the difference? Concurrency is functional programming’s killer app. As we write more and more distributed systems on the web and on mobile, the sharing of resources becomes a major source of complexity in our software. We must learn to share these resources safely and efficiently. That’s what concurrency is all about.</itunes:summary>
      <itunes:subtitle>What are concurrency and parallelism? What’s the difference? Concurrency is functional programming’s killer app. As we write more and more distributed systems on the web and on mobile, the sharing of resources becomes a major source of complexity in our s</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are race conditions?</title>
      <itunes:episode>78</itunes:episode>
      <podcast:episode>78</podcast:episode>
      <itunes:title>What are race conditions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1667</guid>
      <link>https://share.transistor.fm/s/a78995ce</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-race-conditions/">https://lispcast.com/what-are-race-conditions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-race-conditions/">https://lispcast.com/what-are-race-conditions/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 14 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a78995ce/3d890dbf.mp3" length="27995585" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>698</itunes:duration>
      <itunes:summary>What is a race condition? We look at what causes race conditions and some ways you can avoid them.</itunes:summary>
      <itunes:subtitle>What is a race condition? We look at what causes race conditions and some ways you can avoid them.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What are pure functions?</title>
      <itunes:episode>77</itunes:episode>
      <podcast:episode>77</podcast:episode>
      <itunes:title>What are pure functions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1665</guid>
      <link>https://share.transistor.fm/s/205f7274</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-pure-functions/">https://lispcast.com/what-are-pure-functions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-are-pure-functions/">https://lispcast.com/what-are-pure-functions/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/205f7274/2d5afe2b.mp3" length="28347711" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>706</itunes:duration>
      <itunes:summary>What are pure functions? I explore the definition, the term itself, and why functional programmers like pure functions.</itunes:summary>
      <itunes:subtitle>What are pure functions? I explore the definition, the term itself, and why functional programmers like pure functions.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How to apply the Onion Architecture</title>
      <itunes:episode>76</itunes:episode>
      <podcast:episode>76</podcast:episode>
      <itunes:title>How to apply the Onion Architecture</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1658</guid>
      <link>https://share.transistor.fm/s/72f728ac</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-apply-the-onion-architecture/">https://lispcast.com/how-to-apply-the-onion-architecture/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-apply-the-onion-architecture/">https://lispcast.com/how-to-apply-the-onion-architecture/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 07 Feb 2019 00:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/72f728ac/d1e165fe.mp3" length="39946055" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>996</itunes:duration>
      <itunes:summary>I got a lot of questions about how to apply the Onion Architecture to particular situations. In this episode, I try to answer it with a specific example.</itunes:summary>
      <itunes:subtitle>I got a lot of questions about how to apply the Onion Architecture to particular situations. In this episode, I try to answer it with a specific example.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do you create a semantic base layer?</title>
      <itunes:episode>75</itunes:episode>
      <podcast:episode>75</podcast:episode>
      <itunes:title>How do you create a semantic base layer?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1589</guid>
      <link>https://share.transistor.fm/s/bf1adb91</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-create-a-semantic-base-layer/">https://lispcast.com/how-do-you-create-a-semantic-base-layer/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-you-create-a-semantic-base-layer/">https://lispcast.com/how-do-you-create-a-semantic-base-layer/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 06 Dec 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bf1adb91/c4dc8f71.mp3" length="14177141" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1763</itunes:duration>
      <itunes:summary>In stratified design, we are looking for layers of meaning, each one implemented on top of the last. But how do you go about building those in an existing codebase? While it remains more of an exploration than a step-by-step method, we can still describe some techniques that help find them. In this episode, I talk about four of them.</itunes:summary>
      <itunes:subtitle>In stratified design, we are looking for layers of meaning, each one implemented on top of the last. But how do you go about building those in an existing codebase? While it remains more of an exploration than a step-by-step method, we can still describe </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Tension between data and entity</title>
      <itunes:episode>74</itunes:episode>
      <podcast:episode>74</podcast:episode>
      <itunes:title>Tension between data and entity</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1587</guid>
      <link>https://share.transistor.fm/s/7287d9fe</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/tension-between-data-and-entity/">https://lispcast.com/tension-between-data-and-entity/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/tension-between-data-and-entity/">https://lispcast.com/tension-between-data-and-entity/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Dec 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/7287d9fe/ec0200cc.mp3" length="13699125" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>851</itunes:duration>
      <itunes:summary>There is always a tension in our programs between raw data and meaningful information. On the one hand, data is meaningless alone. On the other, we want to treat it as a thing with real semantics that constrain its usage. How do we live with both of these at the same time?</itunes:summary>
      <itunes:subtitle>There is always a tension in our programs between raw data and meaningful information. On the one hand, data is meaningless alone. On the other, we want to treat it as a thing with real semantics that constrain its usage. How do we live with both of these</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is React functional programming?</title>
      <itunes:episode>73</itunes:episode>
      <podcast:episode>73</podcast:episode>
      <itunes:title>Is React functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/is-react-functional-programming/</guid>
      <link>https://share.transistor.fm/s/5bde7dca</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-react-functional-programming/">https://lispcast.com/is-react-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-react-functional-programming/">https://lispcast.com/is-react-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 29 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5bde7dca/3a1ce034.mp3" length="16624501" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1034</itunes:duration>
      <itunes:summary>Even though React modifies the DOM, it is considered functional programming. It’s not strictly functional, but it is easy to reason about because the DOM is its only output. FP concepts can help us understand React.</itunes:summary>
      <itunes:subtitle>Even though React modifies the DOM, it is considered functional programming. It’s not strictly functional, but it is easy to reason about because the DOM is its only output. FP concepts can help us understand React.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Event Sourcing?</title>
      <itunes:episode>72</itunes:episode>
      <podcast:episode>72</podcast:episode>
      <itunes:title>What is Event Sourcing?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1575</guid>
      <link>https://share.transistor.fm/s/45a4fd30</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-event-sourcing/">https://lispcast.com/what-is-event-sourcing/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-event-sourcing/">https://lispcast.com/what-is-event-sourcing/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 26 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/45a4fd30/c1ed0529.mp3" length="13442363" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>835</itunes:duration>
      <itunes:summary>Event Sourcing is an architectural pattern that shows up in many mature information systems. This is the fourth in my three-part architecture series.</itunes:summary>
      <itunes:subtitle>Event Sourcing is an architectural pattern that shows up in many mature information systems. This is the fourth in my three-part architecture series.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is there always a way to implement an algorithm without mutable state?</title>
      <itunes:episode>71</itunes:episode>
      <podcast:episode>71</podcast:episode>
      <itunes:title>Is there always a way to implement an algorithm without mutable state?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1572</guid>
      <link>https://share.transistor.fm/s/ab8f5c28</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-always-a-way-to-implement-an-algorithm-without-mutable-state/">https://lispcast.com/is-there-always-a-way-to-implement-an-algorithm-without-mutable-state/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-there-always-a-way-to-implement-an-algorithm-without-mutable-state/">https://lispcast.com/is-there-always-a-way-to-implement-an-algorithm-without-mutable-state/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 22 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ab8f5c28/5708d9be.mp3" length="6491957" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>802</itunes:duration>
      <itunes:summary>It’s tempting to use mutable state in your algorithm. It’s so convenient! And we’re so used to it, if we come from an imperative paradigm. But we must remember that there is always a way, even if it’s not immediately obvious. I go over two ways to implement an algorithm without mutable state.</itunes:summary>
      <itunes:subtitle>It’s tempting to use mutable state in your algorithm. It’s so convenient! And we’re so used to it, if we come from an imperative paradigm. But we must remember that there is always a way, even if it’s not immediately obvious. I go over two ways to impleme</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the universal process pattern?</title>
      <itunes:episode>70</itunes:episode>
      <podcast:episode>70</podcast:episode>
      <itunes:title>What is the universal process pattern?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1566</guid>
      <link>https://share.transistor.fm/s/eac049e4</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-universal-process-pattern/">https://lispcast.com/what-is-the-universal-process-pattern/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-universal-process-pattern/">https://lispcast.com/what-is-the-universal-process-pattern/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 19 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/eac049e4/3cda99bf.mp3" length="3383533" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>414</itunes:duration>
      <itunes:summary>Part 3 of the functional architecture series. The universal process pattern is a schematic representation of software. For a software process to be useful, it needs input, it needs to calculate something from that input, and it needs to have some output or effect on the world.</itunes:summary>
      <itunes:subtitle>Part 3 of the functional architecture series. The universal process pattern is a schematic representation of software. For a software process to be useful, it needs input, it needs to calculate something from that input, and it needs to have some output o</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the onion architecture?</title>
      <itunes:episode>69</itunes:episode>
      <podcast:episode>69</podcast:episode>
      <itunes:title>What is the onion architecture?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1564</guid>
      <link>https://share.transistor.fm/s/fbaa3769</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-onion-architecture/">https://lispcast.com/what-is-the-onion-architecture/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-onion-architecture/">https://lispcast.com/what-is-the-onion-architecture/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 15 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fbaa3769/863aa3f9.mp3" length="6781929" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>839</itunes:duration>
      <itunes:summary>Part 2 of the functional architecture series. When we’re structuring our functional software, we want to isolate the actions from the calculations. We can do that using the Onion Architecture, which has layers like an onion. The center of the onion is your domain model, then around that are your business rules. Finally, around that is your interaction layer, which talks with the outside world, including the database, web requests, api endpoints, and the UI.</itunes:summary>
      <itunes:subtitle>Part 2 of the functional architecture series. When we’re structuring our functional software, we want to isolate the actions from the calculations. We can do that using the Onion Architecture, which has layers like an onion. The center of the onion is you</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>More about Stratified Design</title>
      <itunes:episode>68</itunes:episode>
      <podcast:episode>68</podcast:episode>
      <itunes:title>More about Stratified Design</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1562</guid>
      <link>https://share.transistor.fm/s/8f33a0ce</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/more-about-stratified-design/">https://lispcast.com/more-about-stratified-design/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/more-about-stratified-design/">https://lispcast.com/more-about-stratified-design/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 12 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/8f33a0ce/13a9b942.mp3" length="7135589" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>883</itunes:duration>
      <itunes:summary>Part 1 in the Functional architecture series. The Stratified Design, which I called “layered design” before, is a way of architecting your code as a series of layers of meaning. It’s a common way of organizing your code and structuring your application.</itunes:summary>
      <itunes:subtitle>Part 1 in the Functional architecture series. The Stratified Design, which I called “layered design” before, is a way of architecting your code as a series of layers of meaning. It’s a common way of organizing your code and structuring your application.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why is functional programming gaining traction? Why now?</title>
      <itunes:episode>67</itunes:episode>
      <podcast:episode>67</podcast:episode>
      <itunes:title>Why is functional programming gaining traction? Why now?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1559</guid>
      <link>https://share.transistor.fm/s/49da6875</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-functional-programming-gaining-traction-why-now/">https://lispcast.com/why-is-functional-programming-gaining-traction-why-now/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-functional-programming-gaining-traction-why-now/">https://lispcast.com/why-is-functional-programming-gaining-traction-why-now/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 08 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/49da6875/80ae172b.mp3" length="15874549" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>987</itunes:duration>
      <itunes:summary>The biggest companies in the world are investing heavily in functional programming. From Facebook building React and Reason, to Apple pivoting to Swift, to Google developing MapReduce, functional programming is gaining traction. But why? I go over four hypotheses and evaluate them.</itunes:summary>
      <itunes:subtitle>The biggest companies in the world are investing heavily in functional programming. From Facebook building React and Reason, to Apple pivoting to Swift, to Google developing MapReduce, functional programming is gaining traction. But why? I go over four hy</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Some thoughts on map, filter, and reduce</title>
      <itunes:episode>66</itunes:episode>
      <podcast:episode>66</podcast:episode>
      <itunes:title>Some thoughts on map, filter, and reduce</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1540</guid>
      <link>https://share.transistor.fm/s/ff165576</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/some-thoughts-on-map-filter-and-reduce/">https://lispcast.com/some-thoughts-on-map-filter-and-reduce/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/some-thoughts-on-map-filter-and-reduce/">https://lispcast.com/some-thoughts-on-map-filter-and-reduce/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 05 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ff165576/aab484bd.mp3" length="6517013" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>805</itunes:duration>
      <itunes:summary>Are map, filter, and reduce popular for a reason? Do these things capture some essence of iteration? Are they just better for loops?</itunes:summary>
      <itunes:subtitle>Are map, filter, and reduce popular for a reason? Do these things capture some essence of iteration? Are they just better for loops?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What do functional programmers think of the class inheritance hierarchy?</title>
      <itunes:episode>65</itunes:episode>
      <podcast:episode>65</podcast:episode>
      <itunes:title>What do functional programmers think of the class inheritance hierarchy?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1538</guid>
      <link>https://share.transistor.fm/s/2d09b429</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-do-functional-programmers-think-of-the-class-inheritance-hierarchy/">https://lispcast.com/what-do-functional-programmers-think-of-the-class-inheritance-hierarchy/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-do-functional-programmers-think-of-the-class-inheritance-hierarchy/">https://lispcast.com/what-do-functional-programmers-think-of-the-class-inheritance-hierarchy/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 01 Nov 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2d09b429/2ba95e60.mp3" length="4844385" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>596</itunes:duration>
      <itunes:summary>When a functional programmers looks at the typical OOP examples that show the inheritance hierarchy, they see something weird: why is one possible field plucked out to become the class? And why make it static?</itunes:summary>
      <itunes:subtitle>When a functional programmers looks at the typical OOP examples that show the inheritance hierarchy, they see something weird: why is one possible field plucked out to become the class? And why make it static?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do functional programmers focus on time?</title>
      <itunes:episode>64</itunes:episode>
      <podcast:episode>64</podcast:episode>
      <itunes:title>Why do functional programmers focus on time?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1536</guid>
      <link>https://share.transistor.fm/s/564f6ac7</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-functional-programmers-focus-on-time/">https://lispcast.com/why-do-functional-programmers-focus-on-time/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-functional-programmers-focus-on-time/">https://lispcast.com/why-do-functional-programmers-focus-on-time/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 29 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/564f6ac7/9b4301ae.mp3" length="9079225" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1126</itunes:duration>
      <itunes:summary>It turns out that in distributed and parallel systems, time plays a huge role. I think that’s why fp is booming these days: all web sites are distributed systems. And web developers are facing all the irreducible problems of distributed systems, and they’re turning to fp for answers.</itunes:summary>
      <itunes:subtitle>It turns out that in distributed and parallel systems, time plays a huge role. I think that’s why fp is booming these days: all web sites are distributed systems. And web developers are facing all the irreducible problems of distributed systems, and they’</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is “to reify” in software?</title>
      <itunes:episode>63</itunes:episode>
      <podcast:episode>63</podcast:episode>
      <itunes:title>What is “to reify” in software?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1534</guid>
      <link>https://share.transistor.fm/s/ea025227</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-to-reify-in-software/">https://lispcast.com/what-is-to-reify-in-software/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-to-reify-in-software/">https://lispcast.com/what-is-to-reify-in-software/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 25 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ea025227/48ac4415.mp3" length="3265451" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>399</itunes:duration>
      <itunes:summary>To reify” means “to make real”. It’s an old concept from philosophy. When you name a concept, you can start talking about it. We do something similar in programming. When you take a concept and make it first class, you can begin to manipulate it with the normal programming constructs.</itunes:summary>
      <itunes:subtitle>To reify” means “to make real”. It’s an old concept from philosophy. When you name a concept, you can start talking about it. We do something similar in programming. When you take a concept and make it first class, you can begin to manipulate it with the </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do functional programmers model things as data?</title>
      <itunes:episode>62</itunes:episode>
      <podcast:episode>62</podcast:episode>
      <itunes:title>Why do functional programmers model things as data?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1520</guid>
      <link>https://share.transistor.fm/s/11f98f47</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-functional-programmers-model-things-as-data/">https://lispcast.com/why-do-functional-programmers-model-things-as-data/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-functional-programmers-model-things-as-data/">https://lispcast.com/why-do-functional-programmers-model-things-as-data/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 22 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/11f98f47/525da582.mp3" length="7023471" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>869</itunes:duration>
      <itunes:summary>Functional programmers tend to prefer pure, immutable data to represent their domain. We talk about many of the benefits of such an approach. But we focus on one in particular: that good data representations can reduce complexity by reducing the number of if statements you need.</itunes:summary>
      <itunes:subtitle>Functional programmers tend to prefer pure, immutable data to represent their domain. We talk about many of the benefits of such an approach. But we focus on one in particular: that good data representations can reduce complexity by reducing the number of</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Sources of complexity in software</title>
      <itunes:episode>61</itunes:episode>
      <podcast:episode>61</podcast:episode>
      <itunes:title>Sources of complexity in software</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1518</guid>
      <link>https://share.transistor.fm/s/f06bc7cd</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/sources-of-complexity-in-software/">https://lispcast.com/sources-of-complexity-in-software/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/sources-of-complexity-in-software/">https://lispcast.com/sources-of-complexity-in-software/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 18 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f06bc7cd/d9da0186.mp3" length="6852795" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>847</itunes:duration>
      <itunes:summary>There are two sources of complexity in software: the complexity inherent in the domain (essential complexity) and the complexity we add as programmers due to the platform or due to bad programming practices (accidental complexity).</itunes:summary>
      <itunes:subtitle>There are two sources of complexity in software: the complexity inherent in the domain (essential complexity) and the complexity we add as programmers due to the platform or due to bad programming practices (accidental complexity).</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do we represent relationships in functional programming?</title>
      <itunes:episode>60</itunes:episode>
      <podcast:episode>60</podcast:episode>
      <itunes:title>How do we represent relationships in functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1486</guid>
      <link>https://share.transistor.fm/s/3a83953e</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-we-represent-relationships-in-functional-programming/">https://lispcast.com/how-do-we-represent-relationships-in-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-we-represent-relationships-in-functional-programming/">https://lispcast.com/how-do-we-represent-relationships-in-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 15 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3a83953e/8f1965d8.mp3" length="15114549" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>940</itunes:duration>
      <itunes:summary>Functional programmers tend to model important relationships using data, while OO programmers tend to represent them with references.</itunes:summary>
      <itunes:subtitle>Functional programmers tend to model important relationships using data, while OO programmers tend to represent them with references.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Single Responsibility Principle for Functional Programming</title>
      <itunes:episode>59</itunes:episode>
      <podcast:episode>59</podcast:episode>
      <itunes:title>Single Responsibility Principle for Functional Programming</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1483</guid>
      <link>https://share.transistor.fm/s/81a09502</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/single-responsibility-principle-for-functional-programming/">https://lispcast.com/single-responsibility-principle-for-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/single-responsibility-principle-for-functional-programming/">https://lispcast.com/single-responsibility-principle-for-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 11 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/81a09502/7b4ddffe.mp3" length="5342741" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>659</itunes:duration>
      <itunes:summary>How do functional programmers use the Single Responsibility Principle?</itunes:summary>
      <itunes:subtitle>How do functional programmers use the Single Responsibility Principle?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is a book a monad?</title>
      <itunes:episode>58</itunes:episode>
      <podcast:episode>58</podcast:episode>
      <itunes:title>How is a book a monad?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1482</guid>
      <link>https://share.transistor.fm/s/bee99995</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-a-book-a-monad/">https://lispcast.com/how-is-a-book-a-monad/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-a-book-a-monad/">https://lispcast.com/how-is-a-book-a-monad/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 08 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bee99995/a6597e3c.mp3" length="4263715" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>524</itunes:duration>
      <itunes:summary>This ain’t no “a monad is a burrito” talk. This is a real-world monad, found in the wild. We look at how reading a book is monadic. It’s what lets you see a list of lines of words as a single stream of words.</itunes:summary>
      <itunes:subtitle>This ain’t no “a monad is a burrito” talk. This is a real-world monad, found in the wild. We look at how reading a book is monadic. It’s what lets you see a list of lines of words as a single stream of words.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Layered design in functional programming</title>
      <itunes:episode>57</itunes:episode>
      <podcast:episode>57</podcast:episode>
      <itunes:title>Layered design in functional programming</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1481</guid>
      <link>https://share.transistor.fm/s/c530f535</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/layered-design-in-functional-programming/">https://lispcast.com/layered-design-in-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/layered-design-in-functional-programming/">https://lispcast.com/layered-design-in-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 04 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c530f535/1c5ac475.mp3" length="3405857" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>417</itunes:duration>
      <itunes:summary>Functional programmers often talk about creating layered designs, where each layer represents a coherent level of abstraction. It’s a way to organize your code.</itunes:summary>
      <itunes:subtitle>Functional programmers often talk about creating layered designs, where each layer represents a coherent level of abstraction. It’s a way to organize your code.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Keeping functional code organized</title>
      <itunes:episode>56</itunes:episode>
      <podcast:episode>56</podcast:episode>
      <itunes:title>Keeping functional code organized</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1480</guid>
      <link>https://share.transistor.fm/s/92555180</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/keeping-functional-code-organized/">https://lispcast.com/keeping-functional-code-organized/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/keeping-functional-code-organized/">https://lispcast.com/keeping-functional-code-organized/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 01 Oct 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/92555180/784611a7.mp3" length="4323687" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>531</itunes:duration>
      <itunes:summary>People ask me how to keep functional code organized. It’s a good question but my answer is so simple, it feels kind of silly saying it: I keep everything in one file, and split it up as it grows.</itunes:summary>
      <itunes:subtitle>People ask me how to keep functional code organized. It’s a good question but my answer is so simple, it feels kind of silly saying it: I keep everything in one file, and split it up as it grows.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is software design?</title>
      <itunes:episode>55</itunes:episode>
      <podcast:episode>55</podcast:episode>
      <itunes:title>What is software design?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1466</guid>
      <link>https://share.transistor.fm/s/fd4da51f</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-design/">https://lispcast.com/what-is-software-design/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-software-design/">https://lispcast.com/what-is-software-design/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 27 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fd4da51f/9b1102ce.mp3" length="11177745" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>694</itunes:duration>
      <itunes:summary>Does the term “design” make sense in the context of code? I discuss Sandi Metz’s definition from her book Practical Object Oriented Design in Ruby.</itunes:summary>
      <itunes:subtitle>Does the term “design” make sense in the context of code? I discuss Sandi Metz’s definition from her book Practical Object Oriented Design in Ruby.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How to create a habit of reuse</title>
      <itunes:episode>54</itunes:episode>
      <podcast:episode>54</podcast:episode>
      <itunes:title>How to create a habit of reuse</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1452</guid>
      <link>https://share.transistor.fm/s/e1c4198c</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-create-a-habit-of-reuse/">https://lispcast.com/how-to-create-a-habit-of-reuse/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-to-create-a-habit-of-reuse/">https://lispcast.com/how-to-create-a-habit-of-reuse/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 24 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e1c4198c/b40e1c81.mp3" length="11500725" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>714</itunes:duration>
      <itunes:summary>In OO languages like Java, people tend to make new classes more than they reuse existing ones. In Clojure and other FP languages, we tend more on the side of reuse. How do we develop that habit?</itunes:summary>
      <itunes:subtitle>In OO languages like Java, people tend to make new classes more than they reuse existing ones. In Clojure and other FP languages, we tend more on the side of reuse. How do we develop that habit?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The easiest way to make your existing code more functional</title>
      <itunes:episode>53</itunes:episode>
      <podcast:episode>53</podcast:episode>
      <itunes:title>The easiest way to make your existing code more functional</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1451</guid>
      <link>https://share.transistor.fm/s/ff943670</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-easiest-way-to-make-your-existing-code-more-functional/">https://lispcast.com/the-easiest-way-to-make-your-existing-code-more-functional/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-easiest-way-to-make-your-existing-code-more-functional/">https://lispcast.com/the-easiest-way-to-make-your-existing-code-more-functional/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 20 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ff943670/fb8798ff.mp3" length="4549613" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>280</itunes:duration>
      <itunes:summary>What is the easiest way to make an existing functions more functional? It’s quite a simple technique and you can apply it today.</itunes:summary>
      <itunes:subtitle>What is the easiest way to make an existing functions more functional? It’s quite a simple technique and you can apply it today.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How does FP achieve reuse?</title>
      <itunes:episode>52</itunes:episode>
      <podcast:episode>52</podcast:episode>
      <itunes:title>How does FP achieve reuse?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1450</guid>
      <link>https://share.transistor.fm/s/819e41d0</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-does-fp-achieve-reuse/">https://lispcast.com/how-does-fp-achieve-reuse/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-does-fp-achieve-reuse/">https://lispcast.com/how-does-fp-achieve-reuse/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 17 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/819e41d0/8eb83213.mp3" length="8825977" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>547</itunes:duration>
      <itunes:summary>Functional programming gets its reuse by creating small components that are very well-defined. Small means they’re probably generally useful (like lists). Well-defined means they are easy to build on top of.</itunes:summary>
      <itunes:subtitle>Functional programming gets its reuse by creating small components that are very well-defined. Small means they’re probably generally useful (like lists). Well-defined means they are easy to build on top of.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why are actions hard to test by definition?</title>
      <itunes:episode>51</itunes:episode>
      <podcast:episode>51</podcast:episode>
      <itunes:title>Why are actions hard to test by definition?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1424</guid>
      <link>https://share.transistor.fm/s/340b1937</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-actions-hard-to-test-by-definition/">https://lispcast.com/why-are-actions-hard-to-test-by-definition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-actions-hard-to-test-by-definition/">https://lispcast.com/why-are-actions-hard-to-test-by-definition/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 13 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/340b1937/cf1cd9a5.mp3" length="10274843" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>637</itunes:duration>
      <itunes:summary>Functional programming divides the world into actions, calculations, and data. Actions are hard to test by definition, and we explore why.</itunes:summary>
      <itunes:subtitle>Functional programming divides the world into actions, calculations, and data. Actions are hard to test by definition, and we explore why.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How do things compose across domains?</title>
      <itunes:episode>50</itunes:episode>
      <podcast:episode>50</podcast:episode>
      <itunes:title>How do things compose across domains?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1421</guid>
      <link>https://share.transistor.fm/s/9c6efefd</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-things-compose-across-domains/">https://lispcast.com/how-do-things-compose-across-domains/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-do-things-compose-across-domains/">https://lispcast.com/how-do-things-compose-across-domains/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 10 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/9c6efefd/5f04f027.mp3" length="7895567" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>489</itunes:duration>
      <itunes:summary>A few episodes ago I talked about how things compose. But I didn’t get into how things compose across domains. For instance, how do actions compose with calculations? Let’s get into that, and what it reveals about our work as functional programmers.</itunes:summary>
      <itunes:subtitle>A few episodes ago I talked about how things compose. But I didn’t get into how things compose across domains. For instance, how do actions compose with calculations? Let’s get into that, and what it reveals about our work as functional programmers.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is functional programming declarative?</title>
      <itunes:episode>49</itunes:episode>
      <podcast:episode>49</podcast:episode>
      <itunes:title>Is functional programming declarative?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1420</guid>
      <link>https://share.transistor.fm/s/2e57699e</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-functional-programming-declarative/">https://lispcast.com/is-functional-programming-declarative/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-functional-programming-declarative/">https://lispcast.com/is-functional-programming-declarative/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 06 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2e57699e/c96707a5.mp3" length="7861537" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>973</itunes:duration>
      <itunes:summary>People often say that functional programming is a “declarative paradigm”. I push back against that categorization. I simply think the word is mostly meaningless.</itunes:summary>
      <itunes:subtitle>People often say that functional programming is a “declarative paradigm”. I push back against that categorization. I simply think the word is mostly meaningless.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How can you work with a JSON value if you know nothing about it?</title>
      <itunes:episode>48</itunes:episode>
      <podcast:episode>48</podcast:episode>
      <itunes:title>How can you work with a JSON value if you know nothing about it?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1411</guid>
      <link>https://share.transistor.fm/s/266e5f71</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-can-you-work-with-a-json-value-if-you-know-nothing-about-it/">https://lispcast.com/how-can-you-work-with-a-json-value-if-you-know-nothing-about-it/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-can-you-work-with-a-json-value-if-you-know-nothing-about-it/">https://lispcast.com/how-can-you-work-with-a-json-value-if-you-know-nothing-about-it/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 03 Sep 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/266e5f71/acdb0cb1.mp3" length="15877205" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>987</itunes:duration>
      <itunes:summary>I have talked about the difficulty of typing certain JSON values coming from some APIs. The JSON is just very complicated. When I do that, I often get this question “how can you work with a JSON value if you know nothing about it?” The question is rhetorical. Of course you can’t do anything if you know nothing about it. But we do know a ton! We just can’t (or it’s very difficult to) encode what we know as a type.</itunes:summary>
      <itunes:subtitle>I have talked about the difficulty of typing certain JSON values coming from some APIs. The JSON is just very complicated. When I do that, I often get this question “how can you work with a JSON value if you know nothing about it?” The question is rhetori</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is The Little Typer the static typing book I’ve been waiting for?</title>
      <itunes:episode>47</itunes:episode>
      <podcast:episode>47</podcast:episode>
      <itunes:title>Is The Little Typer the static typing book I’ve been waiting for?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1410</guid>
      <link>https://share.transistor.fm/s/f659e223</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-the-little-typer-the-static-typing-book-ive-been-waiting-for/">https://lispcast.com/is-the-little-typer-the-static-typing-book-ive-been-waiting-for/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-the-little-typer-the-static-typing-book-ive-been-waiting-for/">https://lispcast.com/is-the-little-typer-the-static-typing-book-ive-been-waiting-for/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 30 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f659e223/7a80ddcd.mp3" length="11082427" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>688</itunes:duration>
      <itunes:summary>Dan Friedman’s The Little Typer is coming out in September. I’m very excited about this book. It’s about dependent types, and it claims to “demonstrate the most beautiful aspects”. I can’t wait!</itunes:summary>
      <itunes:subtitle>Dan Friedman’s The Little Typer is coming out in September. I’m very excited about this book. It’s about dependent types, and it claims to “demonstrate the most beautiful aspects”. I can’t wait!</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Something I missed in Rich Hickey’s last keynote (Clojure/conj 2017)</title>
      <itunes:episode>46</itunes:episode>
      <podcast:episode>46</podcast:episode>
      <itunes:title>Something I missed in Rich Hickey’s last keynote (Clojure/conj 2017)</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1407</guid>
      <link>https://share.transistor.fm/s/d434ffca</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/something-i-missed-in-rich-hickeys-last-keynote-clojure-conj-2017/">https://lispcast.com/something-i-missed-in-rich-hickeys-last-keynote-clojure-conj-2017/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/something-i-missed-in-rich-hickeys-last-keynote-clojure-conj-2017/">https://lispcast.com/something-i-missed-in-rich-hickeys-last-keynote-clojure-conj-2017/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 27 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d434ffca/89443dc5.mp3" length="10764889" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>668</itunes:duration>
      <itunes:summary>I wrote my interpretation of Rich Hickey’s keynote. I called it “Clojure vs the Static Typing World”. However, I missed something very big. I missed that he talked about how common it was to have lots of sub-solutions and partial data. I expand on that idea here.</itunes:summary>
      <itunes:subtitle>I wrote my interpretation of Rich Hickey’s keynote. I called it “Clojure vs the Static Typing World”. However, I missed something very big. I missed that he talked about how common it was to have lots of sub-solutions and partial data. I expand on that id</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Are categories Design Patterns?</title>
      <itunes:episode>45</itunes:episode>
      <podcast:episode>45</podcast:episode>
      <itunes:title>Are categories Design Patterns?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1406</guid>
      <link>https://share.transistor.fm/s/f5834a47</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/are-categories-design-patterns/">https://lispcast.com/are-categories-design-patterns/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/are-categories-design-patterns/">https://lispcast.com/are-categories-design-patterns/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 23 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f5834a47/51ffb6cc.mp3" length="9689581" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>601</itunes:duration>
      <itunes:summary>People often ask ‘what are the design patterns of functional programming?’ A common answer is that categories from category theory, like monads and functors, are the design patterns. But is that true? I explore the consequences of that answer.</itunes:summary>
      <itunes:subtitle>People often ask ‘what are the design patterns of functional programming?’ A common answer is that categories from category theory, like monads and functors, are the design patterns. But is that true? I explore the consequences of that answer.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why is making something first-class the key to expressivity?</title>
      <itunes:episode>44</itunes:episode>
      <podcast:episode>44</podcast:episode>
      <itunes:title>Why is making something first-class the key to expressivity?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1401</guid>
      <link>https://share.transistor.fm/s/db562920</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-making-something-first-class-the-key-to-expressivity/">https://lispcast.com/why-is-making-something-first-class-the-key-to-expressivity/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-making-something-first-class-the-key-to-expressivity/">https://lispcast.com/why-is-making-something-first-class-the-key-to-expressivity/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 20 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/db562920/5022a643.mp3" length="8316943" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>515</itunes:duration>
      <itunes:summary>People often say that functional programming is more expressive. But how does FP achieve that? The key is by making things first-class.</itunes:summary>
      <itunes:subtitle>People often say that functional programming is more expressive. But how does FP achieve that? The key is by making things first-class.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How can pure functions represent state change?</title>
      <itunes:episode>43</itunes:episode>
      <podcast:episode>43</podcast:episode>
      <itunes:title>How can pure functions represent state change?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1400</guid>
      <link>https://share.transistor.fm/s/fcbda374</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-can-pure-functions-represent-state-change/">https://lispcast.com/how-can-pure-functions-represent-state-change/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-can-pure-functions-represent-state-change/">https://lispcast.com/how-can-pure-functions-represent-state-change/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 16 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/fcbda374/7e87189c.mp3" length="10189077" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>632</itunes:duration>
      <itunes:summary>Pure functions have no effect besides returning an immutable value. If that’s true, then how can we use them to represent changing state?</itunes:summary>
      <itunes:subtitle>Pure functions have no effect besides returning an immutable value. If that’s true, then how can we use them to represent changing state?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is callback hell?</title>
      <itunes:episode>42</itunes:episode>
      <podcast:episode>42</podcast:episode>
      <itunes:title>What is callback hell?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1395</guid>
      <link>https://share.transistor.fm/s/5414ac93</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-callback-hell/">https://lispcast.com/what-is-callback-hell/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-callback-hell/">https://lispcast.com/what-is-callback-hell/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 13 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/5414ac93/d41192bc.mp3" length="3953335" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>485</itunes:duration>
      <itunes:summary>JavaScript programmers talk a lot about callback hell. In this episode, we look at the phenomenon from a functional programming perspective.</itunes:summary>
      <itunes:subtitle>JavaScript programmers talk a lot about callback hell. In this episode, we look at the phenomenon from a functional programming perspective.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is a cook like functional programming?</title>
      <itunes:episode>41</itunes:episode>
      <podcast:episode>41</podcast:episode>
      <itunes:title>How is a cook like functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1394</guid>
      <link>https://share.transistor.fm/s/c5de37ed</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-a-cook-like-functional-programming/">https://lispcast.com/how-is-a-cook-like-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-a-cook-like-functional-programming/">https://lispcast.com/how-is-a-cook-like-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 09 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c5de37ed/ba78860f.mp3" length="2414307" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>293</itunes:duration>
      <itunes:summary>We look at a metaphor to explain the three domains in functional programming: actions, calculations, and data. I hope the metaphor makes some things clearer and can help people explain fp better to others.</itunes:summary>
      <itunes:subtitle>We look at a metaphor to explain the three domains in functional programming: actions, calculations, and data. I hope the metaphor makes some things clearer and can help people explain fp better to others.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the primary superpower of functional programmers?</title>
      <itunes:episode>40</itunes:episode>
      <podcast:episode>40</podcast:episode>
      <itunes:title>What is the primary superpower of functional programmers?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1385</guid>
      <link>https://share.transistor.fm/s/d7af11a6</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-primary-superpower-of-functional-programmers/">https://lispcast.com/what-is-the-primary-superpower-of-functional-programmers/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-primary-superpower-of-functional-programmers/">https://lispcast.com/what-is-the-primary-superpower-of-functional-programmers/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 06 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d7af11a6/1fce6301.mp3" length="2631587" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>320</itunes:duration>
      <itunes:summary>Is there something that functional programmers do that, without that, you couldn’t really call them a functional programmer? Is there a power that all other powers are dependent on?</itunes:summary>
      <itunes:subtitle>Is there something that functional programmers do that, without that, you couldn’t really call them a functional programmer? Is there a power that all other powers are dependent on?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Does functional programming have an answer for everything?</title>
      <itunes:episode>39</itunes:episode>
      <podcast:episode>39</podcast:episode>
      <itunes:title>Does functional programming have an answer for everything?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1384</guid>
      <link>https://share.transistor.fm/s/ff9885b8</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/does-functional-programming-have-an-answer-for-everything/">https://lispcast.com/does-functional-programming-have-an-answer-for-everything/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/does-functional-programming-have-an-answer-for-everything/">https://lispcast.com/does-functional-programming-have-an-answer-for-everything/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 02 Aug 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ff9885b8/613da42c.mp3" length="2141105" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>258</itunes:duration>
      <itunes:summary>Some might say that functional programming has the answers to solve the problems of concurrent, parallel, and distributed systems. But is that true? We explore what FP has to offer.</itunes:summary>
      <itunes:subtitle>Some might say that functional programming has the answers to solve the problems of concurrent, parallel, and distributed systems. But is that true? We explore what FP has to offer.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What does it mean to compose in functional programming?</title>
      <itunes:episode>38</itunes:episode>
      <podcast:episode>38</podcast:episode>
      <itunes:title>What does it mean to compose in functional programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1383</guid>
      <link>https://share.transistor.fm/s/421a07e7</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-to-compose-in-functional-programming/">https://lispcast.com/what-does-it-mean-to-compose-in-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-to-compose-in-functional-programming/">https://lispcast.com/what-does-it-mean-to-compose-in-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 30 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/421a07e7/bdd41f1b.mp3" length="7404323" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>458</itunes:duration>
      <itunes:summary>We talk a lot about composition, but what does it mean? Each domain (action, calculation, data) has its own way to compose. In this quick episode, I explain each one.</itunes:summary>
      <itunes:subtitle>We talk a lot about composition, but what does it mean? Each domain (action, calculation, data) has its own way to compose. In this quick episode, I explain each one.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Reduce complexity at every step</title>
      <itunes:episode>37</itunes:episode>
      <podcast:episode>37</podcast:episode>
      <itunes:title>Reduce complexity at every step</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1324</guid>
      <link>https://share.transistor.fm/s/bd63cc86</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/reduce-complexity-at-every-step/">https://lispcast.com/reduce-complexity-at-every-step/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/reduce-complexity-at-every-step/">https://lispcast.com/reduce-complexity-at-every-step/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 26 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bd63cc86/5071c14c.mp3" length="15520007" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>965</itunes:duration>
      <itunes:summary>Postel’s Law states that a program should be liberal in what it accepts and strict in what it sends. What does this have to do with functional programming? How can this help us reduce complexity?</itunes:summary>
      <itunes:subtitle>Postel’s Law states that a program should be liberal in what it accepts and strict in what it sends. What does this have to do with functional programming? How can this help us reduce complexity?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why is Functional Programming more expressive?</title>
      <itunes:episode>36</itunes:episode>
      <podcast:episode>36</podcast:episode>
      <itunes:title>Why is Functional Programming more expressive?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1321</guid>
      <link>https://share.transistor.fm/s/33691e50</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-functional-programming-more-expressive/">https://lispcast.com/why-is-functional-programming-more-expressive/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-is-functional-programming-more-expressive/">https://lispcast.com/why-is-functional-programming-more-expressive/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 23 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/33691e50/598459d6.mp3" length="2931437" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>357</itunes:duration>
      <itunes:summary>I explore the idea that Functional Programming is more expressive than Procedural Programming (and why it is) using a metaphor of a pizza master.</itunes:summary>
      <itunes:subtitle>I explore the idea that Functional Programming is more expressive than Procedural Programming (and why it is) using a metaphor of a pizza master.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is Immutability?</title>
      <itunes:episode>35</itunes:episode>
      <podcast:episode>35</podcast:episode>
      <itunes:title>What is Immutability?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1319</guid>
      <link>https://share.transistor.fm/s/22535790</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-immutability/">https://lispcast.com/what-is-immutability/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-immutability/">https://lispcast.com/what-is-immutability/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 19 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/22535790/744a3aa7.mp3" length="5956325" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>735</itunes:duration>
      <itunes:summary>Functional Programmers will talk about immutable values. What do they mean? How can you write software where none of the values change?</itunes:summary>
      <itunes:subtitle>Functional Programmers will talk about immutable values. What do they mean? How can you write software where none of the values change?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What does it mean for programs to be built using “whole values”?</title>
      <itunes:episode>34</itunes:episode>
      <podcast:episode>34</podcast:episode>
      <itunes:title>What does it mean for programs to be built using “whole values”?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1317</guid>
      <link>https://share.transistor.fm/s/e6365a5d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-programs-to-be-built-using-whole-values/">https://lispcast.com/what-does-it-mean-for-programs-to-be-built-using-whole-values/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-programs-to-be-built-using-whole-values/">https://lispcast.com/what-does-it-mean-for-programs-to-be-built-using-whole-values/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 16 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e6365a5d/468c992a.mp3" length="21688133" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1351</itunes:duration>
      <itunes:summary>John Hughes, FP researcher extraordinaire, says Whole Values is one of the principles of Functional Programming. But what does he mean? We explore this important concept.</itunes:summary>
      <itunes:subtitle>John Hughes, FP researcher extraordinaire, says Whole Values is one of the principles of Functional Programming. But what does he mean? We explore this important concept.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How is Functional Programming like grocery shopping?</title>
      <itunes:episode>33</itunes:episode>
      <podcast:episode>33</podcast:episode>
      <itunes:title>How is Functional Programming like grocery shopping?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1314</guid>
      <link>https://share.transistor.fm/s/88d26883</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-functional-programming-like-grocery-shopping/">https://lispcast.com/how-is-functional-programming-like-grocery-shopping/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-is-functional-programming-like-grocery-shopping/">https://lispcast.com/how-is-functional-programming-like-grocery-shopping/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 12 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/88d26883/9fb9c35d.mp3" length="9306269" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1154</itunes:duration>
      <itunes:summary>Our understanding of the real world has to be applicable to the software world. Our programming paradigms need to correspond to our intuitions of the real world.</itunes:summary>
      <itunes:subtitle>Our understanding of the real world has to be applicable to the software world. Our programming paradigms need to correspond to our intuitions of the real world.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Divide and conquer algorithms</title>
      <itunes:episode>32</itunes:episode>
      <podcast:episode>32</podcast:episode>
      <itunes:title>Divide and conquer algorithms</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1274</guid>
      <link>https://share.transistor.fm/s/747250f3</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/divide-and-conquer-algorithms/">https://lispcast.com/divide-and-conquer-algorithms/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/divide-and-conquer-algorithms/">https://lispcast.com/divide-and-conquer-algorithms/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 09 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/747250f3/54daf1a2.mp3" length="11376811" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>706</itunes:duration>
      <itunes:summary>The divide and conquer pattern is a widely used functional programming pattern. It lets you turn potentially hard problems into trivial problems and then recombine the answers.</itunes:summary>
      <itunes:subtitle>The divide and conquer pattern is a widely used functional programming pattern. It lets you turn potentially hard problems into trivial problems and then recombine the answers.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The #3 most important idea in Computer Science</title>
      <itunes:episode>31</itunes:episode>
      <podcast:episode>31</podcast:episode>
      <itunes:title>The #3 most important idea in Computer Science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1272</guid>
      <link>https://share.transistor.fm/s/37a0def7</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-3-most-important-idea-in-computer-science/">https://lispcast.com/the-3-most-important-idea-in-computer-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-3-most-important-idea-in-computer-science/">https://lispcast.com/the-3-most-important-idea-in-computer-science/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 05 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/37a0def7/14d01f62.mp3" length="5481415" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>338</itunes:duration>
      <itunes:summary>Well, this one is probably the most controversial. But I think the #3 most important idea has something to do with the problem of exponential growth of the number of possible states we can represent as we add bits to our system.</itunes:summary>
      <itunes:subtitle>Well, this one is probably the most controversial. But I think the #3 most important idea has something to do with the problem of exponential growth of the number of possible states we can represent as we add bits to our system.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The #2 most important idea in Computer Science</title>
      <itunes:episode>30</itunes:episode>
      <podcast:episode>30</podcast:episode>
      <itunes:title>The #2 most important idea in Computer Science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1271</guid>
      <link>https://share.transistor.fm/s/ed126fd7</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-2-most-important-idea-in-computer-science/">https://lispcast.com/the-2-most-important-idea-in-computer-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-2-most-important-idea-in-computer-science/">https://lispcast.com/the-2-most-important-idea-in-computer-science/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 02 Jul 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ed126fd7/592bb332.mp3" length="7087193" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>438</itunes:duration>
      <itunes:summary>In my opinion, the #2 most important idea is something that came directly out of computing. But I’m not so sure. Do you know? Let me know, too!</itunes:summary>
      <itunes:subtitle>In my opinion, the #2 most important idea is something that came directly out of computing. But I’m not so sure. Do you know? Let me know, too!</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What is the business value of Clojure?</title>
      <itunes:episode>29</itunes:episode>
      <podcast:episode>29</podcast:episode>
      <itunes:title>What is the business value of Clojure?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1270</guid>
      <link>https://share.transistor.fm/s/3f2d3c97</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-business-value-of-clojure/">https://lispcast.com/what-is-the-business-value-of-clojure/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-is-the-business-value-of-clojure/">https://lispcast.com/what-is-the-business-value-of-clojure/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 28 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3f2d3c97/205dfa37.mp3" length="13352969" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>830</itunes:duration>
      <itunes:summary>Is there some reason a business would choose Clojure over other languages? Let’s find out!</itunes:summary>
      <itunes:subtitle>Is there some reason a business would choose Clojure over other languages? Let’s find out!</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The #1 Most Important idea in Computer Science</title>
      <itunes:episode>28</itunes:episode>
      <podcast:episode>28</podcast:episode>
      <itunes:title>The #1 Most Important idea in Computer Science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1269</guid>
      <link>https://share.transistor.fm/s/3b43fe1d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-1-most-important-idea-in-computer-science/">https://lispcast.com/the-1-most-important-idea-in-computer-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/the-1-most-important-idea-in-computer-science/">https://lispcast.com/the-1-most-important-idea-in-computer-science/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 25 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3b43fe1d/30b5dda6.mp3" length="12129835" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>753</itunes:duration>
      <itunes:summary>The idea of the Universal Turing Machine is incredibly important. But does your language support both properties?</itunes:summary>
      <itunes:subtitle>The idea of the Universal Turing Machine is incredibly important. But does your language support both properties?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Is Smalltalk a Functional language? Is Lisp Object-Oriented?</title>
      <itunes:episode>27</itunes:episode>
      <podcast:episode>27</podcast:episode>
      <itunes:title>Is Smalltalk a Functional language? Is Lisp Object-Oriented?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1268</guid>
      <link>https://share.transistor.fm/s/ff2f5ce4</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/">https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/">https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 21 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ff2f5ce4/c642ae56.mp3" length="5803257" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>358</itunes:duration>
      <itunes:summary>Alan Kay says there are only 2 Object Oriented languages that he knows of: Smalltalk and Lisp. The deeper I go into the history of Smalltalk, the more functional Smalltalk looks.</itunes:summary>
      <itunes:subtitle>Alan Kay says there are only 2 Object Oriented languages that he knows of: Smalltalk and Lisp. The deeper I go into the history of Smalltalk, the more functional Smalltalk looks.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why do we need a Theory of Functional Programming?</title>
      <itunes:episode>26</itunes:episode>
      <podcast:episode>26</podcast:episode>
      <itunes:title>Why do we need a Theory of Functional Programming?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1267</guid>
      <link>https://share.transistor.fm/s/98a531d3</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-we-need-a-theory-of-functional-programming/">https://lispcast.com/why-do-we-need-a-theory-of-functional-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-do-we-need-a-theory-of-functional-programming/">https://lispcast.com/why-do-we-need-a-theory-of-functional-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 18 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/98a531d3/8894641c.mp3" length="10815529" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>671</itunes:duration>
      <itunes:summary>Though I have gotten good reception for the theory in general, a few people have asked me why we need a theory. More people have told me I’m complicating Functional Programming, which should be a simple idea.</itunes:summary>
      <itunes:subtitle>Though I have gotten good reception for the theory in general, a few people have asked me why we need a theory. More people have told me I’m complicating Functional Programming, which should be a simple idea.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>My big beef with refactoring</title>
      <itunes:episode>25</itunes:episode>
      <podcast:episode>25</podcast:episode>
      <itunes:title>My big beef with refactoring</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1265</guid>
      <link>https://share.transistor.fm/s/20ee5d0f</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/my-big-beef-with-refactoring/">https://lispcast.com/my-big-beef-with-refactoring/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/my-big-beef-with-refactoring/">https://lispcast.com/my-big-beef-with-refactoring/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 14 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/20ee5d0f/94669bb1.mp3" length="18831533" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1172</itunes:duration>
      <itunes:summary>I love refactoring. It’s therapeutic. It helps productivity. But refactoring is not enough to write good software. We can’t just write it so it works then clean it up. In this episode, I explain why.</itunes:summary>
      <itunes:subtitle>I love refactoring. It’s therapeutic. It helps productivity. But refactoring is not enough to write good software. We can’t just write it so it works then clean it up. In this episode, I explain why.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Build your Core Abstraction</title>
      <itunes:episode>24</itunes:episode>
      <podcast:episode>24</podcast:episode>
      <itunes:title>Build your Core Abstraction</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1264</guid>
      <link>https://share.transistor.fm/s/1c4f31a8</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/build-your-core-abstraction/">https://lispcast.com/build-your-core-abstraction/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/build-your-core-abstraction/">https://lispcast.com/build-your-core-abstraction/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 11 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/1c4f31a8/4145c2c8.mp3" length="6263725" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>774</itunes:duration>
      <itunes:summary>With limited development time, where should you focus your efforts? You should build something timeless at the center of you application to create a strong foundation to build on top of. I call that you Core Abstraction.</itunes:summary>
      <itunes:subtitle>With limited development time, where should you focus your efforts? You should build something timeless at the center of you application to create a strong foundation to build on top of. I call that you Core Abstraction.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Focus on composition first</title>
      <itunes:episode>23</itunes:episode>
      <podcast:episode>23</podcast:episode>
      <itunes:title>Focus on composition first</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1261</guid>
      <link>https://share.transistor.fm/s/157fe47d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/focus-on-composition-first/">https://lispcast.com/focus-on-composition-first/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/focus-on-composition-first/">https://lispcast.com/focus-on-composition-first/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 07 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/157fe47d/63c2c4f2.mp3" length="7904329" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>979</itunes:duration>
      <itunes:summary>Where should we start when we are designing out data structures–especially the data that we expect to last a long time. The answer is in the composition operations.</itunes:summary>
      <itunes:subtitle>Where should we start when we are designing out data structures–especially the data that we expect to last a long time. The answer is in the composition operations.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Build an interface around data</title>
      <itunes:episode>22</itunes:episode>
      <podcast:episode>22</podcast:episode>
      <itunes:title>Build an interface around data</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1260</guid>
      <link>https://share.transistor.fm/s/f178fc37</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/build-an-interface-around-data/">https://lispcast.com/build-an-interface-around-data/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/build-an-interface-around-data/">https://lispcast.com/build-an-interface-around-data/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 04 Jun 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/f178fc37/92ea476e.mp3" length="14052331" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>873</itunes:duration>
      <itunes:summary>Clojure programmers often complain about data structures getting unwieldy and hard to understand. How can we prevent this?</itunes:summary>
      <itunes:subtitle>Clojure programmers often complain about data structures getting unwieldy and hard to understand. How can we prevent this?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Focus on the data first</title>
      <itunes:episode>21</itunes:episode>
      <podcast:episode>21</podcast:episode>
      <itunes:title>Focus on the data first</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1259</guid>
      <link>https://share.transistor.fm/s/871b102d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/focus-on-the-data-first/">https://lispcast.com/focus-on-the-data-first/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/focus-on-the-data-first/">https://lispcast.com/focus-on-the-data-first/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 31 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/871b102d/d27a3a19.mp3" length="6395443" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>790</itunes:duration>
      <itunes:summary>What should we design first to make sure our software will last without having to constantly rework our code? We should focus on the data first because it is the most timeless.</itunes:summary>
      <itunes:subtitle>What should we design first to make sure our software will last without having to constantly rework our code? We should focus on the data first because it is the most timeless.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>How variants can reduce complexity</title>
      <itunes:episode>20</itunes:episode>
      <podcast:episode>20</podcast:episode>
      <itunes:title>How variants can reduce complexity</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1258</guid>
      <link>https://share.transistor.fm/s/519cd944</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-variants-can-reduce-complexity/">https://lispcast.com/how-variants-can-reduce-complexity/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/how-variants-can-reduce-complexity/">https://lispcast.com/how-variants-can-reduce-complexity/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 28 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/519cd944/bee0a0d8.mp3" length="15544121" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>967</itunes:duration>
      <itunes:summary>If we don’t limit it, complexity will get out of hand. One way to limit complexity is by collapsing the number of possible states down to a few known states that we know how to handle.</itunes:summary>
      <itunes:subtitle>If we don’t limit it, complexity will get out of hand. One way to limit complexity is by collapsing the number of possible states down to a few known states that we know how to handle.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Why are corner cases the devil? 😈</title>
      <itunes:episode>19</itunes:episode>
      <podcast:episode>19</podcast:episode>
      <itunes:title>Why are corner cases the devil? 😈</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1250</guid>
      <link>https://share.transistor.fm/s/e62499d7</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-corner-cases-the-devil-%f0%9f%98%88/">https://lispcast.com/why-are-corner-cases-the-devil-%f0%9f%98%88/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/why-are-corner-cases-the-devil-%f0%9f%98%88/">https://lispcast.com/why-are-corner-cases-the-devil-%f0%9f%98%88/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 24 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/e62499d7/40569512.mp3" length="8746517" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>542</itunes:duration>
      <itunes:summary>Corner cases make for complex code. They multiply with each other. And as they multiply, they reduce the effectiveness of each new line of code.</itunes:summary>
      <itunes:subtitle>Corner cases make for complex code. They multiply with each other. And as they multiply, they reduce the effectiveness of each new line of code.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What will increase your programming productivity the most?</title>
      <itunes:episode>18</itunes:episode>
      <podcast:episode>18</podcast:episode>
      <itunes:title>What will increase your programming productivity the most?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1249</guid>
      <link>https://share.transistor.fm/s/bdb3057b</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-will-increase-your-programming-productivity-the-most/">https://lispcast.com/what-will-increase-your-programming-productivity-the-most/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-will-increase-your-programming-productivity-the-most/">https://lispcast.com/what-will-increase-your-programming-productivity-the-most/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 21 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/bdb3057b/e5a10ac2.mp3" length="10206043" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>633</itunes:duration>
      <itunes:summary>Lisps have traditionally been highly interactive. This allowed AI researchers and language developers to iterate quickly and learn about what works and what doesn’t. How can you tap into this in your workflow?</itunes:summary>
      <itunes:subtitle>Lisps have traditionally been highly interactive. This allowed AI researchers and language developers to iterate quickly and learn about what works and what doesn’t. How can you tap into this in your workflow?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A cool Functional Programming pattern. Do you know what to call it?</title>
      <itunes:episode>17</itunes:episode>
      <podcast:episode>17</podcast:episode>
      <itunes:title>A cool Functional Programming pattern. Do you know what to call it?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1234</guid>
      <link>https://share.transistor.fm/s/a216309c</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/a-cool-functional-programming-pattern-do-you-know-what-to-call-it/">https://lispcast.com/a-cool-functional-programming-pattern-do-you-know-what-to-call-it/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/a-cool-functional-programming-pattern-do-you-know-what-to-call-it/">https://lispcast.com/a-cool-functional-programming-pattern-do-you-know-what-to-call-it/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 17 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/a216309c/5df89a71.mp3" length="18328499" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1141</itunes:duration>
      <itunes:summary>I use this pattern all the time when I’m programming, and I don’t know if it has a name. It involves lifting a value into a new space, solving a problem with it, then lowering it back down.</itunes:summary>
      <itunes:subtitle>I use this pattern all the time when I’m programming, and I don’t know if it has a name. It involves lifting a value into a new space, solving a problem with it, then lowering it back down.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Can you do Functional Programming in any language?</title>
      <itunes:episode>16</itunes:episode>
      <podcast:episode>16</podcast:episode>
      <itunes:title>Can you do Functional Programming in any language?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1232</guid>
      <link>https://share.transistor.fm/s/21cc2d24</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-do-functional-programming-in-any-language/">https://lispcast.com/can-you-do-functional-programming-in-any-language/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/can-you-do-functional-programming-in-any-language/">https://lispcast.com/can-you-do-functional-programming-in-any-language/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 14 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/21cc2d24/9aa15f0d.mp3" length="17830877" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1110</itunes:duration>
      <itunes:summary>Can you do functional programming in any language? Is it possible to do functional programming in C, in Java, in assembly, in Ruby, or do you need a functional language? What is a functional language anyway?</itunes:summary>
      <itunes:subtitle>Can you do functional programming in any language? Is it possible to do functional programming in C, in Java, in assembly, in Ruby, or do you need a functional language? What is a functional language anyway?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What does it mean for Actions to be first-class?</title>
      <itunes:episode>15</itunes:episode>
      <podcast:episode>15</podcast:episode>
      <itunes:title>What does it mean for Actions to be first-class?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1228</guid>
      <link>https://share.transistor.fm/s/48c10100</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-actions-to-be-first-class/">https://lispcast.com/what-does-it-mean-for-actions-to-be-first-class/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/what-does-it-mean-for-actions-to-be-first-class/">https://lispcast.com/what-does-it-mean-for-actions-to-be-first-class/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 10 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/48c10100/3924563e.mp3" length="19066573" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1187</itunes:duration>
      <itunes:summary>In Functional Programming, everything needs to be first class? But what does that mean? And why is it important? I discuss the idea of composing Actions and Calculations dynamically.</itunes:summary>
      <itunes:subtitle>In Functional Programming, everything needs to be first class? But what does that mean? And why is it important? I discuss the idea of composing Actions and Calculations dynamically.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Should we waste memory?</title>
      <itunes:episode>14</itunes:episode>
      <podcast:episode>14</podcast:episode>
      <itunes:title>Should we waste memory?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1224</guid>
      <link>https://share.transistor.fm/s/37d4dfa8</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/should-we-waste-memory/">https://lispcast.com/should-we-waste-memory/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/should-we-waste-memory/">https://lispcast.com/should-we-waste-memory/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 07 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/37d4dfa8/2c0e07e7.mp3" length="14758679" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>918</itunes:duration>
      <itunes:summary>We have so much memory now, compared to the 1970s, that it often seems like we have memory to burn. I misspoke in a previous episode where I made it seem like I’m in favor of wasting memory. But what did I mean instead?</itunes:summary>
      <itunes:subtitle>We have so much memory now, compared to the 1970s, that it often seems like we have memory to burn. I misspoke in a previous episode where I made it seem like I’m in favor of wasting memory. But what did I mean instead?</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>Yes</itunes:explicit>
    </item>
    <item>
      <title>Is FP just programming with pure functions?</title>
      <itunes:episode>13</itunes:episode>
      <podcast:episode>13</podcast:episode>
      <itunes:title>Is FP just programming with pure functions?</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1223</guid>
      <link>https://share.transistor.fm/s/ec36c47d</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-fp-just-programming-with-pure-functions/">https://lispcast.com/is-fp-just-programming-with-pure-functions/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/is-fp-just-programming-with-pure-functions/">https://lispcast.com/is-fp-just-programming-with-pure-functions/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 03 May 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/ec36c47d/0092731e.mp3" length="10394835" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>645</itunes:duration>
      <itunes:summary>As I develop and expound this theory, it may seem to be too complicated. Isn’t functional programming just programming with pure functions? Why make this more complicated than that? We talk about my reasons and my goals for the theory.</itunes:summary>
      <itunes:subtitle>As I develop and expound this theory, it may seem to be too complicated. Isn’t functional programming just programming with pure functions? Why make this more complicated than that? We talk about my reasons and my goals for the theory.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>The magical leverage of languages</title>
      <itunes:episode>12</itunes:episode>
      <podcast:episode>12</podcast:episode>
      <itunes:title>The magical leverage of languages</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1222</guid>
      <link>https://share.transistor.fm/s/908b5b6c</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebraic-properties-composition/">https://lispcast.com/algebraic-properties-composition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebraic-properties-composition/">https://lispcast.com/algebraic-properties-composition/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 30 Apr 2018 06:30:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/908b5b6c/73ca9ba3.mp3" length="12918609" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>803</itunes:duration>
      <itunes:summary>If I write a straightforward solution to a problem in Clojure, it might take me a thousand lines of code to solve it. To handle all the corner cases and everything, I got a thousand lines of code. However, if I take this other approach where it’s much more indirect, or instead of solving the problem that I have in front of me, I write a language–a DSL. The DSL could take me 500 lines of code to write. That’s a fairly large DSL. Usually they’re much smaller, but it takes me 500 lines of code. Actually, writing the solution in it only takes 10 lines of code.</itunes:summary>
      <itunes:subtitle>If I write a straightforward solution to a problem in Clojure, it might take me a thousand lines of code to solve it. To handle all the corner cases and everything, I got a thousand lines of code. However, if I take this other approach where it’s much mor</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Algebraic Properties and Composition</title>
      <itunes:episode>11</itunes:episode>
      <podcast:episode>11</podcast:episode>
      <itunes:title>Algebraic Properties and Composition</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1220</guid>
      <link>https://share.transistor.fm/s/2b6cd6a9</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebraic-properties-composition/">https://lispcast.com/algebraic-properties-composition/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/algebraic-properties-composition/">https://lispcast.com/algebraic-properties-composition/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 26 Apr 2018 06:27:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/2b6cd6a9/0e8eb5ca.mp3" length="9684349" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>600</itunes:duration>
      <itunes:summary>In school, we learn about a few algebraic properties. These apply very well in functional programming because their expression is so simple, their definitions are so simple and they really focus on how things compose.</itunes:summary>
      <itunes:subtitle>In school, we learn about a few algebraic properties. These apply very well in functional programming because their expression is so simple, their definitions are so simple and they really focus on how things compose.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Bottom up vs Top Down Programming</title>
      <itunes:episode>10</itunes:episode>
      <podcast:episode>10</podcast:episode>
      <itunes:title>Bottom up vs Top Down Programming</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1219</guid>
      <link>https://share.transistor.fm/s/b4e016b8</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/bottom-vs-top-programming/">https://lispcast.com/bottom-vs-top-programming/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/bottom-vs-top-programming/">https://lispcast.com/bottom-vs-top-programming/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 23 Apr 2018 14:22:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b4e016b8/20c3f814.mp3" length="11515879" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>715</itunes:duration>
      <itunes:summary>I think the real trick to all of that is always think about the data as being forever. One thing that we often do when we’re programming is we want things to be a little bit more concrete.</itunes:summary>
      <itunes:subtitle>I think the real trick to all of that is always think about the data as being forever. One thing that we often do when we’re programming is we want things to be a little bit more concrete.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What a Clojure Web Framework might look like</title>
      <itunes:episode>9</itunes:episode>
      <podcast:episode>9</podcast:episode>
      <itunes:title>What a Clojure Web Framework might look like</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1217</guid>
      <link>https://share.transistor.fm/s/b657d6ae</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/clojure-web-framework-might-look-like/">https://lispcast.com/clojure-web-framework-might-look-like/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/clojure-web-framework-might-look-like/">https://lispcast.com/clojure-web-framework-might-look-like/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 19 Apr 2018 07:16:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b657d6ae/443f8a2c.mp3" length="21394595" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1332</itunes:duration>
      <itunes:summary>One of the questions that came up a couple times was what is a Web framework? What does that even mean? I don’t want to get into philosophical discussion about what a framework is. Is it a library or framework or any of those kinds of questions. I’ll tell you what I meant, what I still mean by this assertion that we need one.</itunes:summary>
      <itunes:subtitle>One of the questions that came up a couple times was what is a Web framework? What does that even mean? I don’t want to get into philosophical discussion about what a framework is. Is it a library or framework or any of those kinds of questions. I’ll tell</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0006</title>
      <itunes:episode>8</itunes:episode>
      <podcast:episode>8</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0006</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1216</guid>
      <link>https://share.transistor.fm/s/c062587e</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0006/">https://lispcast.com/theory-functional-programming-0006/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0006/">https://lispcast.com/theory-functional-programming-0006/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 16 Apr 2018 17:07:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/c062587e/40af6fc7.mp3" length="19535741" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1216</itunes:duration>
      <itunes:summary>What I want to talk about is this issue of what is an action and what is a calculation in terms of timeliness, because we know that deep down in the computer, everything is an action. Every operation depends on what is that particular locations in memory at the time that the operation is run.</itunes:summary>
      <itunes:subtitle>What I want to talk about is this issue of what is an action and what is a calculation in terms of timeliness, because we know that deep down in the computer, everything is an action. Every operation depends on what is that particular locations in memory </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>What Clojure needs to grow — a boring web framework and boring data science</title>
      <itunes:episode>7</itunes:episode>
      <podcast:episode>7</podcast:episode>
      <itunes:title>What Clojure needs to grow — a boring web framework and boring data science</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1215</guid>
      <link>https://share.transistor.fm/s/122d39f6</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/clojure-needs-grow-boring-web-framework-boring-data-science/">https://lispcast.com/clojure-needs-grow-boring-web-framework-boring-data-science/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/clojure-needs-grow-boring-web-framework-boring-data-science/">https://lispcast.com/clojure-needs-grow-boring-web-framework-boring-data-science/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 12 Apr 2018 17:03:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/122d39f6/957563f7.mp3" length="19559195" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1218</itunes:duration>
      <itunes:summary>I think a lot about what Clojure needs. Is there something that is sort of the bottleneck for growth? People talk about different things as their hypotheses for what would make it grow. I think that what Clojure needs — I’ll talk about my hypotheses — I think what we really need is to solve all of the boring problems that other languages have already solved.</itunes:summary>
      <itunes:subtitle>I think a lot about what Clojure needs. Is there something that is sort of the bottleneck for growth? People talk about different things as their hypotheses for what would make it grow. I think that what Clojure needs — I’ll talk about my hypotheses — I t</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>Programming is a pop culture and what we should do about it</title>
      <itunes:episode>6</itunes:episode>
      <podcast:episode>6</podcast:episode>
      <itunes:title>Programming is a pop culture and what we should do about it</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1214</guid>
      <link>https://share.transistor.fm/s/3fc3ac92</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/programming-pop-culture/">https://lispcast.com/programming-pop-culture/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/programming-pop-culture/">https://lispcast.com/programming-pop-culture/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 09 Apr 2018 16:59:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/3fc3ac92/976df973.mp3" length="13362081" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>830</itunes:duration>
      <itunes:summary>I want to talk about how programming is a pop culture. It’s true, programming is a pop culture. There are big trends, fads, new frameworks coming out all the time. It’s all about attention and getting mind share and people watching your media about what framework or what language to use, or how to program.</itunes:summary>
      <itunes:subtitle>I want to talk about how programming is a pop culture. It’s true, programming is a pop culture. There are big trends, fads, new frameworks coming out all the time. It’s all about attention and getting mind share and people watching your media about what f</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0005</title>
      <itunes:episode>5</itunes:episode>
      <podcast:episode>5</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0005</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1211</guid>
      <link>https://share.transistor.fm/s/b932b3ee</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0005/">https://lispcast.com/theory-functional-programming-0005/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0005/">https://lispcast.com/theory-functional-programming-0005/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 05 Apr 2018 16:01:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b932b3ee/c58ba117.mp3" length="17915585" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1115</itunes:duration>
      <itunes:summary>There are different patterns that we use as functional programmers to reduce the possible states so that it becomes easier to reason about. I think that this is something that we should talk about a little bit more, because it’s actually something that isn’t talked about much in imperative programming.</itunes:summary>
      <itunes:subtitle>There are different patterns that we use as functional programmers to reduce the possible states so that it becomes easier to reason about. I think that this is something that we should talk about a little bit more, because it’s actually something that is</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0004</title>
      <itunes:episode>4</itunes:episode>
      <podcast:episode>4</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0004</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1169</guid>
      <link>https://share.transistor.fm/s/b52813b9</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0004/">https://lispcast.com/theory-functional-programming-0004/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0004/">https://lispcast.com/theory-functional-programming-0004/</a></p>]]>
      </content:encoded>
      <pubDate>Mon, 02 Apr 2018 13:52:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/b52813b9/3aa82b2f.mp3" length="52887442" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2200</itunes:duration>
      <itunes:summary>Today, we’re going to be talking actions. Now, as counter-intuitive as it may be, functional programming has more to say about actions than it does about data and calculations. At least, more interesting stuff to say.</itunes:summary>
      <itunes:subtitle>Today, we’re going to be talking actions. Now, as counter-intuitive as it may be, functional programming has more to say about actions than it does about data and calculations. At least, more interesting stuff to say.</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0003</title>
      <itunes:episode>3</itunes:episode>
      <podcast:episode>3</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0003</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1165</guid>
      <link>https://share.transistor.fm/s/d0dcf694</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0003/">https://lispcast.com/theory-functional-programming-0003/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0003/">https://lispcast.com/theory-functional-programming-0003/</a></p>]]>
      </content:encoded>
      <pubDate>Thu, 29 Mar 2018 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/d0dcf694/26185f14.mp3" length="42563581" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>1770</itunes:duration>
      <itunes:summary>All right, this is my attempt at writing a book. If you haven’t joined me before, my name is Eric Normand. I’m writing a book called “A Theory of Functional Programming.” The industry needs a good definition of functional programming. No one has provided that yet, and so I’m trying to provide it.</itunes:summary>
      <itunes:subtitle>All right, this is my attempt at writing a book. If you haven’t joined me before, my name is Eric Normand. I’m writing a book called “A Theory of Functional Programming.” The industry needs a good definition of functional programming. No one has provided </itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0002</title>
      <itunes:episode>2</itunes:episode>
      <podcast:episode>2</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0002</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1166</guid>
      <link>https://share.transistor.fm/s/97940875</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0002/">https://lispcast.com/theory-functional-programming-0002/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0002/">https://lispcast.com/theory-functional-programming-0002/</a></p>]]>
      </content:encoded>
      <pubDate>Wed, 28 Mar 2018 06:00:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/97940875/8d0e1cff.mp3" length="52643490" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2190</itunes:duration>
      <itunes:summary>All right. I am talking about, “A Theory of Functional Programming,” which is a book that I’m working on, and this is actually me working on it right now. I am going to talk about the topic, and hopefully, the transcript will turn into my book. I talked about a lot of things last time. That was last Friday, and I know that the last thing I talked about was composition, and I don’t think I got very far into that, so I’ll talk about it.</itunes:summary>
      <itunes:subtitle>All right. I am talking about, “A Theory of Functional Programming,” which is a book that I’m working on, and this is actually me working on it right now. I am going to talk about the topic, and hopefully, the transcript will turn into my book. I talked a</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
    <item>
      <title>A Theory of Functional Programming 0001</title>
      <itunes:episode>1</itunes:episode>
      <podcast:episode>1</podcast:episode>
      <itunes:title>A Theory of Functional Programming 0001</itunes:title>
      <itunes:episodeType>full</itunes:episodeType>
      <guid isPermaLink="false">https://lispcast.com/?p=1162</guid>
      <link>https://share.transistor.fm/s/74bb8f67</link>
      <description>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0001/">https://lispcast.com/theory-functional-programming-0001/</a></p>]]>
      </description>
      <content:encoded>
        <![CDATA[<p>For audio, video, and text transcripts: <a href="https://lispcast.com/theory-functional-programming-0001/">https://lispcast.com/theory-functional-programming-0001/</a></p>]]>
      </content:encoded>
      <pubDate>Fri, 02 Mar 2018 16:41:00 +0000</pubDate>
      <author>Eric Normand</author>
      <enclosure url="https://media.transistor.fm/74bb8f67/b38b60d5.mp3" length="17959720" type="audio/mpeg"/>
      <itunes:author>Eric Normand</itunes:author>
      <itunes:duration>2155</itunes:duration>
      <itunes:summary>OK. I’m trying this out. I’m writing a book. I’m going to move. I’m writing a book. I think I’m going to call it, A Theory of Functional Programming.” Let me explain. Here is the reasoning. That’s bad lighting hold on. I’ll explain what I’m doing and I’ll explain the reasoning behind the book.</itunes:summary>
      <itunes:subtitle>OK. I’m trying this out. I’m writing a book. I’m going to move. I’m writing a book. I think I’m going to call it, A Theory of Functional Programming.” Let me explain. Here is the reasoning. That’s bad lighting hold on. I’ll explain what I’m doing and I’ll</itunes:subtitle>
      <itunes:keywords></itunes:keywords>
      <itunes:explicit>No</itunes:explicit>
    </item>
  </channel>
</rss>
