What's Wrong With Ruby's Object Model (And Why That's a Good Thing)

MountainWest RubyConf 2012

David Brady

@dbrady

#ruby

#object-oriented-programming-oop

#monkey-patching

#refactoring

#developer-experience-dx

#behavior-driven-development-bdd

#programming-techniques

What's Wrong With Ruby's Object Model (And Why That's a Good Thing)

by David Brady

The video presentation titled "What's Wrong With Ruby's Object Model (And Why That's a Good Thing)" by David Brady, delivered at the MountainWest RubyConf 2012, explores the shortcomings of Ruby's object model while also highlighting its advantages. Brady begins by addressing the audience's perception of the brain's asymmetry, discussing the evolution of scientific understanding regarding left and right brain functions, before relating this to programming principles that govern Ruby's object model. He emphasizes that many programmers mistakenly interpret object-oriented programming as merely combining functions and data, rather than focusing on behavior.

Key points discussed in the video include:
- Neuroscience Background: The initial explanation on the left-brain and right-brain theories showcases how misconceptions in understanding can analogy in programming contexts.

- Formalism vs. Hermeneutics: Brady contrasts traditional formalism in programming, which emphasizes mathematical principles and bottom-up design, with Alan Kay's hermeneutics, which fosters a comprehensive understanding of programming as a living, behavioral entity.

- Refactoring Code: Through a personal coding example, Brady illustrates the potential pitfalls of Ruby's object model that permits poor coding practices such as excessive procedural coding. He emphasizes the need for refactoring to ensure clarity and maintainability, depicting a step-by-step journey of improving written code through structured organization, testing, and enhancing readability.

- Monkey Patching: The concept is explored as a double-edged sword that offers flexibility but can contribute to chaos and unintentional complications within the codebase.

- Community and Collaboration: Concluding, Brady emphasizes the importance of community input, emotional intelligence in code development, and a holistic view of programming that promotes shared creativity.

The key takeaway from the presentation is that the limitations within Ruby's object model can also serve as opportunities for improvement, urging the audience to adopt a more behavioral mindset towards programming. By understanding the symbiotic relationship between code structure and community engagement, programmers can foster a collaborative and empathic atmosphere in their development practices.

00:00:15.040 Guys, I have a problem. I really need your help. I want to give a talk on what's wrong with Ruby's object model.

00:00:21.240 It actually turns out that there's something wrong with Ruby as a language, and there's also something wrong with Ruby as a culture, which means it's a problem with all of you.

00:00:27.400 In order to get this through to you, I have to bring you up to speed on the current state of the art in neuroscience.

00:00:33.559 So, by a quick show of hands, how many of you understand that the concept of left brain versus right brain is just bunk? Okay, you guys are the problem.

00:00:40.079 I need to bring you up to speed. Here's the deal: for the past several hundred years, we've known that if you get kicked in the left side of your head, you lose your language skills.

00:00:46.760 In the 1950s, scientists started doing experiments where they cut people's brains in half to create split-brain patients. This was a humane cure for epilepsy, relatively speaking. They came up with these theories that the left brain stores logic and language, while the right brain stores emotion and intuition.

00:01:06.080 It turns out that about 10% of people actually have this flipped due to genetics. This became a popular theory, and it got into pop culture, where people would say, 'I'm artsy-fartsy; I'm right-brained' or 'I'm an engineer; I'm left-brained.' Science basically confirmed that yes, the brain is pretty static and asymmetric. This led scientists to investigate what the different halves of the brain actually do.

00:01:35.840 However, throughout the 1980s, we started debunking these ideas. We found that if you have brain cancer and lose a part of the brain, you can regrow language skills by retraining other parts of the neural network. It turns out the brain is more plastic than we think. In 1980, the invention of the functional MRI allowed scientists to observe which parts of the brain activate during various human activities.

00:02:01.840 We discovered that activities like solving calculus problems, working on logic puzzles, or painting a portrait actually light up both halves of the brain. The notion that the brain is completely asymmetric is simply incorrect. However, in this room of about 200 people, there are about 10 of you who are reversed, but for 190 of you, your language processing is in the left front of your brain. So, I'm not really sure this theory of asymmetry holds water.

00:02:45.879 Now, the real problem began around the 1980s to the 1990s, when there was a political shift in the scientific community. Researchers decided to stop studying asymmetry in the brain, categorizing it as a study that was under the umbrella of 'beaches with medicine.' Anyone wanting to research brain asymmetry faced funding challenges.

00:03:15.799 This marked a shift towards what we now call very bad science. Then along comes Ian McGilchrist, a Scottish researcher, who declared, 'Screw it! I'm going to study it anyway.' What he discovered was that the brain is not symmetric at all.

00:03:42.920 The auditory processor on the left side of the brain is 35% larger than on the right, and the visual cortex is 30% larger as well. The Broca's area—responsible for executive function—also measures 5% larger on the left. In fact, every sub-cortex on the left side is larger than the corresponding sub-cortex on the right. One hemisphere of your brain is larger than the other, and that stands to reason: the right side is denser and heavier, full of proteins called myelin that allow nerve impulses to travel farther and faster.

00:04:23.040 The right side of the brain is vastly interconnected, with the prefrontal cortex connected to the visual cortex. Everything is wired together, whereas the left side has more specialized functions, which are relatively isolated from each other. If you think about it, for neural networks to specialize, they need to be isolated; if they're not, they lose their specific functions. Ian's great revelation was that instead of asking what the two halves of the brain do, we should be asking how they accomplish their tasks.

00:05:09.560 He found a fascinating procedure: inject sodium amytal into one side of the carotid artery to effectively 'put to sleep' one half of the brain, then interview the patient to discover what they felt, understood, or could remember. I have to refer you to a great YouTube video about this at the end of this talk. He discovered that the left brain is responsible for narrowing focus—zeroing in on attention—while the right brain is responsible for broadening focus, aware of everything happening around it.

00:06:05.880 For instance, if a bird is trying to peck at a pebble among some grains, the left brain is focused solely on that pebble, while the right brain notices everything around it—the lovely day, the rippling grass, potential predators, and other birds. This interconnectedness in the right brain enables it to read emotions in human faces and gives us empathy.

00:07:17.080 The notion that the right brain is emotional and the left brain is logical isn't entirely incorrect. The left side of the brain isolates context, preferring to analyze facts in isolation. It seeks to prove a statement true or false without incorporating any context. The right brain’s job is to integrate these facts. Ian found that if you have someone who is left-brain dominant and you lose their left brain, they lose their language skills. However, if you lose their right brain, they may lose half their bodily awareness.

00:08:12.519 For example, soldiers returning home from war with injuries to the right side of their brain may neglect grooming the left side of their face—not due to absent-mindedness, but because they don't perceive that side of their body as 'theirs.' This should terrify you. Individuals with completely diminished right brain function can exist in a state where they fail to recognize their own limbs. Left brain thinking is confident; it knows what it knows, and thinks it knows it hard.

00:09:05.480 Einstein noted that over 75 years ago, left-brained thinking was taking over Western thought. He stated, 'The intuitive mind is a sacred gift, and the rational mind is a faithful servant. We have created a society that honors the servant but has forgotten the gift.'

00:09:59.680 Now, how does this affect computer science? We have the concept of formalism versus hermeneutics. Formalism is rooted in mathematics and involves taking a basic principle, solving it, and building upon it, establishing a bottom-up programming approach. This often leads to programs that seem to work, yet can be inherently flawed. Alan Kay introduced hermeneutics, which treats programs as complete objects or biological entities, pushing developers to think about behavior rather than just functions.

00:11:54.399 If you think of object-oriented programming as merely functions and data—a class defined by functions and data—you are part of the problem. True object-oriented programming is about behavior. I am well behind in my talk, but let's talk about some code.

00:12:28.480 I want you to understand three things about this code. First, I wrote this code. Second, it represents my best effort at that time, and there isn't a single class or method in it. Finally, this code was my best effort two months ago. I promised to bring in some 'nasty' code that we could refactor.

00:13:40.360 So, let's refactor. This code draws a planner sheet for time management. I initially wrote the first version in 1996 in QuickBasic, then ported it to C, Perl, and Python. By the time I got to Ruby, however, I was still solving it procedurally. I couldn’t figure it out in an object-oriented way, so this is the result. It's a steaming pile of code, but let's refactor it!

00:14:36.080 We first need to turn this into an application. By dividing it into recognizable components—like a bin and a lib directory—we can bring some structure to this mess. The real issue with Ruby's object model is that it allows me to write code like this, which is a problematic feature. What's great, however, is that this code worked perfectly for two months before I returned to it and could refine it.

00:15:39.560 Let's make it right. We can add a bit of ceremony, even though Ruby doesn’t require it as other languages may. We can create a bin folder to hold our driver file, designate a lib directory for other components, and include necessary libraries. Now let’s address monkey patching, one of the things that can be both good and bad about Ruby.

00:16:15.000 Monkey patching allows developers to extend or alter libraries at runtime, which can yield flexibility but can also lead to chaos. I thought Python couldn’t do this as seamlessly as Ruby, but it turns out that Python can monkey patch too. However, the Python community is generally against such practices, which tends to stifle innovation.

00:16:37.679 For example, while Python's creator Guido suggested freezing libraries for extended periods, in Ruby, if someone proposes a helpful modification—like a new monkey patch—it's often readily accepted and integrated quickly into frameworks like Rails. This is an issue because it allows people like me to write suboptimal code, which can then become established features of the language.

00:17:23.279 I want to refactor this code, but first, we need to establish tests. This script is completely untestable. The test I had was inadequate and relied on an external assumption, showing how easy it is to fall into the trap of writing poor tests.

00:17:58.320 While working with this refactored test, it failed for various reasons during the process, yet it highlighted that the yucky test was still able to reveal meaningful issues and validate our changes. Eventually, we found the test earned its place in the suite, proving valuable despite its initial appearance.

00:19:09.600 If I pull out all that script code into a planner class, the resulting driver file actually makes sense. We're starting to see improvement because Ruby allows us the flexibility to refactor incrementally, which is a significant strength of the language. We’re able to use the Ruby language's properties to progressively refine the code instead of rewriting it entirely.

00:20:20.280 Reflecting on the code, we've found that magic numbers were rampant, and we started to extract constants to clarify our intentions. Even though getting there involves rewriting parts of the code, what's crucial is that this change promotes readability. We continue refining pieces of code and eliminating complexity, ensuring each line serves a clear purpose.

00:21:46.600 When looking deeper into the structure, we encounter basic programming constructs—the essence of a basic routine that might result in unnecessary complexity due to lacking iterators and more modern approaches. We review what worked long ago but realize Ruby has advanced techniques that allow for simplification and abstraction.

00:23:18.600 One revised aspect we worked through involved replacing complicated lines of code with cleaner abstractions. While the earlier code might have worked, we've shown how it can be reshaped and rethought for increased clarity and maintainability. Knowing where to check these practices becomes vital. For instance, incorporating descriptive comments leads to clearer code comprehension.

00:24:52.480 We'll also embrace supporting techniques to isolate behaviors, attain testing advancements, and enable enhancements necessary for an evolving codebase. While some techniques might seem dubious, they're a part of our development journey and can equip us in tough situations.

00:26:14.640 Let’s jump back into where we began refactoring to see positivity emerge from this process, always remaining open to growth as the code evolves. With continuous refactoring will allow us to create contexts where tests can run smoothly, providing a necessary base for future disciplines. Yet, with better code, we can flow through iterative transformations and correctly avoid trivial errors that compromise our work.

00:27:37.760 As we develop toward the next layer, we don’t need to hack all existing functionality away if it does not face demand. A programmed level can persist as a useful feature without the pressure to continuously evolve. The Iterative process ultimately leads us to understand how to shape future iterations steadily—considering how to enrich programming paradigms for better understanding the Ruby dynamic.

00:29:32.720 To preview what's ahead, we need versatility and courage, leveraging experiences we’ve accumulated to push boundaries. From fluidity to the echo of synthesized values in programming, we can step toward new implementations, embracing emotional intelligence for growth and clearer collaboration. This journey stands in stark contrast to left-brained isolation which often leads to siloed thinking.

00:31:30.960 Ultimately, the conversation of right-brain integration transcends programming: Good programming encourages community participation and values perspectives. This push for shared creativity becomes crucial in an era of stark divisions by design. We find empathy through synthesis rather than isolation, building a sense of belonging, an integral part of the Ruby community. This is why the holistic view matters; it captures our journey as programmers and friends.

00:33:02.000 Thank you!

MountainWest RubyConf 2012