Speaker 1: So how often do you actually think about the invisible
Speaker 1: architecture of the Internet when you do something really simple,
Speaker 1: like say a Google search.
Speaker 2: I mean probably never, right, You just want your answer
Speaker 2: right exactly.
Speaker 1: You type in a query, hit enter, and boom, billions
Speaker 1: of records are just sifted through to hand you a
Speaker 1: result in literally milliseconds. We treat it like magic.
Speaker 2: Oh absolutely, But you know, peaking under the hood reveals
Speaker 2: something entirely unexpected.
Speaker 1: Yeah, you won't just find like miles of fiber optic
Speaker 1: cables or massive server farms. You actually find this intense,
Speaker 1: unresolved mathematical debate from the nineteen.
Speaker 2: Thirties and the remnants of a totally failed nineteen eighties
Speaker 2: software revolution.
Speaker 1: Too, which is wild and well. It all points to
Speaker 1: a completely alien philosophy regarding how computers should solve problems
Speaker 1: in the first place.
Speaker 2: It really is a fundamental shift in logic. I mean,
Speaker 2: anybody who has written even a few lines of say
Speaker 2: Python or JavaScript, they intuitively understand computers as machines that
Speaker 2: just follow sequential instructions.
Speaker 1: Like step one, do this, step two, check that.
Speaker 2: Exactly, step three, update this counter. But there is an
Speaker 2: entire parallel universe of programming that completely abandons that step
Speaker 2: by step logic, basically rips the clock out of the
Speaker 2: computer entirely.
Speaker 1: And we are dissecting that universe today through our deep
Speaker 1: dive into Greg Michaelson's book An Introduction to Functional Programming
Speaker 1: through Lambda.
Speaker 2: Calculus, a fantastic albeit heavy.
Speaker 1: Read, oh definitely heavy. We're specifically looking at his foundational
Speaker 1: chapters and that rather candid twenty eleven Prephecy wrote, and
Speaker 1: you know, the objective here isn't just to learn a
Speaker 1: new coding language.
Speaker 2: No, no, it's way bigger than that, right.
Speaker 1: It's to understand what functional programming actually is mechanically, like,
Speaker 1: why this incredibly dense, seventy five year old math concept
Speaker 1: breaks our standard rules of computing, and.
Speaker 2: How it quietly became the load bearing pillar for the
Speaker 2: biggest distributed systems on the planet.
Speaker 1: So to appreciate this functional approach, we really have to
Speaker 1: isolate the underlying flaw in how we normally write software.
Speaker 2: Yeah, we do so. The most commercial code is written
Speaker 2: in what we call imperative languages. So thinks ce Java, Python,
Speaker 2: usual suspects, right, and they are built on this concept
Speaker 2: of mutating state. You issue an imperative command to change
Speaker 2: the value of a.
Speaker 1: Variable, like giving the computer in order.
Speaker 2: Exactly, you tell the system, hey, X is currently five,
Speaker 2: but now I command you to make x equal to.
Speaker 1: Six, which I mean that seems entirely logical to me.
Speaker 1: We are commanding the machine to update its memory.
Speaker 2: It does seem logical, well, until you try to do
Speaker 2: a million things at once.
Speaker 1: Aw the scale issue.
Speaker 2: Right. Because imperative programming is entirely reliant on state mutation,
Speaker 2: it creates this terrifying vulnerability known as a side effect.
Speaker 1: Okay, let's unpack this. Yeah, what exactly does a side
Speaker 1: effect look like in action?
Speaker 2: Well, imagine you have a variable tracking a user's bank balance, okay,
Speaker 2: and thread A is reading that balance to display it
Speaker 2: on a screen for you. But at that exact millisecond,
Speaker 2: thread B in the background mutates that variable to process
Speaker 2: a subscription fee.
Speaker 1: Oh wow, so thread A suddenly grabs the wrong number.
Speaker 2: Exactly. In an imperative program the state is the shared,
Speaker 2: constantly shifting battleground. Anyone can change it, so.
Speaker 1: It's basically like a chalkboard where you keep erasing and
Speaker 1: rewriting a running tally, and if someone erases it while
Speaker 1: you're looking away, you're messed up.
Speaker 2: That is a perfect analogy.
Speaker 1: Yes, so functional programming then basically removes the.
Speaker 2: Eraser precisely, it takes the eraser completely out of the equation.
Speaker 1: In this paradigm, a variable isn't a storage container you
Speaker 1: can just overwrite. It's more like a prominent mathematical binding.
Speaker 1: It's like carving a number into a stone tablet.
Speaker 2: I like that carved in stone. So once X is
Speaker 2: tied to the value of five, it is five forever.
Speaker 1: And if you want a new state, like if the
Speaker 1: bank balance changes.
Speaker 2: You don't mutate X. You have to evaluate a completely
Speaker 2: new expression that outputs a new value. You carve a
Speaker 2: new tablet.
Speaker 1: So you never actually change the data.
Speaker 2: Nope, you only pass it through functions to create new data.
Speaker 1: But how does that actually help with the bank balance problem.
Speaker 2: Well, that permanent binding changes the literal physics of the software.
Speaker 2: Because you never erase or mutate anything. You completely eliminate
Speaker 2: those side effects we talked about.
Speaker 1: Oh, because nothing can sneak in and change the data
Speaker 1: behind your back exactly.
Speaker 2: A function in this world is mathematically pure. It receives
Speaker 2: an input, does its calculation, and returns an output.
Speaker 1: It's totally isolated.
Speaker 2: Right, it's a hermetically sealed unit of logic. It cannot
Speaker 2: secretly reach outside of itself and mess with a global
Speaker 2: counter or access a database in the background.
Speaker 1: Okay, hold on, I understand the security of a hermetically
Speaker 1: sealed function. But and here's the catch. In a physical machine,
Speaker 1: things physically have to happen one after another in.
Speaker 2: Our standard view of time.
Speaker 1: Yes, right, If I write a program in an imperative language,
Speaker 1: the order of my commands is life. Rather, if I
Speaker 1: swap lines of code, the program.
Speaker 2: Just crashes because line three depends on the mutated state
Speaker 2: created by line two exactly.
Speaker 1: Sequence dictates.
Speaker 2: Well, that's the imperative prison. Right. You are basically chained
Speaker 2: to time. But because functional programming prohibits mutation entirely, time
Speaker 2: loses its authority over the code. Wait really, yeah, execution
Speaker 2: order simply ceases to matter.
Speaker 1: That sounds physically impossible. How can a machine process logic
Speaker 1: without a sequence. Doesn't the program need to know what
Speaker 1: to execute first to feed into the next step.
Speaker 2: It relies on this really elegant mathematical principle called the
Speaker 2: Church Rosser theorem. Okay, way on me, Let's look at
Speaker 2: a basic arithmetic expression, say two plus three in parentheses
Speaker 2: multiplied by four plus five in parentheses.
Speaker 1: Right.
Speaker 2: Because these are pure values with no hidden side effects,
Speaker 2: it genuinely does not matter if you calculate the two
Speaker 2: plus three first or if you calculate the four plus five.
Speaker 1: First, because they don't impact each other.
Speaker 2: Exactly, you will arrive at forty five either way.
Speaker 1: Okay, that makes sense in a small scale.
Speaker 2: Well, the church Rosso theorem mathematically proves that if a
Speaker 2: functional program terminates, it will yield the exact same final
Speaker 2: result regardless of the order in which its sub expressions
Speaker 2: are evaluated.
Speaker 1: Ah So, because the functions are pure, they just don't
Speaker 1: care who finishes first. They aren't waiting on some global
Speaker 1: variable to change somewhere else.
Speaker 2: What's fascinating here is what happens when you scale that
Speaker 2: concept up. You suddenly see why massive tech companies like
Speaker 2: Google and Amazon care deeply about this.
Speaker 1: Oh, because if execution order doesn't matter, you aren't limited
Speaker 1: to running your program on just one processor exactly.
Speaker 2: You can take a massive functional program, shatter it into
Speaker 2: a million independent pieces, and farm those pieces out to
Speaker 2: tens of thousands of cheap servers simultaneously.
Speaker 1: That is incredible, and Michaelson actually notes this in his
Speaker 1: twenty eleven preface right that Google's map produce framework is
Speaker 1: built directly on these concepts.
Speaker 2: He does, map reduce is the engine that made their
Speaker 2: search indexing so incredibly fast.
Speaker 1: How does that actually map to functional programming? Though?
Speaker 2: So the map function processes data independently across thousands of
Speaker 2: machines without any shared state, and then the reduced function
Speaker 2: aggregates all those pure outputs.
Speaker 1: So there are no locks, no race conditions, no side effects, none.
Speaker 2: It's perfectly parallel.
Speaker 1: Okay, I see how that enables massive parallel processing for
Speaker 1: a tech giant. But let me challenge the everyday utility
Speaker 1: of this for a second.
Speaker 2: Go for it.
Speaker 1: If I have no sequence and I'm not allowed to
Speaker 1: mutate a variable, how do I actually do something repetitive?
Speaker 1: How do I iterate?
Speaker 2: Give me an example?
Speaker 1: Okay, say I want to search through a list of
Speaker 1: a million log files to find one specific error code.
Speaker 1: In normal imperative code, I write a standard for loop.
Speaker 1: I use a counter variable what's called I, and I
Speaker 1: mutate I from one to a million, checking the list
Speaker 1: each time.
Speaker 2: The classic approach.
Speaker 1: Sure, right, So how do you loop without a counter.
Speaker 2: Well you don't. You don't use loops at all.
Speaker 1: Wait what no loops?
Speaker 2: No loops. Loops inherently require state mutation. You have to
Speaker 2: update that counter instead. Functional programming relies on recursion.
Speaker 1: Okay, recursion, how does that work? In this context?
Speaker 2: You have a function that processes the very first item
Speaker 2: in the list, just the first one. If it's not
Speaker 2: the error code you're looking for. The function calls a
Speaker 2: brand new, pristine copy of itself. Oh, I see it,
Speaker 2: and it passes the remainder of the list to that
Speaker 2: new copy.
Speaker 1: Okay, let me make sure I'm visualizing this right. So
Speaker 1: instead of one runner running a million laps and checking
Speaker 1: a stopwatch every time, you basically have a relay race
Speaker 1: with a million distinct runners.
Speaker 2: Yes, that's a great way to put it.
Speaker 1: Each runner only runs one step, looks at the data,
Speaker 1: and passes the baton to a totally new clone of themselves.
Speaker 2: That's a very solid way to visualize it. Every recursive
Speaker 2: call creates a completely fresh execution context. You never change
Speaker 2: the original list.
Speaker 1: You just keep peeling off the first element and passing
Speaker 1: the rest for.
Speaker 2: Us exactly, and this forces a radically different approach to
Speaker 2: data structures as a whole because there's no assignment. There
Speaker 2: are no arrays where you can just tweak element number four.
Speaker 1: Right, because you can't mutate it.
Speaker 2: You have to explicitly pass entire nested structures through these
Speaker 2: recursive chains, and you rely heavily on abstraction to keep
Speaker 2: the logic clean.
Speaker 1: Which brings us to chapter two. Michaelson dedicates that whole
Speaker 1: chapter to the concept of abstraction, and it seems really
Speaker 1: pivotal here.
Speaker 2: It is without abstraction, this whole system collapses under its
Speaker 2: own weight.
Speaker 1: Because abstraction isn't just about hiding complexity, right, It's about
Speaker 1: shifting from concrete values to generalized rules exactly.
Speaker 2: Michaelson gives a great simple example. If you are calculating
Speaker 2: the cost of a shopping cart. You don't hard code
Speaker 2: nine items times ten cents.
Speaker 1: You introduce names like quantity in price, right.
Speaker 2: You abstract the specific operation into a general, pure rule.
Speaker 1: Here's where it gets really interesting, though. Functional programming takes
Speaker 1: this a step further. It doesn't just abstract data, it
Speaker 1: abstracts the operations themselves.
Speaker 2: Yes, functions are tree as first class citizens.
Speaker 1: Which sounds fancy, but what does it actually mean.
Speaker 2: In practice, it means functions are treated exactly like data.
Speaker 2: You can pass a function into another function as.
Speaker 1: An argument, like passing a number.
Speaker 2: Exactly the same. You can even write a function whose
Speaker 2: only job is to dynamically construct and spit out an
Speaker 2: entirely new function based on the input it received.
Speaker 1: That is wild. You are manipulating logic the exact same
Speaker 1: way you manipulate integers.
Speaker 2: It is a total paradigm shift.
Speaker 1: And the ultimate expression of that is Lisp right list processing.
Speaker 1: I know it's one of the earliest languages to adopt
Speaker 1: these concepts.
Speaker 2: Oh LSP is legendary for this because.
Speaker 1: In LASP, the syntax you write to create the program
Speaker 1: is literally just a nested list itself.
Speaker 2: Right, So the command add two three is mathematically the
Speaker 2: same fundamental data structure as a list of groceries like
Speaker 2: Apple's milk bread.
Speaker 1: The code is data and the data is code. I
Speaker 1: think the technical term is homo econicity.
Speaker 2: Homo econicity. Yes, it's a bit of a mouthful, but
Speaker 2: it basically it means an Lisp program can effortlessly read, rewrite,
Speaker 2: and generate other Lisp programs.
Speaker 1: On the fly, mind bending.
Speaker 2: It creates this incredible fluidity. Imperative languages which strictly separate
Speaker 2: the compiled instructions from the memory heap, they simply cannot
Speaker 2: mimic that.
Speaker 1: But you know what makes this so compelling isn't just
Speaker 1: the architecture itself. It's the origin story.
Speaker 2: Oh, the history is fascinating.
Speaker 1: Right, because this entirely alien way of structuring computation was
Speaker 1: not invented by some modern computer scientists trying to optimize
Speaker 1: cloud networkloads.
Speaker 2: Not at all. It's way older than that.
Speaker 1: It was born from a profound philosophical crisis among mathematicians
Speaker 1: in the nineteen thirties.
Speaker 2: We really have to rewind the tape to understand this.
Speaker 2: Long before silicon ships even existed, mathematicians were obsessed with
Speaker 2: a seemingly.
Speaker 1: Simple question, is math unbreakable?
Speaker 2: Exactly? Is it perfect? So in the nineteen twenties, the
Speaker 2: German mathematician David Hilbert proposed what became known as Hilbert's program.
Speaker 1: Okay, what was his goal?
Speaker 2: He wanted to formally prove that mathematics was both consistent
Speaker 2: and complete.
Speaker 1: Those words probably have very strict definitions in this context.
Speaker 2: Very strict consistent means you can never use the rules
Speaker 2: of math to prove a contradiction like you can't logically
Speaker 2: prove that one equals two.
Speaker 1: That makes sense and complete.
Speaker 2: Complete means that every single true mathematical statement has a
Speaker 2: definitive proof that can be derived from the foundational axioms.
Speaker 1: So no mysteries, everything can be proven right.
Speaker 2: Hilbert wanted to build a perfect mechanized system of logic
Speaker 2: where literally any problem could eventually be solved just by
Speaker 2: turning the crank of mathematical rules.
Speaker 1: A beautiful dream, and then Kirk Godel totally shattered that
Speaker 1: dream in nineteen thirty one.
Speaker 2: He utterly obliterated it with his incompleteness theorems how did
Speaker 2: you do it? Godel realized that if a formal system
Speaker 2: is complex enough to handle basic arithmetic, it can actually
Speaker 2: be made to talk about itself.
Speaker 1: Okay, this is getting a bit meta.
Speaker 2: It is. He developed this brilliant technique called Godal numbering,
Speaker 2: where he assigned a unie nique numerical code to every
Speaker 2: mathematical symbol and operation.
Speaker 1: So he basically turned mathematical equations into a kind of
Speaker 1: programming language that could output statements about its own code.
Speaker 2: Yes, and using that he encoded a mathematical statement that
Speaker 2: translated essentially to this statement cannot be proven.
Speaker 1: Oh wow. It's a classic liar's.
Speaker 2: Paradox, but weaponized against arithmetic itself. Think about it. If
Speaker 2: the statement is false, it means it can be proven,
Speaker 2: which means math just proved a falsehood, making the entire
Speaker 2: field of mathematics inconsistent.
Speaker 1: And if the statement is true.
Speaker 2: If the statement is true, it means there is a
Speaker 2: true mathematical fact that lacks a proof, meaning mathematics is
Speaker 2: fundamentally incomplete.
Speaker 1: Wow. So there are true things we can never mathematically
Speaker 1: prove exactly.
Speaker 2: It's a devastating realization for mathematicians.
Speaker 1: I can imagine. Yeah, but the ashes of Hilbert's program
Speaker 1: triggered this incredible race, didn't.
Speaker 2: It It did. If math has limits, mathematicians urgently needed
Speaker 2: to define exactly what could be computed, Like what are.
Speaker 1: The strict boundaries of mechanical calculation?
Speaker 2: Right? And in nineteen thirty six, two brilliant thinkers published
Speaker 2: two completely different road maps for computability.
Speaker 1: This is where the timeline of human technology literally splits.
Speaker 2: It really does. On one side, you have Alan Turing.
Speaker 2: Turing defined computability using a theoretical.
Speaker 1: Machine, the famous Turing machine.
Speaker 2: Right picture an infinite tape divided into squares with a
Speaker 2: read right head, moving left and right, erasing and rewriting
Speaker 2: symbols one step at a time based on a set
Speaker 2: of rules.
Speaker 1: And that tape inherently implies sequence. It moves forward, it
Speaker 1: moves backward, It updates the state of the squares during
Speaker 1: basically formalized the imperative model we talked about earlier. Do
Speaker 1: this change that?
Speaker 2: Move here exactly. And on the other side of this
Speaker 2: you have Alonzo Church, who is actually Turing's doctoral advisor.
Speaker 1: Oh really, I didn't know that.
Speaker 2: Yeah, and Church didn't care about tapes or machines or sequence.
Speaker 2: He created lambda calculus.
Speaker 1: Which is the foundation of functional programming.
Speaker 2: Yes, it is a formal system based entirely on stateless function,
Speaker 2: abstraction and variable substitution. No tape, no time, no mutation, just.
Speaker 1: Pure expressions evaluating other expressions.
Speaker 2: If we connect this to the bigger picture, the ultimate
Speaker 2: plot twist here is Church's thesis. Turing and Church actually
Speaker 2: prove that their completely divergent systems were mathematically equivalent.
Speaker 1: Wait, really, the tape and the stateless equations are the same.
Speaker 2: Yes, anything you can compute on Turing's sequential tape, you
Speaker 2: can compute using Church's timeless lambda equations. They defined the
Speaker 2: exact same universe of computability. They were just speaking two
Speaker 2: completely different dialects.
Speaker 1: But those dialects had massive real world implications.
Speaker 2: Huge implications Turing's model maps beautifully onto physical.
Speaker 1: Reality because a read write head moving along a tape
Speaker 1: is conceptually identical to an electrical switch turning on and
Speaker 1: off to update a memory register exactly.
Speaker 2: So when engineers built the first digital computers, they basically
Speaker 2: built physical Turing machines, and.
Speaker 1: So imperative programming languages like Fortran and c were designed
Speaker 1: to orchestrate those physical state changes.
Speaker 2: While Church's lambda calculus, despite being mathematically pure and beautiful,
Speaker 2: was just too abstract for early hardware. It got relegated
Speaker 2: to academia.
Speaker 1: Well until the nineteen eighties.
Speaker 2: Anyway, Right the eighties changed things.
Speaker 1: Michaelson's twenty eleven preface spends a lot of time dissecting
Speaker 1: this massive resurgence of functional programming during that era.
Speaker 2: What happened the tech industry hit a wall. It was
Speaker 2: widely known as the software crisis.
Speaker 1: Because of the side effects. We talked about.
Speaker 2: Exactly, because imperative programs rely on mutating shared state. As
Speaker 2: programs grew larger and larger, the side effects became impossible
Speaker 2: for humans to manage.
Speaker 1: I'm guessing bugs were just multiplying exponentially. Code was crashing
Speaker 1: left and right.
Speaker 2: There was a genuine panic in the industry. The Japanese
Speaker 2: government actually launched the Fifth Generation Computing Initiative, aiming to
Speaker 2: build machines that ran entirely on pure.
Speaker 1: Logic, and the UK responded to that right they did.
Speaker 2: The ALVI program. They heavily funded functional languages like Hope,
Speaker 2: mL and eventually Haskell.
Speaker 1: Because a pitch was incredibly alluring. Just abandoned imperative state,
Speaker 1: adopt Church's timeless mathematics, and your code will be theoretically
Speaker 1: bug free and mathematically provable.
Speaker 2: It was touted as a total silver bullet.
Speaker 1: So what does this all mean? If it was mathematically superior,
Speaker 1: why did it fail to take over the industry, Why
Speaker 1: did messy imperative languages like C plus plus and Java
Speaker 1: end up winning the war?
Speaker 2: Well, Michael Sola is refreshingly honest about this in his preface.
Speaker 2: Pure declarative and functional languages were basically overhyped because they
Speaker 2: ignored the fundamental nature of reality, meaning what exactly, meaning
Speaker 2: the physical world is inherently stateful. Time exists, oh or right,
Speaker 2: when a human interacts with a computer, clicking a button,
Speaker 2: typing a word, saving a file to a hard drive,
Speaker 2: those are sequential events. They literally mutate the state of
Speaker 2: the world.
Speaker 1: Ah. If pure functional programming doesn't allow side of it
Speaker 1: effects or state changes, how do you even update a
Speaker 1: database or draw a pixel on a screen?
Speaker 2: You see the problem. It becomes incredibly cumbersome. You have
Speaker 2: to invent these hugely complex mathematical workarounds, things called monads,
Speaker 2: just to allow a pure function to interact with the messy,
Speaker 2: time bound reality of a user interface.
Speaker 1: So pure functional programming is brilliant beyond time, but it
Speaker 1: is deeply awkward when forced to operate within time.
Speaker 2: That's a great summary. Therefore, imperative languages maintain their dominance
Speaker 2: for writing operating systems, desktop applications, and user interfaces.
Speaker 1: But the narrative doesn't just end in the eighties, obviously,
Speaker 1: since we're still talking about it today.
Speaker 2: No, it doesn't, because the Internet changed the scale of
Speaker 2: software completely.
Speaker 1: Right. We move from desktop apps running on a single
Speaker 1: CPU to these distributed cloud systems running across ten thousand nodes, and.
Speaker 2: Suddenly we hit the limits of Turing's tape all over.
Speaker 1: Again, because when you have a million users hitting at
Speaker 1: database simultaneously, imperative state mutation becomes your biggest bottleneck.
Speaker 2: Exactly, you spend all your processing power just trying to
Speaker 2: lock variables so that all those different threads don't overwrite
Speaker 2: each other, like try and keep.
Speaker 1: A million people from erasing that jockboard at the same time.
Speaker 2: Yes, and to solve this, the industry quietly surrendered to
Speaker 2: Alonzo Church.
Speaker 1: Which is amazing. We see it everywhere now. Telcom giants
Speaker 1: use erlang, which is a deeply functional language to manage
Speaker 1: millions of concurrent phone calls without crashing.
Speaker 2: Yep. Microsoft baked f sharb into their entire enterprise framework.
Speaker 1: And even the biggest imperative heavyweights like Python, c Sharp, Java,
Speaker 1: they have aggressively adopted functional features over the years.
Speaker 2: They absolutely had to. They absorbed lambda expressions, higher order functions,
Speaker 2: and map produce paradigms specifically to handle parallel processing safely.
Speaker 1: So it's really a hybrid reality now very much so.
Speaker 2: We use Turing's sequential state mutating logic for the boundaries
Speaker 2: of our applications, you know the UI, the direct database
Speaker 2: rights the things humans physically touched.
Speaker 1: But for the massive concurrent data crunching core, we rely
Speaker 1: on Church's stateless pure functions.
Speaker 2: It's the best of both worlds.
Speaker 1: Well, we've covered a staggering amount of theory today. We
Speaker 1: really have We impact how the simple act of forbidding
Speaker 1: a variable to change, basically banning the eraser on the chalkboard,
Speaker 1: completely eliminates side effects.
Speaker 2: And we examine how the Church Rosser theorem proves that
Speaker 2: pure functions don't care about execution order at all, which
Speaker 2: opened the door for massive parallel computing.
Speaker 1: We trace those origins all the way back to the
Speaker 1: shattering of Hilbert's program by Kurt Guttle, which led to
Speaker 1: the defining computability race between Turing's physical tape and Church's
Speaker 1: mathematical lamb to calculus.
Speaker 2: And then we looked at how the nineteen eighties failed
Speaker 2: to force a purely stateless model onto a very stateful world,
Speaker 2: leading to today's pragmatic hybrid architecture that we use every day.
Speaker 1: It really leaves a fascinating philosophical.
Speaker 2: Questions on the table I know where you're going with this.
Speaker 1: Right, Because we default to imperative coding because it mirrors
Speaker 1: our day to day sequential experience of time. We do this,
Speaker 1: then we do that.
Speaker 2: It feels natural to us.
Speaker 1: But if lambda calculus is actually a cleaner, more mathematically
Speaker 1: pure way to process complex logic across a massive network,
Speaker 1: how does our own neural network operate?
Speaker 2: This raises an important question. Are our brains imperative machines
Speaker 2: constantly overwriting localized memory states as we experience time step
Speaker 2: by step?
Speaker 1: Or is human cognition actually a functional web evaluating infinitely
Speaker 1: nested concepts in parallel, completely independent a sequence. Have a
Speaker 1: great time mulling that over