Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "cond-&gt; and cond-&gt;&gt;." We devote some time to two functions that are indispensable when computations require variation. Selected quotes:  "Our love of Clojure is unconditional!" "These are all about conditional operations." "It's shorter and easier to understand, which is uncommon in development." "That gave me data I could reason about in the program."  Links:  cond-&gt; cond-&gt;&gt;

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "cond-&gt; and cond-&gt;&gt;." We devote some time to two functions that are indispensable when computations require variation. Selected quotes: <ul> <li>"Our love of Clojure is unconditional!"</li> <li>"These are all about conditional operations."</li> <li>"It's shorter and easier to understand, which is uncommon in development."</li> <li>"That gave me data I could reason about in the program."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/cond-%3E" rel="nofollow" target="_blank">cond-&gt;</a></li> <li><a href="https://clojuredocs.org/clojure.core/cond-%3E%3E" rel="nofollow" target="_blank">cond-&gt;&gt;</a></li></ul>

Ep 090: Conditional Results

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "if, when, case, condp, and cond." We wander through the myriad ways of making decisions and listing choices in Clojure. Selected quotes:  "Clojure is all about the practical." "Never be afraid of the in-line if." "We need to conserve parentheses, for future generations of lispers." "Build up the language to the vocabulary of your domain, and you won't have to think about the language any more, you'll just be thinking about your problem." "Where are you in programming, without branching?"  Links:  if when case cond condp  Related Episodes:  086: Let Tricks 087: Polymorphic Metal

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "if, when, case, condp, and cond." We wander through the myriad ways of making decisions and listing choices in Clojure. Selected quotes: <ul> <li>"Clojure is all about the practical."</li> <li>"Never be afraid of the in-line if."</li> <li>"We need to conserve parentheses, for future generations of lispers."</li> <li>"Build up the language to the vocabulary of your domain, and you won't have to think about the language any more, you'll just be thinking about your problem."</li> <li>"Where are you in programming, without branching?"</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/if" rel="nofollow" target="_blank">if</a></li> <li><a href="https://clojuredocs.org/clojure.core/when" rel="nofollow" target="_blank">when</a></li> <li><a href="https://clojuredocs.org/clojure.core/case" rel="nofollow" target="_blank">case</a></li> <li><a href="https://clojuredocs.org/clojure.core/cond" rel="nofollow" target="_blank">cond</a></li> <li><a href="https://clojuredocs.org/clojure.core/condp" rel="nofollow" target="_blank">condp</a></li> </ul> Related Episodes: <ul> <li><a href="https://clojuredesign.club/episode/086-let-tricks/" rel="nofollow" target="_blank">086: Let Tricks</a></li> <li><a href="https://clojuredesign.club/episode/087-polymorphic-metal/" rel="nofollow" target="_blank">087: Polymorphic Metal</a></li></ul>

Ep 089: Branching Out

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "doall, dorun, doseq, and run!." We eagerly discuss the times we need to interact with the messy world from our nice clean language. Selected quotes:  "We're going to talk about not being lazy, for once." "Laziness is a virtue." "Clojure loves immutability. The world loves mutability."  Links:  doall dorun doseq run! Larry Wall's Three Virtues  Related Episodes:  014: Fiddle with the REPL 085: For for the When 086: Let Tricks

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "doall, dorun, doseq, and run!." We eagerly discuss the times we need to interact with the messy world from our nice clean language. Selected quotes: <ul> <li>"We're going to talk about not being lazy, for once."</li> <li>"Laziness is a virtue."</li> <li>"Clojure loves immutability. The world loves mutability."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/doall" rel="nofollow" target="_blank">doall</a></li> <li><a href="https://clojuredocs.org/clojure.core/dorun" rel="nofollow" target="_blank">dorun</a></li> <li><a href="https://clojuredocs.org/clojure.core/doseq" rel="nofollow" target="_blank">doseq</a></li> <li><a href="https://clojuredocs.org/clojure.core/run%21" rel="nofollow" target="_blank">run!</a></li> <li><a href="http://threevirtues.com/" rel="nofollow" target="_blank">Larry Wall's Three Virtues</a></li> </ul> Related Episodes: <ul> <li><a href="https://clojuredesign.club/episode/014-fiddle-with-the-repl/" rel="nofollow" target="_blank">014: Fiddle with the REPL</a></li> <li><a href="https://clojuredesign.club/episode/085-for-for-the-when/" rel="nofollow" target="_blank">085: For for the When</a></li> <li><a href="https://clojuredesign.club/episode/086-let-tricks/" rel="nofollow" target="_blank">086: Let Tricks</a></li></ul>

Ep 088: Do Dorun Run!

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "multimethods." We discuss polymorphism and how we tackle dynamic data with families of functions. Selected quotes:  "You don't have to reach for polymorphism as quickly in Clojure." "Polymorphism at its simplest." "A natural fit for processing a list of heterogeneous things." "Our natural tool of computation: the function."  Links:  defmulti defmethod Multimethods and Hierarchies defmethod in Pyrite font

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "multimethods." We discuss polymorphism and how we tackle dynamic data with families of functions. Selected quotes: <ul> <li>"You don't have to reach for polymorphism as quickly in Clojure."</li> <li>"Polymorphism at its simplest."</li> <li>"A natural fit for processing a list of heterogeneous things."</li> <li>"Our natural tool of computation: the function."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/defmulti" rel="nofollow" target="_blank">defmulti</a></li> <li><a href="https://clojuredocs.org/clojure.core/defmethod" rel="nofollow" target="_blank">defmethod</a></li> <li><a href="https://clojure.org/reference/multimethods" rel="nofollow" target="_blank">Multimethods and Hierarchies</a></li> <li><a href="https://www.dafont.com/pyrite.font?text=defmethod" rel="nofollow" target="_blank">defmethod in Pyrite font</a></li></ul>

Ep 087: Polymorphic Metal

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "let." Let us share some tricks to reduce nesting and make your code easier to understand. Selected quotes:  "It's really about avoiding nesting." "Functions grow as a function of their nesting." "I don't want to start doing math on a nil!" "It's a clue that the value might not be there." "It's like your prep space in the kitchen."  Links:  let

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "let." Let us share some tricks to reduce nesting and make your code easier to understand. Selected quotes: <ul> <li>"It's really about avoiding nesting."</li> <li>"Functions grow as a function of their nesting."</li> <li>"I don't want to start doing math on a nil!"</li> <li>"It's a clue that the value might not be there."</li> <li>"It's like your prep space in the kitchen."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/let" rel="nofollow" target="_blank">let</a></li></ul>

Ep 086: Let Tricks

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "for." We talk about this data generating macro, while we remember situations when it was useful. Selected quotes:  "You are generating a new sequence in a declarative way." "In typical Clojure fashion, I looked up the definition." "Forgive us for our puns." "Where the while is in the for. Another statement that doesn't make sense to the outside listener."  Links:  for

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "for." We talk about this data generating macro, while we remember situations when it was useful. Selected quotes: <ul> <li>"You are generating a new sequence in a declarative way."</li> <li>"In typical Clojure fashion, I looked up the definition."</li> <li>"Forgive us for our puns."</li> <li>"Where the while is in the for. Another statement that doesn't make sense to the outside listener."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/for" rel="nofollow" target="_blank">for</a></li></ul>

Ep 085: For for the When

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "sort and sort-by." We lay out a list of ways to sort your data, ordered by their relative power. Selected quotes:  "Clojure core is a shared vocabulary that we all can use." "I can't sort things in my mind, I'll just have the computer do it for me." "There only needs to be one sort-by function, because of the flexibility of passing in the classifying function." "We don't need any framework-y mumbo-jumbo." "We do interop, but only at the edges."  Links:  sort sort-by

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "sort and sort-by." We lay out a list of ways to sort your data, ordered by their relative power. Selected quotes: <ul> <li>"Clojure core is a shared vocabulary that we all can use."</li> <li>"I can't sort things in my mind, I'll just have the computer do it for me."</li> <li>"There only needs to be one sort-by function, because of the flexibility of passing in the classifying function."</li> <li>"We don't need any framework-y mumbo-jumbo."</li> <li>"We do interop, but only at the edges."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/sort" rel="nofollow" target="_blank">sort</a></li> <li><a href="https://clojuredocs.org/clojure.core/sort-by" rel="nofollow" target="_blank">sort-by</a></li></ul>

Ep 084: All Sorts

Sift

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "partition-by and group-by." We get a handle on big buckets of data by sifting elements into smaller buckets. Selected quotes:  "If you know the core toolbox better, you will use it more effectively."   "Is there a group-by hiding in this code that uses filter?" "Be eager to be lazy."  Links:  partition-by group-by

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "partition-by and group-by." We get a handle on big buckets of data by sifting elements into smaller buckets. Selected quotes: <ul> <li>"If you know the core toolbox better, you will use it more effectively."</li> </ul> <ul> <li>"Is there a group-by hiding in this code that uses filter?"</li> <li>"Be eager to be lazy."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/partition-by" rel="nofollow" target="_blank">partition-by</a></li> <li><a href="https://clojuredocs.org/clojure.core/group-by" rel="nofollow" target="_blank">group-by</a></li></ul>

Ep 083: Sift Sans Sort

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "filter, filterv, remove, keep, and keep-indexed." We talk about sifting data and marvel at the simple function that can turn two steps into one. Selected quotes:  "It's not just linguistic, it helps it make more sense." "We should be more positive about our intent." "Clojure's sense of falsey is thankfully limited to nil and false." "Nil is a positive statement that it didn't work out." "Keep is great for those times where you need data for both the transform and the filter." "It's only a complement away!" "Reaching for optimization too early leads to more complexity."  Links:  filter filterv remove keep keep-indexed

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "filter, filterv, remove, keep, and keep-indexed." We talk about sifting data and marvel at the simple function that can turn two steps into one. Selected quotes: <ul> <li>"It's not just linguistic, it helps it make more sense."</li> <li>"We should be more positive about our intent."</li> <li>"Clojure's sense of falsey is thankfully limited to nil and false."</li> <li>"Nil is a positive statement that it didn't work out."</li> <li>"Keep is great for those times where you need data for both the transform and the filter."</li> <li>"It's only a complement away!"</li> <li>"Reaching for optimization too early leads to more complexity."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/filter" rel="nofollow" target="_blank">filter</a></li> <li><a href="https://clojuredocs.org/clojure.core/filterv" rel="nofollow" target="_blank">filterv</a></li> <li><a href="https://clojuredocs.org/clojure.core/remove" rel="nofollow" target="_blank">remove</a></li> <li><a href="https://clojuredocs.org/clojure.core/keep" rel="nofollow" target="_blank">keep</a></li> <li><a href="https://clojuredocs.org/clojure.core/keep-indexed" rel="nofollow" target="_blank">keep-indexed</a></li></ul>

Ep 082: Filter and Friends

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "first, second, key, and val." We talk about positive nothing and the proliferation of tuples. Selected quotes:  "Let our ramblings help your code ramblings." "First is the key." "Nil, the positive statement of nothing." "Key and val are a hint that the bit of data you're working on is really a small part of a map."  Links:  first second key val

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "first, second, key, and val." We talk about positive nothing and the proliferation of tuples. Selected quotes: <ul> <li>"Let our ramblings help your code ramblings."</li> <li>"First is the key."</li> <li>"Nil, the positive statement of nothing."</li> <li>"Key and val are a hint that the bit of data you're working on is really a small part of a map."</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.core/first" rel="nofollow" target="_blank">first</a></li> <li><a href="https://clojuredocs.org/clojure.core/second" rel="nofollow" target="_blank">second</a></li> <li><a href="https://clojuredocs.org/clojure.core/key" rel="nofollow" target="_blank">key</a></li> <li><a href="https://clojuredocs.org/clojure.core/val" rel="nofollow" target="_blank">val</a></li></ul>

Ep 081: List No More

Each week, we discuss a software design problem and how we might solve it using functional principles and the Clojure programming language.

For those new to functional programming this is a great way to start rewiring your brain. Two guys talking about the way they&#39;d solve a problem in code sounds like it should be about as interesting as listening to a recitation of an open source licence and yet Christoph and Nate always manage to keep it engaging. The two have great chemistry and an easy rapport that makes every episode feel like you&#39;re a fly on the wall of a software design meeting.

A fun and enjoyable chat about software architecture

I just want to say thank you guys for the great content. Your somewhat off-the-cuff dialogue about design decisions has been really helpful to me as I learn functional programming.

I mostly write code in JavaScript, but your high-level discussions apply to my own situations in so many ways. I might have even grown to *like* software architecture. Props to you guys for dropping some much needed insights while keeping it humorous and light.

Very useful!

Functional Design in Clojure

Christoph complicated development by misunderstanding the REPL.  We go back to the roots of Christoph's experience with Clojure... How do I run Clojure code? The REPL is fun for evaluation, but how do you run a "real" program? Experience in other languages: edit the file, compile, rerun the program Mentality: get through the edit, compile, run loop as fast as possible! Autobuilder is the logical end. "Where's my autobuilder in Clojure?!" The REPL model is fundamentally different. "[The REPL] is like cutting the Gordian Knot. You change the problem and that's how you solve it." "The reason why the problem I wanted solved, wasn't 'solved', is because nobody has that problem because they do things differently here." Tactic 1: edit, save, restart the REPL "Restarting the REPL isn't super slow, but let's just say it's not instantaneous." Tactic 2: edit, save, run (use 'the.namespace :reload) in the REPL "Now I have a REPL history of use statements!" Problems: forgetting to reload dependent namespaces loading dependencies in the wrong order old definitions built up   Big Problem: function renames left the old version around, so accidental calls using the old name produced no errors and ran old behavior! Back to quitting the REPL to clean out the cruft. Ugh! Discovered clojure.tools.namespace! Reloads everything and cleans out the cruft! Tactic 3: edit, save, (use '[clojure.tools.namespace.repl :only (refresh)]), (refresh) Problem: refresh would purge itself! "I don't know why it took me so long to discover the magical user namespace!" The REPL will automatically use the user namespace. "I can put code into a user namespace and it will be there for me." Christoph would switch namespaces in the REPL without even stopping to wonder what namespace he started in. "It's like walking out of a door and not even thinking about the fact you're in a building. Oh wait! What room did I just leave?" Tactic 4: make sure refresh is in the user namespace, edit, save, (refresh) However, Christoph still didn't understand the REPL. Just thought the REPL was for: reloading the code and restarting evaluating snippets of code inspecting stuff   Nate's big ah-ha moment: "Not only is my application inspectable, it's fungible. I can change it in place as it's flying along! I don't have to restart it!" Christoph's hint that there was still more came from seeing comment blocks in code and reading about vim-fireplace. "There's a new room you can explore. That room is editor integration with the REPL."  Clojure in this episode:  use clojure.tools.namespace.repl/refresh clojure.pprint/pprint  Related projects:  clojure.tools.namespace vim-fireplace Cider for Emacs

Christoph complicated development by misunderstanding the REPL. <ul> <li>We go back to the roots of Christoph's experience with Clojure...</li> <li>How do I run Clojure code?</li> <li>The REPL is fun for evaluation, but how do you run a "real" program?</li> <li>Experience in other languages: edit the file, compile, rerun the program</li> <li>Mentality: get through the edit, compile, run loop as fast as possible!</li> <li>Autobuilder is the logical end.</li> <li>"Where's my autobuilder in Clojure?!"</li> <li>The REPL model is fundamentally different.</li> <li>"[The REPL] is like cutting the Gordian Knot. You change the problem and that's how you solve it."</li> <li>"The reason why the problem I wanted solved, wasn't 'solved', is because nobody has that problem because they do things differently here."</li> <li>Tactic 1: edit, save, restart the REPL</li> <li>"Restarting the REPL isn't super slow, but let's just say it's not instantaneous."</li> <li>Tactic 2: edit, save, run <code>(use 'the.namespace :reload)</code> in the REPL</li> <li>"Now I have a REPL history of <code>use</code> statements!"</li> <li>Problems: <ul> <li>forgetting to reload dependent namespaces</li> <li>loading dependencies in the wrong order</li> <li>old definitions built up</li> </ul> </li> <li>Big Problem: function renames left the old version around, so accidental calls using the old name produced no errors and ran old behavior!</li> <li>Back to quitting the REPL to clean out the cruft. Ugh!</li> <li>Discovered <code>clojure.tools.namespace</code>! Reloads everything and cleans out the cruft!</li> <li>Tactic 3: edit, save, <code>(use '[clojure.tools.namespace.repl :only (refresh)])</code>, <code>(refresh)</code></li> <li>Problem: <code>refresh</code> would purge itself!</li> <li>"I don't know why it took me so long to discover the magical <code>user</code> namespace!"</li> <li>The REPL will automatically <code>use</code> the <code>user</code> namespace.</li> <li>"I can put code into a <code>user</code> namespace and it will be there for me."</li> <li>Christoph would switch namespaces in the REPL without even stopping to wonder what namespace he started in.</li> <li>"It's like walking out of a door and not even thinking about the fact you're in a building. Oh wait! What room did I just leave?"</li> <li>Tactic 4: make sure <code>refresh</code> is in the <code>user</code> namespace, edit, save, <code>(refresh)</code></li> <li>However, Christoph still didn't understand the REPL.</li> <li>Just thought the REPL was for: <ul> <li>reloading the code and restarting</li> <li>evaluating snippets of code</li> <li>inspecting stuff</li> </ul> </li> <li>Nate's big ah-ha moment: "Not only is my application inspectable, it's fungible. I can change it in place as it's flying along! I don't have to restart it!"</li> <li>Christoph's hint that there was still more came from seeing <code>comment</code> blocks in code and reading about vim-fireplace.</li> <li>"There's a new room you can explore. That room is editor integration with the REPL."</li> </ul> Clojure in this episode: <ul> <li><code>use</code></li> <li><code>clojure.tools.namespace.repl/refresh</code></li> <li><code>clojure.pprint/pprint</code></li> </ul> Related projects: <ul> <li><a href="https://github.com/clojure/tools.namespace" rel="nofollow" target="_blank">clojure.tools.namespace</a></li> <li><a href="https://github.com/tpope/vim-fireplace" rel="nofollow" target="_blank">vim-fireplace</a></li> <li><a href="https://github.com/clojure-emacs/cider" rel="nofollow" target="_blank">Cider for Emacs</a></li></ul>

Episode 012: Embrace the REPL

It's summertime, and that means it's time for something new. Each week, we will answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign or send an email to feedback@clojuredesign.club. This week, we're starting off with "Why do you recommend Clojure?". We take turns sharing our favorite reasons, and we can't help but have fun riffing on how enjoyable Clojure is to use. Come along for the ride. Selected quotes:  "Question everything else. Clojure is the answer." "Once you discover structural editing, you'll never go back." "Data is inert. It can't act." "When dealing with mutable data and side effects, it's like trying to add a domino in the middle and make sure to not break the chain." "Most of the time, running with scissors is considered to be a bad thing." "Somebody in Java has done all that plumbing that you don't really want to do."

It's summertime, and that means it's time for something new. Each week, we will answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a> or send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>. This week, we're starting off with "Why do you recommend Clojure?". We take turns sharing our favorite reasons, and we can't help but have fun riffing on how enjoyable Clojure is to use. Come along for the ride. Selected quotes: <ul> <li>"Question everything else. Clojure is the answer."</li> <li>"Once you discover structural editing, you'll never go back."</li> <li>"Data is inert. It can't act."</li> <li>"When dealing with mutable data and side effects, it's like trying to add a domino in the middle and make sure to not break the chain."</li> <li>"Most of the time, running with scissors is considered to be a bad thing."</li> <li>"Somebody in Java has done all that plumbing that you don't really want to do."</li></ul>

Ep 036: Why Do You Recommend Clojure?

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "Why use Clojure over another functional language?". We examine the different categories of functional programming languages and distill out what differentiates Clojure and why we prefer it. Selected quotes:  "Running just one function when developing is not only allowed in Clojure, it's encouraged and celebrated." "You don't have to make the whole world (application) agree. You can work on just a part of it and then bring it back into the rest of the world when you want it to agree." "I would like some XML in my cake." "Oh, you were a hipster Scala user." "When I pull in code off clojars, it's going to use the Clojure way, because there is a Clojure way." "If you can make all your abstractions with a simpler set of semantics, wouldn't that be better than a broader set?" "Multi-paradigm languages are inherently more complex. You really end up in the 'good parts' kind of problem. Scala, The Good Parts. Javascript, The Good Parts." "Code is about communicating with two things. The computer and the other developers. The computer can handle esoteric language features, but other developers will have a harder time with them."  Related episodes:  002: Tic-Tac-Toe, State in a Row 014: Fiddle with the REPL

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "Why use Clojure over another functional language?". We examine the different categories of functional programming languages and distill out what differentiates Clojure and why we prefer it. Selected quotes: <ul> <li>"Running just one function when developing is not only allowed in Clojure, it's encouraged and celebrated."</li> <li>"You don't have to make the whole world (application) agree. You can work on just a part of it and then bring it back into the rest of the world when you want it to agree."</li> <li>"I would like some XML in my cake."</li> <li>"Oh, you were a hipster Scala user."</li> <li>"When I pull in code off clojars, it's going to use the Clojure way, because there is a Clojure way."</li> <li>"If you can make all your abstractions with a simpler set of semantics, wouldn't that be better than a broader set?"</li> <li>"Multi-paradigm languages are inherently more complex. You really end up in the 'good parts' kind of problem. Scala, The Good Parts. Javascript, The Good Parts."</li> <li>"Code is about communicating with two things. The computer and the other developers. The computer can handle esoteric language features, but other developers will have a harder time with them."</li> </ul> Related episodes: <ul> <li><a href="/episode/002-tic-tac-toe-state-in-a-row" rel="nofollow" target="_blank">002: Tic-Tac-Toe, State in a Row</a></li> <li><a href="/episode/014-fiddle-with-the-repl" rel="nofollow" target="_blank">014: Fiddle with the REPL</a></li></ul>

Ep 039: Why Use Clojure Over Another Functional Language?

Nate wants to experiment with the UI, but Twitter keeps getting the results.  "This thing that we're making because we're lazy has now taken 4 or 5 weeks to implement." Last week: "worker" logic vs "decider" logic. Allowed us to flatten the logic. "You can spend months on the backend and people think you've barely got anything done. You can spend two days on the UI and then people think you're making progress." (04:20) Now we want to work on the UI, but we don't want data to post to real Twitter. "Why do you keep posting 'asdf asdf asdf' to Twitter?" UI development involves a lot of exploration. Need to try things out with data. We want to be able to control the data we're working with. "We want carefully-curated abnormal data to test the edges of our UI." (06:30) We could have a second Twitter account to fill with junk data. Or, we could use the Twitter API sandbox. Problem: we don't have much control over the data set. Eg. We can't just "reset" back to what it used to be. Problem: what about when we're hacking on a plane? Plus, we want to be able to share test data between developers. (09:10) What can we do instead? Let's make a "fake" Twitter service we run on our machine. "Fake" Twitter gives us something our application can talk to that is under our control. Having a "fake" Twitter service creates new problems Project wants to grow larger and larger Now we have to run more things Creates more obstacles between checking out the code and getting work done   (12:35) Rather than a "fake" Twitter service, we want to "fake it" inside the application. What is "faking it"? Is this the same as "mocking"? Use a protocol for our Twitter API "handle". Allows for an alternative implementation. Not the same as mocking We are not trying to recreate all the possibilities. We are not trying to use it to test the component code.   The purpose is different than mocking. The Twitter "faker" is to help us work on the rest of the application. The "faker" is about being productive, not about testing. (17:20) Can have the faker start with useful data. Default data in the faker can launch you straight into dev productivity. "You want automation to support your human-centric exploration of things." "If your environment is as fast as it can possibly be, then it allows you to be as fast as you can possibly be." (20:10) Can use the faker for changing the interaction Eg. have a "slow" mode that makes all the requests take longer. Useful to answer the question: "What does this UI feel like when everything gets slow?" "The faker can implement behavior you need, for exploring the space you need to cover, to converge on the right solution." (22:00) Can have the faker pretend something was posted manually. Allows you to see how the UI behaves when the backend discovers a manual post. (23:00) Goals of faking Support exploration. Not about testing and validation Support the human, creative side of development Support the developer experience    Related episodes:  006: All Wrapped Up in Twitter 021: Mutate the Internet 022: Evidence of Attempted Posting 023: Poster Child 024: You Are Here, But Why?  Clojure in this episode:  defprotocol defrecord component/system-map  Related projects:  Component

Nate wants to experiment with the UI, but Twitter keeps getting the results. <ul> <li>"This thing that we're making because we're lazy has now taken 4 or 5 weeks to implement."</li> <li>Last week: "worker" logic vs "decider" logic. Allowed us to flatten the logic.</li> <li>"You can spend months on the backend and people think you've barely got anything done. You can spend two days on the UI and then people think you're making progress."</li> <li>(04:20) Now we want to work on the UI, but we don't want data to post to real Twitter.</li> <li>"Why do you keep posting 'asdf asdf asdf' to Twitter?"</li> <li>UI development involves a lot of exploration. Need to try things out with data.</li> <li>We want to be able to control the data we're working with.</li> <li>"We want carefully-curated abnormal data to test the edges of our UI."</li> <li>(06:30) We could have a second Twitter account to fill with junk data.</li> <li>Or, we could use the Twitter API sandbox.</li> <li>Problem: we don't have much control over the data set. Eg. We can't just "reset" back to what it used to be.</li> <li>Problem: what about when we're hacking on a plane?</li> <li>Plus, we want to be able to share test data between developers.</li> <li>(09:10) What can we do instead? Let's make a "fake" Twitter service we run on our machine.</li> <li>"Fake" Twitter gives us something our application can talk to that is under our control.</li> <li>Having a "fake" Twitter service creates new problems <ul> <li>Project wants to grow larger and larger</li> <li>Now we have to run more things</li> <li>Creates more obstacles between checking out the code and getting work done</li> </ul> </li> <li>(12:35) Rather than a "fake" Twitter service, we want to "fake it" inside the application.</li> <li>What is "faking it"? Is this the same as "mocking"?</li> <li>Use a protocol for our Twitter API "handle". Allows for an alternative implementation.</li> <li>Not the same as mocking <ul> <li>We are not trying to recreate all the possibilities.</li> <li>We are not trying to use it to test the component code.</li> </ul> </li> <li>The purpose is different than mocking. The Twitter "faker" is to help us work on the rest of the application.</li> <li>The "faker" is about being productive, not about testing.</li> <li>(17:20) Can have the faker start with useful data.</li> <li>Default data in the faker can launch you straight into dev productivity.</li> <li>"You want automation to support your human-centric exploration of things."</li> <li>"If your environment is as fast as it can possibly be, then it allows you to be as fast as you can possibly be."</li> <li>(20:10) Can use the faker for changing the interaction</li> <li>Eg. have a "slow" mode that makes all the requests take longer.</li> <li>Useful to answer the question: "What does this UI feel like when everything gets slow?"</li> <li>"The faker can implement behavior you need, for exploring the space you need to cover, to converge on the right solution."</li> <li>(22:00) Can have the faker pretend something was posted manually.</li> <li>Allows you to see how the UI behaves when the backend discovers a manual post.</li> <li>(23:00) Goals of faking <ul> <li>Support exploration. Not about testing and validation</li> <li>Support the human, creative side of development</li> <li>Support the developer experience</li> </ul> </li> </ul> Related episodes: <ul> <li><a href="/episode/006-all-wrapped-up-in-twitter" rel="nofollow" target="_blank">006: All Wrapped Up in Twitter</a></li> <li><a href="/episode/021-mutate-the-internet" rel="nofollow" target="_blank">021: Mutate the Internet</a></li> <li><a href="/episode/022-evidence-of-attempted-posting/" rel="nofollow" target="_blank">022: Evidence of Attempted Posting</a></li> <li><a href="/episode/023-poster-child" rel="nofollow" target="_blank">023: Poster Child</a></li> <li><a href="/episode/024-you-are-here-but-why" rel="nofollow" target="_blank">024: You Are Here, But Why?</a></li> </ul> Clojure in this episode: <ul> <li><code>defprotocol</code></li> <li><code>defrecord</code></li> <li><code>component/system-map</code></li> </ul> Related projects: <ul> <li><a href="https://github.com/stuartsierra/component" rel="nofollow" target="_blank">Component</a></li></ul>

Ep 025: Fake Results, Real Speed

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "Should I use lein, boot, or tools.deps?" We assemble a list of build tool characteristics and talk about how each tool stacks up before giving our recommendations. Selected quotes:  "The best thing about boot is that you can use all the flexibility of Clojure code. The worst thing about boot is that you can use all the flexibility of Clojure code." "Tools.deps, the non-build build tool." "I have a file, it's got Clojure in it, and I want to run it." "Tools.deps has enabled people to make build functions that stand alone. They don't have any ceremony to become part of the tool. It's just a main."

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "Should I use lein, boot, or tools.deps?" We assemble a list of build tool characteristics and talk about how each tool stacks up before giving our recommendations. Selected quotes: <ul> <li>"The best thing about boot is that you can use all the flexibility of Clojure code. The worst thing about boot is that you can use all the flexibility of Clojure code."</li> <li>"Tools.deps, the non-build build tool."</li> <li>"I have a file, it's got Clojure in it, and I want to run it."</li> <li>"Tools.deps has enabled people to make build functions that stand alone. They don't have any ceremony to become part of the tool. It's just a main."</li></ul>

Ep 040: Should I Use Lein, Boot, or Tools.deps?

Nate continues to explore the REPL by gluing it to his editor to see what happens.  We revisit Tic-Tac-Toe and change it using our new REPL superpowers. Let's add request logging to the play endpoint: /play?row=0&amp;col=1. Need to add log/info calls in handler function for play endpoint: on-play. Naive Christoph would add logging to the function, recompile, and run the jar. Less naive Christoph would reload the namespace but still restart the web server. Crazy idea: paste the function definition into the REPL! Copy the whole defn for on-play Go to the REPL window Switch to the app.main namespace (where we put on-play) Paste the function definition into the REPL   No restarting required! Each time we evalute the defn in the REPL, the new function replaces the old version immediately! We can iterate on a single function quickly. Clojure is Lisp, and Lisp is dynamic and isomorphic Dynamic: can change definition on the fly, so the new function exists immediately after executing the definition Isomorphic: everything is a "form". No special "declaration syntax" vs "expression syntax". A declaration is a form just like any other expression.   "Clojure is dynamic to the end. Every statement is modifying the running application, and because every statement has access to the entire application, all the way down to the definitions, you can redefine on the fly." Declarations are just ordinary macros (def, defn, defmacro, etc), not special syntax only the compiler understands. A declaration macro updates the enclosing namespace dynamically on the fly! "You just replaced the wheels on the car while you were driving." "I can replace the steering wheel and my hands don't even realize they're using a new steering wheel." "Running the form is what brings that thing dynamically into existence or replaces the one that was there." "It's the way you can speed your development up because you can replace these functions on the fly." Problem: you have to copy and paste between the editor and the REPL. Idea: use terminal automation to help with the copy + paste! "Yet another example of solving a problem you probably shouldn't even have." Pre-Lisp thinking: "The right way to do software is to compile it from grains of sand each and every time, and then run it from the beginning." Better Idea: Connect the REPL directly to your editor. (See "More reading" for how.) How it works: Move your cursor to the form to evaluate Do the "right" key combo (depends on your editor) Editor sends the form to the REPL REPL evaluates the form and sends the result back Editor shows the result   Use comment blocks as a nifty way to provide executable examples within the code. Your editor is a first-class REPL.  Related episodes:  004: Atomic Curls 012: Embrace the REPL  More reading:  Enhancing your REPL workflow Guidelines for REPL-Aided Development  Clojure in this episode:  ns, in-ns, use *ns*, ns-map def, defn comment let println clojure.tools.logging/debug  Related projects:  clojure.tools.logging for application logging vim-fireplace for VIM connected REPL Cider for Emacs connected REPL Ring for HTTP Compojure for HTTP request routing

Nate continues to explore the REPL by gluing it to his editor to see what happens. <ul> <li>We revisit Tic-Tac-Toe and change it using our new REPL superpowers.</li> <li>Let's add request logging to the play endpoint: <code>/play?row=0&amp;col=1</code>.</li> <li>Need to add <code>log/info</code> calls in handler function for play endpoint: <code>on-play</code>.</li> <li>Naive Christoph would add logging to the function, recompile, and run the jar.</li> <li>Less naive Christoph would reload the namespace but still restart the web server.</li> <li>Crazy idea: paste the function definition into the REPL! <ol> <li>Copy the whole <code>defn</code> for <code>on-play</code></li> <li>Go to the REPL window</li> <li>Switch to the <code>app.main</code> namespace (where we put <code>on-play</code>)</li> <li>Paste the function definition into the REPL</li> </ol> </li> <li>No restarting required! Each time we evalute the <code>defn</code> in the REPL, the new function replaces the old version immediately!</li> <li>We can iterate on a single function quickly.</li> <li>Clojure is Lisp, and Lisp is dynamic and isomorphic <ul> <li>Dynamic: can change definition on the fly, so the new function exists immediately after executing the definition</li> <li>Isomorphic: everything is a "form". No special "declaration syntax" vs "expression syntax". A declaration is a form just like any other expression.</li> </ul> </li> <li>"Clojure is dynamic to the end. Every statement is modifying the running application, and because every statement has access to the entire application, all the way down to the definitions, you can redefine on the fly."</li> <li>Declarations are just ordinary macros (<code>def</code>, <code>defn</code>, <code>defmacro</code>, etc), not special syntax only the compiler understands.</li> <li>A declaration macro updates the enclosing namespace dynamically on the fly!</li> <li>"You just replaced the wheels on the car while you were driving."</li> <li>"I can replace the steering wheel and my hands don't even realize they're using a new steering wheel."</li> <li>"Running the form is what brings that thing dynamically into existence or replaces the one that was there."</li> <li>"It's the way you can speed your development up because you can replace these functions on the fly."</li> <li>Problem: you have to copy and paste between the editor and the REPL.</li> <li>Idea: use terminal automation to help with the copy + paste!</li> <li>"Yet another example of solving a problem you probably shouldn't even have."</li> <li>Pre-Lisp thinking: "The right way to do software is to compile it from grains of sand each and every time, and then run it from the beginning."</li> <li>Better Idea: Connect the REPL directly to your editor. (See "More reading" for how.)</li> <li>How it works: <ul> <li>Move your cursor to the form to evaluate</li> <li>Do the "right" key combo (depends on your editor)</li> <li>Editor sends the form to the REPL</li> <li>REPL evaluates the form and sends the result back</li> <li>Editor shows the result</li> </ul> </li> <li>Use <code>comment</code> blocks as a nifty way to provide executable examples within the code.</li> <li>Your editor is a first-class REPL.</li> </ul> Related episodes: <ul> <li><a href="/episode/004-atomic-curls" rel="nofollow" target="_blank">004: Atomic Curls</a></li> <li><a href="/episode/012-embrace-the-repl" rel="nofollow" target="_blank">012: Embrace the REPL</a></li> </ul> More reading: <ul> <li><a href="https://clojure.org/guides/repl/enhancing_your_repl_workflow" rel="nofollow" target="_blank">Enhancing your REPL workflow</a></li> <li><a href="https://clojure.org/guides/repl/guidelines_for_repl_aided_development" rel="nofollow" target="_blank">Guidelines for REPL-Aided Development</a></li> </ul> Clojure in this episode: <ul> <li><code>ns</code>, <code>in-ns</code>, <code>use</code></li> <li><code>*ns*</code>, <code>ns-map</code></li> <li><code>def</code>, <code>defn</code></li> <li><code>comment</code></li> <li><code>let</code></li> <li><code>println</code></li> <li><code>clojure.tools.logging/debug</code></li> </ul> Related projects: <ul> <li><a href="https://github.com/clojure/tools.logging" rel="nofollow" target="_blank">clojure.tools.logging</a> for application logging</li> <li><a href="https://github.com/tpope/vim-fireplace" rel="nofollow" target="_blank">vim-fireplace</a> for VIM connected REPL</li> <li><a href="https://github.com/clojure-emacs/cider" rel="nofollow" target="_blank">Cider</a> for Emacs connected REPL</li> <li><a href="https://github.com/ring-clojure/ring" rel="nofollow" target="_blank">Ring</a> for HTTP</li> <li><a href="https://github.com/weavejester/compojure" rel="nofollow" target="_blank">Compojure</a> for HTTP request routing</li></ul>

Episode 013: Connect the REPL

Nate is worried about the hardcoded credentials in the code.  It's episode 011 on 01/11. It's binary! "As a developer, you quickly learn what's under your control and what's not. Very little is under your control." Don't accidentally check in the credentials. "We need a configuration management system. Oh wait! That's a totally different problem." What about putting the configuration into an EDN file? Let's call it config.edn Why EDN? Isn't JSON the "one, true format for config information"? Pros of EDN: native to Clojure can have comments is extensible   Why not environment variables? Environment variables are great for production, but in development files are better. Have to restart the REPL to change env variables. Make a component that reads the config. That will reload config when you reset with component.repl. Two main considerations: Dynamically reloading configuration during development Plumbing the configuration values through the app   Make a namespace for app.config "Files are way more fungible than the environment." We want both options: env for production and a file for dev. Make two functions in app.config: from-env and from-file. Use schema to make sure both functions return the same config map. "A thing I have done before...you decide if it's clever." Define a default configuration and then merge the config maps with that. Better yet, from-env handles defaults and we merge the map from dev.edn into that. Can use environ with Leiningen profiles. Still requires restarting the REPL. Defaults should make sense for development, so you can just check out and run. For bad config, we want helpful error messages, not stack traces. What goes in configuration? Items under your control Items that vary   Twitter API URL does not vary. Even if Twitter provided sandbox URLs, those URLs don't vary. The config option should be "production" and "sandbox", not the URL. The wrapper code will select the right URL. Avoid the nonsense of trying to infer "sandbox" from reading the URL. "The hallmark of good design is: the less thinking you have to do, the better." "The more semantic the config, the less thinking you have to do." It's important to think about the data first, where it comes from, and where it goes.  Clojure in this episode:  merge try, catch slurp clojure.edn/read-string environ.core/env component.repl/reset  Related projects:  Component component.repl Environ Leiningen, profile support Schema  Code sample from this episode: (ns app.config  (:require    [clojure.edn :as edn]    [environ.core :refer [env]]))(defn from-env []  {:twitter-key (or (env :twitter-key) "")   :twitter-secret (or (env :twitter-secret) "")   :initial-tweets (or (env :initial-tweets) 20))(defn config []  (merge (from-env)         (edn/read-string (try (slurp "dev.edn") (catch Throwable e "{}")))))

Nate is worried about the hardcoded credentials in the code. <ul> <li>It's episode 011 on 01/11. It's binary!</li> <li>"As a developer, you quickly learn what's under your control and what's not. Very little is under your control."</li> <li>Don't accidentally check in the credentials.</li> <li>"We need a configuration management system. Oh wait! That's a totally different problem."</li> <li>What about putting the configuration into an EDN file?</li> <li>Let's call it <code>config.edn</code></li> <li>Why EDN? Isn't JSON the "one, true format for config information"?</li> <li>Pros of EDN: <ul> <li>native to Clojure</li> <li>can have comments</li> <li>is extensible</li> </ul> </li> <li>Why not environment variables?</li> <li>Environment variables are great for production, but in development files are better.</li> <li>Have to restart the REPL to change env variables.</li> <li>Make a component that reads the config. That will reload config when you <code>reset</code> with component.repl.</li> <li>Two main considerations: <ol> <li>Dynamically reloading configuration during development</li> <li>Plumbing the configuration values through the app</li> </ol> </li> <li>Make a namespace for <code>app.config</code></li> <li>"Files are way more fungible than the environment."</li> <li>We want both options: env for production and a file for dev.</li> <li>Make two functions in <code>app.config</code>: <code>from-env</code> and <code>from-file</code>.</li> <li>Use schema to make sure both functions return the same config map.</li> <li>"A thing I have done before...you decide if it's clever."</li> <li>Define a default configuration and then <code>merge</code> the config maps with that.</li> <li>Better yet, <code>from-env</code> handles defaults and we <code>merge</code> the map from <code>dev.edn</code> into that.</li> <li>Can use <code>environ</code> with Leiningen profiles. Still requires restarting the REPL.</li> <li>Defaults should make sense for development, so you can just check out and run.</li> <li>For bad config, we want helpful error messages, not stack traces.</li> <li>What goes in configuration? <ul> <li>Items under your control</li> <li>Items that vary</li> </ul> </li> <li>Twitter API URL does not vary.</li> <li>Even if Twitter provided sandbox URLs, those URLs don't vary. The config option should be "production" and "sandbox", not the URL. The wrapper code will select the right URL.</li> <li>Avoid the nonsense of trying to infer "sandbox" from reading the URL.</li> <li>"The hallmark of good design is: the less thinking you have to do, the better."</li> <li>"The more semantic the config, the less thinking you have to do."</li> <li>It's important to think about the data first, where it comes from, and where it goes.</li> </ul> Clojure in this episode: <ul> <li><code>merge</code></li> <li><code>try</code>, <code>catch</code></li> <li><code>slurp</code></li> <li><code>clojure.edn/read-string</code></li> <li><code>environ.core/env</code></li> <li><code>component.repl/reset</code></li> </ul> Related projects: <ul> <li><a href="https://github.com/stuartsierra/component" rel="nofollow" target="_blank">Component</a></li> <li><a href="https://github.com/stuartsierra/component.repl" rel="nofollow" target="_blank">component.repl</a></li> <li><a href="https://github.com/weavejester/environ" rel="nofollow" target="_blank">Environ</a></li> <li><a href="https://leiningen.org/" rel="nofollow" target="_blank">Leiningen</a>, <a href="https://github.com/technomancy/leiningen/blob/stable/doc/PROFILES.md" rel="nofollow" target="_blank">profile support</a></li> <li><a href="https://github.com/plumatic/schema" rel="nofollow" target="_blank">Schema</a></li> </ul> Code sample from this episode: <code>(ns app.config (:require [clojure.edn :as edn] [environ.core :refer [env]])) (defn from-env [] {:twitter-key (or (env :twitter-key) "") :twitter-secret (or (env :twitter-secret) "") :initial-tweets (or (env :initial-tweets) 20)) (defn config [] (merge (from-env) (edn/read-string (try (slurp "dev.edn") (catch Throwable e "{}"))))) </code>

Episode 011: The Convention of Configuration

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "How can I save my data from serialization?" We record our thoughts on the many trade-offs we have encountered preserving our data when it leaves our programs. Selected quotes:  "Clojure has the best data structures on the planet." "One of the reasons why JSON is so popular is because XML was so overbearingly hard." "XML decided that trees aren't dimensional enough, so they added another dimension in attributes." "Serialization formats aren't for humans, Nate, what are you talking about?!" "EDN isn't horrible to look at because it's just Clojure data structures." "We don't want freezer burn!"  Related episodes:  014: Fiddle with the REPL  Links:  EDN Transit Nippy Fressian fress: Fressian for Clojure(Script) AND WASM!

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "How can I save my data from serialization?" We record our thoughts on the many trade-offs we have encountered preserving our data when it leaves our programs. Selected quotes: <ul> <li>"Clojure has the best data structures on the planet."</li> <li>"One of the reasons why JSON is so popular is because XML was so overbearingly hard."</li> <li>"XML decided that trees aren't dimensional enough, so they added another dimension in attributes."</li> <li>"Serialization formats aren't for humans, Nate, what are you talking about?!"</li> <li>"EDN isn't horrible to look at because it's just Clojure data structures."</li> <li>"We don't want freezer burn!"</li> </ul> Related episodes: <ul> <li><a href="/episode/014-fiddle-with-the-repl" rel="nofollow" target="_blank">014: Fiddle with the REPL</a></li> </ul> Links: <ul> <li><a href="https://github.com/edn-format/edn" rel="nofollow" target="_blank">EDN</a></li> <li><a href="https://github.com/cognitect/transit-format" rel="nofollow" target="_blank">Transit</a></li> <li><a href="https://github.com/ptaoussanis/nippy" rel="nofollow" target="_blank">Nippy</a></li> <li><a href="https://github.com/Datomic/fressian" rel="nofollow" target="_blank">Fressian</a></li> <li><a href="https://github.com/pkpkpk/fress" rel="nofollow" target="_blank">fress: Fressian for Clojure(Script) AND WASM!</a></li></ul>

Ep 053: How Can I Save My Data From Serialization?

Nate finds that trouble comes in pairs.  Last week, we were able to make our parsing lazy. Each step was lazy, and we side-stepped the landmine of waiting to perform computation till after the file is closed. (02:00) There's a new error: Sprinkles are failing! Sprinkles are the "likes" of DonutGram, and are the metric by which all donuts are judged. Log lines are showing up, like failed to add sprinkle to donut 23948. Let's write another regexp and handler. This is easy! But wait, we notice that there is another log line right after: sprinkle fail reason: db timeout exceeded. We want to capture that reason as part of the error, but it's on a different line. Our current code (from Episode 029), has a nifty abstraction with a paired regexp and handler function. If the regexp matches, then the matches are passed to the handler. The underlying assumption is that each line stands alone. Now we have two lines, and that breaks our pre-abstraction. Our function needs more context, give our function two lines instead of just one. Our parse-details function goes out the window, what can we do to get more context for each parsing? (07:05) Let's go to the Clojure library and check out the partition function. Used to break up a list into chunks. Eg. Chunking arg lists into key/value pairs. The step argument varies how far you reach into the collection for the next chunk. For instance, (partition 2 1 (range 1 7)) yields ((1 2) (2 3) (3 4) (4 5) (5 6)). Each element is paired with it's following element. Doing this with our log lines means we have a second line in the group that we hand to our parsing function. The parsing function can look in the first line for the error, and then if it finds it, look in the second line for the reason. If both are found, we return a sprinkle error record. If either regex fails, nil is returned, so our list becomes a sequence of sprinkle errors or nils. Then we can filter out the nils and summarize the sprinkle errors. "Some of these errors hurt more than others." The sequence is not fully realized, because partition is lazy. It constructs chunks on demand. "This is the beauty of Clojure core, all this stuff is lazy. Except, of course, for the eager parts." (15:45) Problem: when looking through log lines, there are often other log lines in between. What happens if our sprinkle fail reason is not on the line immediately after the sprinkle error? We might need to look ahead a little further ahead than the next line. One solution is to increase the partition size when chunking the lines. How about (partition 10 1 lines) or (partition 100 1 lines)? The first line is the indication that there's an error, and then look through the rest of the lines for the reason. We could log out "should never happen" if we don't find the error in the next 10 lines. It becomes a magic number problem, how far do we need to look ahead? At least these large partitions use structural sharing to re-use the record memory. We only pay extra for the containing collections. "Is there a partition-infinity?" "It feels like something we can be lazy about, and push off to our next episode." "It's like when a show jumps the shark and you know it will come to an end, but you're just not sure which season that's going to be in." What if parsing the first line determines how many further lines we need to consume? "Fun is a loaded term." "It always puts you in an interesting situation when your pre-optimization doesn't quite hold up a month down the road." "I had the perfect abstraction for the wrong shape." "The world changed around me." "Clearly it's not the fault of my code."  Related episodes:  028: Fail Donut 029: Problem Unknown: Log Lines 030: Lazy Does It  Clojure in this episode:  partition -&gt;&gt; map, filter group-by, frequencies  Code sample from this episode: (ns devops.week-03  (:require    [devops.week-01 :refer [parse-line]]    [devops.week-02 :refer [process-log]]    ))(defn parse-sprinkle-error  [line-pairs]  (let [[first-line second-line] line-pairs        [_whole donut-id] (some-&gt;&gt; first-line :log/message (re-matches #"failed to add sprinkle to donut (\d+)"))        [_whole error] (some-&gt;&gt; second-line :log/message (re-matches #"sprinkle fail reason: (.*)"))]    (when (and donut-id error)      (merge first-line             {:kind :sprinkle              :sprinkle/donut-id donut-id              :sprinkle/error error}))))(defn sprinkle-errors  [lines]  (-&gt;&gt; lines       (partition 2 1)       (map parse-sprinkle-error)       (remove nil?)))(defn sprinkle-errors-by-type  [errors]  (-&gt;&gt; errors       (map :sprinkle/error)       (frequencies)))(comment  (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-errors sprinkle-errors-by-type))  ) Log file sample: 2019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | failed to add sprinkle to donut 239482019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | sprinkle fail reason: should never happen2019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | failed to add sprinkle to donut 942382019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | sprinkle fail reason: timeout exceeded threshold2019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | failed to add sprinkle to donut 248392019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | sprinkle fail reason: too many requests2019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | failed to add sprinkle to donut 192382019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | sprinkle fail reason: should never happen2019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | failed to add sprinkle to donut 504932019-05-14 16:48:55 | process-Poster | INFO  | com.donutgram.poster | sprinkle fail reason: unknown state

Nate finds that trouble comes in pairs. <ul> <li>Last week, we were able to make our parsing lazy.</li> <li>Each step was lazy, and we side-stepped the landmine of waiting to perform computation till after the file is closed.</li> <li>(02:00) There's a new error: Sprinkles are failing!</li> <li>Sprinkles are the "likes" of DonutGram, and are the metric by which all donuts are judged.</li> <li>Log lines are showing up, like <code>failed to add sprinkle to donut 23948</code>.</li> <li>Let's write another regexp and handler. This is easy!</li> <li>But wait, we notice that there is another log line right after: <code>sprinkle fail reason: db timeout exceeded</code>.</li> <li>We want to capture that reason as part of the error, but it's on a different line.</li> <li>Our current code (from Episode 029), has a nifty abstraction with a paired regexp and handler function. If the regexp matches, then the matches are passed to the handler.</li> <li>The underlying assumption is that each line stands alone.</li> <li>Now we have two lines, and that breaks our pre-abstraction.</li> <li>Our function needs more context, give our function two lines instead of just one.</li> <li>Our <code>parse-details</code> function goes out the window, what can we do to get more context for each parsing?</li> <li>(07:05) Let's go to the Clojure library and check out the <code>partition</code> function.</li> <li>Used to break up a list into chunks. Eg. Chunking arg lists into key/value pairs.</li> <li>The <code>step</code> argument varies how far you reach into the collection for the next chunk.</li> <li>For instance, <code>(partition 2 1 (range 1 7))</code> yields <code>((1 2) (2 3) (3 4) (4 5) (5 6))</code>. Each element is paired with it's following element.</li> <li>Doing this with our log lines means we have a second line in the group that we hand to our parsing function.</li> <li>The parsing function can look in the first line for the error, and then if it finds it, look in the second line for the reason. If both are found, we return a sprinkle error record.</li> <li>If either regex fails, <code>nil</code> is returned, so our list becomes a sequence of sprinkle errors or <code>nil</code>s.</li> <li>Then we can filter out the <code>nil</code>s and summarize the sprinkle errors.</li> <li>"Some of these errors hurt more than others."</li> <li>The sequence is not fully realized, because <code>partition</code> is lazy. It constructs chunks on demand.</li> <li>"This is the beauty of Clojure core, all this stuff is lazy. Except, of course, for the eager parts."</li> <li>(15:45) Problem: when looking through log lines, there are often other log lines in between.</li> <li>What happens if our sprinkle fail reason is not on the line immediately after the sprinkle error?</li> <li>We might need to look ahead a little further ahead than the next line.</li> <li>One solution is to increase the partition size when chunking the lines. How about <code>(partition 10 1 lines)</code> or <code>(partition 100 1 lines)</code>?</li> <li>The first line is the indication that there's an error, and then look through the rest of the lines for the reason.</li> <li>We could log out "should never happen" if we don't find the error in the next 10 lines.</li> <li>It becomes a magic number problem, how far do we need to look ahead?</li> <li>At least these large partitions use structural sharing to re-use the record memory. We only pay extra for the containing collections.</li> <li>"Is there a <code>partition-infinity</code>?"</li> <li>"It feels like something we can be lazy about, and push off to our next episode."</li> <li>"It's like when a show jumps the shark and you know it will come to an end, but you're just not sure which season that's going to be in."</li> <li>What if parsing the first line determines how many further lines we need to consume?</li> <li>"Fun is a loaded term."</li> <li>"It always puts you in an interesting situation when your pre-optimization doesn't quite hold up a month down the road."</li> <li>"I had the perfect abstraction for the wrong shape."</li> <li>"The world changed around me." "Clearly it's not the fault of my code."</li> </ul> Related episodes: <ul> <li><a href="/episode/028-fail-donut" rel="nofollow" target="_blank">028: Fail Donut</a></li> <li><a href="/episode/029-problem-unknown-log-lines" rel="nofollow" target="_blank">029: Problem Unknown: Log Lines</a></li> <li><a href="/episode/030-lazy-does-it" rel="nofollow" target="_blank">030: Lazy Does It</a></li> </ul> Clojure in this episode: <ul> <li><code>partition</code></li> <li><code>-&gt;&gt;</code></li> <li><code>map</code>, <code>filter</code></li> <li><code>group-by</code>, <code>frequencies</code></li> </ul> Code sample from this episode: <code>(ns devops.week-03 (:require [devops.week-01 :refer [parse-line]] [devops.week-02 :refer [process-log]] )) (defn parse-sprinkle-error [line-pairs] (let [[first-line second-line] line-pairs [_whole donut-id] (some-&gt;&gt; first-line :log/message (re-matches #"failed to add sprinkle to donut (\d+)")) [_whole error] (some-&gt;&gt; second-line :log/message (re-matches #"sprinkle fail reason: (.*)"))] (when (and donut-id error) (merge first-line {:kind :sprinkle :sprinkle/donut-id donut-id :sprinkle/error error})))) (defn sprinkle-errors [lines] (-&gt;&gt; lines (partition 2 1) (map parse-sprinkle-error) (remove nil?))) (defn sprinkle-errors-by-type [errors] (-&gt;&gt; errors (map :sprinkle/error) (frequencies))) (comment (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-errors sprinkle-errors-by-type)) )</code> Log file sample: <code>2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | failed to add sprinkle to donut 23948 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | sprinkle fail reason: should never happen 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | failed to add sprinkle to donut 94238 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | sprinkle fail reason: timeout exceeded threshold 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | failed to add sprinkle to donut 24839 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | sprinkle fail reason: too many requests 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | failed to add sprinkle to donut 19238 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | sprinkle fail reason: should never happen 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | failed to add sprinkle to donut 50493 2019-05-14 16:48:55 | process-Poster | INFO | com.donutgram.poster | sprinkle fail reason: unknown state</code>

Ep 031: Eager Abstraction

Each week, we discuss a different topic about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, our topic is: "Functions! Functions! Functions!" We wonder how we could function without these critical building blocks, so we catagorize their varied uses. Selected quotes:  "Functions put the fun in functional."   "Each function category has a different mindset." "Programming is more fun when you're only thinking about the problem in front of you." "Naming bits of computation helps you understand an abstraction without having to dip into it." "So you don't want the function to be called 'write-or-fetch-or-sleep-or-return!'?" "Side effecting functions shouldn't think. They are grunts." "The I/O fairy hands you data, and you get it all transformed with pure functions, and then you hand it back to the I/O fairy." "That Twitter use case, that has a lot more side effects."  Related episodes:  002: Tic-Tac-Toe, State in a Row 024: You Are Here, But Why?

Each week, we discuss a different topic about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, our topic is: "Functions! Functions! Functions!" We wonder how we could function without these critical building blocks, so we catagorize their varied uses. Selected quotes: <ul> <li>"Functions put the fun in functional."</li> </ul> <ul> <li>"Each function category has a different mindset."</li> <li>"Programming is more fun when you're only thinking about the problem in front of you."</li> <li>"Naming bits of computation helps you understand an abstraction without having to dip into it."</li> <li>"So you don't want the function to be called 'write-or-fetch-or-sleep-or-return!'?"</li> <li>"Side effecting functions shouldn't think. They are grunts."</li> <li>"The I/O fairy hands you data, and you get it all transformed with pure functions, and then you hand it back to the I/O fairy."</li> <li>"That Twitter use case, that has a lot more side effects."</li> </ul> Related episodes: <ul> <li><a href="/episode/002-tic-tac-toe-state-in-a-row" rel="nofollow" target="_blank">002: Tic-Tac-Toe, State in a Row</a></li> <li><a href="/episode/024-you-are-here-but-why" rel="nofollow" target="_blank">024: You Are Here, But Why?</a></li></ul>

Ep 052: Functions! Functions! Functions!

Nil Punning

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "What is 'nil punning'?" We gaze into the nil and find a surprising number of things to talk about. Selected quotes:  "The lowly, magnificent nil. Some people love it, some people hate it." "Null is the value you give your program if you want to see it die." "Nil is not null." "This function found nothing, and I passed that to the next function, and it found nothing in the nothing." "It's amazing how much nothing you can find in nothing." "You can pull data out without fear." "What does a nil Cat look like?" "A lot of arithmetic stuff is nil-intolerant." "No answer isn't going to start becoming an answer later."

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "What is 'nil punning'?" We gaze into the nil and find a surprising number of things to talk about. Selected quotes: <ul> <li>"The lowly, magnificent nil. Some people love it, some people hate it."</li> <li>"Null is the value you give your program if you want to see it die."</li> <li>"Nil is not null."</li> <li>"This function found nothing, and I passed that to the next function, and it found nothing in the nothing."</li> <li>"It's amazing how much nothing you can find in nothing."</li> <li>"You can pull data out without fear."</li> <li>"What does a nil Cat look like?"</li> <li>"A lot of arithmetic stuff is nil-intolerant."</li> <li>"No answer isn't going to start becoming an answer later."</li></ul>

Ep 047: What Is "Nil Punning"?

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "When is Clojure not the right tool for the job?" We look at the varied forms that Clojure can assume and consider where it might not fit. Selected quotes:  "Just reject all the jobs where Clojure is inappropriate and you'll always be able to use Clojure." "The JVM is like a super tanker. It will get a whole lot of work done. But it takes a little while to get going." "On the language level, there are social aspects. Bringing in Clojure covertly will make the rest of the team angry." "A lot of times, when talking about technical things, we tend to overlook the human effects." "Two questions: Is the technology suitable? Are we going to get screwed if we go down this path?" "There is a conceptual leap into functional programming that is non-trivial." "People will have a hard time letting go of their existing language until they can feel how Clojure is different."  Related episodes  038: How do I convince my coworkers to use Clojure?

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "When is Clojure not the right tool for the job?" We look at the varied forms that Clojure can assume and consider where it might not fit. Selected quotes: <ul> <li>"Just reject all the jobs where Clojure is inappropriate and you'll always be able to use Clojure."</li> <li>"The JVM is like a super tanker. It will get a whole lot of work done. But it takes a little while to get going."</li> <li>"On the language level, there are social aspects. Bringing in Clojure covertly will make the rest of the team angry."</li> <li>"A lot of times, when talking about technical things, we tend to overlook the human effects."</li> <li>"Two questions: Is the technology suitable? Are we going to get screwed if we go down this path?"</li> <li>"There is a conceptual leap into functional programming that is non-trivial."</li> <li>"People will have a hard time letting go of their existing language until they can feel how Clojure is different."</li> </ul> Related episodes <ul> <li><a href="/episode/038-how-do-i-convince-my-coworkers-to-use-clojure" rel="nofollow" target="_blank">038: How do I convince my coworkers to use Clojure?</a></li></ul>

Ep 046: When Is Clojure Not the Right Tool for the Job?

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "Working with heavily nested trees." We discuss three powerful libraries (Specter, Spectacles, and clojure.walk) and where they might fit into our Clojure programs. Selected quotes:  "Tree manipulation is like surgery, you need to get down to the right level before you start making changes." "I've seen people come up with novel and interesting solutions to problems that other people just don't have." "Spec is a structural type checker, instead of a name-based type checker, which is far more useful." "Every time you reach for a tool, you're inviting its complexity into your project." "The structure of your data will lead you toward a particular tool."  Related episodes:  020: Data Dessert - Summary episode for the time log series  Links:  clojure.walk Specter Spectacles

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "Working with heavily nested trees." We discuss three powerful libraries (Specter, Spectacles, and clojure.walk) and where they might fit into our Clojure programs. Selected quotes: <ul> <li>"Tree manipulation is like surgery, you need to get down to the right level before you start making changes."</li> <li>"I've seen people come up with novel and interesting solutions to problems that other people just don't have."</li> <li>"Spec is a structural type checker, instead of a name-based type checker, which is far more useful."</li> <li>"Every time you reach for a tool, you're inviting its complexity into your project."</li> <li>"The structure of your data will lead you toward a particular tool."</li> </ul> Related episodes: <ul> <li><a href="/episode/020-data-dessert" rel="nofollow" target="_blank">020: Data Dessert</a> - Summary episode for the time log series</li> </ul> Links: <ul> <li><a href="https://clojuredocs.org/clojure.walk" rel="nofollow" target="_blank">clojure.walk</a></li> <li><a href="https://github.com/redplanetlabs/specter" rel="nofollow" target="_blank">Specter</a></li> <li><a href="https://github.com/stathissideris/spectacles" rel="nofollow" target="_blank">Spectacles</a></li></ul>

Ep 054: The Forest in the Trees

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "Opt-In Complexity" We discuss complexity and try to come up with a simple explanation for why Clojurians avoid it so ruthlessly. Selected quotes:  "Abstraction: the thing that creates more complexity while making you feel like you have less." "Clojure people seem to be allergic to complexity." "Frameworks are the breeding ground for complexity." "Complexity is the enemy of long lived code bases."   "Each part of the application is in its own vault of isolation, and they only get to come together and interact in the lobby." "You can't be afraid of something that hasn't scared you yet." "It's very difficult to say no once you've said yes."  Links:  Simple Made Easy Luminus Hoplon Pedestal

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "Opt-In Complexity" We discuss complexity and try to come up with a simple explanation for why Clojurians avoid it so ruthlessly. Selected quotes: <ul> <li>"Abstraction: the thing that creates more complexity while making you feel like you have less."</li> <li>"Clojure people seem to be allergic to complexity."</li> <li>"Frameworks are the breeding ground for complexity."</li> <li>"Complexity is the enemy of long lived code bases."</li> </ul> <ul> <li>"Each part of the application is in its own vault of isolation, and they only get to come together and interact in the lobby."</li> <li>"You can't be afraid of something that hasn't scared you yet."</li> <li>"It's very difficult to say no once you've said yes."</li> </ul> Links: <ul> <li><a href="https://www.infoq.com/presentations/Simple-Made-Easy/" rel="nofollow" target="_blank">Simple Made Easy</a></li> <li><a href="http://www.luminusweb.net/" rel="nofollow" target="_blank">Luminus</a></li> <li><a href="http://hoplon.io/" rel="nofollow" target="_blank">Hoplon</a></li> <li><a href="http://pedestal.io/" rel="nofollow" target="_blank">Pedestal</a></li></ul>

Ep 056: Opt-in Complexity

Nate and Christoph reflect on what they learned during the Twitter series.  6 months of podcast episodes! Situated programs: Part of the real world. Affect and affected by the world around it. (04:25) Concept 1: Was very helpful to focus on nailing down the algorithm before diving into the code. (06:00) Concept 2: Two kinds of data: operating data and forensic data Operating data: information you use for logic. Make it aggressively minimal. Forensic data: information you record, off to the side, to tell a story later. Record as much as feasible. Don't do logic on the forensic data! If you end up writing code to sift through the forensic data in the future, cherry pick out the data need to use and treat that as operational data for that problem.   "'No' is temporary. 'Yes' is forever." (09:45) Concept 3: Use components to wrap integrations We wrapped DB and Twitter integrations. If a component needs a resource, that resource should be a component. Because resources are components, you can substitute the real component with a "faker" component.   (11:10) Concept 4: Fake resources for productivity A "faker" component takes the place of a real component to enable developers to be more productive. Faking is not for testing code, it's for effective development. Can avoid Internet and latency. Can run the code right out of the repo. Allows you to explore how the whole system behaves during edge cases and behaviors. Allows you to start with useful information or quickly reset back to scenarios.   "If an edge case is going to be annoying in the wild, you might as well get used to it being annoying during development." (13:40) Concept 5: Aggressively decouple decision logic from imperative work Push side effects (like I/O) to the "edges", but some situations make that less straightforward. Challenge: our algorithm had a tick-tock: side effect, logic, side effect, logic, ... Our approach: separate each side effect and only do one at a time.   (16:10) Concept 6: Watch out for convenient side effects Eg. Doing a little bit of I/O in the middle of a function. Eg. Get "now" from the system clock in the middle of a function   (16:35) Concept 7: Side-effect assumptions make your system fragile. When you have code in one place that depends on something having been established by code in another place. Eg. Knowing the calling function has already done a check. There is an implicit umbrella of context. Creates a hidden dependency between those two places. When the assumption is violated, there's nothing to stop the code making the assumption from just marching off the cliff. Put the guard logic next to the code that needs it.   (19:15) Concept 8: Make context explicit A function should take all of its "knowledge" in as data. It should not assume something has been done for it elsewhere. "This forces you to write down all the things that matter instead of assuming something else has put things in place." Explicit context allows you to separate out imperative steps. "The hidden relationships, the ones that are only in my brain, those are the things that will completely burn me in 6 months."   (20:45) Concept 9: Favor instructions as data rather than instructions as function names. Eg. Our Twitter wrapper only has one invoke function. (Inspired by aws-api.) Function names aren't part of the data. If the "command" name is the function name, how do you match on it? You can't. When commands = function names, you have implicit information: "I must have command X because I'm on line Y." Observation: the description of the goal is usually more stable than the steps to achieve the goal. If all of the instructions are in data, the processing component can completely change how it achieves the goal without the calling component changing how it interacts.   (26:00) Concept 10: Treat components within your application as loosely coupled services. What is a "microservice"? When you make a request (aka "data"), ship it out, and get a response back (aka "data"). In Clojure, we can treat component interactions like loosely coupled APIs too: send them rich data, get rich data back. Get loose coupling on the inside of the service, not just between services.   (27:25) We want to help programmer effectiveness and reduce burnout. "We want to help you avoid situations where you're beating your head against the wall wondering where things went wrong." "One of the great benefits of simple design and Clojure, it allows you create things that are fun to create AND fun to maintain."  Message Queue discussion:  (29:15) "You know what else is a lot of fun? Hearing from our listeners!" We had an issue with our SSL certs. Thanks for the heads up and let us know if you have any tech trouble. "Automagically". We can't say we invented it, but we love that word. "What is magic? An invisible force with a visible effect. Sound an awful lot like a side effect!" "You start wielding the power, it feels GREAT! And then it all starts going wrong." Easy does not imply simple. Go watch that talk. (See below.)  Related episodes:  020: Data Dessert 021: Mutate the Internet 022: Evidence of Attempted Posting 023: Poster Child 024: You Are Here, But Why? 025: Fake Results, Real Speed 026: One Call to Rule Them All  Clojure in this episode:  nil  Related links:  Cognitect aws-api Simple Made Easy

Nate and Christoph reflect on what they learned during the Twitter series. <ul> <li>6 months of podcast episodes!</li> <li>Situated programs: Part of the real world. Affect and affected by the world around it.</li> <li>(04:25) Concept 1: Was very helpful to focus on nailing down the algorithm before diving into the code.</li> <li>(06:00) Concept 2: Two kinds of data: operating data and forensic data <ul> <li>Operating data: information you use for logic. Make it aggressively minimal.</li> <li>Forensic data: information you record, off to the side, to tell a story later. Record as much as feasible.</li> <li>Don't do logic on the forensic data!</li> <li>If you end up writing code to sift through the forensic data in the future, cherry pick out the data need to use and treat that as operational data for that problem.</li> </ul> </li> <li>"'No' is temporary. 'Yes' is forever."</li> <li>(09:45) Concept 3: Use components to wrap integrations <ul> <li>We wrapped DB and Twitter integrations.</li> <li>If a component needs a resource, that resource should be a component.</li> <li>Because resources are components, you can substitute the real component with a "faker" component.</li> </ul> </li> <li>(11:10) Concept 4: Fake resources for productivity <ul> <li>A "faker" component takes the place of a real component to enable developers to be more productive.</li> <li>Faking is not for testing code, it's for effective development.</li> <li>Can avoid Internet and latency.</li> <li>Can run the code right out of the repo.</li> <li>Allows you to explore how the whole system behaves during edge cases and behaviors.</li> <li>Allows you to start with useful information or quickly reset back to scenarios.</li> </ul> </li> <li>"If an edge case is going to be annoying in the wild, you might as well get used to it being annoying during development."</li> <li>(13:40) Concept 5: Aggressively decouple decision logic from imperative work <ul> <li>Push side effects (like I/O) to the "edges", but some situations make that less straightforward.</li> <li>Challenge: our algorithm had a tick-tock: side effect, logic, side effect, logic, ...</li> <li>Our approach: separate each side effect and only do one at a time.</li> </ul> </li> <li>(16:10) Concept 6: Watch out for convenient side effects <ul> <li>Eg. Doing a little bit of I/O in the middle of a function.</li> <li>Eg. Get "now" from the system clock in the middle of a function</li> </ul> </li> <li>(16:35) Concept 7: Side-effect assumptions make your system fragile. <ul> <li>When you have code in one place that depends on something having been established by code in another place.</li> <li>Eg. Knowing the calling function has already done a check.</li> <li>There is an implicit umbrella of context. Creates a hidden dependency between those two places.</li> <li>When the assumption is violated, there's nothing to stop the code making the assumption from just marching off the cliff.</li> <li>Put the guard logic next to the code that needs it.</li> </ul> </li> <li>(19:15) Concept 8: Make context explicit <ul> <li>A function should take all of its "knowledge" in as data. It should not assume something has been done for it elsewhere.</li> <li>"This forces you to write down all the things that matter instead of assuming something else has put things in place."</li> <li>Explicit context allows you to separate out imperative steps.</li> <li>"The hidden relationships, the ones that are only in my brain, those are the things that will completely burn me in 6 months."</li> </ul> </li> <li>(20:45) Concept 9: Favor instructions as data rather than instructions as function names. <ul> <li>Eg. Our Twitter wrapper only has one <code>invoke</code> function. (Inspired by aws-api.)</li> <li>Function names aren't part of the data. If the "command" name is the function name, how do you match on it? You can't.</li> <li>When commands = function names, you have implicit information: "I must have command X because I'm on line Y."</li> <li>Observation: the description of the goal is usually more stable than the steps to achieve the goal.</li> <li>If all of the instructions are in data, the processing component can completely change how it achieves the goal without the calling component changing how it interacts.</li> </ul> </li> <li>(26:00) Concept 10: Treat components within your application as loosely coupled services. <ul> <li>What is a "microservice"? When you make a request (aka "data"), ship it out, and get a response back (aka "data").</li> <li>In Clojure, we can treat component interactions like loosely coupled APIs too: send them rich data, get rich data back.</li> <li>Get loose coupling on the inside of the service, not just between services.</li> </ul> </li> <li>(27:25) We want to help programmer effectiveness and reduce burnout.</li> <li>"We want to help you avoid situations where you're beating your head against the wall wondering where things went wrong."</li> <li>"One of the great benefits of simple design and Clojure, it allows you create things that are fun to create AND fun to maintain."</li> </ul> Message Queue discussion: <ul> <li>(29:15) "You know what else is a lot of fun? Hearing from our listeners!"</li> <li>We had an issue with our SSL certs. Thanks for the heads up and let us know if you have any tech trouble.</li> <li>"Automagically". We can't say we invented it, but we love that word.</li> <li>"What is magic? An invisible force with a visible effect. Sound an awful lot like a side effect!"</li> <li>"You start wielding the power, it feels GREAT! And then it all starts going wrong."</li> <li>Easy does not imply simple. Go watch that talk. (See below.)</li> </ul> Related episodes: <ul> <li><a href="/episode/020-data-dessert" rel="nofollow" target="_blank">020: Data Dessert</a></li> <li><a href="/episode/021-mutate-the-internet" rel="nofollow" target="_blank">021: Mutate the Internet</a></li> <li><a href="/episode/022-evidence-of-attempted-posting/" rel="nofollow" target="_blank">022: Evidence of Attempted Posting</a></li> <li><a href="/episode/023-poster-child" rel="nofollow" target="_blank">023: Poster Child</a></li> <li><a href="/episode/024-you-are-here-but-why" rel="nofollow" target="_blank">024: You Are Here, But Why?</a></li> <li><a href="/episode/025-fake-results-real-speed" rel="nofollow" target="_blank">025: Fake Results, Real Speed</a></li> <li><a href="/episode/026-one-call-to-rule-them-all" rel="nofollow" target="_blank">026: One Call to Rule Them All</a></li> </ul> Clojure in this episode: <ul> <li><code>nil</code></li> </ul> Related links: <ul> <li><a href="https://github.com/cognitect-labs/aws-api" rel="nofollow" target="_blank">Cognitect aws-api</a></li> <li><a href="https://www.infoq.com/presentations/Simple-Made-Easy" rel="nofollow" target="_blank">Simple Made Easy</a></li></ul>

Ep 027: Collected Context

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "Sets! What are they good for?" We examine one of the lesser used data structures in Clojure and talk about its unique characteristics and uses. Selected quotes:  "Sets aren't going to get top billing." "Sets are really about uniqueness." "Sets let us calculate differences cheaply." "Clever is a word I used to like when I was a younger programmer." "Clever now equals hours of suffering!"

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the topic is: "Sets! What are they good for?" We examine one of the lesser used data structures in Clojure and talk about its unique characteristics and uses. Selected quotes: <ul> <li>"Sets aren't going to get top billing."</li> <li>"Sets are really about uniqueness."</li> <li>"Sets let us calculate differences cheaply."</li> <li>"Clever is a word I used to like when I was a younger programmer."</li> <li>"Clever now equals hours of suffering!"</li></ul>

Ep 055: Sets! What Are They Good For?

Christoph gets some work done by fiddling around.  Editor integration is a massive change in how to use the REPL. Put a comment block right underneath a function you are working on, and invoke the function with test arguments. Can quickly make changes to code and try it out--all in the same place! Problem: comment blocks littering the code. "A good rule of thumb I've found is: when I have to use the world 'careful', it's a big red flag. I'm doing something I should be able to prevent without having to be careful." Code in comment blocks can be helpful in the future. "'It's not done yet." What file is ever done? You're always going to come back to it in 6 months." Easy to skip around between forms you've run before. "It's like a random access REPL history." Ah ha moment: make a separate file for the helpful comment blocks. "[The comment blocks] are like the copilot of my development experience." "They're me helping me!" "You're your own copilot!" Separate file needed a namespace: the fiddle namespace was born. "I'm just fiddling around." Put the "fiddle files" in the dev tree so it only gets loading in development. "These fiddle files started multiplying, like little helpful rabbits." Like pages in a notebook centered on a theme. Each "page" is a file: a file for remembering how to call certain core functions a file for experimenting with date and time conversions a file for exploring a new concept a file for interacting with new code being developed   Never have to leave to editor. REPL is working behind the scenes. Unlike REPL history, you can share fiddle files. Fiddles can help show the developer's mindset during development. "It's like seeing into the back of your mind of the way you explore this on your own." Example: exploring a data set work on code for parsing a data file write different expressions to sift through the data e.g. threaded expression to: open the data, parse it, filter, and map build up helpers for making sense of the data parser and helpers in fiddle are the start of the "real" application code write examples with commentary   Example: exploring the working state of the application set of utility functions for grabbing information from component that set of helpers can be share between developers code that pulls out state from specific components all at once "Where did this nil come from?"   Example: exploring external APIs write simple function for calling the HTTP endpoint start calling it with different examples can easily see and re-run calls that you've tried Slow API? Use (def response (...)) to save a result, and write expressions using response.   "A fiddle file like a scratch pad for new features." Characteristics of fiddles a working set of expressions like a notebook with code around a theme like a scratch pad for exploring toward a solution can be shared written context from solving the problem   "The me of the future won't have as much access to the mental state of the me of the present." Do your future self a favor and write down some of your current mental context. Could make educational fiddles for new developers in a project. "Fiddles are a way of capturing process: a way of capturing the craft of making it, not just the outcome."  Related episodes:  012: Embrace the REPL 013: Connect the REPL 002: Tic-Tac-Toe, State in a Row  Clojure in this episode:  comment def, defn -&gt;, -&gt;&gt; filter, map, reduce select-keys clojure.pprint/  pprint print-table    Related projects:  Editors with REPL integration Project Jupyter Component Joda Time Java Time

Christoph gets some work done by fiddling around. <ul> <li>Editor integration is a massive change in how to use the REPL.</li> <li>Put a <code>comment</code> block right underneath a function you are working on, and invoke the function with test arguments.</li> <li>Can quickly make changes to code and try it out--all in the same place!</li> <li>Problem: comment blocks littering the code.</li> <li>"A good rule of thumb I've found is: when I have to use the world 'careful', it's a big red flag. I'm doing something I should be able to prevent without having to be careful."</li> <li>Code in <code>comment</code> blocks can be helpful in the future.</li> <li>"'It's not done yet." What file is ever done? You're always going to come back to it in 6 months."</li> <li>Easy to skip around between forms you've run before.</li> <li>"It's like a random access REPL history."</li> <li>Ah ha moment: make a separate file for the helpful <code>comment</code> blocks.</li> <li>"[The comment blocks] are like the copilot of my development experience." "They're me helping me!" "You're your own copilot!"</li> <li>Separate file needed a namespace: the <code>fiddle</code> namespace was born.</li> <li>"I'm just fiddling around."</li> <li>Put the "fiddle files" in the <code>dev</code> tree so it only gets loading in development.</li> <li>"These fiddle files started multiplying, like little helpful rabbits."</li> <li>Like pages in a notebook centered on a theme. Each "page" is a file: <ul> <li>a file for remembering how to call certain core functions</li> <li>a file for experimenting with date and time conversions</li> <li>a file for exploring a new concept</li> <li>a file for interacting with new code being developed</li> </ul> </li> <li>Never have to leave to editor. REPL is working behind the scenes.</li> <li>Unlike REPL history, you can share fiddle files.</li> <li>Fiddles can help show the developer's mindset during development.</li> <li>"It's like seeing into the back of your mind of the way you explore this on your own."</li> <li>Example: exploring a data set <ul> <li>work on code for parsing a data file</li> <li>write different expressions to sift through the data</li> <li>e.g. threaded expression to: open the data, parse it, <code>filter</code>, and <code>map</code></li> <li>build up helpers for making sense of the data</li> <li>parser and helpers in fiddle are the start of the "real" application code</li> <li>write examples with commentary</li> </ul> </li> <li>Example: exploring the working state of the application <ul> <li>set of utility functions for grabbing information from <code>component</code></li> <li>that set of helpers can be share between developers</li> <li>code that pulls out state from specific components all at once</li> <li>"Where did this <code>nil</code> come from?"</li> </ul> </li> <li>Example: exploring external APIs <ul> <li>write simple function for calling the HTTP endpoint</li> <li>start calling it with different examples</li> <li>can easily see and re-run calls that you've tried</li> <li>Slow API? Use <code>(def response (...))</code> to save a result, and write expressions using <code>response</code>.</li> </ul> </li> <li>"A fiddle file like a scratch pad for new features."</li> <li>Characteristics of fiddles <ul> <li>a working set of expressions</li> <li>like a notebook with code around a theme</li> <li>like a scratch pad for exploring toward a solution</li> <li>can be shared</li> <li>written context from solving the problem</li> </ul> </li> <li>"The me of the future won't have as much access to the mental state of the me of the present."</li> <li>Do your future self a favor and write down some of your current mental context.</li> <li>Could make educational fiddles for new developers in a project.</li> <li>"Fiddles are a way of capturing process: a way of capturing the craft of making it, not just the outcome."</li> </ul> Related episodes: <ul> <li><a href="/episode/012-embrace-the-repl" rel="nofollow" target="_blank">012: Embrace the REPL</a></li> <li><a href="/episode/013-connect-the-repl" rel="nofollow" target="_blank">013: Connect the REPL</a></li> <li><a href="/episode/002-tic-tac-toe-state-in-a-row" rel="nofollow" target="_blank">002: Tic-Tac-Toe, State in a Row</a></li> </ul> Clojure in this episode: <ul> <li><code>comment</code></li> <li><code>def</code>, <code>defn</code></li> <li><code>-&gt;</code>, <code>-&gt;&gt;</code></li> <li><code>filter</code>, <code>map</code>, <code>reduce</code></li> <li><code>select-keys</code></li> <li><code>clojure.pprint/</code> <ul> <li><code>pprint</code></li> <li><code>print-table</code></li> </ul> </li> </ul> Related projects: <ul> <li><a href="https://clojure.org/community/resources#_clojure_tools" rel="nofollow" target="_blank">Editors with REPL integration</a></li> <li><a href="https://jupyter.org/" rel="nofollow" target="_blank">Project Jupyter</a></li> <li><a href="https://github.com/stuartsierra/component" rel="nofollow" target="_blank">Component</a></li> <li><a href="https://www.joda.org/joda-time/" rel="nofollow" target="_blank">Joda Time</a></li> <li><a href="https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html" rel="nofollow" target="_blank">Java Time</a></li></ul>

Episode 014: Fiddle With the REPL

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "What's so different about Clojure's REPL?" We evaluate what a REPL really is and show that it's much more about the developer experience than simply calculating values. Selected quotes:  "The Clojure REPL is your window into the state of a running application."   "It's a much larger, broader kind of experience." "It's funny to have mutable programs and immutable data, but that's what Clojure gives you." "The fact that the REPL can read expressions and run them becomes one of it's least interesting attributes."  Related episodes  012: Embrace the REPL 013: Connect the REPL 014: Fiddle with the REPL

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "What's so different about Clojure's REPL?" We evaluate what a REPL really is and show that it's much more about the developer experience than simply calculating values. Selected quotes: <ul> <li>"The Clojure REPL is your window into the state of a running application."</li> </ul> <ul> <li>"It's a much larger, broader kind of experience."</li> <li>"It's funny to have mutable programs and immutable data, but that's what Clojure gives you."</li> <li>"The fact that the REPL can read expressions and run them becomes one of it's least interesting attributes."</li> </ul> Related episodes <ul> <li><a href="/episode/012-embrace-the-repl" rel="nofollow" target="_blank">012: Embrace the REPL</a></li> <li><a href="/episode/013-connect-the-repl" rel="nofollow" target="_blank">013: Connect the REPL</a></li> <li><a href="/episode/014-fiddle-with-the-repl" rel="nofollow" target="_blank">014: Fiddle with the REPL</a></li></ul>

Ep 044: What's So Different About Clojure's REPL?

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the question is: "What advice would you give to someone getting started with Clojure?". We trade off giving practical tips for intrepid learners while we reminisce about our own paths into Clojure. Selected quotes:  "Reading other people's code will change how you view the problem." "You're going to get stuck, but that's ok. "REPL driven development is so fast, you'll need to take a break from the whiplash." "Clojure doesn't give you breaks, like other programming languages do with their compiles and restarts." "The best code to use is code that was written by somebody else, because it's probably bug free." "The problem isn't the code that I'm writing, the problem is with my approach." "Try to solve a programming problem that you care about."  Related episodes:  012: Embrace the REPL 013: Connect the REPL 014: Fiddle with the REPL

Each week, we answer a different question about Clojure and functional programming. If you have a question you'd like us to discuss, tweet <a href="https://twitter.com/clojuredesign" rel="nofollow" target="_blank">@clojuredesign</a>, send an email to <a href="mailto:feedback@clojuredesign.club">feedback@clojuredesign.club</a>, or join the <code>#clojuredesign-podcast</code> channel on the <a href="http://clojurians.net/" rel="nofollow" target="_blank">Clojurians Slack</a>. This week, the question is: "What advice would you give to someone getting started with Clojure?". We trade off giving practical tips for intrepid learners while we reminisce about our own paths into Clojure. Selected quotes: <ul> <li>"Reading other people's code will change how you view the problem."</li> <li>"You're going to get stuck, but that's ok.</li> <li>"REPL driven development is so fast, you'll need to take a break from the whiplash."</li> <li>"Clojure doesn't give you breaks, like other programming languages do with their compiles and restarts."</li> <li>"The best code to use is code that was written by somebody else, because it's probably bug free."</li> <li>"The problem isn't the code that I'm writing, the problem is with my approach."</li> <li>"Try to solve a programming problem that you care about."</li> </ul> Related episodes: <ul> <li><a href="/episode/012-embrace-the-repl" rel="nofollow" target="_blank">012: Embrace the REPL</a></li> <li><a href="/episode/013-connect-the-repl" rel="nofollow" target="_blank">013: Connect the REPL</a></li> <li><a href="/episode/014-fiddle-with-the-repl" rel="nofollow" target="_blank">014: Fiddle with the REPL</a></li></ul>

Ep 037: What Advice Would You Give to Someone Getting Started With Clojure?

Christoph finds map doesn't let him be lazy enough.  Last week, we were dealing with multi-line sprinkle errors. We were able to get more context using partition. (01:33) Problem: the component lines had to be adjacent. Solution last week was to create larger partitions to hopefully get the rest of the error. This became a magic number problem, guessing how far we had to look ahead. "If there's anything I've learned in my career, telling the future is one of the hardest things to do.' What number should be big enough? 100? 1000? (04:00) The other problem is that the function is handed a pre-selected set of lines. The decision about how many lines is appropriate is made outside the function. Wouldn't it be nice if the function had control over how far to look ahead. "The function can't function." "Functions are all we've got in functional programming. Well, that and lists." It would be great if the function itself could take a sequence and look as far as it needs to. How about handing the function the entire lazy sequence? (05:52) Problem: Handing in the entire sequence means we can't use map to convert lines into sprinkle errors anymore. We can write a function that gives us just one sprinkle error from the sequence, but we want to convert the sequence into a sequence of all the sprinkle errors. We're going from something that operates on a subset of the sequence to something that operates on the entire sequence, which is too much control. We need a way for it to look ahead but still It's no longer just working on a chunk of the sequence, but on the unbounded sequence itself. We need to elevate it to the same power as other sequence operators, like map and filter. We don't, however, want the function to eagerly find all sprinkle errors in the sequence. It needs to be lazy. (09:26) Solution 1: How can we just get one sprinkle error out? If the first line isn't the error start, recur with the tail until found. Do a take-while to find the second half of the error. When both found, return the value.   We need to terminate the search if we hit the end of the sequence, so we only continue if (seq lines) is not nil. "There's no sense in looking in an empty bucket." But we don't want just one, we want the entire sequence. It would be really nice to return the value when we find it and then wait to find the next one until it is requested. Conceptually, we could tell the calling function an index of where to start looking for the next error. (13:44) Solution: In Clojure, we keep our place using the lazy-seq function. lazy-seq is a sequence, but it hasn't been realized yet. It's like being able to hand back a value and a function to call for the next value. When you find a value, you can cons it onto the head of an invocation of lazy-seq to make a new sequence. Step 1. Wrap your entire function body in lazy-seq. This is similar to using delay, because it wraps the code in something that will only be evaluated when it is first accessed. Step 2. Ensure that the body obeys the contract. It must return either: nil, which indicates that the sequence is complete. a sequence, usually constructed by calling cons on a value and a call to lazy-seq.   Top of the body is a call to (when (seq lines) ..., to ensure that the sequence terminates when there is no data left. Since the top of our function is lazy-seq, we can cons the found value onto a recursive call to the function. In the recursive call, we must pass the next section of the sequence, so that when evaluated it will pick up at the right place. If we don't find the start of the error, we recurse with the rest of the sequence to try parsing from there. This function will go through the sequence eagerly until it finds something. Instead of operating on single elements in the sequence, we can take a sequence and produce a sequence, powered by lazy-seq. With this capability, you can build a higher level sequence that consumes this sequence and produces a new summary, all done lazily.  Related episodes:  028: Fail Donut 029: Problem Unknown: Log Lines 030: Lazy Does It 031: Eager Abstraction  Clojure in this episode:  partition seq, cons, rest lazy-seq, delay map, filter, take-while recur  Code sample from this episode: (ns devops.week-04  (:require    [devops.week-01 :refer [parse-line]]    [devops.week-02 :refer [process-log]]    [devops.week-03 :refer [sprinkle-errors-by-type]]    ))(defn sprinkle-error-seq  [lines]  (lazy-seq    (when (seq lines)      (let [[first-line second-line &amp; tail] lines            [_whole donut-id] (some-&gt;&gt; first-line :log/message (re-matches #"failed to add sprinkle to donut (\d+)"))            [_whole error] (some-&gt;&gt; second-line :log/message (re-matches #"sprinkle fail reason: (.*)"))]        (if (and donut-id error)          (cons (merge first-line                       {:kind :sprinkle                        :sprinkle/donut-id donut-id                        :sprinkle/error error})                (sprinkle-error-seq tail))          (sprinkle-error-seq (next lines)))))))(comment  (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-error-seq doall))  (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-error-seq sprinkle-errors-by-type))  )

Christoph finds map doesn't let him be lazy enough. <ul> <li>Last week, we were dealing with multi-line sprinkle errors.</li> <li>We were able to get more context using <code>partition</code>.</li> <li>(01:33) Problem: the component lines had to be adjacent.</li> <li>Solution last week was to create larger partitions to hopefully get the rest of the error.</li> <li>This became a magic number problem, guessing how far we had to look ahead.</li> <li>"If there's anything I've learned in my career, telling the future is one of the hardest things to do.'</li> <li>What number should be big enough? 100? 1000?</li> <li>(04:00) The other problem is that the function is handed a pre-selected set of lines.</li> <li>The decision about how many lines is appropriate is made outside the function.</li> <li>Wouldn't it be nice if the function had control over how far to look ahead.</li> <li>"The function can't function."</li> <li>"Functions are all we've got in functional programming. Well, that and lists."</li> <li>It would be great if the function itself could take a sequence and look as far as it needs to.</li> <li>How about handing the function the entire lazy sequence?</li> <li>(05:52) Problem: Handing in the entire sequence means we can't use <code>map</code> to convert lines into sprinkle errors anymore.</li> <li>We can write a function that gives us just one sprinkle error from the sequence, but we want to convert the sequence into a sequence of all the sprinkle errors.</li> <li>We're going from something that operates on a subset of the sequence to something that operates on the entire sequence, which is too much control.</li> <li>We need a way for it to look ahead but still</li> <li>It's no longer just working on a chunk of the sequence, but on the unbounded sequence itself.</li> <li>We need to elevate it to the same power as other sequence operators, like <code>map</code> and <code>filter</code>.</li> <li>We don't, however, want the function to eagerly find all sprinkle errors in the sequence. It needs to be lazy.</li> <li>(09:26) Solution 1: How can we just get one sprinkle error out? <ol> <li>If the first line isn't the error start, <code>recur</code> with the tail until found.</li> <li>Do a <code>take-while</code> to find the second half of the error.</li> <li>When both found, return the value.</li> </ol> </li> <li>We need to terminate the search if we hit the end of the sequence, so we only continue if <code>(seq lines)</code> is not nil.</li> <li>"There's no sense in looking in an empty bucket."</li> <li>But we don't want just one, we want the entire sequence.</li> <li>It would be really nice to return the value when we find it and then wait to find the next one until it is requested.</li> <li>Conceptually, we could tell the calling function an index of where to start looking for the next error.</li> <li>(13:44) Solution: In Clojure, we keep our place using the <code>lazy-seq</code> function.</li> <li><code>lazy-seq</code> is a sequence, but it hasn't been realized yet.</li> <li>It's like being able to hand back a value and a function to call for the next value.</li> <li>When you find a value, you can <code>cons</code> it onto the head of an invocation of <code>lazy-seq</code> to make a new sequence.</li> <li>Step 1. Wrap your entire function body in <code>lazy-seq</code>.</li> <li>This is similar to using <code>delay</code>, because it wraps the code in something that will only be evaluated when it is first accessed.</li> <li>Step 2. Ensure that the body obeys the contract. It must return either: <ul> <li><code>nil</code>, which indicates that the sequence is complete.</li> <li>a sequence, usually constructed by calling <code>cons</code> on a value and a call to <code>lazy-seq</code>.</li> </ul> </li> <li>Top of the body is a call to <code>(when (seq lines) ...</code>, to ensure that the sequence terminates when there is no data left.</li> <li>Since the top of our function is <code>lazy-seq</code>, we can <code>cons</code> the found value onto a recursive call to the function.</li> <li>In the recursive call, we must pass the next section of the sequence, so that when evaluated it will pick up at the right place.</li> <li>If we don't find the start of the error, we recurse with the <code>rest</code> of the sequence to try parsing from there.</li> <li>This function will go through the sequence eagerly until it finds something.</li> <li>Instead of operating on single elements in the sequence, we can take a sequence and produce a sequence, powered by <code>lazy-seq</code>.</li> <li>With this capability, you can build a higher level sequence that consumes this sequence and produces a new summary, all done lazily.</li> </ul> Related episodes: <ul> <li><a href="/episode/028-fail-donut" rel="nofollow" target="_blank">028: Fail Donut</a></li> <li><a href="/episode/029-problem-unknown-log-lines" rel="nofollow" target="_blank">029: Problem Unknown: Log Lines</a></li> <li><a href="/episode/030-lazy-does-it" rel="nofollow" target="_blank">030: Lazy Does It</a></li> <li><a href="/episode/031-eager-abstraction" rel="nofollow" target="_blank">031: Eager Abstraction</a></li> </ul> Clojure in this episode: <ul> <li><code>partition</code></li> <li><code>seq</code>, <code>cons</code>, <code>rest</code></li> <li><code>lazy-seq</code>, <code>delay</code></li> <li><code>map</code>, <code>filter</code>, <code>take-while</code></li> <li><code>recur</code></li> </ul> Code sample from this episode: <code>(ns devops.week-04 (:require [devops.week-01 :refer [parse-line]] [devops.week-02 :refer [process-log]] [devops.week-03 :refer [sprinkle-errors-by-type]] )) (defn sprinkle-error-seq [lines] (lazy-seq (when (seq lines) (let [[first-line second-line &amp; tail] lines [_whole donut-id] (some-&gt;&gt; first-line :log/message (re-matches #"failed to add sprinkle to donut (\d+)")) [_whole error] (some-&gt;&gt; second-line :log/message (re-matches #"sprinkle fail reason: (.*)"))] (if (and donut-id error) (cons (merge first-line {:kind :sprinkle :sprinkle/donut-id donut-id :sprinkle/error error}) (sprinkle-error-seq tail)) (sprinkle-error-seq (next lines))))))) (comment (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-error-seq doall)) (process-log "sample.log" #(-&gt;&gt; % (map parse-line) sprinkle-error-seq sprinkle-errors-by-type)) )</code>

Ep 032: Call Me Lazy

The best episodes for anyone looking to learn more about topics such as happiness, fulfillment, depression and psychology/mental health in general. With interviews with industry experts, personal stories of individuals, this topic has lessons applicable to everyone. Add episodes you're interested into your queue below!

Best Episodes on Mental Health, Emotions & Thoughts

The best self improvement podcast episodes. From improving productivity, to finding purpose in your life to what constitutes freedom, this topic is on anything and everything that can help people to improve their lives. Add episodes you're interested into your queue below!