Welcome to our series on Functional Programming! Are you ready for some fun? So, yeah, I'm sure you've heard all the fuss about functional programming recently. People are talking and arguing about combinators and monads and monoids and all kinds of other words that sound like they came out of some mathematical laboratory. Don't worry, that's not the direction we're going. Oh, we might peek into the math lab from time to time, but this series is about doing, not about pontificating. (Well, usually, anyway.) In this episode we're going to introduce the basics of FP. We'll talk about what it is, where it came from, how it relates to regular programming, and we'll even show you some code. The code will be in Clojure. That's the language we'll be using for the most part, though we'll likely look at some F# from time to time. So, get ready for a some loops and whirls, because this episode is likely to turn your brain a little sideways.

Do you remember Master Mind, that clever board game from the '80s, with the colored pegs? We implemented a version of it back in Episode 9. Well, in this episode we're implementing it again, but in Clojure. In this episode we're going to walk through the code for this program, one commit at a time. You'll see how I used TDD to develop it. You'll see the functional design. You'll be amazed that there are no assignment statements. You'll be astounded at the data-flow style. And, in the end, you'll know the best strategy for winning Master Mind and will be able to amaze your friends. So hop on board and let's get this train moving, because we're about to immerse ourselves in functional programming, Clojure, and Master Mind. The code in this video can be found here. Make sure you walk through all the commits in sequence. There is much to learn by watching the progress of development.

Spacewar! How cool is this? Did you ever think that you would be combing through the innards of a real-time, interactive video game written in Clojure? Well, you are now! This game is thousands of lines of Clojure code. It has Klingons, Romulans, Starbases, and The Enterprise. You must save the Federation. This episode and the two that follow will lead you through the design and implementation of a functional and interactive GUI program. It is 100% functional: no cheating, no mutated variables, and not even any Transactional Memory; just plain old functional programming. You should probably follow along and grab the code. If you want to play the game, you can find the ClojureScript version in your web browser here.

OK, so now things are going to get really tech-y and geeky. We're going to talk about how all the GUI widgets work, how they are arranged in a hierarchy, and how they communicate events and respond to commands—all without mutating any state. The data structures we'll use for this are going to quickly get very complicated. In order to avoid losing control of them, in a dynamically-typed language like Clojure, we're going to investigate the use of Clojure's type specification library clojure.spec. Oh boy, this functional programming stuff is fun! And so is playing Spacewar! Have you played it yet?

So, now it's time to get into the real guts of the Spacewar game. The game logic. There are quite a few fun and interesting topics we're going to cover. These are a few of the questions I want to address: 1- There are 8,000 lines of code and 777 unit tests. What kind of coverage does that represent? What was the testing strategy for GUI vs. Game Logic? 2- How does Clojure/spec help us keep our data types under control in a dynamically typed language? Are dynamically typed functional languages inherently weaker than statically typed functional languages? Or are there advantages to dynamic typing? 3- How do you manage to update complex state when you aren't allowed to change the state of any variables? Does this represent extra work? 4- Lazy evaluation is a powerful technique, but what kind of trouble can it get you into? 5- Where does this program go from here? Prepare yourself for a really interesting deep technical dive as we walk through Spacewar -- Game Logic.

Fifty-Eight. 58 is 2*29 and is the sum of the first seven prime numbers: 2+3+5+7+11+13+17. 58 is the year that Sputnik was launched. "58 is like the luckiest number ever." according to Patrick on the Sponge Bob show. And...Episode 58 is where we talk about the SOLID principles in Functional Programs. YAY! In the last episode, Episode 57 (which is 3*19 and the atomic number of Lanthanum (not to be confused with gold-pressed Latinum)) I told you we were done with Starwars. I lied. Well, no, I didn't exactly lie. I was wrong, but I didn't know it at the time. You see, at the time I knew I wanted to do an episode on the SOLID principles in functional programming. I just didn't know I was going to be using Starwars as the example. But then, as I started writing the episode, it became clear to me that there were loads and loads of SOLID principle conformance and violation in Starwars. Anyway, Starwars it is. One more time. And this time we're going to look at it from the point of view of: SRP - The Single Responsibility Principle, OCP - The Open-Closed Principle, LSP - The Liskov Substitution Principle, ISP - The Interface Segregation Principle, and DIP - The Dependency Inversion Principle.

OK, ok. So this is the episode you've been waiting for. Enough of the silly game programs like Master Mind. Enough of the silly GUI Star Trek games. Now it's time for real enterprise software. A WEBSITE! Yeah, that's the ticket! Right. So, in this episode, Uncle Bob writes a fully functional website in Clojure, using pure functional programming. Oh, yes he does! But first, he rants about the web in general—because what would one of these episodes be without a good rant? Then, he goes into the history of the web, and hypertext, and all the stuff that we think of as modern enterprise software. Uh huh. Then it's on to the Clojure frameworks used in the example: Ring, httpKit, and compojure. Then we look at the code for the website; more importantly, we look at the architecture of the website. And then, finally, once we've peered at the glory of a functional website, the truth will come to us at last, when all are one and one is all: that all websites are functional. (Cue final guitar lead)

Monoids and Monads and Bears, Oh My! And Functors too. Get ready for a gentle stroll down Category Theory lane. Don't freak out. We're not going to get into any heavy mathematics or anything. We're just going to skim the surface of category theory. We'll dip our toe into the waters, just enough to explain one of the most powerful concepts in programming: The concept of Composition. We'll begin by describing what composition is, and the history of composition in software -- starting with Turing and ending up with objects, and lambdas, and streams. Then we'll dig just below the crust of category theory in order to expose the simplest of the concepts: Categories and Monoids. We'll show how these two concepts relate to Map and Reduce. Then we'll dig a tiny bit further into the concepts of Functors, Categories of Categories, and -- of course -- Monads! And that will be enough. Oh yes, that will be enough. These concepts may seem a bit academic; but I think you'll find them valuable as a way to think about how the elements of software systems are composed.

In ages long past (2006), two great giants of software battled over the power of Test Driven Development (TDD) vs. the power of The Hammock (HDD). Ron Jeffries, a programmer who wrote his first code under the mountain at Strategic Air Command in 1958, and was one of the founders of the Agile movement strived to show that programs and algorithms can be derived through consistent practice of TDD. Peter Norvig, one time head of the Computational Sciences Division at Nasa Ames Research Center, and currently the director of research at Google fought to show that it was the deep up-front thinking from time spent within the Hammock that creates the better design. The battle ground they chose was Sudoku; the number puzzle that became a short-lived fad in the early 2000s. Ron attempted to incrementally build a Sudoku solver one test case at a time following the practice of TDD. Peter climbed into the Hammock and built his solution using deep thinking and analysis. Which of the two prevailed? What did they prove? Is TDD the answer? Or should programmers spend more time in the Hammock? In this episode, we will replay that battle and we will create a Sudoku solver using functional programming in Clojure. We will use TDD. We will spend time in the Hammock. And we will answer the age-old questions that those two giants fought over. In the end, as we conclude our series on functional programming, we will at last know whether it is TDD or the Hammock that best drives the designs of algorithms.

This episode is the capstone of our Functional Programming series. In it we explore Clojure, the language that we've been using throughout the series. We'll start with a history of LISP. Where did it come from? Who invented it, and why? Then we'll talk about one of my favorite books. The Structure and Interpretation of Computer Programs. This is the book that first taught me LISP and Functional Programming. It's a classic, and it's one you should read. Then it's on to Clojure. This is not a tutorial. I'm not going to teach you all the ins and outs of the language. My goal is to give you just enough familiarity to make you curious. Clojure is Lisp. Clojure is Functional. Clojure rides on the JVM. Clojure supports concurrency. Next we'll spend a moment explaining how the data structures in Clojure can be simultaneously efficient and immutable. That's quite a trick, and you'll enjoy hearing about how it's done. Then we'll talk about lazy evaluation, and some of the costs and benefits of the technique. It's powerful, there's no doubt. But if you don't know what's going on behind the scenes, you can get into trouble that's hard to debug. Finally we'll discuss Macros and Homoiconicity (if that's a word.) Oh the power! THE POWER! This may be the most powerful aspect of LISP; and in Clojure it is especially powerful. It's so powerful, in fact, that you should hardly ever use it. And with that, we'll be done with the Functional Programming series.