1:39 - Groupon
5:12 - Synchronous vs. Asynchronous
6:55 - Actor model
14:29 - Establishing a Bounded Context
16:35 - Information Hiding and Effect Hiding
24:47 - "A car with four-wheel independent steering isn't more effective in any way."
28:44 - Accidental Complexity
34:26 - Protocols to Patterns
37:03 - Adaptor Pattern
38:48 - Bit Blit
41:33 - Where does OO and FP intersect at a functional level?
We are reading Growing Object Oriented Software Guided by Tests and we will review with the author on August 22nd!
JAMES: But, if she should go into labor and we could---
AVDI: I will totally unmute them.
JAMES: Right. It could be our first on air delivery.
JOSH: Yeah. Watch. Watch.
DAVID: You know what the little sound bite at the beginning of the episodes?
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to rubyrogues.com/newrelic.]
[Hosting is provided by the Blue Box Group. Check them out at bluebox.net]
[This episode is sponsored by JetBrains, makers of RubyMine. If you like having an IDE that provides great inline debugging tools, built in version control and intelligent coding and refactoring, check out RubyMine by going to JetBrains.com/ruby]
Hey everybody and welcome to episode 65 of the Ruby Rogues podcast. This week on our podcast, we have David Brady.
DAVID: Good morning. I’m Homeopathic David Brady. I’m a one part in 10 billion.
CHUCK: Awesome. We also have Josh Susser.
JOSH: Good morning. I’m Allopathic Josh.
CHUCK: We also have James Edward Gray II.
JAMES: You know, I listened to that “Hiring Programmers” episode and not one thing I said ended up in there.
CHUCK: I’m sorry. I’m Charles Max Wood from DevChat.TV, and we also have a special guest and that is Michael Feathers.
MICHAEL: Hello there. I’m down here in Miami saying hello and being with you guys.
CHUCK: For the two people that haven’t heard of you, do you want to tell us a little bit about yourself?
MICHAEL: Yeah sure. Been in software development for about 25 years, spent a lot of time consulting, work for Groupon now, wrote a book in 2005 called “Working Effectively with Legacy Code,” and spent a lot of time thinking about software problems and helping people solve them. That’s me.
JAMES: Woo hoo!
CHUCK: This week, we’re going to be talking about “Functional versus Object-Oriented Programming”. This was a topic that Josh suggested a while ago and then Michael also wrote a blog post about it and so we decided to pull the two ideas together and chat about it.
JOSH: To be fair, I don’t think I so much suggested the topic as ranted about it enough that you guys just figured we should do a topic or do an episode.
JAMES: Yeah. How can we make Josh shut up, I mean, you know?
DAVID: I want to be on record here. I’ve told you guys that appeasement never works but okay.
CHUCK: Alright. I’m not 100% sure where to start. Do we want to start with the blog post or is there a better place to start at?
JAMES: Sure, I just re-read that post this morning. Michael, can you give us 10,000 view of what you said there?
MICHAEL: Yeah, sure. It’s funny because a lot of people might be getting into a functional programming over the past five or six years I guess. This profile has become raised quite a bit and the thing is we know it’s all old stuff. Functional has been around for ages but we’ve been through this period in the industry where we’ve been using objective orientation for just about everything. And a question I’ve had for a while is really what’s the relationship between those two things and how do we actually decide when to use objects and when to use functions.
In that blog post, I made a bit of an argument that, essentially when you look at the qualities that you try to get when you’re working in an object-oriented way and in a functional way, it seems like the natural ordering for them is to basically have functional stuff kind of at the bottom of your architecture and then object-oriented stuff more at the top. And I got through a bit of an argument about that. In the post, I basically said I don’t really feel that this argument is completely right but is like a starting point in essence.
The core of it really is that with functional program, you have referential transparency and immutability that enables referential transparency and lazy evaluation, and with object orientation in the message passing style, it enables asynchrony. And so it makes a lot of sense when --- objects they can send messages among each other and then have their core computational bits be referentially transparent of functional things. That’s pretty much the core of it. So I know quite where you go from there.
CHUCK: What would that look like or how would that be different from what we typically use? Because I guess at the lower levels of our objects, we have some kind of procedural code, but I guess it’s not immutable. Is that the main difference?
MICHAEL: Yeah it seems to be. I didn’t really like outlining this like a prescription saying this is the way things should be, but it does feel in the way like this is the way things kind of are in a sense. I guess I can backtrack for a second.
In the blog post, I kind of used Alan Kay’s definition of object orientation, which is that object orientation, is essentially something like a metaphor for Biology in essence. You can imagine that in any biological system you have cells for instance, and they’re able to go and communicate by sending messages back and forth to each other. That’s the core idea that Alan Kay tried to get across when he was describing object orientation early on. What he’s kind of saying is that essentially we used that same message passing style in object orientation but the thing that’s really key and different is that, when we may use objects in C++ or Smalltalk or Ruby, they tend to be synchronous. Synchronous calls, right?
In a biological system, when you send messages, it’s asynchronous. You send a chemical expression to another cell and you’re not blocked. You can just go ahead and do whatever you want to do, right? The cell can basically continue its own processing and stuff along those lines. That’s like the ultimate decoupling and that’s really what to me object orientation is about. It’s just totally decoupling separate things.
The thing I’m kind of noticing is that in our industry now essentially, we tend to have that sort of thing already but we don’t really call those bigger things objects. Quite often, you see message buses and all sorts of things like that in the main workflows of businesses. And to me, that’s the object stuff in a way. It’s kind of like we send messages and that’s the way of decoupling things among different architectural components, and its like, “Yeah the lower level stuff, why not make it functional.” It tends to be a nice paradigm for doing heavy computational lifting. I know I really rambled a little bit but it feels to me more like this is an observation more than prescription in a way.
JAMES: It’s interesting to me that you chose to call the objects by their asynchronous nature because it’s kind of like you said that I don’t think we tend to use on that way as much. And I agree with you that you’re right that it’s totally about… I mean, if you’re going to do tell, don’t ask especially for something like a parser then ideally, you need to pass it in chunks of data and it needs to call you back whenever it’s parsed the significant amount that it knows where to pass, right?
MICHAEL: Yeah, we’ll call you back or tell somebody else about it
JAMES: Right. Right. Yeah and pass the message along. Right. But it seems to me that what’s kind of hot in functional programming in recent years is like actors and stuff which seems to be how they get their asynchronicity.
JOSH: Which is amusing because actors are really an object-oriented technology.
DAVID: Yeah. I was about to point out the Actor pattern is an OO thing.
MICHAEL: It’s funny because a number of people who read the blog basically said to me, “Well, hey Mike, you’re really talking about actors.” I’m kind of like, “Yeah, you know you’re right.” But I guess what it’s trying to do is make an argument from what’s the core thing of each of these technologies is supposed to get us, right? With object orientation, the notion has been kind of decoupling and encapsulation. And when you carry that thought as far forward as you can go, you end up with something which is kind of cell like in Biology and that’s very much akin to the Actor style of programming.
JOSH: Well actor came from the very early days of Smalltalk where Alan Kay went to MIT and showed it off. Who was it?
MICHAEL: I forgot the guy’s name.
JOSH: C. A. Hoare who saw the Smalltalk-72 and said, “Hey this is cool,” and went off and did actor based on that.
CHUCK: Can you guys clarify really quickly. I know it’s a rather simple concept but, clarify what an “actor” is because when I think of actor on programming, I’m thinking of some guy getting drunk and wrapping his programmer at a telephone pole.
JOSH: Okay. An “actor” is basically an object with its own thread of execution and you communicate with it using asynchronous messages primarily.
DAVID: Or its own process or its own machine, yeah.
JOSH: Sure. Yeah it’s an independent thread of execution and you send it messages and it has something like an inbox or mailbox that accumulates those messages and then it just processes them. It’s very much like a web server but at a different level of scale.
CHUCK: It’s like having a team in India for your programming.
JOSH: [laughs] I don’t think so.
DAVID: Yeah. Those actors make Bollywood movies.
CHUCK: Oh right.
JAMES: Right and there’s a lot more dancing.
DAVID: And singing, yeah.
JOSH: The Actor model as it’s evolved into, is actually probably more like the original concept of objects that modern object-oriented languages.
MICHAEL: I can look at it as basically why the synchronous stuff that we do in programming is an artifact of our computational environment that typically we were working on single processors and that was just the easy default.
JOSH: When you’re building your languages of virtual machine, you can emulate anything you want. And the Smalltalk virtual machine, it’s multi-threaded. You can build something like actors in it fairly easily but the 99% of what you’re doing there is synchronous calls so it’s optimized to support that really well.
MICHAEL: Yeah. It’s the path of least resistance really.
JAMES: Plus there is…I mean…
JOSH: Let’s stop dancing around and let’s talk about functional versus object. I think the Actor model is interesting. Michael, your blog post about “Tell Above, and Ask Below,” that I think, I’ve said this and Avdi said that seems to be a very comfortable way to address programming systems at the scale that a lot of us operate.
MICHAEL: Yeah. I pretty much design that way also.
JOSH: My sort of snarky spin on that is that that’s a great way to make effective use of the functional paradigm because any time you get bigger than a method of an object, it becomes a little too crazy to use.
MICHAEL: Can you explain more about it?
JOSH: I think that one of the things that object-oriented programming is great is model in large systems. It’s great at putting boundaries around pieces of code and then you can define what that looks like from the outside. You can do that recursively at any level of the system but the uniformity that you get by making everything objects and by having each object has its own API to talk to it and patterns for structuring it. We’ve seen big systems built in an object-oriented fashion that worked really well and certainly, most programmers can reason about systems like that much better than they can reason about very large functional systems.
MICHAEL: It’s really different because I haven’t seen very large functional systems and I keep wondering what they look like and it’s a very funny thing about them because I tend to have the same feeling but I can’t really pull back and say, “Well, that’s based on something I’ve seen.”
JAMES: I can tell you what a large functional system looks like.
MICHAEL: Oh please.
MICHAEL: Oh okay. Yeah.
JAMES: I’m kind of kidding though but it’s still and even kind of interesting at Emacs because they almost go with their modules and stuff like that; they almost kind of get toward object-oriented kind of segregation. It’s not but…
MICHAEL: From a very big C-systems I’ve seen, there is kind of a Quasi object orientation and kind of embeds itself in large C-systems too, just the basics of modularity and stuff along those lines on state management.
JOSH: Right but functional stuff is really lovely for dealing with algorithmic things and the mathematical foundation. It has a lot of strengths there. I think that the division of using functional style within methods to structure your algorithms, I think that works really well in a lot of cases but once you get outside of an object, the ability to handle complexity I think breaks down, which is sort of funny given that’s exactly the opposite of what Rich Hickey was talking about at his RailsConf Keynote.
DAVID: Why is that? I mean if I can break an object down into smaller objects and smaller objects and I can do that ad infinitum, how come I can’t compose functions up into functions up into functions and have a very high level function that really only does, it’s a very small expression because it’s shelling out. It’s prowling down into some other functions. Why do we not see this scaling up very high?
JOSH: Well, if you build your software like that, it would probably be fine, but the problem is the data. And even in Rich’s talk, he kept talking about, “Oh yeah, we just built these large data structures.” It’s their --- god object pattern where you say, “Okay great. We want to have all these functions that we can reason about using the techniques of functional programming and we want them to be composable and lazy evaluation. You take all of the data complexity and you put it in some big Hash in the sky and that’s your shared state and it’s mutable and you’ve sort of drawn a box around that and said, “Okay, this is where all of the complexity of the system lives and then all of the functions can be pure and mathematical and lazy, and asynchronous.”
DAVID: So if that’s the logical conclusion of everything is a Hash and doesn’t that sort of violate Rich’s original intent of complexing things? I mean, doesn’t complex everything?
JAMES: It definitely complexes the data, right? I mean, you always have these structures that you have to keep track of and like Josh says, that is mutable.
DAVID: I am going somewhere with this line of questioning which is to call back to Michael’s blog post. Talking about actors, the hybridity, it sounds like what we’re really after in both of these is trying to establish a bounded context, basically like referential transparency gives you a boundary to your context. There are no side effects down below this level and so you’re safe. You can talk to that safely and you can distribute yourself and do that. Having a god object seems like it’s basically expanding your context boundary to the whole system and that seems like a bad idea.
JOSH: The problem with god object isn’t necessarily that they have a lot of data in them, but they have a lot of behavior in them.
DAVID: It’s in their whole system, right? They are synchronous representations of the entire system.
JOSH: Okay. Yeah.
JAMES: Go ahead.
MICHAEL: It’s very funny because in object orientation, there is this sense of like, “I don’t need to know what’s happening beyond this boundary in order to go and do the things I need to do”. The same thing can be emulated in functional systems also, but it seems like people don’t seem mind having data which is more public in functional systems as long as it’s immutable. So there are two aspects, that one is going and saying, “Look, I understand the boundary of side effects within this particular area versus I understand the boundary of what I need to know in this certain area.” It feels like there are two separate things that object orientation and functional handle them in two different ways.
JOSH: Can you talk more about that?
MICHAEL: Yeah. Okay. Imagine you have some big immutable data structure that you’re using and you work in a language like Clojure. We can go ahead and say, “Look, this is immutable where I’m basically making my variants off of it and stuff like that through construction”. It’s like that structure may be globally known, but the thing is you also know that locally, you’re not going to be doing anything which is going to alter the larger data structure outside of you. You do need to be aware of the complexity of that data structure in order to go and sort of work with it. It seems like it’s just very separate in object orientation. You have the thing works like, “Okay, here’s an API and beyond that API, I don’t need to know what’s going on inside of it. I don’t need to know the internal data structures that have been used or anything on those lines.”
That’s the style they can use in functional programming naturally but it’s a bit different. I guess the difference is between the information hiding and I guess can we call it for functional programming. I guess we could call it effect hiding.
DAVID: Wow. So one context boundary is on your inputs and one is on the outputs and it’s like functional programming protects you against the outputs and object oriented protects you against the inputs.
MICHAEL: I guess yeah.
DAVID: And they both have their pants down on the other end.
MICHAEL: This is a thing that really gets me about all this. I think some people will go and basically say, “Ah, the day of object orientation is over and functional is the way things are.” I think that’s really just a pipe dream or just people hyping things up. My feeling is that both of them are going to find their place but we don’t know where the places are going to be yet. We don’t really know when we’re going to be, what the best effect when we use object orientation and design, or functional design. And we don’t really know how to go and give a good advice about that.
I’ve been kind of hoping that the Scala community might be able to go and sort of give us something more in that direction. Or F# when you have a hybrid language like that and people are just trying out various different things. There ought to be some patterns emerging from that about how to use these different paradigms together.
JOSH: That’s interesting. That perspective is I think counter to my own in many ways. I look at hybrid languages and I usually cringe.
MICHAEL: [laughs] I do too so just in fairness.
JOSH: Well good. Good to know you’re sane. I look at languages like Scala through the, I don’t know what the other color of rose is for glasses.
DAVID: The pink-colored glasses?
JOSH: Basically, my experience with the Common Lisp Object System way back when, which is a very rich and flexible object-oriented system built on top of a functional system. And the nature of software that was built without was, I don’t want to get hyperbolic and say that it was unparalleled in its complexity, but it was pretty bad. It wasn’t just like this is a mess; it was that if you try to call a function, you literally had no idea what it would do. Yeah, there were so many weird things actually.
MICHAEL: The multiple dispatch thing?
JOSH: Yeah, multi-methods and multiple inheritance and generic functions getting in there. You just don’t really know what’s going to happen. I looked at that and I got pretty flustered trying to sort my way around systems there and really develop an aversion to mixing that kind of complexity and with object orientation.
Object orientation at its foundation is incredibly simple. You send a message to an object, and the object does something in response. What we call object-oriented programming has some very standard ways of reducing complexity by eliminating duplication and it has classes and inheritance, they do the things that you do all the time very quickly and efficiently. And that’s great but when you try and add more flexibility to the system, you just make it worse most of the time.
MICHAEL: That sounds like that’s less an indictment of mixing OO and functional as much as just going meta with an object orientation.
JAMES: Yeah I think so because you can make similarly evil system in Ruby with a co-application of mix-ins and method based things and stuff like that, right?
MICHAEL: Yeah. I think that thing that’s funny about this is also you can do all those things and it’s like we have the power to do those things in these very rich environments but it still comes down to individual developer taste and stuff like that saying, “Look, if I’m approaching this system as an outsider, what do I need to know to be able to use it and how do I apply the principle and let people do what they need to do with it?” If you have to use some magic behind the scenes in order to make that sort of thing happen, that’s fine. You hope that people don’t really have to get mired into magic in order to go and do their work. I feel almost like that criticism is more to help people use these technologies as opposed to the intrinsic nature of the technologies.
DAVID: Yeah. Yeah. Their programming doesn’t kill people, meta-programmers kill people.
MICHAEL: Have you said that I do have apprehension about the whole mixing of object orientation and functional programming. It’s particularly a language like Scala, where you basically have strong typing. It just feels like there’s some fundamental incompatibility between OO subtyping and the parametric polymorphism that we have in functional programming. They just feel like together they don’t cover everything and it’s like when you do something in one side, of course you do something on the other side. It’s like a weird interleaved pattern. You see that with some of the complexity that kind of comes out in Scala. I feel like, yeah, you can use these things effectively but it’s scary. I don’t know.
JOSH: Yeah. I’ve been feeling that way for a while too. Ruby is an interesting environment to programming because some of it is well designed from an object-oriented perspective and some of it is a lot more functional. And then there’s places where those models, I think mesh pretty well if you look at the enumerable API. I think that’s essentially a functional programming. But the scope of it is so restricted, that it doesn’t interfere with doing the object orientation. But if you look at one of these systems where… Yeah on functional systems, they like to use sort of uniform data structures a lot. Okay, I got an array of stuff, I got a list of stuff, I had a Hash, and as long as you know about those common data structures and are okay dealing with things at the what is it the -- of naming level. Okay great. It’s either ---- of naming or --- of position to make effective use of these common data structures.
Then you have a lot of flexibility on how you structure your functions and object orientation uses it the other way around. You build objects where they’re very specialized in how they operate. So, that’s different from these common data structures. If you’re trying to use APIs or libraries or gems or whatever in Ruby that one of them is built along the strongly object-oriented design direction and the other one is doing the functional thing. It can be very hard to mix those. One of them you want to pass in an object, the other one you want to pass in a lambda.
MICHAEL: Yeah. I think that’s the thing which I don’t know whether we’re going to solve this. I can hope we’ve learned more because to me, it’s just terribly interesting. But it’s like there is that thing as like how do you decide which technology to use in which particular circumstance. Is it just style? How much were just capricious and how much of it can really be something that we arrive at based upon our understanding of particular problems and say, “Yes, for this problem. This is a natural fit. We should be using more functional style.” For this particular way of structuring this particular type of system, is it better to do it this way or that way? I don’t know”.
To me, I’m kind of excited because I think it’s really an interesting area. I do have to say those like with languages like Scala and F#, I was scared when I first saw them (and I guess I still am in a way), it is and I sort of remember the C++ days where it’s kind of like here we had a language which was object oriented but was designed to go and basically sort of hijack all the C code in the world, right? Lots of people who basically only knew procedural programming and they have all these object stuffs that they could go on and work with. And it feels to me that the mix of objection orientation and functional within the same language has an even higher potential for strangeness, or misuse that can lead to poor maintainability if people make serious mistakes and I think we’re still on that phase where that’s possible.
DAVID: Sure. Is that a power versus safety trade-off though, where we’ve got the power to do it right? We’re just not smart enough to do it yet.
JOSH: I think somewhat but one of my favorite analogy is this, “A car with four-wheel independent steering, isn’t it more effective in any way?” It’s not more powerful. It’s definitely not safer. The one thing that you can do is you can spin around in place and that’s not a very useful thing to do with a car.
DAVID: But it is freaking awesome.
JAMES: Yeah. Wait.
MICHAEL: Yeah but this stuff does evolve over time. I mean, it’s like I still remember when we were in deep inheritance hierarchies were a pretty decent idea and you can use OO to model the world and stuff along those lines and it’s fine that we’ve seen now that basically practically nobody offers a straight multiple inheritance anymore and OO language is considered just a poor idea. And it happens very slowly but I think with a bit of time, this will settle out.
JOSH: Hey Michael, have you spent any time working with the Self language.
MICHAEL: No. I’ve read about it and I found it utterly fascinating, but I never really have an instance to play with.
JOSH: I got to play with Self. Yeah. I never used Self for anything really significant, but I did play around with it a lot and I view it as the scheme of object-oriented programming.
MICHAEL: Yeah. I know it’s funny. I used to joke with people and say, “Look, it seems like if you try to go and basically make a language as minimal as possible, you can either end up with Lisp or Self, it seems. Those are two languages which take some poor ideas and just kind of carry them to the absolute extreme.
JOSH: When I worked in Apple, I am on the project for the language that eventually became Dylan and one of the exercises we did was we looked at some of the foundational technologies and we did a comparison of Scheme and Self and worked it down into what are all the fundamental abstractions in the languages. And it turned out that Scheme and Self had exactly the same level of complexity. They had the same number of fundamental abstractions. When you got down to the bottom, they were essentially the same thing just in different orientations.
DAVID: Were they the same things or just the same number where 1 uses objects, 1 uses verbs?
JOSH: They were essentially the same thing.
DAVID: Okay. So they weren’t just doing equivalent using the same number of tokens?
JOSH: No. No. But it was like both languages have the concept of a local variable and an execution context.
MICHAEL: Yeah. That’s kind of interesting.
JOSH: But the thing that’s amazing about Self is they were able to take all of these object stuff and in a very magical way, turned it into those equivalents. So think local variables in an execution context, were defined as slots of the context object and a “slide” is just another name for an “instance variable” in Self and the lexical scoping and dynamic scoping that you can see in Scheme, is done with object delegation in the Self model. So, one execution context inherits from the enclosing execution context.
If I’m in a lexical scope and I make a call to a local variable and it’s not there at all, it will delegate to its enclosing lexical scope and go find it there. It’s beautiful how simple the language and it gave me a real appreciation for that at the roots, the model of computation is very similar.
MICHAEL: Yeah. It’s so much like the various different flavors of Geometry right? Like Euclidean, Non-Euclidean and stuff like that. You have a set of axioms and it’s kind of like if you tweak one or another, you get one direction or get the other I guess.
JOSH: So you’re saying that object-oriented programming has worked?
MICHAEL: No. I’ll tell you though. It really is very striking to me that, I’ve been involved in object orientation for years and I’ve thought it a very powerful way of structuring solutions but I feel like personally, I missed the fact that a lot of what we introduced is accident complexity I think. The more I reflect on it now, I noticed that there is a lot of accidental complexity that comes up in object orientation and doesn’t need to be there. If so, this is interesting. I don’t know. At least a matter of perception and yeah I think changing the industry. I’m very curious about that. It’s very strange.
JAMES: Can you talk more about how that accidental complexity gets introduced? Is it how we model things and think about things? Is that kind of where we’re going?
MICHAEL: I think so. I know that from my perspective at least, I was very strongly into notion of decoupling things as much as possible. And it seems like object orientation offers us a lot of avenues to do that sort of thing but it does seem like it can go and end up having lots of spurious abstractions which aren’t really necessary in the long term, that sometimes more functional solutions can go and give you even though they may not be as easy to mutate under change. Chances are, they aren’t going to change all that much so it’s okay to use functional stuff on those areas.
JOSH: I have a probing question about that.
JOSH: Okay. You’re saying how Alan Kay talked about objects as like cells in a biological organism and one of the things…
JAMES: Can I use a great quote from there? I loved one of the quotes in the article.
JAMES: In your article you said, “The nice thing about object structure is that it de-emphasizes the players and maximizes the play.”
MICHAEL: Yeah and that’s something that is paraphrased of something that Alan Kay said. He basically said that with object orientation, messages are the more important thing.
JOSH: Yeah. It’s absolutely true. One of the things he talked about with the cell analogy is that, if you look at the metabolic operation of the cell, it spends about 90% of its metabolic energy keeping the outside out and the inside in. The rest of what it does is just side effects. Okay, I’m generating a protein whatever. Mostly, it’s about, “Okay, the outside is out and the inside is in, and oh I need some glucose molecules so that I can operate or some iron to make hemoglobin or whatever it needs.”
It’s pretty easy when you’re thinking about an object to say, “Okay, the cell membrane, here is my external API that I’ve designed and these are the places where I need to enforce my assumptions about what my data values are going to be and sequencing of operations what have you.” The thing that I want to know is, I’ve never been able to figure out what’s the right place to put that sort of enforcement in a functional system. What’s the functional programming equivalent of the cell membrane? We know what it is and the object system.
MICHAEL: Yeah. I don’t know. It’s kind of funny because it seems like people had different answers for that sort of thing. I know in Scala, they basically try to make modules into objects. In and Haskell you got modules in essence where you go and say “Look, here’s a public API.” Yeah. I don’t think there’s any one fixed answer. I think every language arise with that in a different way. Yeah. I don’t know, if you look at functional programming at its core, it’s not going to have an answer about encapsulation that way. That’s my feeling and it’s hard to back that up.
DAVID: Do they the referential transparency? Doesn’t that help try to cover that?
MICHAEL: Well, it tells you basically that this thing is always going to do the same thing, right? In essence, I guess the main thing that we worry about with object orientation which is kind of like, “Okay, when I change this, what else changes in the system?” That question is answered in functional programming when you have referential transparencies. It’s like, “Okay. Yeah nothing you do over here is going to affect that over there except through this well-defined interface. I don’t know. I apologize for being vaguer.
JOSH: It’s okay. We are talking about functional stuff.
MICHAEL: But, no I don’t know.
DAVID: We’re going to get so much hate mail from the functional guys.
JOSH: I’m really looking forward to it I got to say.
I’m on a feisty mood this week. We all know that lovely --- all the way down and I’m curious is it interesting to talk about what are the turtles for objects and for functions.
MICHAEL: Yeah. I think it’s there. The thing is that my experience isn’t wide in functional programming but the things I do notice is that it seems like some systems I’ve seen is kind of DSLish in a way. It’s kind of like you are taking these atomic bits combining them in such a way you’re going to make something which people can use to create their own language to go and solve problems, right? It reminds of something I saw ages ago, which is like, you’re just basically making the pieces and then people combine the pieces to go and solve the problems that they want to solve, right? In terms of turtles all the way down, I guess that has that kind of feel where it feels like an object orientation. I think we gave up on reuse in the Small a long time ago with object orientation and we’re using the Large for frameworks and stuff along those lines.
JOSH: What do you mean reusing the Small?
MICHAEL: It seemed like in the early days of object orientation, there was this notion you can make these little individual classes that people could reuse in various different contexts. And of course, there are things like that like dates and money objects and stuff like that, but it seems like the tendency in object orientation is spent to go and sort of like make frameworky things that are the elements we use more than individual classes, right? It’s kind of hard to go and say, “Ah, it’s just bringing this class and I do things, right? You’re bringing it as a whole set of classes to do things.
JOSH: Yeah. Definitely, the whole industry made a move away from protocols to patterns and patterns are not really reusable in the same way that protocols are. Do we need a definition here?
CHUCK: Sure. Go for it.
JAMES: Yeah. Absolutely.
JOSH: It’s been a long time since we did the definitions. People I think are familiar with internet protocols. It’s basically a set of rules for how to communicate between two entities. In object-oriented programming, the protocol is the same thing, it’s a set of rules for how you communicate with an object or between two objects and if you look at something like the enumerable mix-in in Ruby, that defines a protocol that says, “Okay great. If you have an enumerable, here are the operations that you can invoke on that object and what you should expect to get back and maybe what it will call back to you.” A protocol is essentially an API that an object is published.
DAVID: I kind of feel like reusing the small was the baby we threw out when we threw out the multiple inheritance bath water or C++ templates, right? I mean, the problem is that you bring in these mix-ins and they start to interact with each other and sometimes in unexpected ways, you have to understand the mix-ins. If you bring in an enumerable, that’s going to do some things to your object and if you bring in something else that, monkeys with you spaceship operator, it’s going to fight with the enumerable mix-in and in Java, they just threw up their arms and said, “Screw it. You can’t do it. No mix-ins. You’re going to have to write an interface.”
And anytime you want to use this interface even though the interface does the same exact thing everywhere, you guys still have to implement it the same way over and over and over, and C++ solved that with templates, Ruby solves it with mix-ins, and Javas just don’t.
JOSH: Yeah, on Smalltalk I did it with just single inheritance and a lot of duplication.
MICHAEL: Sounds like a Java solution.
JOSH: But I think you do have turtles and in an object-oriented system, you can define it. It’s all objects and messages. And you can even define inheritance or delegation that way. You can break it down to, “Okay, I’m an object. I just got a message and it has some parameters or some arguments,” and “Oh. I don’t actually have the method for handling that message. I’m going to take that and I’m going to pass that message to some other object, my super object, and have that delegate the message over there.” You can model the operation of delegation in terms of message passing.
MICHAEL: Yeah that seems kind of funny too because it seems like in object orientation, it’s like you’re mixing and matching things is kind of like you’re doing a lot of patching sometimes like a lot of adapter pattern and that sort of stuff. And this feels like with the functional stuff I haven’t seen much of that but it might be experienced enough to know. It’s like you’re taking the API as given. You’re taking the signatures of these particular functions as given and using them, choosing to use them at a particular level in your program in fact exposing them out all that much.
JOSH: There’s a saying that at some point, a difference in quantity becomes a difference in quality or quantitative difference becomes a qualitative difference. If you’re making $10/hour and you get a raise to make $11/hour, that’s not really a qualitative difference but if you get a raise and you’re making $100 /hour, that’s a real qualitative difference. You’re now making more, now you can afford a lot more stuff. So, in an object-oriented system where you’re looking that there are turtles all the way down and even fundamental operations like delegation can be modeled as message passing them on objects.
If you apply some magic and say, “Okay, there is a couple operations in this system that are infinitely fast or close to it.” Then you start using those operations for everything that’s performance critical. That’s what they did with the original implementations. They took those operations and made them blindingly fast and so you got things like inheritance and class hierarchies and that stuff became used a lot but there was no fast operation for doing something like multiple inheritance, so you have to make it use very much modeling the system.
I think it’s kind of telling there was this one primitive operation that got used in Smalltalk a lot called Bit Blit (which was the graphics primitive) and everybody who worked on Smalltalk in the ‘80s, it was like the joke was, “Oh I can’t do this. What do I do? Oh just use Bit Blit.” It was basically an incredibly fast computational engine and you could implement Conway’s Game of Life by doing a bit mask logical operations so it’s just awesome. I’ve seen image rotators done by recursively translating images around and I can’t do a good job of describing that here, maybe I’ll find something for the picks for the link of that algorithm.
Anyway, that operation was so blindingly fast, that it perverted the nature of how people design software. And people are designing software so that you could take advantage of Bit Blit being so fast. Method lookup is one of those blindingly fast things in object-oriented systems. It’s funny to call it fast because it’s actually incredibly slow, but compared to anything else you’re doing, it’s really fast.
What’s the equivalent in the functional world of the tricks that, “Okay, we took this thing mathematically. It’s similar to everything else but we’re just going to make it in order of magnitude or 3 faster.”
MICHAEL: Gosh. I don’t know.
JAMES: Does in functional almost get that for free though just basically by the design of itself? Because to me, I guess what I’m saying is that, I feel like functional languages are almost more ideal for computers, than maybe even humans but the computers seemed to be able to turn through those functional operations so fast.
MICHAEL: It seems very hard to go an talk anything about performance these days as there are so many different ways of optimizing things and stuff on those lines. It seems like certain things should be relatively easy to optimize using Lisp-based operations and functional programming languages mask and reduces the stuff on those lines but whether they actually are fast? I don’t know. I like your argument about it’s blindingly fast, but I wonder whether it was plain fast as much as what’s made easy for the developer.
JOSH: Okay. There’s that old chest note about how you can write Lisp in Lisp, in like a page of code and I think that that implementation of Lisp is probably not extremely performant.
JAMES: Sure. Right.
JOSH: Yeah. What’s the bit of that that you have to make it blindingly fast to have it be usable?
JAMES: It’s a good question. I guess popping the function stack I guess, the call stack or something like that. It’s got to be something similar. I wanted to do one thing before Chuck cut us off kind of change in the subject a little bit, but where are the spaces where these two paradigms intersect at a useful level? And the reason I’m asking that is because I did the ICFP contest a couple of weeks back and I built an object system to model the problem. And basically it was a search through a large space and I had this object tree where basically I have some big array that represents the board. It was a game, but I have an array that represents a space and they have individual objects in each slot in array that are areas on the board with various information.
And so because I had to search through this, I had to move through those positions very quickly and switch and I ended up applying some functional ideas to get some kind of surprising speed out of Ruby. And basically I made it where my models were immutable and I over road Ruby’s initialized copy method to make it where I duplicated the array on copy, but I didn’t duplicate the individual objects in the slots.
Basically, you have a very large search space, let’s say a million slots. I duplicate that array which is a fairly fast operation just it’s only pointing to various addresses but I leave all those objects alone because they’re immutable though we pointed at the same objects and memory which means I saved Ruby copying a million objects every time I duplicated this thing. And then because they were immutable, I just returned a copy. Usually I need to change one or two objects, so I end up just changing the one that I need but what was interesting to me was, I took this very OO system by applying a few functional principles to it, I was able to use it for something that was a little bit surprising. I was searching through a very large in Ruby quickly.
MICHAEL: I think that sort of highlights the thing that it really is important to be well versed in all these different approaches to program construction. And you’ll never know when a particular idea is going to go and come up when you’re looking at problem and the only way to have those ideas come up is if you have experience on those different areas. I think it’s really powerful. I don’t know what the answer is with this stuff as far as where’s the best place to use these things. but I don’t know and I’m not sure whether I’d get to that but I find it really fascinating to think about.
CHUCK: Awesome. Well I’m going to take this opportunity to cut things off and get to the picks unless there is anything that you guys have a burning desire to talk about that we haven’t covered.
JAMES: I just want to say thanks to Michael for an awesome conversation. It was really ----
MICHAEL: Yes. Yes.
CHUCK: I know I’m going to have to go back and listen to it when I’m awake.
MICHAEL: Thank you very much. It’s been very fun. This is a very interesting topic to me and it’s great to converse with people that have shared interest on it.
CHUCK: Awesome. Well, let’s do the picks. David, do you want to start this off?
DAVID: Sure. I want to start off. This is kind of funny. This pick basically proves that I can be bought. A couple of days ago, I woke up and there was an email in my inbox that says, “Your purchase from noelrappin.com is complete and I went, “What?” I immediately went into a fraud alert mode like tracking it.”
JAMES: Noel is stealing your identity!
DAVID: Yeah or someone else has stolen my money to buy something from Noel, which actually a pretty good use of the money. I’ve met Noel so I didn’t feel too threatened just by sending him an email saying, “Did I just purchase something from you? Did I preorder something from you and forgot that I did it?” Because that sounds like something I would do. He wrote back to me and he said, “No, I just sent you a free copy of my book.” He has two books that are out and there was no way to personalize the message so sorry for any undue alarm.
CHUCK: Actually Dave, I forgot to tell you I’m providing a life-sized Noel to each of the Rogues.
DAVID: Right on. Right on. It’s a duplicate, right? It’s referentially transparent.
CHUCK: Yeah but it’s immutable.
JOSH: It’s okay. It’s so lazy it will never do anything.
JOSH: Except some of the people who use this.
I do have a second pick, something that I thought of because of what Josh mentioned about Bit Blit and Conway’s Game of Life and that is a YouTube video that I’m posting here. It’s Conway’s Game of Life written in one line of APL, which is an extremely functional language. He basically establishes a matrix and then shifts that matrix up and over and then up and it shifts it around to all eight adjacent positions like you would do with a Bit Blit to bit mask it off, and then he sums up the matrix taking out the sums to determine which cells live on to the next thing. APL uses all kinds of Unicode characters, so it’s kind of hard to follow the code but watching the output on the screen is terrifying because he ends up writing a full-blown copy of life. It’s very, very cool. So those are my picks.
JOSH: That sounds awesome. In case people aren’t familiar with APL, I’ll just say that it’s the kind of language you can write a prime number sieve in what five characters?
CHUCK: That’s awesome.
DAVID: Yeah and only one of them are in the Roman alphabet.
CHUCK: Alright. James, what are your picks?
JAMES: I’m basically obsessed with the Raspberry Pi right now. If you guys have seen this but it’s a little basically circuit board Arduino kind of thing except it’s like a full Linux arm computer thing. 700MHz processor, it’s got 256 of RAM on it. It’s got HDMI outs and you just plug it in your HDTV, USB on it, Ethernet, and then it’s got general purpose I/O, GPIO, so basically you can connect it up to circuit boards or any other Arduino-like tasks you want to do. And there’s just so much awesome stuff you can do with this thing and they’re building it to use in education, really teaching people about computers and stuff like that which I think is awesome but it’s just extremely hackable, fun to play with I mean you can see videos on their site which I’ll put a link in the show notes to people like doing voice activated mechanical arms or doing automatic translation or just anything.
Some people are using it as a media center because it actually turns out it’s fast enough processor to stream HD and it’s got the HDMI built in so just totally fun, very hackable piece of hardware. And if you want to see a lot of good uses for it, Highgroove, a great Rails consultancy, has this Tech Talks they do every once in a while and they have one recently on the Raspberry Pi and that was where I found out about it. So he shows you what it is and what it can do and the various things people have used it for. It’s pretty cool stuff so check out that talk and these are my picks.
CHUCK: Awesome. Josh, what are your picks?
JOSH: Okay. My first pick is for the T gem, like the letter T as in Tanqueray or Twitter. This is the Twitter command line power tools gem and it comes to us from Erik Michaels-Ober. This is just like if you want to dump a list of all your followers or compare the people you’re following to the people who follow you or make posts from the command line, it’s really good for all that stuff. Because it uses the API rather than the UI, it’s more effective at searching for old Tweets so it’s useful just for that.
JAMES: Thank God.
JOSH: Yeah. Did that actually solve the problem that we had with the golf game?
JAMES: I don’t know if anybody has tried it yet but…
JOSH: Okay. Okay.
JAMES: Searching on Twitter is oh my God.
My third pick is for simple.com formerly known as BankSimple. They’re an online bank so I have been using them for the last week or two and they have a great website that’s pretty much like Mint for your account with the and a really nice iPhone app. They just rolled out a couple of weeks ago so they’re still ramping things up and they’re going through an invitation list to get people in the system. And there are still some features that they need like being able to make deposits with the camera on the iPhone, which should be coming soon. But it’s a pretty nice alternative to checking account with somebody like Chase or Wells Fargo. It’s nice that it’s an online banking built by people who understand usability.
JAMES: i.e. not Paypal.
JOSH: Yes. It’s the opposite of PayPal. I think that’s enough picks for me today.
CHUCK: Awesome. Alright. I guess it’s my turn. One of the things that I’ve been using a bit lately to track clients and potential clients is Salesforce. I decided to just go with kind of the big dog in the arena and I’ve actually been pretty happy with the way that it all works. I was looking for a CRM. I had tried Highrise before and it just didn’t seem to really work for me. So I decided to try some of these other ones and I got into Salesforce. They gave me a free trial for a couple of weeks and it just really works well with the way that I manage things and so it’d been really, really nice.
It also fit in with my other pick and that is a book that we reviewed on the Ruby Freelancer Show. It’s called “Get Clients Now!” and it’s by CJ Hayden. If you want some information about it, we actually did an interview with her for the book club on that podcast and there’s a lot of great information there and I’ll put a link to that in the show notes. But yeah, it’s a terrific book and if you’re a freelancer or trying to build a brand, then this is a really great way of doing it. It’s geared more toward people who provide services as opposed to people that sell products but I’m pretty sure that you could adapt pretty easily to that just with some of the techniques and things that you would use to build a community around a product instead of around a client base around a service business. Anyway, those are my picks and we’ll let Michael give us some picks and then we’ll wrap the show up.
MICHAEL: Sounds good. There’s a book I’m partway through that I’ve kind of liked where it’s going. It’s a book called “Elemental Design Patterns” by a guy named Jason McSmith, and what the idea is basically taking a lot of the design patterns that we can search fundamental. I began in four design patterns and stuff like that and breaking them down into smaller pieces and trying to go and get a sense of how those things interact. I tend to be very much a person who likes to go and get down to the foundations of things. It seems like he’s got a decent categorization scheme for things and it was a very interesting read. I guess in the interest of going and sort like going completely outside of self, I think we could do that with picks.
I was impressed to see a movie the other day at a local art cinema called “Beyond the Black Rainbow” and it was very, very interesting. It’s probably something that our listeners might appreciate also. There’s a movie made in 2010 by a guy name Panos Cosmatos and what it is, is it’s basically kind of an amalgamation of all the 1970s strange sci-fi horror movies you’ve ever seen in your life. It has elements of 2001, the “Demon Seed,” “Logan’s Run,” and other ones. Yeah, just all sorts of films like it have a very period feel and yeah just fascinating. There’s a little clips of it up on YouTube and I just was really struck by it. It’s not one of the things you’ll see in your local Cineplex, but still a very interesting film and definitely I’ll be getting when it gets on DVD. Yeah, I guess those are my picks.
CHUCK: Awesome. Thanks again for coming on the show, Michael. It’s a really, really good show. A few announcements that we have, first of all, you can get the show in iTunes. You can just do a search for “Ruby Rogues”. In fact, if you search for Ruby, we come up near the top. Also, we are reading “Growing Object-Oriented Software Guided by Tests,” and we will be reviewing the book with the authors on August the 22nd. I think that’s it for announcements. You can get the show notes at rubyrogues.com and I just want to thank the Rogues again for coming and we will catch you all next week.
JAMES: Chuck, we have one more announcement.
CHUCK: Oh yes.
JAMES: Avdi’s baby has not yet been born.
CHUCK: [laughs] Is that a non-announcement then?
JAMES: Okay. Sorry.
MICHAEL: It’s been an hour.
JOSH: I wonder if his wife is going to pull one of those last minute releases that come out just after the podcast.
JAMES: Oh yeah.
JOSH: I feel like we’re like Ruby 5 or something.
DAVID: Oh my gosh! He’s sandbagging.
JAMES: Yeah. Next week, we might announce the birth of Avdi’s child who knows.
MICHAEL: Very cool.
CHUCK: Stay tuned. (For another exciting episode!)