Grokking Simplicity (early impressions)

I’m going to spam the world by simply writing some early impressions on Grokking Simplicity by Eric Normand.

Nothing to do with the fact I've just picked up a mechanical keyboard and this seems like a great way to get used to the new key profile…

I read somewhere that a good way to make a book’s contents stick is to read a chapter or two, and then write about it. Just share some impressions and some thoughts. The book is subtitled “taming complex software with functional thinking” — I’d probably assume, if permitted, it might have read “a zero bullshit, wholly pragmatic way of thinking about functional programming in real-world circumstances.

Functional and me

So it’s only fair that I add a nice disclaimer [or two] here. My track record with functional has been more like a fling I occasionally call up, we have a little fun but it never gets serious. I took the typical teachings like “no side effects” “reduce global state” and “write pure functions” and weaved some of them into my day-to-day life because genuinely they’re good principles to live by. I did quite a bit of reactive programming in my days with RxJS and missed it after I moved over to a ReactJS position where it wasn’t a player in the stacks. The second disclaimer is I’m still reading but it feels like a big enough book that I could share a few interesting takeaways as I go.

Who should read it?

Well according to the book, they stipulate that it should be for anyone with 2–5 years of programming with at least one programming language under your belt.

I’m rocking 15+ but I’d be surprised if I even clocked up 1 of those doing what I’d consider ‘functional programming’ in any sense of ideas behind it. Something you learn later but no one explains that well early on in your career is it’s less about ‘what’ and a lot more about the ‘why’. Understanding the principles of something is far more useful and serves you more than learning the difference between currying and memoization.

What’s in the book?

The book itself is broken into 3 main parts

• Chapters 1–2 are some primers on his philosophies and principles and a little example of it applied in a trivial robotic-powered pizza company.
• Chapters 3–9 will go into (I’m getting into this now) the idea of how you should break down your applications into ‘actions’, ‘calculations’ and ‘data’.
• Chapters 10–19 focus on using first-class abstractions (sounds interesting)

Academic vs. Professional (real world)

An early ah-ha moment in this book tackles what I’m hoping will be the reason why I’ve struggled to take this fling further. The majority of the materials out there are based on academic functional programming which has a long history as far as I can see, as far back as the 1950s

The first high-level functional programming language, Lisp, was developed in the late 1950s for the IBM 700/7000 series of scientific computers by John McCarthy while at the Massachusetts Institute of Technology (MIT).

For those of us who don’t look a little more at our history, you’d be fooled into thinking it was something more so from the previous 20 years. I know I thought that… so it was interesting to consider that PLUS the fact a lot of the materials out there don’t typically originate from those of us writing applications where ‘side effects’ are ‘desired effects’. What is more important is understanding how we apply ‘functional thinking’ to our work.

Actions, Calculations and Data

These ‘he says’ probably come with different names depending on who you’re learning from. My impression is he’s deliberately picking his taxonomy to avoid you googling things like ‘pure’ and ‘impure’ functions and falling into the rabbit hole dug by 70 years of academic thinking.

• Actions: Functions are those which are not idempotent, when called, they will create effects or results that change over time. The idea here is you find these and isolate them, so you can focus the most time and attention on them. When something goes wrong in your life or with your code, then it’s highly likely one of these functions.
• Calculations: These are functions that when called with the same inputs will calculate the same output each time. The more we can build functions like this the better. They’re easy to test, and once tested you could almost forget about them.
• Data: This is inert, and requires interpretation. I’m not entirely sure yet WHY it needed its own spotlight but I’m sure this will make more sense later.

Next…

I’ll continue reading, it’s a very well-written and easy-to-follow set of explanations.