OO Design and the history of philosophy

Talks

Steve Klabnik

@steveklabnik

#object-oriented-programming-oop

OO Design and the history of philosophy

by Steve Klabnik

The video titled "OO Design and the history of philosophy," presented by Steve Klabnik at the wroc_love.rb 2013 event, explores the connection between Object-Oriented Programming (OOP) and philosophy, particularly focusing on ancient Greek thought. Klabnik emphasizes that understanding the philosophical foundations of our actions can enhance our programming mindset.

Key points discussed include:
- Philosophy and Programming: Klabnik introduces the idea that philosophy aids in analyzing questions and thinking through problems. He encourages programmers to apply philosophical tools to improve their coding practices.
- Personal Journey: He shares his journey into programming, expressing how early experiences inspired him to create games, linking his understanding of the world with software design.
- Metaphysics and Ontology: Klabnik discusses metaphysics, particularly ontology—the study of what exists—highlighting its relevance in programming, as it parallels the way we categorize and design objects in code.
- Plato's Theory of Forms: He explores how Plato’s concept of forms relates to OOP, using the example of a "circle" to explain that no physical representation can be perfect, just as no object in programming fully encapsulates its ideal form.
- Critique of OOP: While acknowledging the utility of OOP, he critiques its limitations, noting that it can complicate code structure, especially in complex cases like those often encountered in databases.
- Identity and Programming: The discussion shifts to the idea of identity within programming. He questions whether one can maintain their identity as a programmer while shifting between languages and styles.
- Philosophy of Technology: Klabnik touches on Fordyce’s approach toward technology, encouraging developers to embrace the evolving nature of software development and not to seek perfection but rather to continually iterate and improve.
- Conclusion: The talk concludes with an invitation for ongoing discourse in the intersection of philosophy and software, encouraging collaboration and creative contributions in the field.

00:00:18.480 Hi everybody, I'm Steve. If you don't know, I work on Rails, sometimes Ruby, Ruby gems, Draper, Actom model serializers, and a bunch of other stuff. I sometimes go to conferences and teach Ruby on Rails training classes with Jumpstart Lab, so if anybody wants to get more awesome at Ruby or Rails, that's what we do. I'm hoping this year will involve a lot of Ember for me, actually, so I might be slowly transitioning to doing more JavaScript work. This talk is one that I pitched about 'Object-Oriented Programming and Philosophy.' Since it's a semi-academic topic, I thought it would be fun to come up here in a suit and make slides with terrible handwriting, just like my professors used to have. I recently gave this talk at Heroku's Waza conference, and since it was a lot of effort to get everything together for the projector, I decided to take photographs of my slides to avoid the live drawing. While you don’t get the drawing, you do get my hand-drawn slides, which are likely unreadable since I type all the time and rarely handwrite things. So that's the background for this talk.

00:00:55.760 We'll have some good times. I don’t have notes on my slides, just handwritten notes in this Moleskine notebook. I was going for maximum performance for this talk, which is kind of funny.

00:01:09.640 Let's kick this off. One of the great things about philosophy is that it's a means of analyzing questions and thinking through problems. While I may offer some recommendations in this talk, I'm not trying to tell you what to do. Instead, I want to provide you with an example of how applying philosophical tools when programming can enhance your coding mindset. I’m going to critique object-oriented programming a little, but I don't actually think it's terrible; it's something I use all the time. However, some lessons from philosophy might suggest that object-oriented programming isn't always the best method for writing software, a conclusion for you to analyze on your own. The most important point to note is that I'm not trying to preach. Naturally, I might come off that way, and I apologize in advance. Feel free to disregard anything I say; you'll be awesome regardless.

00:01:57.920 I started programming when I was about seven years old. My uncle was a programmer who built computers and programmed the operating system by flipping physical switches and pressing a button to store bits into memory. It was pretty intense! He had to explain what he did to my grandparents, who already had a hard time understanding technology. My grandparents were particularly awesome since their son was a programmer, but explaining what computers were back in the late '80s was much tougher than it is now. So, he brought an Apple Mac Plus home to show them what he did all day, and I happened to be at my grandma's house the day he did this. When he opened the computer, I asked, 'What's this?' He replied, 'It's a computer; check this out! Here’s a little game.' He typed 'adventure' and hit enter. I don’t know if you’ve ever played Colossal Cave Adventure, but it’s a text-based game where you start in a cave with passages to the east and west, and you have to type commands like 'go west' and then face challenges, like fighting a pirate who could kill you. I was entranced the moment I started playing.

00:03:07.720 Because he was a programmer, he told me that I could create games like that too. Someone had to make it! It was the neatest thing I'd ever seen. My family chipped in and got me a computer that connected to the television. It didn’t even have a monitor! But it did have a BASIC interpreter, so I sat there with a BASIC manual, figuring things out on my own. My uncle didn’t mentor me as much as he handed me the manual and told me to read it. He didn’t literally say 'RTFM,' but that was basically the message. I was motivated to figure it out on my own. I wanted to make adventure games like I had experienced. I started designing the game I wanted to create by drawing little maps, outlining rooms connected by doorways. I decided to number those rooms for coding, where room one corresponded to lines 100 to 200 and room two to lines 200 to 300 and so forth. This structure connected my game design with the actual lines of code, and I realized my understanding of that world shaped how I coded it. Just like most early programming that relied on GOTO statements and numbered lines, it became complicated and hard to maintain. I learned about maintainability in a theoretical sense at a young age.

00:05:11.840 The key point I'd like to emphasize is that our understanding of the world shapes how we write code, which directly affects software design. Now, I want to discuss a specific branch of philosophy called metaphysics, which investigates what kinds of entities exist in the world and what their nature is. I think these questions are particularly relevant to programmers because they inform how we design our code. I became interested in this topic reflecting on the developments in a branch of metaphysics known as ontology. If you’ve ever dealt with semantic web or related linguistic topics, you might have encountered the term. Essentially, an ontology is a list of all entities—it's about cataloging what is in existence. This ties closely to how we create classes in our programming; it’s all about identifying 'here's an object, here's another object,' leading to constant discussions on the best design practices.

00:06:50.880 It struck me that philosophers have sought to answer these same questions across different domains for thousands of years. I felt somewhat foolish for ignoring philosophical developments when creating software ontologies, so I explored more about this and want to share a bit of my findings with you. More about metaphysics: traditionally, philosophy is referred to as the love of wisdom, which sounds nice but doesn’t really signify much on its own—who wouldn’t want wisdom? In contrast, two philosophers named Deleuze and Guattari offer an alternative perspective defining philosophy as the art of forming, inventing, and fabricating concepts. This resonates strongly with the programming field, as we are constantly inventing concepts we use in our code. Sometimes we’re successful, resulting in well-refined code; other times, we struggle to develop concepts, leading to poor programming practices.

00:07:46.640 This connection between what philosophers do and what programmers do is significant. Philosophers invent concepts as perspectives from which to view the world, while programmers create tools affecting and shaping that world. Philosophers deal in concepts that are primarily abstract, whereas what we deal with—bits running in a computer—while physical in nature aren’t often seen that way. The terminology 'virtual reality' or 'virtual world' reinforces this abstraction.

00:09:28.680 Next, I want to address Plato—everyone loves discussing ancient Greeks in philosophy. While I find some Greek philosophers to be overrated, we must acknowledge they laid the groundwork in the field. Plato lived around 350 BC, and philosopher Alfred North Whitehead once remarked that the biggest summary of European philosophical tradition consists of footnotes to Plato, emphasizing his influence.

00:09:43.520 However, focusing solely on one thinker may amplify their mistakes. Despite this, Plato's concepts are essential to understanding object-oriented programming. The first is what he termed 'forms.' Plato believed these forms symbolize abstract ideals that existed beyond our perception; they are the essence behind things. While I may have mixed up slides, I’ll use the example of a circle. No one has ever drawn a perfect circle, but we understand the idea of a circle is a form.

00:10:37.440 The circle represents a form, and any drawing of it can never be perfect. The real-world drawing—an object—might not be perfect, but it references that perfect concept as an attribute. This analogy applies to programming. When I create a class 'Chair' that inherits from Active Record Base, for instance, that class embodies the general concept of a chair, and we define its properties, like 'has a seat.' Thus, every object in our ontology adheres to the ideal form of a chair, mirroring Plato’s theory closely with how object-oriented programming operates.

00:11:34.720 This model allows us to mimic the real world in programming. Often, we see that a car has parts like an engine, which could be represented as a class called 'Engine.' However, it can be challenging to write Active Record classes reflecting the complexities of real-world entities. We’ve heard discussions earlier today about design patterns and challenges in writing clean, maintainable software. In the Ruby community, there's experienced pushback against Active Record because it tends to complicate code.

00:12:45.480 Despite this, I want to point out that the notion of forms, while applicable in some scenarios, doesn’t always hold up in more complex cases. The circle example is delightful, yet applying it broadly, particularly outside of geometry, quickly becomes problematic. I’m going to present an alternative model for how we think about objects and their identities in software development.

00:13:31.280 A question that may arise is: what are we missing in object-oriented programming—or specifically in Active Record? Notably, if we examine a class, we might find methods aren’t represented in a basic diagram, and Active Record gives us a plethora of methods. These methods function as forces acting on different objects. It's interesting to note the connection between object-oriented programming and functional programming, particularly through the lens of currying.

00:14:12.239 Imagine a function f(x, y) that represents x + y. If we partially apply it, say with y = 3, we derive a new function f(3) that processes one argument equating to 3 + y. Likewise, object-oriented programming can resemble partial application. For example, suppose we have 'C.do_it(steve)'—this structure may seem odd because the chair is an object, yet the interaction structure raises questions on identity within the context of programming languages.

00:15:05.080 Different programming styles—functional, object-oriented, and structured—give us varied perspectives for solving problems. I prefer to code with objects because they align well with my outlook on the world. Different models cater to different challenges, leading me to avoid structured programming, even if in mathematical terms they might be equivalent. Understanding these distinctions effectively helps us approach programming more holistically. Thinking about how we structure programming led me to consider identity under object-oriented programming. When I give this presentation, I’m delving primarily into philosophical perspectives relating to our identity as programmers. Are we only deemed programmers if we strictly adhere to certain languages within certain timeframes? This nuanced conversation inches toward broader discussions within philosophy.

00:16:50.960 For instance, if one calls themselves a Rubyist but then develops projects in JavaScript, are they still a Rubyist? What if they haven’t programmed in Ruby for a year—do they lose that identity? Similar inquiries arise in areas like gender identity; definitions based solely on attributes can prove problematic. This highlights how messy the real world is, in which we attempt to force-fit definitions into rigid categories, causing complexities to arise. Thus, I implore you to imagine a more compelling model for identity; one that accounts for the fluidity of existence rather than rigid classifications.

00:18:51.480 Philosophically speaking, the concepts of 'repeated difference' emerge as particularly valuable. This perspective stems from a realization that history often repeats its mistakes—both in coding and in broader societal patterns. Why does history seem to doom us to repeat errors? This notion of 'repetition' underpins the idea that we can evolve our understanding and enhance coding practices without merely reproducing past mistakes. There exists a distinction between mere copying (or mimicking) and genuine repetition, which involves embodying prior concepts while also shifting them.

00:20:10.840 So, when I discuss identity within programming, I emphasize a process-based ontology—this means we should account for temporal changes rather than viewing identity as fixed. If I’m constructing a blog, for example, it’s not solely because it fits a definitive mold; it's about how it embodies traits that connote 'blog.' This conceptualization leads to more meaningful frameworks for understanding what it means to develop software.

00:21:20.800 In this context, I’ve been intrigued by databases constructed around temporal data, like Datomic, which takes a unique approach to data management. Instead of standard tables and rows, it focuses on storing facts with timestamps. As a result, rather than destroying data upon updates, it appends new information, allowing historical data to remain accessible. This reveals insights into the construction of queries and how we reference data, reinforcing the importance of retaining history in software construction.

00:23:25.520 Remembering that every design process is a continuous journey is crucial in programming. I often see individuals aim for perfect code, which stymies the creative process. As programmers, rarely do we reach a point of complete satisfaction, resulting instead in a cycle of adjustments and compromises. Design is an evolving process—technology is not static, and our approaches must adapt too. Consider Agile methodologies as well, which promoted adaptive responses over strict, linear planning.

00:24:53.560 Any significant design shifts necessitate context; each progress point leads to greater clarity. Change is often slow and may lead to discomfort. Much of our programming exists in a 'perpetual beta,' where we continuously work toward refinement. While this might breed frustration, the struggles and triumphs ultimately grant a greater sense of accomplishment.

00:25:56.800 Before concluding, I propose starting a mailing list dedicated to the intersection of philosophy and software, where individuals can engage with this interplay. My friend Greg and I have initiated a Google group for anyone interested, regardless of prior exposure. Many seek avenues to explore philosophy further without a clearly defined path, and this provides an inviting space to inquire and share resources. This originated from discussions around the sociological perspective of abstraction—the challenges faced when discussing broad concepts divorced from the minutiae affecting real-life experiences.

00:28:23.960 Finally, I wanted to mention Friedrich Nietzsche's ideas as they relate to our discourse. He introduced constructs such as 'master' and 'slave' morality, suggesting we shouldn’t legislate our worth through comparisons with others. Rather, we should pursue our own creative paths, reinforcing self-improvement over dwelling on juxtapositions based on comparative failures. This notion embodies his 'will to power,' urging us to create and affirm life rather than labeling others. This spirit leads to our discussions surrounding software development as well—when addressing competing technologies like the discourse between Hpricot and NokoGiri. The context of friendly rivalry is essential. Both projects drove each other to enhance performance. Aaron Patterson’s work on NokoGiri exemplified striving for better; instead of criticizing Hpricot outright, he innovated to exemplify improvements through alternative means, emphasizing forward thinking. This mentality captures the essence of what we should embody as developers.

00:30:36.239 I believe we owe a great deal of acknowledgement to both prior playwrights and current innovators. As we continue to build upon earlier works, we reshape our software, maintaining the lifeblood of innovation. While the past remains a reference point, our vision should focus on personalized development paths, outlining our own objectives. Thus, I urge everyone to embrace this perspective and strive to create unique contributions without merely mirroring those who came before. Let's continue building rather than comparing.

00:32:04.440 I conclude this talk by encouraging you to express ideas, debate, and inquire about these themes and trends. You can reach out to me on Twitter for discourse—feel free to engage in conversation about differing viewpoints. I invite all to build alternatives, be creatives, and forge your paths in this evolving landscape of technology. Let’s collectively contribute to the unfolding narrative of software development!

00:34:05.680 Any questions? It seems like everyone is quiet, but I’m available for further discussion or inquiries via email afterward. Feel free to ask about the correspondence between object-oriented programming, mathematics, and philosophy—we can explore how to bridge these ideas. Philosophical discourse continuously evolves; I believe there's something significant missing in the overlap between these concepts that can enrich our understanding. Thank you all for your engagement; I appreciate it.

wroc_love.rb 2013