@neumann the discussion on component. It was a dependency injection solution without all the architectural language and a deep dive into the GoF pattern thinking. I remember thinking, "that's neat" without relating it back to my previous imperative/OO experience doing the same thing until perhaps an hour after I'd listened to the episode. I think that made it easier for me to absorb.

I like treatment of design consideration -> functional version of a pattern in actual implementation.

@neumann @matt501 +1000. This is the same reason I loved your numerous treatments about error handing and threading results through multiple functions — from my caveman understanding, it was addressing the monoid and applicative functor patterns from category theory, without actually describing them as such. Which is absolutely marvelous. PS: My $0.02. I love your current format of talking thru code — I think bringing on guests would detract from one of the really unique things about your podcast.

@matt501 @genekim Thanks so much for your feedback! I appreciate it, and I'm glad you've been enjoying the episodes. I had a bad experience with functional programming in grad school. I was having trouble understanding all the theory stuff (monads, functors, etc.), went to the professor for help, and he said something to the extent of: "This stuff is just obvious. Just look at it again. It makes total sense." Needless to say, it wasn't obvious to me! I came back to pure functional programming about 7 years later, but this time in Clojure not Haskell. I was smitten by the practicality of Clojure. I finally worked through all that stuff without the big theory words getting in my way. I think the concepts do end up being straightforward, but the theory words always feel like they get in the way. I want functional programming to be a practical superpower for everyday developers! I'm so happy to hear that despite our avoidance of theory words, you've both been able to go back and make those connections. Super cool!!

@genekim The "talking through code" bit has definitely been challenging. This summer, as we do the Q&A, I'm spending some time thinking through how to do that well. It's much easier to talk about concepts, but I really think the concrete problems are the most compelling. FP isn't some distant thing in the ivory tower. It's a straightforward thing right in front of you that can make your everyday life as a developer better. Code brings FP close. Big words keep it far away.

@neumann FWIW, I think your treatment of “talking thru code” has been superb — I can’t think of any obvious ways to improve it. I was describing it to a friend: “it’s challenging and illuminating. it’s nearly at the limit of what you can process w/o using a whiteboard or looking at concrete code examples, but can still listen to while driving, walking… but I’ve learned so much from it.”

@genekim That's great to hear!

@neumann I've got to second @genekim about guests. The standout episodes for me was the tic-tac-toe episodes, because that had a really nice progression, and was not like any other (at least Clojure focused) podcasts. The REPL (or "workflow") series was also really nice, again because you took your time to build up to the final workflow. (IIRC, you too were surprised that it spanned three episodes, but I wouldn't want it any shorter.)

@lodin.johan Thanks for the feedback! It's helpful to know what stands out. I appreciate it! Yeah, we thought the REPL episode would be a week, but then it was two, and then it was three! It's fun to see where the topic goes.

@neumann @nate Now that I think about it, what I think I really like about your podcast is that you in your different series kind of retrace your paths to insights. It naturally ends up explaining the "why", not only the "what" or "how". (Conference talks and blogs rarely provide this "long form" problem solving, showing intermediate steps and how a solution evolved.)