Avdi Grimm
Closing Keynote: OOPS
Summarized using AI
Closing Keynote: OOPS
by Avdi GrimmIn his closing keynote at the Keep Ruby Weird 2018 event, Avdi Grimm explores the theme of whimsy in Ruby programming, focusing on the philosophical implications of object-oriented programming (OOP) and its inherent transactional fallacy. He argues that code, while essential, is incidental to programming, which should be viewed as an applied philosophy that shapes our understanding of the world. Grimm emphasizes the importance of messaging over method calling in OOP, referencing Alan Kay's original vision of OOP as a messaging-oriented system rather than one focused solely on objects.
Key points discussed include:
- Whimsy in Ruby Culture: The quirky nature of Ruby programming reflects a whimsical culture, although Grimm admits he struggles with this concept.
- Code as Incidental: Programming should be seen as a way to express philosophy and understand the world, rather than just writing code.
- Messaging vs. Methods: OOP should focus on messaging, where objects communicate and decide how to respond, contrasting with the traditional view of calling methods.
- Transactional Fallacy: Grimm identifies a significant issue in programming practices—modeling processes as transactions leads to confusion and disconnection from real-world dynamics.
- Importance of Grace: Building graceful processes involves starting from current states, acknowledging history, and embracing failures as part of the learning experience.
- Embodiment in Programming: Encourages programmers to stay connected with their bodies and recognize their physical self as vital to their work life.
Grimm concludes that by recognizing the intertwined relationship between our programming ideals and our life philosophies, we can approach both programming and life with a mindset focused on process, flexibility, and grace. He urges programmers to move beyond transactional thinking and build systems that respect the complexities and messiness of reality. The keynote serves as a reflective call to rethink our programming practices and life choices, reminding us to embrace the process rather than fixate on predetermined outcomes.
00:00:09.500
Hello! How y'all doing?
00:00:16.100
Right, so yes, I am Avdi and this is my very first Keep Ruby Weird.
00:00:22.380
Now I'm kind of bummed out that I missed all the other ones, but we soldier on. This has been so cool!
00:00:34.469
Before I go any further, can we just get a round of applause for Terrence and all the organizers?
00:00:49.780
I have to admit that I feel a little bit unqualified to be up here. I've been a fan of Ruby's weirdness over the years, and the quirks associated with it.
00:01:01.430
However, I think the most defining feature of Ruby's weirdness and its culture has been whimsy.
00:01:10.060
It has a real whimsical silliness to it. I had to come to terms with the fact that I'm just not very good at whimsy.
00:01:21.140
In fact, I dislike puns.
00:01:26.540
So hopefully, you can put up with me. I may not be good at whimsy, but I have a lot of weird ideas.
00:01:35.770
For the past few years, I’ve been preoccupied with one particular weird idea: I believe that code is incidental to the practice of programming.
00:01:55.970
I don’t think that code is central. Instead, I believe that programming is the practice of applied philosophy.
00:02:12.800
We use code as a tool for making sense of the world around us, for categorizing concepts, and for telling the stories that shape our experiences.
00:02:24.830
But here's the crucial point: I don't think it goes just one way.
00:02:32.319
I believe that the way we design software is unconsciously influenced by our beliefs about how the world works. Our ways of perceiving the world are also unconsciously influenced by how we model the world in code.
00:03:07.240
There's a principle from the Hermetic philosophical tradition that encapsulates this idea: "As above, so below."
This means that what is within us is reflected in our work in the world, and our work in turn changes how we perceive the world.
00:03:29.709
I believe our approach to software gives us a window into how we think about the world, our lives, and our relationships.
00:03:55.180
Today, I want to take you on a philosophical journey. I want to tell you a story about this mutually reflective relationship between our inner world and the world of programming.
00:04:08.470
It starts 20 years ago. This year is an anniversary for me. Twenty years ago, this past summer, I was taking an advanced C++ course at my local community college.
00:04:29.979
I was nailing all my assignments but still needed a final project to wrap up my grade.
00:04:43.270
Coincidentally, at that same time, my dad was working as a programmer at Raytheon. He got this bright idea that since I was learning about C++, I could consult with his team on their software project.
00:05:06.340
Somehow, he convinced his boss that this was a good idea. So there I was, this 18-year-old kid in a tie-dye shirt, sitting with buttoned-down engineers, trying to sound like I knew what I was talking about.
00:05:21.070
Mostly, I remember just repeating the word "polymorphism" over and over again, while they nodded along.
00:05:34.330
A couple of months later, I received a call from the engineering manager asking if I wanted to work for them as a contractor on the same project.
00:05:50.290
That was the beginning of my professional software career, coincidentally attached to a radar project that I worked on.
00:06:01.750
Has anyone here ever flown into Chicago, San Francisco, Detroit, Philadelphia, or Atlanta?
00:06:13.980
I've realized that my career in software has centered around the idea of object-oriented programming from the very beginning.
00:06:30.350
I've been thinking about object-oriented programming for two decades now, and along the way, I discovered that nearly everything I thought I knew about it was wrong.
00:06:45.550
I don’t have time tonight to discuss all the OO fallacies I've had to unlearn—that's a different talk altogether.
00:06:58.150
But here's the thing: you might be wondering what right or wrong even means concerning object-oriented programming.
00:07:07.180
Who gets to define object-oriented programming anyway?
00:07:18.580
Well, OO is not like Agile; it wasn't defined by a committee. While it built on many earlier ideas, the design paradigm of object-oriented programming was invented and named by Alan Kay.
00:07:29.569
Kay and his team at Xerox PARC created a programming language that aimed to embody the spirit of object-oriented programming, and that was Smalltalk.
00:07:42.729
Pretty much every OO language or those trying to embody OO principles have been influenced by Smalltalk, including Ruby.
00:07:54.830
If I'm going to discuss what is and isn't object-oriented, my authority will be Alan Kay and his writings about object-orientation.
00:08:07.880
While he never provided a formal definition, one of the most concise explanations he gave is this: "OOP to me means only messaging, local retention, and protection and hiding of state, plus extreme late binding of all things."
00:08:21.849
Understanding how Kay defined OO clarified many things for me. However, even with those understandings, there was one massive fallacy I had yet to confront, which I want to address today.
00:08:37.070
Early in my career, I thought OO was all about calling methods. Calling a method meant invoking a procedure on an object instead of merely passing an object or a data structure to that procedure.
00:09:04.730
Later, I learned that OO was really about sending messages. Alan Kay himself regretted naming it object-oriented programming, as the focus should be on messages.
00:09:19.579
So, what is the difference between messages and methods? When we send a message, the object we send it to decides which procedure to run.
00:09:32.540
Different objects can implement different methods for the same message. This is a form of late binding, as the decision is made at the last moment.
00:09:50.290
Messages invoke methods where the actual definition is determined at runtime based on the object's type.
00:10:02.570
This definition of messages makes sense, right? It’s the one I've taught to others for years. But let's compare the object-oriented definition of messaging with the original, traditional meaning.
00:10:16.700
When we send a message through the mail, we include everything the recipient might need to know in order to act upon that message. If they need information from an outside document, we summarize the relevant parts.
00:10:50.210
When sending a message to an object, we can send along the whole kitchen sink if we want. When we send a message through the mail, we step away from the mailbox and move on with our lives.
00:11:13.340
We may or may not receive a reply. In contrast, when we send a message to an object, it’s synchronous; we wait until that object finishes processing the message.
00:11:29.000
In some languages, we always receive a reply in the form of a return value.
00:11:43.570
If we send a message in a language the recipient doesn't understand, nothing happens. But if we send a message to an object that doesn't understand it, our entire thread of execution crashes.
00:12:08.220
When sending a message through the mail, we know it might not reach anyone. Yet when sending a message to an object, we expect it to be handled or our entire thread fails.
00:12:19.410
These characteristics start to diverge from the concept of messaging. Yet we’re told that messaging is central to OO.
00:12:47.740
Let me tell you a quick parable: One day, the master said to the novice, "When you achieve mastery, you will be able to move objects using only the power of your words."
00:12:54.920
The novice replied, "But master, I have lived with you for ten years and have never seen you use this power even to bring the TV remote to the couch. You always tell me to fetch it for you."
00:13:03.290
At that moment, the novice was enlightened.
00:13:06.870
Here’s the bitter truth of object-oriented programming over the past 40 years: much like the Zen master, we promise the power of sending messages.
00:13:25.110
However, we are not actually succeeding. Alan Kay envisioned objects as similar to biological cells or individual computers on a network, communicating solely through messages.
00:13:36.060
But even Smalltalk, the language designed to embody OO principles, never fully realized the messaging idea.
00:13:42.720
In fact, every OO language has failed to deliver on the central promise of OO, yet we continue to act as though we are programming with real messages.
00:14:07.070
This disconnect between our conversations and the reality is why we repeatedly revisit the question of how to do OO correctly.
00:14:20.960
My goal isn’t to dismantle your faith in object-oriented programming, but cognitive dissonance is dangerous.
00:14:34.290
For decades, we have claimed that we are programming with messages when we obviously are not.
00:14:50.210
Many will argue that the original sin of object-oriented programming is mutable state. I disagree.
00:15:04.700
I believe the original sin is return values. Return values fundamentally deny the messaging model.
00:15:17.170
But I'm not here to deliver yet another critique of object-oriented programming. This problem of synchronous procedure calls with return values goes beyond just OO.
00:15:32.510
There is a monster stalking the programming labyrinth, and in my experience, this monster causes more confusion, more technical debt, and more rework than any other misconception.
00:15:51.820
I call this beast the transactional fallacy. The transactional fallacy occurs every time a developer models a process as a transaction.
00:16:09.540
A transaction has a goal and no existence beyond that goal. It is synchronous, blocking until it finishes.
00:16:29.270
You can’t set a transaction aside for later. It must complete in essentially zero time, at least from a human perspective.
00:16:45.970
It shouldn’t hang indefinitely; it either completes or aborts with no concept of partial completion.
00:16:58.620
If an error occurs, it self-destructs, leaving behind nothing more than an exception.
00:17:14.200
Every time your service workers crash because a web service unexpectedly takes minutes to respond, that's the transactional fallacy at work.
00:17:30.500
Every time your program freezes while parsing a large chunk of input and showing a progress bar seems impossible, that’s the transactional fallacy.
00:17:46.930
When you realize a form needs to be multi-page and your code requires drastic rewrites, that's the transactional fallacy.
00:18:05.200
When users lose their work after a session expires and become frustrated, that’s the transactional fallacy in action.
00:18:27.840
And then, when you find out you need to run queries against incomplete form submissions, once again, that's the transactional fallacy.
00:18:41.470
Modeling processes as transactions creates numerous complications.
00:18:51.940
Every time I bring one of my kids to a new doctor, I spend 15 minutes filling out intake forms.
00:19:03.800
At least I know that if I put the clipboard down, the forms won’t reset. I can take the forms with me into the consulting room and fill them out asynchronously.
00:19:11.860
I can leave some fields blank, and if they need additional information, they can reach out to me.
00:19:19.970
I shudder to think what the intake experience would be like if designed by a programmer.
00:19:36.060
The transactional fallacy has a universal symbol: the spinning beach ball of death.
00:19:49.600
It's the universal symbol for a programmer's expectation that something will finish or fail quickly, yet it does neither.
00:20:03.950
The transactional fallacy extends beyond code; remember what I said earlier: as above, so below.
00:20:20.960
Our coding approach and our philosophy of life are interconnected and mutually reinforcing.
00:20:37.320
Fundamentally, the transactional fallacy is not merely a programming problem; it reflects a misunderstanding of the world and the lives of the people in it.
00:20:56.730
When we commit to a transactional perspective, it can lead to serious ramifications.
00:21:03.269
I want to get a little more personal. I mentioned earlier that I started my software career at 18.
00:21:16.350
In retrospect, this marked the beginning of an almost 20-year-long transaction.
00:21:27.809
They say it's good to have goals. Well, back then, I envisioned my desired life: a wife, lots of kids, a house in the woods in the mountains.
00:21:42.480
I wanted to work from home, surrounded by my kids. I aimed to homeschool and homestead.
00:21:56.480
I dreamt of building tire swings, creating tree forts, being snowed in with a roaring fire, and sipping tea while thinking and writing.
00:22:09.600
So I set out on a path to accomplish these dreams.
00:22:23.970
Shortly after getting that first software job, I figured I could fast-track my goals by acquiring an instant family.
00:22:39.810
I became a husband to a woman I barely knew and a stepfather to two young children I was unprepared to raise.
00:22:55.490
As we had more children, money was tight, and those visions of my goals seemed to fade.
00:23:02.460
So, I focused single-mindedly on advancing my career to achieve them.
00:23:15.500
This influenced every decision I made, from working late, neglecting hobbies and friendships, switching jobs, to starting my own business.
00:23:33.110
I raised my profile through blogging, podcasting, writing books, and giving conference talks, all in service to this one vision.
00:23:46.350
I was relentless, living for the future: 'When I get there, I’ll have game nights with the kids,' or 'When I get there, we’ll go hiking every week.'
00:24:08.170
I thought, 'Just a few more long days and years, and everything will align.' Even when our values suggested we should update our dreams, I didn’t waver.
00:24:32.530
My life had become a synchronous transactional function, fixated on the return value. You bet you didn’t see that coming.
00:24:50.780
I reached my destination literally; I drove up a steep mountain driveway to our new Tennessee home.
00:24:56.640
At age 35, I had accomplished every goal. But I only enjoyed that feeling for two years.
00:25:09.920
A year and a half ago, my wife told me she was leaving, something we both agreed should have happened much earlier.
00:25:35.200
Working through our separation agreements revealed how every part of the dream I worked toward was set for disassembly.
00:25:56.170
From the aftermath, many revelations emerged, including how transactional my approach to life had become.
00:26:09.890
I realized I had spent nearly two decades trying to bring my life to an end, not in death, but to a static state—a return value.
00:26:31.030
If you’ve seen the Lego Movie, I realized I had become Lord Business, striving to control everything.
00:26:38.880
My vision was so vivid that I lost sight of the present. It wasn’t news that my partner and I were miserable together, but I had overlooked it.
00:26:58.490
Transactions ignore intermediate statuses; they resolve to only two possible outcomes: success or failure.
00:27:09.770
As programmers, we often think in terms of problems, solutions, outcomes, and binary states. I had become my own spinning beach ball of death, waiting on function returns.
00:27:27.880
It may seem I'm stretching the metaphor here, but consider this: you can’t spend eight hours a day, five days a week on something and not have it influence your worldview.
00:27:36.180
As above, so below—our programming paradigms seep into our worldview.
00:27:50.780
This brings us back to programming. Is there an alternative to thinking in transactions?
00:28:05.540
Let’s revisit Alan Kay and Smalltalk for a moment. He envisioned objects as biological cells or individual computers, communicating through messages.
00:28:12.200
This description suggests something asynchronous, independent, and potentially resilient.
00:28:29.300
Digging into Smalltalk's history reveals the roots of a more profound design than the sham messaging system we've learned to cope with.
00:28:41.179
For example, in Smalltalk 72, classes are also functions that match incoming messages and decide their actions, potentially ignoring them altogether.
00:29:00.930
If you look at this closely, it resembles Erlang or Elixir code, demonstrating pattern matching on incoming messages. Carl Hewitt observed Smalltalk 72 and later developed the actor model, which shaped Erlang’s design.
00:29:14.430
Here's the colossal secret at the heart of object-oriented programming: it wasn't meant to be about objects in the current sense.
00:29:34.720
Alan Kay's vision went beyond objects; it was about processes.
00:29:51.200
In the past few years, I've shifted how I approach programming: I now seek processes.
00:30:05.060
I’ve started modeling systems as processes composed of more processes. It's not just about choosing the right language or framework; it's about perspective.
00:30:21.750
It's looking for workflows in the human systems we enable and modeling those workflows as processes instead of just individual steps.
00:30:35.290
In the end, everything is a process: web service calls, user accounts, and even our own lives.
00:30:52.040
Your project is a process. Your software team is a process. Your identity is a process, ever-changing but coherent.
00:31:08.450
Your life is not a transaction; it is a process. Life has taught me to look for processes and embrace them.
00:31:23.890
What has changed in these two decades of software development? I no longer seek objects; I’m learning how to build graceful processes.
00:31:48.170
I won’t pretend to have time to teach you process-oriented programming; I’m still figuring that out myself.
00:32:05.330
But remember, as above, so below: the way we live influences how we design software.
00:32:20.330
For the remainder of my time here, I want to talk about what it means to be a graceful process.
00:32:38.440
Then, hopefully, you’ll find some of these lessons inspire changes in how you write code.
00:32:55.690
However, we face a problem: I can’t simply teach you about being process-oriented because transferring static knowledge is itself a transactional act.
00:33:07.870
Fortunately, you have a teacher ready to help you; that teacher has always been waiting for you.
00:33:20.910
The best teacher for embracing life’s processes is your body. Your body is never static; it has no ideal end state.
00:33:35.600
Your body constantly regenerates, interrupting you during your attempts to reach return values, like feeling sleepy, hungry, or cold.
00:33:48.180
We programmers tend to act like brains in jars, trying to separate ideas from our physical selves.
00:34:02.750
Learning to be a graceful person means recognizing your embodiment. It could start with mindfulness practices, like meditation or yoga.
00:34:16.440
You might take up running, biking, weightlifting, or hiking.
00:34:27.630
However, watch out: hackers are so accustomed to detaching from their bodies that we often quantify instead of connecting.
00:34:39.800
So, throw away your Fitbit. Listen to your body. Feel when you need to move more. Understand when you’re dehydrated. Excuse me.
00:34:53.770
Believe it or not, for me, understanding embodiment has even enriched my appreciation for Instagram and selfie culture.
00:35:10.490
I don’t follow many programmers; I mostly follow poets. But I do follow Lydia Halle, known as the Avec Odor, and Alex, the Yogi Coder.
00:35:20.220
They both have huge followings. They post about their coding and what they’re learning, but surprisingly, they include pictures of themselves.
00:35:41.140
This may seem extraneous, but it stands against the common disembodiment among programmers, reminding us that we are people with bodies.
00:35:53.020
I challenge you to become comfortable portraying yourself and your body. You can start immediately by taking a selfie with me tonight.
00:36:05.750
Building graceful processes also entails starting from where you are and learning to appreciate state.
00:36:19.020
I realize that this is not a popular suggestion in some circles. However, state represents recognition of time.
00:36:40.070
Everything we aim to achieve, whether with computers or otherwise, involves time marching on.
00:36:56.100
State acknowledges that any process, whether a workflow or a human, is a collection of events and their effects.
00:37:04.020
Another perspective is that state embodies an understanding of entropy.
00:37:17.460
The world constantly throws chaos at us. I've seen it suggested that human beings serve as compression functions.
00:37:36.600
We accept an endless stream of incoming events and generate a smaller set of actions in response: the things we speak, write, and do.
00:37:53.680
This helps us create sense and meaning, opposing entropy in a chaotic world. Our software processes must do the same.
00:38:09.930
State signifies the requirement for history in our systems; stateless transactions simply aren't sufficient.
00:38:26.520
Alan Kay recently wrote a brilliant post on Quora addressing whether functional programming and object-oriented programming are incompatible.
00:38:43.660
He asserted that we need both progression over time and clear reasoning about how every detail has come to be.
00:39:00.130
Yet, we can avoid the problematic semantics of mutable state. Kay argued we could have real objects as stable world lines.
00:39:14.950
They could reach their next stable states in a functional manner without race conditions or bugs.
00:39:32.090
This compatibility reveals that using objects with state can compose functional calculations into discrete timelines.
00:39:53.470
I think for humans in general, and for programmers particularly, we cherish the idea of a clean reset.
00:40:05.740
One of the hardest realities for me to accept is that growing older involves continuously closing doors.
00:40:18.290
There are many experiences I will never have, people I will never meet.
00:40:30.700
Starting from where you are means recognizing entropy.
00:40:34.440
It means accepting that no clean slates exist; history is always present.
00:40:49.060
Starting where you are means engaging with legacy code when you’d rather rewrite it completely.
00:41:01.790
Building graceful processes also entails falling forward and failing forward.
00:41:22.850
I read Douglas Adams' Hitchhiker's Guide to the Galaxy series as a kid. Adams wrote about the art of flying: the knack lies in learning to throw yourself at the ground and miss.
00:41:35.600
I used to dismiss this as humor, but recently, I've come to realize the profound philosophy behind it.
00:41:48.700
Entropy is inevitable, and thus, failure is inevitable; surprises are unavoidable.
00:42:05.680
Sometimes, unexpected things happen, like a scorpion landing on your monitor. How do modern programming languages typically handle sneak attacks?
00:42:16.180
They raise exceptions, discarding the current stack and local variables, potentially shutting down database connections.
00:42:34.290
More often than not, the focus on preventing failure increases the potential impact of the failure when it finally occurs.
00:42:49.240
Failure, alas, always manages to occur. We should focus less on preventing failure and more on understanding how we arrived at that moment.
00:43:03.310
The trick is falling forward with style.
00:43:15.900
When my transactional life crashed, I discovered something shocking. While I had local friends and many online acquaintances, I had neglected to foster a local tribe.
00:43:33.330
This is a widespread issue among programmers. Being a brain in a jar leads us to settle for online friendships.
00:43:48.620
I conducted a Twitter poll recently with over a thousand responses. Most participants felt they lacked adequate local support.
00:43:59.410
If you're part of those 72%, I urge you to prioritize making local friendships. This is crucial and should be done before facing catastrophes.
00:44:13.450
If you’re unsure how to begin, please come talk to me afterward; I’m here to help.
00:44:25.660
Now that I’m no longer striving toward a fixed life point, I engage in reflective thinking about my life’s purpose.
00:44:48.130
This turns out to be a surprisingly difficult task because I’ll delve deeper and just end up with vague mission statements.
00:45:05.210
Phrases like 'everything to be the goodest for everyone, everywhere, always' are commendable but impractical.
00:45:21.230
Instead, I've found it helpful not to seek a mission, but to cultivate concrete, fanciful images or 'arrows' guiding my direction.
00:45:38.130
One arrow for me has been my beer list—prominent people I hope to share a beer with someday.
00:45:54.590
It probably won't shock you that Alan Kay is on that list. I also aspire to meet Adam Savage, the former host of MythBusters.
00:46:11.580
However, I don't just want to share a drink randomly or because of a backstage pass.
00:46:27.720
By referring to my beer list, I aim to become the kind of person they would invite to have a drink.
00:46:43.680
I want to find myself in a life situation where it’s natural for me to share a beer with them.
00:46:58.040
Most people on my list I likely won't meet, but this list serves as a criterion for decision-making.
00:47:11.680
It helps clarify which choices draw me closer to being someone they'd want to share a beer with.
00:47:27.720
So, find those arrows, those inspiring images to guide your choices when faced with crossroads.
00:47:43.800
These images will be different for everyone.
00:47:56.680
For some time now, I’ve discussed graceful processes, but you might be curious where grace comes into play.
00:48:09.690
I have few remaining hobbies, but I regularly take myself out dancing.
00:48:24.800
When I go to clubs for goth industrial or electronic dance music, they lack couples' dancing.
00:48:36.720
I've been dancing for years but never learned to dance with a partner.
00:48:49.260
Occasionally, someone tries to dance with me, and it feels awkward. One incident ended with someone asking if I was okay.
00:49:03.400
Recently, someone invited me to dance after we had just met. I warned them I wasn't trained in dancing, but they insisted.
00:49:16.330
It became a fiasco. I had no idea what I was doing; each time I failed at a move, they gracefully flowed into it.
00:49:31.950
Even as I botched the twirls, they smiled and kept dancing, eventually making us both look good.
00:49:42.770
This made me consider the meaning of grace—twofold. It signifies beauty in movement, but in many religious backgrounds, it also represents salvation.
00:49:56.220
In that dancing moment, I recognized that the two meanings converge—grace allows for error, transforming it into beauty.
00:50:11.370
Grace turns the chaos we encounter into meaning.
00:50:27.360
It involves being mindful, grounded, and aware of your place in space.
00:50:41.440
Grace requires beginning where you are, working with legacy, and embracing the journey.
00:51:05.170
It embodies the essence of falling forward and spontaneously responding when faced with last-minute decisions.
00:51:18.760
Grace leans toward the people surrounding you, trusting them to catch you or help you up.
00:51:34.570
Grace is present, not fixated on the future.
00:51:51.310
Grace means being able to laugh at oneself and letting go of what you're trying to solve in order to pursue the bigger picture.
00:52:05.620
Ultimately, grace is what saves us. So, live gracefully, build graceful processes, and don’t forget to dance.
00:52:12.790
Thank you very much.
Explore all talks recorded at Keep Ruby Weird 2018
