Grokking Simplicity

What Hacker News says

1. sltrDec 2025
   > Does anyone have any good resources on how to get better at doing "functional core imperative shell" style design?

   I can recommend Grokking Simplicity by Eric Normand. https://www.manning.com/books/grokking-simplicity

   thread
2. leonseledJul 2024
   Yea agree. I feel one of the best books ive read that makes this concrete is Grokking Simplicity by Eric Normand. It’s less about functional programming and more about functional thinking. Lots of concrete great advice in that book.
   thread
3. LeftiumMar 2024
   Learning Functional Programming can provide immediate benefits. However, FP practitioners tend to be bad at teaching/explaining (to non-mathematicians) and even worse at marketing[0]. I've attached a list of good resources on FP at the end of this comment. I also wrote an article on the benefits of functional programming: https://blog.leftium.com/2023/04/more-performant-testable-co...

   Functional programming is more of a spectrum; not an "all or nothing" concept. You can write FP-style programs in non-FP languages. (And you can use non-FP style in FP languages.) Understanding FP will help you write better non-FP code.

   Simple example: I have switched from declaring an empty array [], then filling it via a loop to declaring the same array with values from a functional expression (like map). This has two benefits:

   1. The array can be declared const, and its contents possibly even declared read-only.

   2. TypeScript can automatically infer the type/shape of the array contents.

   The other example usually cited is that FP will help you understand recursion better, even in non-FP languages.

   FP is a paradigm that can be applied at many levels. You can apply it:

   - at the code level: removing logical branching in code (https://youtu.be/GyYME8btMHE?t=1473)

   - at the high-level design level: event sourcing (https://youtu.be/8JKjvY4etTY)

   Although FP languages make it more convenient to write functional-style code, notice the examples above don't need "functional" programming languages. In fact, many "non-functional" languages have borrowed the best parts of functional languages (first-class (lambda) functions, map, reduce, etc)[1].

   One of the most valuable, but misunderstood concepts of FP is immutability (functional purity). Grokking Simplicity[2] states it most elegantly: it's not about avoiding mutation because "mutation is bad." In fact, mutation is usually the desired result, but care must be taken because mutation depends on when and how many times it's called.

   So good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. After all, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc). Impure functions like these depend on the time they are called, so they are the most difficult to get right.

   ---

   Here's a short list of my top introductions/explanations of FP:

   - Grokking Simplicity: https://www.manning.com/books/grokking-simplicity

   - Functional Core, Imperative Shell: https://hw.leftium.com/#/item/18043058

   - ScottWlaschin: https://hw.leftium.com/#/item/21879368

   - Greg Young on Event Sourcing: https://youtu.be/8JKjvY4etTY

   - https://project-awesome.org/stoeffel/awesome-fp-js

   [0]: https://youtu.be/nuML9SmdbJ4

   [1]: https://hw.leftium.com/#/item/21280429

   [2]: https://www.manning.com/books/grokking-simplicity

   Show morethread
4. LeftiumAug 2023
   - Functional Core, Imperative Shell[1] helped me truly grok the paradigm of functional programming.

   - Grokking Simplicity[2] then shifted my thoughts on functional programming: it's not about avoiding mutation because mutation is bad. In fact mutation is usually the desired result, but care must be taken because mutation depends on when and how many times it's called.

   Mutation is flipping bits in storage, setting pixels on a screen, sending emails: these effects are desired, but it is crucial to only have these effects happen when we want them to, in the order desired, and exactly the number of times we expect.

   Compare to pure functions, which simply calculate a value: these can be called whenever, however many times we wish without any major negative consequences. They are much easier to reason about.

   ---

   However, the two books that rewired my mental model the most were not technical. These books totally altered my overall mindset:

   1. Conversations with God[3]. Best answers for biggest questions in life; answered better than any religion; actually resolves all the conflicts between different religions:

   - What is the meaning of life?

   - How did the universe begin?

   - Why do bad things happen to good people?

   - What happens after we die?

   2. Direct response marketing. (I coined the term "precision marketing" to differentiate from the "brute force marketing" usually conjured when people hear the word "marketing.") Lots of different resources; Start from Zero[4] is a good one. Expert Secrets[5] is a well-written collection of direct response marketing's greatest hits.

   [1]: https://hw.leftium.com/#/item/18043058

   [2]: https://www.manning.com/books/grokking-simplicity

   [3]: https://www.cwg.org/

   [4]: https://startfromzero.com/

   [5]: https://expertsecrets.com/

   Show morethread
5. LeftiumJul 2023
   FP is a way of thinking, which FP languages give nice features/syntax for. You can do non-FP style programming with an FP language.

   In fact, many FP language features have been borrowed by non-FP languages to the point people don't consider them "FP" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class functions[1].)

   Three features that would make FP thinking in JS easier:

   1. immutable tuples and records[2]

   2. pipe operator[3]

   3. pattern matching[4]

   Major epiphany: According to Grokking Simplicity[5], good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. Impure functions depend on the time they are called, so they are the most difficult to get right. In the end, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc).

   "Functional Core, Imperative Shell"[6] is probably the most useful FP concept. It is about pushing mutation/errors/impure functions to the outer edges of your code, so the inner code can focus on the "happy path." Complex business logic lives in the inner core; the outer shell is often simple/branchless so unit tests aren't even needed.

   [0]: https://hw.leftium.com/#/item/21280429

   [1]: https://hw.leftium.com/#/item/26900419

   [2]: https://hw.leftium.com/#/item/23924933

   [3]: https://hw.leftium.com/#/item/34454184

   [4]: https://hw.leftium.com/#/item/16921652

   [5]: https://www.manning.com/books/grokking-simplicity

   [6]: https://hw.leftium.com/#/item/18043058

   Show morethread
6. jasimApr 2023
   > Functional architecture makes extensive use of advanced abstraction, to implement reusable components, and, more importantly, supple domain models that anticipate the future.

   I believe Mike Sperber is talking about Haskell when he says "advanced abstraction", but most regular line-of-business software can reap significant benefits with just simple FP principles: mostly immutable data, record types, sum types, and a vocabulary of small decomposed functions that can parse, transform, and combine this data, together building to larger wholes.

   You do need a language with types and first-class functions, and the most common vehicle for that currently is TypeScript. Combine that with a book like Grokking Simplicity by Eric Normand, especially the fundamental idea of separating data, computation, and action, and you have a software system that is supple, simple, and amenable to continuous growth and refactoring over a long period of time.

   Grokking Simplicity, IMO, is a severely under-discussed book when it comes to FP. Its only sticking point for me is its lack of static types, but otherwise it is the first and only book that I've seen that distils the functional way of thinking for the working programmer in an accessible way, without having to resort to the all-or-nothing proposition of completely pure FP.

   Show morethread