They give a nice introduction to encoding state as pure functions. In fact, there are many more purely functional encodings for all kinds of data like trees, integers, sum/product types, images, monads, ...

The encodings can be a bit confusing, but really elegant and tiny at the same time. Take for example a functional implementation of the Maybe monad in javascript:

  Nothing = nothing => just => nothing
  Just = v => nothing => just => just(v)
  
  pure = Just
  bind = mx => f => mx(mx)(f)
  
  evalMaybe = maybe => maybe("Nothing")(v => "Just " + v)
  console.log(evalMaybe(bind(Nothing)(n => pure(n + 1)))) // Nothing
  console.log(evalMaybe(bind(Just(42))(n => pure(n + 1)))) // Just 43

I recently came across the notion that you need inductive data types (and can't just use Church encodings) if you want to do theorem proving, like proving that `0 != 1`.

I threw up some content up here: https://intellec7.notion.site/Drinking-SICP-hatorade-and-why... , along with an unrelated criticism of SICP.

I'd like to better understand what the limitations are of "everything is just a function".

I've watched the actual SICP lectures before (the 1986 recordings on MIT OCW). They're often praised for the information density, but it actually still wastes a lot of time listening to students' Q&A, the lecturers drawing the class' attention to various attempts at "multimedia" presentation in the classroom, simply not having the entire lesson plan worked out in advance (i.e., not being able to preempt the Q&A) etc. For that matter, the sheer amount of time spent on writing things on a chalkboard really adds up.

And of course the order of the material could be debated and rearranged countless ways. One of my future planned projects is to do my own video series presenting the material according to my own sensibilities.

It's nice to hear that the course apparently still stays true to its roots while using more current languages like Python. Python is designed as a pragmatic, multi-paradigm language and I think people often don't give it enough credit for its expressive power using FP idioms (if not with complete purity).

The cons/car/cdr implementation as lambda was magical the first time I saw it. But it just shows that the language runtime must implement key/value dictionaries and you are able to borrow that implementation to make other data structures.

Warning: Diving into SCIP/Lisp/Scheme can transform how you think about programming... food for thought is always welcomed! But applying those ideas wholesale to OOP codebases often backfires or gets pushback from teammates. Languages handle paradigms differently, and going against the grain usually leads to worse code.

Example: After Lisp, you might replace every for loop with forEach or chain everything through map/reduce. But unless you’re working in a language that fully embraces functional programming, this approach can hurt both readability and performance.

At the end of the day, it’s grounding to remember there’s mutable memory and a CPU processing the code. These days, I find data-oriented design and “mechanical sympathy” (aligning code with hardware realities) more practical day-to-day than more abstract concepts like Church numerals.