Grokking Simplicity by Eric Normand teaches the difference between actions, calculations, and data as a way to reason about mutation and side effects, and it works better as a vocabulary book than a technique book. If you’ve already internalized what map, filter, and reduce are for, and I mean really internalized it and not just being able to write the syntax, most of the core material is going to read as confirmation of things you already believe instead of new information. The higher-order function chapters and the copy-on-write chapters fall right into that bucket. They’re clearly and patiently explained, and useful for someone who’s never had the difference between mutating and copying spelled out, but they’re slow going if you’ve been burned by shared mutable state enough times to already distrust it on instinct.

The best material is outside that core. The architecture chapters cover both stratified design and the onion model, and they were solid and worth having read, though not so revelatory that I’m in a hurry to go through them again. The concurrency chapters were the standout. They introduce a diagramming technique for reasoning about timelines and ordering that I hadn’t run into before and thought was really creative, and it’s a lot different from the usual “just use locks or actors and hope” approach most books take. Those are the chapters I’d go back to if a project involving concurrency comes up, since it’s the kind of technique you have to actually apply before it sticks.

The biggest miss for me was the immutable data chapters. I went in hoping for advice on using immutable data structures in single-binding languages, the discipline of writing code where a name, once bound, stays bound. What I got was mostly copy-on-write technique, demonstrated with JavaScript objects that get rebound on every update. That’s a reasonable way to teach it in a language like Elixir where rebinding is idiomatic, but it doesn’t really carry over to the habit I was actually after, which is reaching for val by default in Kotlin, or treating a Haskell declaration as a one-time mathematical definition instead of a variable that just happens not to change. The chapter shows you how to build the immutable structure, but it doesn’t really show you how to live in a codebase that treats bindings as permanent.

Overall, it’s a fast, well-explained, easy read that’s clearly aimed at someone running into these ideas for the first time. If that’s not you, you’ll skim more than you expect, but the concurrency material deserves a second look, and the architecture chapters were worth reading once, even if they weren’t essential.

Advanced Functional Programming with Elixir turned out to be a pretty good, easy introduction to functional programming concepts, and it uses good domain examples instead of math. It walks through Elixir’s protocol system with a DDD slant, using a theme park domain with rides, patrons, and Fast Passes instead of the numbers-only examples you get in most Haskell books. The code is built around a companion library called FunPark, a teaching-scale version of Koski’s real production package, Funx. The theme park was a good choice, and it paid off most in the Eq/FastPass chapter, where a real business rule (two Fast Passes with the same datetime conflict, but should still be equal by id) motivated contramap far better than an abstract definition ever could have.

The quality was uneven, but in a predictable way. Eq, Ord, and Predicates were a low bar that the book cleared easily. Monoid was the standout chapter, and the one place where all the abstract machinery (Eq.All, comparators built with contramap) paid off concretely enough to justify the ceremony. The monad theory was thin and abstract on its own and only came together once Maybe and Either gave it somewhere to land. The one real gap was motivation for Reader and Effect, which never quite sold me. The mechanics were fine, but no example was compelling enough to answer “why bother wrapping this?”

The Eq and Ord chapters are straightforward once you accept that Elixir protocols dispatch on struct type only, which forces workarounds like contramap and to_eq_map (comparators as plain maps, not just protocol implementations) the moment your domain needs more than one valid notion of equality for a type. That ties into DDD nicely, since equality isn’t structural, it depends on the bounded context, so the same type can have different valid comparators depending on which part of the domain is asking.

The Predicates and Foldable chapter introduced Foldable for Function (a predicate as a fold, with zero-arity thunk dispatch) with almost no explanation, and I had to do some real reconstruction before it landed. It turned out to be a catamorphism (one function per fixed shape) hiding under a name that sounds like list reduction. I also caught a bug in the protocol declaration there. defprotocol declared fold_l(structure, transform_fn, base), but every real implementation and call site used (structure, acc, func), so the protocol’s own docs had the argument names reversed. It’s harmless, since protocol callback names aren’t enforced, but it’s misleading on a cold read.

Monoid was the best chapter. Sum is the toy case, and Eq.All and Eq.Any are the real payoff, equality combinators as monoids, with && and || doing the combining. I caught one real typo there too (default_not_eq vs. default_not_eq?), and it confirmed a design tension worth remembering: this machinery is worth it once you have multiple domain-meaningful comparators that need combining and reusing, but not for a one-off comparison you could write with && directly.

The monad theory chapter is careful to say it’s “inspired by category theory, not a direct implementation.” The laws (left identity, right identity, and associativity) landed fine once I reverse-engineered pure, which shows up without explanation, as the same idea as Monoid’s wrap/empty, just Monad-flavored. There’s no dedicated Functor chapter, and map gets treated as a free consequence of bind and pure instead of getting its own build-up, unlike From Objects to Functions, which used Functor as the on-ramp to Monad.

Reader was clean mechanically (the environment as a deferred function, ask/asks, and run as the escape hatch), but the worked examples were too small to justify the ceremony over just passing an argument. The one clear win was swapping run(computation, prod_env) for run(computation, test_env), which is a real dependency injection payoff, independent of the toy examples around it.

Maybe and Either are where the book actually sold itself. You chain bind-based computations and only check for failure once at the end, instead of doing constant nil checks, which is a direct answer to how much Go’s manual err != nil checking grates on me. Either wins over Maybe when you need to carry why something failed. Choosing bind to fail fast versus ap to collect all the errors was the most concrete moment in the whole book where an abstraction proved its worth, since the same operations give you two different validation strategies with one shared vocabulary.

Effect never made a compelling case for why actions specifically need to be trapped in a monad, though the ride repository example was believable as a real pattern. It was the weakest chapter at justifying its own existence.

I’m not convinced the full ceremony is worth it over Kotlin’s null safety for the Maybe case, since that comparison feels close to a wash. Either doesn’t have an equally clean stand-in in Kotlin, though. Kotlin’s Result<T> is tied to Throwable, so a hand-rolled Outcome type or Arrow’s Either are the real equivalents, and that’s the one idea from this book most likely to actually change how I write Kotlin.

Overall, it’s a good, easy introduction to FP for someone with some prior exposure who wants examples grounded in a domain instead of math. I’m glad I had AI on hand to work through the parts the book left underexplained, especially the Foldable predicate case, since it would’ve been a rougher read alone.

Full book notes.

A perfectly good introduction to the Elixir language, although it didn’t have anything specific to learning functional programming in it beyond getting used to doing things the Elixir way. I guess it had more recursion than most introductory programming books… It feels like a terrible introduction in comparison to Dave Thomas’ Programming Elixir though, since it stops totally short of introducing the Actor model and OTP, which are unique strengths of Elixir, but that’s obviously a longer book to read.

Full book notes.

This was one of the better books I’ve read recently for actually changing how I think about programming. It combines domain-driven design, test-first development, and functional programming into one coherent story, which is pretty rare, since most books only tackle one of those at a time. Unlike some of my other recent reads, the Kotlin itself was well-structured and idiomatic throughout, not just functional-flavored Java.

The book builds a real app, a to-do list called Zettai, outside-in with TDD, starting from acceptance tests and working down to the domain core. It uses http4k, which the author picked specifically for its “everything is a function” philosophy (an HttpHandler is just (Request) -> Response), and Exposed for persistence. The book’s repo only has the start and end states for each step (step1 through step7, spread loosely across 13 chapters) rather than the intermediate changes, so I had to lean on the book’s prose to follow why the code evolved the way it did and not just what it ended up as.

The book starts with actor-based domain-driven testing and works its way through receiver-typed lambdas and extension functions, higher-order functions and purity, and a hub-and-spokes (ports and adapters) architecture before it gets into the theory. From there it covers monoids (with a door state machine example), functors, monads, and applicatives, then event sourcing and profunctors, and it finishes with a logging and JSON capstone that pulls everything together. The theory was mostly motivated with real code before the abstraction got a name, which I appreciated. Functors come out of Holder, List, and Outcome, and then ProjectionQuery deliberately breaks the container idea to push you into thinking of them as computations instead of containers. Monads come from a concrete TxReader<TxReader<T>> nesting problem instead of being introduced abstractly, and applicatives show up through error-accumulating validation with `!` and `*` operators, contrasted against the way monads short-circuit. The exceptions were the door monoid section and parts of chapter 7, where the vocabulary showed up before the payoff did. That was disorienting in the moment, even though the payoff did eventually arrive by the end of the chapter.

The Kotlin was the kind you’d want to see in a strong codebase, with extension functions, receiver types, sealed classes, and generics all used the way they’re meant to be used and not just as vehicles for FP theory. The actor-based test framework, Pesticide, was a neat pattern too, you write a test once and run it against the domain, a local HTTP server, or a deployed instance, even if I’m not sure I’d adopt the library itself over something mainstream like kotest.

The final third, especially the logging and JSON chapters, had a noticeably higher error rate than the rest of the book. Functions like storeEvents got used before they were shown, parameter counts didn’t match, and field names had typos. The JSON chapter has you build a hand-rolled JSON library that even the author admits he was “wary” of introducing, and it’s incomplete, since its own reflection-based code generation “seldom works right without manual intervention.” A thin adapter wrapping kotlinx.serialization in an Outcome probably would have served the book’s own goals better than building JSON parsing from scratch. There’s also an optional 50-page category theory appendix, which was a mixed bag. Functors, monads, and comonads mostly confirmed what the main text had already taught me, and Kleisli categories turned out to be bind with different notation once I decoded them, but profunctors and the Yoneda lemma were presented abstractly enough that I had to reconstruct them from the code examples myself before they landed.

Looking back at it now, after a stretch in Haskell, I remember a lot more about the DDD and TDD from this book than I do about the details of Kotlin. It was really into TDD, with the whole app built outside-in from acceptance tests, and I miss that now that I’m working through 1000 pages of Django 5 By Example without a single test in them. Anyway, it’s a dense book, but it was worth the length, and it changed how I think about combining DDD, testing, and FP instead of treating them as separate concerns. I’d recommend it to someone with some Kotlin under their belt and the patience for some rough editing toward the end.

Full book notes.

Haskell

But let’s talk about the new title. It is “Senior Software Engineer Learns Functional Programming.” One of the last things I did but never blogged about was try to learn Haskell. I started with the venerable The Haskell Book. I read a bit over half and realized I still couldn’t program much of anything in Haskell. This was after spending previous effort learning functional programming. I learned some Scala and the syntax of Clojure and felt ineffectual with both aside from being able to use Scala as a better Java, so that’s what led me to Haskell to learn functional programming right. Well, I still want to do that. I didn’t think I wanted to really, but I spent some time reading Advanced Functional Programming with Elixir and it made a perfectly good case for why Haskell is a better programming language and featured a style that was not idiomatic Elixir but instead very Haskell inspired, and it got me interested again. So I’m not going to start over with The Haskell Book and try to re-learn programming from first principles. Instead I am going to read Haskell by Example which is more hands on and dip into the explanations of The Haskell Book whenever I need more theory. I’m also about halfway through Learn You a Haskell which I started over vacation, since I’m finding my intuition for working with linked lists has degraded.

Elixir

The subtitle of the blog is “With explorations in Haskell, Elixir, and Clojure”. I’ve already read two Elixir books on the basics of the language (reviews upcoming) and I have every intention of spending more time with Elixir. The books I read didn’t even touch on the cool Actor model and OTP stuff that makes Elixir unique. It’s not the best language for learning to deal with immutable values since it allows you to rebind variables, which feels a bit like cheating. Sure the data structure itself is immutable, but you just end up pointing the same variable at the updated copy. Haskell won’t let you get away with that. I understand since the variables aren’t global and are local to the Actors working behind the scenes it is safe even for concurrent code, but I intend to learn how to deal with immutable data structures bound once to a name. So I will definitely spend some time away with Haskell but eventually get back to Elixir. It overlaps my other goal of trying web frameworks thanks to Phoenix, so my two big projects (“Learn Functional Programming” and “Try Web Frameworks”) actually meet.

Clojure

I have also bought the most recent edition of Programming Clojure and Clojure Brain Teasers and plan to spend time with it again. I read Getting Clojure and Living Clojure and Clojure for the Brave and True years ago, and I felt pretty comfortable with the syntax of the languages and all the parentheses, but I never was able to use it for much. So after I spend some time writing code with Haskell, I’ll spend some time with Clojure again and see if I can do anything cool with it. I’m a Java developer by trade, so its position on the JVM feels quite welcome, and once I learn idiomatic functional coding in a language where I can’t back off and call Java code, maybe it will be accessible to me. I’ll probably spend a while with Haskell and then Elixir first though. I do want to play around with Ring to try writing my webapps with a minimalist Clojure library.

Web Frameworks

Back to the web frameworks though… I was going to dive into Agile Web Development with Rails 8 and try Ruby. Then I will read through Django 5 by Example. This builds up four sizable projects which I plan to steal. I don’t really like any dynamic language all that much, but I do normally prefer Python to Ruby for its usefulness with AI and its sensible stance on one way to do things and lack of going crazy with metaprogramming. I have every intention of stealing the Django projects to reimplement in other frameworks to serve my own curiosity. First in Rails, then move on to the next stop. So then I can read Programming Elixir and Programming Phoenix Liveview to try doing a web framework. How do I plan to make time for all this? Well, I think I can wrestle with Haskell for at most 30-60 minutes a day, so my time beyond that can be spent toying with web frameworks which requires less cognitive load. After Phoenix, there’s other options. I can try writing a typed API in Haskell with Servant or do something with Yesod. I also wouldn’t mind reading Distributed Services in Go and trying the same projects as microservices. I happen to like Go for being so simple that you can’t hide anything behind the language. I’ve recently read two books on it (reviews forthcoming) and feel pretty comfortable with it. Aside from that, I wouldn’t mind trying an Angular frontend with a backend in another language, since we actively use Angular in the new project at work. And I’m not opposed to trying React to just see the difference. Obviously, all JavaScript Single-Page Applications are more the rage now than old school web frameworks like Rails, and it fits my interests of seeing different ways to do things. I also have been toying around with Kotlin and would love an excuse to go back, so I would like to try Spring with Kotlin for the big enterprise way of doing a web framework along with Ktor for a lighter weight framework in the same language. I could code Spring in Java, but I do like not coding in Java when I’m away from work and find Kotlin a fun alternative. Spring and Angular are probably the most professionally relevant interests that I’ll be pursuing, but it’s obvious that I’m not trying to maximize for utility. I do really think it very clever that the new project at work is leaning into a modern Angular UI with a Java backend instead of using any of the trainwreck front end projects available on the Java platform. JSF was bad enough to make me never want to see a Java frontend again. Anyway, that’s as far as I’ve thought these two projects through, but if I make it that far with them, I’ll have a better idea of what I want to do next. Put together, they should keep me busy for a while, and assuming I don’t give up blogging for ten years or so again, it will give me something to blog about.

Why Now?

Why do I think blogging will catch on this time? Well, what made me give up my side projects and blogging before was primarily being burnt out on spending all day coding at work to get off and do more of it at night. Now that my kid is older and I’ve got more time to focus on personal development, I figured why not fire the blog back up so I can shout my book reviews and whatnot into the void. Aside from that, work has us leaning a lot more on AI for writing code these days, so it’s as good an excuse as any to keep my own skills sharp with some side projects. I’ve also been rather good lately at putting my mind to stuff and keeping it going. I lost about 40 pounds and run 10K every day I don’t lift weights. So maybe I can stay focused on something intellectual too. Also, I still run over an hour most days a week, which gives me a great opportunity to listen to a history audiobook or fictional work, so it isn’t like I’m giving up my hobby reading. I’m just cutting into other spare time with a new project. As a busy dad, I really get 1-2 hours of free time that I’m not working out most days, so it’s easy to spend 30-60 minutes on Haskell and the remainder if there is any on something else. Or so I think. We’ll see if this blog rebirth lasts. So far, I’ve read about 8 technical books that I’ll end up posting reviews for, so I already have more content than I had last time before discontinuing it, and it seems something fun to do. I’ve already been reading a minimum of 30 minutes a day for over a year, and often for hours, so I’m just going to read different stuff.

I didn’t put this in the first draft, because it feels kinda silly to get inspired by a book about a famous person, but there’s also another thing that motivated me to do more programming on the side. I listened to the audiobook on Steve Jobs while I was running. Really, I don’t care that much about Steve Jobs and still don’t after listening to his life story. He definitely had vision and did good things with Apple, and I’m writing this on a Mac so can’t complain about the results, but I consider him more of a visionary businessman than a real hacker. I liked Isaacson’s biography of Benjamin Franklin and figured Steve Jobs would be another accessible work by him for my runs. But you can’t read about the founding of Apple without encountering Woz. A true engineer that would’ve gladly made computers and gave them away, because he loved tinkering with circuitboards. I don’t really care about circuitboards either; I’ve always been a software guy. But being exposed to a story with that type of passion reminded me I used to be passionate about computers.

I’ve always had a bit of a love-hate relationship with Apple. I still have Linux on my desktop PC and am a proud member of the Columbia Linux User’s Group despite not attending meetings all that often. The early Apple computers were toys with no CLI and one button mice because multiple buttons are confusing. But after OS X was reborn with BSD under the hood and a full fledged terminal, I found that having a computer that mostly worked with the default configuration and actually looked pretty good made it easier for me to focus on writing code and not spend so much time tinkering around with Linux. I learned from the Steve Jobs book that the first Macs were expandable because Woz thought people should be able to tinker with their own computers. Maybe I would’ve liked those better than the Macs at school.

Anyway, back to passion, I didn’t take my computer apart and hide all the pieces because I thought it would be faster when I put it back together hours later. I did it because I wanted to learn how a computer was put together (I didn’t know I wasn’t really a hardware guy back then; I honestly prefer buying them off the shelf now). I also didn’t learn C and relational databases because I thought they would be profitable (although database knowledge is the gift that keeps on giving). I loved solving problems in C in the middle of the night on my hand-me-down computer. I didn’t found an ISP in the 90’s to get rich quick, I founded it to have fast Internet access and to have cool problems to figure out. Likewise, I didn’t make straight A’s in school because I expected it to help my job prospects. No one cares about my GPA. I loved the material! It was fascinating to learn about algorithms, operating systems, and, after programming so long, compilers. Somewhere along the way, it just became work like any other job. So it’s a combination of factors: having more free time now that my kid’s a little older, work leaning harder on AI for the actual code these days so I want to keep my own chops sharp on the side, a refound passion for programming inspired by a rather unlikely source, and the fact I’ve been reading every day over a year anyway, so why not make it technical. I still don’t know functional programming beyond how to apply a good map and filter, and I still haven’t tried a lot of different web frameworks. They’re all likely to be better than the Java EE/Spring hybrid monstrosity that I work on most of the time. Almost anything beats JSF.

And as an aside, this will probably be my last time trying to learn “functional programming”. If I try to learn the secrets of Haskell again and bounce off, I am just going to adopt Go as my programming language of choice and write lots of simple procedural code with structs and err checks every other line. As an old school C hacker and Perl scripter before they bolted on OOP, it feels quite natural to write straightforward procedural code, but I’m trying to work outside my comfort zone even if I think the benefits of functional programming might be overpromised.

But I really kinda understood the point of functional programming with Advanced Functional Programming with Elixir, and all those err checks in Go grated at my nerves, so the beauty of being able to chain a bunch of calls together then deal with errors or results at the end was quite appealing to me. Monads aren’t really the Elixir way though. Your average Elixir programmer would do some simple pattern matching to catch :err and deal with it instead, but Advanced Functional Programming with Elixir featured a Haskell inspired functional programming library and monads. And while I wasn’t ultimately convinced of the utility of the Reader or Effect monads (I’m open to learning more about those in Haskell, and I will have to anyway if I spend time with it), I really liked Maybe and liked Either even more. Even Java has Option, but Either is a lot more useful. Plus parallel validations with Applicative were kinda cool. They weren’t a reason to re-learn programming, but I’ll take them along with my Either and roll with it a bit.

Conclusion

So that’s it. The blog is reborn. I’ve got one project that meshes with the title of learning functional programming. I have another of trying web frameworks that has some limited overlap built in and picks up where the blog left off. I transferred my old posts over and rebuilt the site in Hugo and moved over what I could from the old Jekyll files. And I’ve written a very long coming back post plus already have a stash of book reviews in my Obsidian. So I guess I’m back and doing this for now and we’ll see where it goes. I may get tired of posting updates here and just read the books, but I like having somewhere to collect my thoughts and review what I read.