We are very excited to welcome the amazing and wonderful Sandi Metz as our guest on this episode of The Rabbit Hole! We are going to be talking to Sandi about her book 99 Bottles of OOP and the new edition that is currently in the works. This new edition will take the ideas that Sandi had written about for Ruby and expand them to other programming languages. Thus our conversation takes the form of comparing the differences, strengths and weaknesses of the languages in question. A good portion of the episode is spent looking at the contrast between Ruby and JavaScript and Sandi admits some surprisingly positive feelings towards JavaScript's limitations. We chat about type safety, declarations, descriptive language and why Sandi is particularly interested in getting more familiar with TypeScript. For all this and more, be sure to listen in to what Sandi has to say!
Key Points From This Episode:
Transcript for Remix - Comparing Programming Languages with Sandi Metz
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez, our cohost today.
[0:00:10.4] DA: Dave Anderson.
[0:00:11.4] MN: Our producer.
[0:00:12.8] WJ: William Jeffries.
[0:00:13.6] MN: Our special guest.
[0:00:16.0] SM: Sandi Metz.
[0:00:17.2] MN: There you go, we have her ladies and gentlemen, Sandi Metz is in the building. How’s it going Sandi? How are you?
[0:00:32.7] SM: I’m good, how are you guys?
[0:00:34.8] WJ: We're doing well, I’m very excited for some breaking news. [inaudible]
[0:00:43.3] SM: I knew I’d regret telling you guys.
[0:00:48.0] WJ: You’re working on a new project?
[0:00:49.9] SM: We are working on a new project that my most recent book, 99 Bottle of oops, we’re at making it 50% longer and translating it into a number of other languages, besides just Ruby.
[0:01:03.0] DA: Cool. Now it’s Spanish but like –
[0:01:07.5] SM: Could be Spanish there. That would be a cost-cutting concern.
[0:01:11.4] DA: Yeah, I’m always surprised at like the Unicode support in Ruby like you can name a method as like an emoji bomb or something like that.
[0:01:17.9] SM: Yeah.
[0:01:19.6] WJ:What languages are you going to be translating the book into?
[0:01:22.5] SM: Well, maybe all of the languages? Probably that’s a little extreme. Right now, we have Java – well, okay, we’re leaning to our dynamically typed object oriented languages. Near and dear to our heart so that means like starting at Ruby where it is and moving out to JavaScript. The JavaScript’s almost done. We’re the PHP as well under way, the Python is just barely started.
[0:01:48.3] DA: I’m excited for Python. That's my favorite language.
[0:01:51.5] SM: Interesting. No, it’s so hard to know like which language which you pick, who will be interested, right? Mostly what – how would – I’m just going to throw it back to you guys. How do you decide what languages a book, that it’s really about sort of dynamic OO but uses a specific language like Ruby as illustrations?
What do you do? If you're going to put it in other languages then what languages would you choose?
[0:02:25.8] WJ: I would pick JavaScript first and Python second because your target is web developers that are adjacent to the Ruby community and it seems like those would be like if you're at a conference and you do a poll, a Ruby conference is going to have, I would guess the most number of attendance from those two languages. Although, maybe I’m wrong about that.
[0:02:45.1] MN: No, PHP has a huge following though. I’m not surprised.
[0:02:49.7] SM: PHP is surprising.
[0:02:51.8] MN: Yeah, it’s crazy.
[0:02:53.2] SM: You know, there’s that whole thing for everybody wasn’t here when we had our initial chat when we talked about the difference between internet Sandi and real Sandi. Real Sandi is just me, right? The internet Sandi is that person that people might know. I sometimes go and speak at PHP conferences and when I walk in, people know who I am. Which really surprises me, right? I’m like, "How would you possibly know who I am?"
[0:03:19.8] DA: That’s funny because I read practical objects are into design in Ruby, on the recommendation of a friend and I was nowhere near a Ruby project. It was just a Ruby was the closer to language and on that was now, gave you a good baseline of like how you should think about these kind of problems in an object oriented way which is probably applicable.
[0:03:44.1] SM: Yeah, absolutely. I mean, it’s not just that Ruby is my favorite. I’m not saying that. If you wanted to express an idea to programmers who mostly want to see code. Then, and you don’t know what – and there’s a bunch of different people who are more comfortable or in different languages, there’s a way in which a language like ruby which has such simple syntax is sort of the most common denominator.
It’s the most readable of all those languages, right? How much weird syntax is there in Ruby? Not much. Even if I didn’t enjoy writing Ruby code so much, it would make sense to write books about OO in Ruby, I think.
[0:04:29.2] WJ: You must feel like there is value in translating it to people’s native programming language because you’re investing probably a significant amount of resources into this project..
[0:04:39.9] SM: Yeah. I feel a need to be careful here. Let me put it this way. I’m – I went to the tech school, right? And learn four trend 35 years ago. I don’t have a computer science degree and so the things I know are things that I sort of learned myself or that other people were kind enough to write down so that I could study.
I am keenly sympathetic for the problem of JavaScript because there are million JavaScript people out there who just got somehow got a website and got a book and wrote some code and that code is often really painful for them to maintain but it’s like, what should we think about those people? Should we think they’re stupid or should we just admire their effort?
There’s a way in which I have warm feelings about JavaScript and what I know is that – but many JavaScript programmers have read the Ruby books I’ve written. It feels only fair and right to try to get it in their language. That was really the first – that was the push, right? To get it in JavaScript but then once you solved the tool team problem of having a book that can be rendered using language A or language B, you may as well just do other languages.
[0:05:50.3] DA: Totally. Yeah, I totally feel that sentiment too with JavaScript to where it didn’t even – I have been a programmer for a while and I have used JavaScript but it always felt incidental to the task. Yoou know, the real coding is happening on backend and server render pages and then JavaScript was just kind of there like being scrappy and gluing things together.
Until like web pack and modules and packages, MTM came on thescene, it didn’t really feel like a real programming thing, it was just something that you had to do
[0:06:24.5] SM: Not a language in which you could write an app that you were proud of in.
[0:06:28.7] WJ: You know, I’m surprised that JavaScript was the first language that you picked. I mean, I suppose I shouldn’t be because the way you phrase it, it makes a lot of sense that of courses there would be demand there. It’s just that in industry I’ve seen so little object oriented JavaScript and so little interest in writing object on JavaScript.
[0:06:49.6] SM: Yeah.
[0:06:50.8] WJ: They want to make it functional or procedural or something else.
[0:06:57.6] SM: I mean, it’s just super interesting idea, right? Almost a little guy. And so if the OO paradigm makes sense for some category of problem, I would argue that it does. Not all category of problem but some problems are really suited to be solved with. Then four languages that can do OO, if you’re using that language and you encounter that category of problem then a solution can be the most cost-effective one. I mean, I agree totally William that the knowledge of how to do OO in JavaScript — it’s not that JavaScript can’t because it certainly can. It’s just that JavaScript doesn’t.
[0:07:34.5] DA: Right, yeah. I think there’s also a class of problems that you might see with like, you know, Raft application that’s just gone out of hand. Components all over the place and there’s logic in them and things are all tangled. It's like how did we get here? We’re just passing data structures out, we’re just passing naïve data structures and they can’t help themselves so the components need to do all the heavy lifting
I work with like old school developers who are like, "You know what you need? You need objects right now," and there’s like strong resistance. "No, not in my JavaScript, get these objects out of here but they help."
[0:08:20.6] WJ: Especially with Reac which is you know, rather opinionated in its functionality.
[0:08:25.7] DA: It seems like sometimes like, you know, React can be a functional thing it is a view that is a result of a ffunction that’s on the inputs but when it needs to do something that’s more dynamic or you know, domain models, it’s the things that you pass into it, then OO could be useful.
[0:08:46.0] SM: The thing I always wonder, the thing I was going to say a second ago is. If the frameworks in many languages, the frameworks themselves sort of push you away from doing OO because the frameworks make all the decisions and they want you to just pass on lumps of stuff that the frameworks do things with. But I would wonder if you look under the covers and React, if you look under the covers and all those JavaScript-y frameworks. How object oriented is it behind the curtain?
I suspect pretty OO-ish. I would assert that things – you all know, things get out of control and they’re hard to maintain if they’re just spaghetti and so some organizing paradigm needs to be underlying those frameworks or else they just can’t be tested and maintained.
[0:09:35.2] WJ: Can you translate the book into React?
[0:09:37.8] SM: No.
[0:09:38.6] MN: That’s a React component.
[0:09:40.3] SM: Not doing it.
[0:09:43.6] MN: 99 bottles of them.
[0:09:48.5] SM: It’s funny. I’m sort of making a living out of not teaching people how to use frameworks like I am not interested in that. Not that I’m saying that frameworks are bad. I think frameworks are great, there’s a bunch of things in the world that are commodities, that I want to get some other software to do for me.
But, if you only know how to use frameworks, you probably are only capable of using frameworks, right? I could be want to be able to write a big app and solve a big problem, mostly what you want is to write your own code and drive the framework away from you and use it at the edges of your app and put all your code in the middle.
And so for apps of any complexity, that pile of code that you would write to represent your app might be big and probably should be – use some other paradigm – you shouldn’t just lean on the framework, right? There’s more to it than just the piles of stuff that you would – the parts where your code touches the framework.
[0:10:47.1] DA: There’s more to life than a 2,000 line helper’s file
[0:10:49.7] SM: Yeah, it is the truth.
[0:10:53.4] WJ: When you were translating the book into JavaScript, did you find any areas where you felt like the language was fighting you?
[0:10:59.5] SM: Okay. I am not the person who is doing the – perhaps I gave you the wrong impression. I’m not writing the JavaScript. I’m not good enough at JavaScript to do that, there’s a guy, someone you might know actually. Tom Stuart who wrote the book Understanding Computation.
He’s really good at OO and he’s good at JavaScript and his – it all looks very much like Ruby to me. There’s almost nothing — the only thing I can think of that is different are things that — where we use like the inherited hook in Ruby. The inherited call back to do some registration and that call back is not there. Right?
The syntax is a little bit different. But all the things that I want to do OO-wise are there in JavaScript.
[0:11:48.0] WJ: Did you have to translate any of the plain English?
[0:11:51.7] SM: Yeah. But not too much. The difference between a method or faction in a message. Those things don’t necessary seem different. One of them is like the function or method that you would define on an object and the other is, from the sender’s point of view, the way I would invoke that. And in my mind, those are – I make a big distinction between them. Like sending a message.
I wouldn’t send the method, I send a message and over there, on the other side of the wall, it somehow invokes a method and those two things could be tightly coupled like the name of the message and the name of the method might be the same, often they are.
But I really want to think about those in different ways because from the message sender's point of view, I want to really insist on being ignorant, about what’s over there. That language is not the kind of thing that comes naturally to a JavaScript programmer.
[0:12:50.8] DA: Yeah, that’s interesting. Even like, I mean, I eventually learned Ruby for realsies but even back then I didn’t dive deep enough to the thing about those kind of distinctions.
[0:13:03.6] SM: We want this to be – to use the language that people are familiar with that seems idiomatic in their language and so those things happened in the book.
[0:13:12.9] DA: Yeah, that totally makes sense. I think that’s really one of the most important thing when shifting between languages. Not surprising people in drastic ways. You go too far into like, you know, Ruby land where you try to do something like meta programming with your class or something like that.
[0:13:32.1] SM: Exactly.
[0:13:33.1] DA: Was there any like comparison between languages, between code samples and that you found really surprising?
[0:13:41.2] SM: It’s always interesting. Like, you think you know something, right? And then the whole world looks like that thing and I am so used to not having interfaces in Ruby. Not having declare an interface just doing a hand wavy thing and saying, it’s a duck type, can’t you see? Just don’t screw it up. Right?
You know, when I teach, I’m always asking like I go in, I teach these classes and mostly they’re Ruby people. Though I sometimes see it in other languages and inevitable ask whatever dynamically typed language that I have. I’ll say, “Do you ever check? Do you ever send a message and check the kind of the thing that came back? So that you’ll know how to talk to it." And people say, “Oh yeah, all the time,” and I say, “How is that working out for you?” And they say, “We hate it. It is killing us.” Right?
And you know it is the thing that is statically type language for you. People have compilers, they just pull their hair out when they see that code, right? It is the kind of mistake that you mostly like you probably could if you are hair-brained enough you could but if you just behave in the normal way the least, frictionless way in a statically type language you cannot do that, right? It is not possible to make that error because the compiler ensures that when you send a message that then you get back, the response to the API that you expected to have, all right?
So in Ruby like I never do that. I never check kind of because I know that you shouldn’t. That is a bad idea, I think you should polymorphically, if you send a message, whatever you get back that they should polymorphically conform to the API that you expect and that means that you have to make them all be that way, right? If you get right and you just have to do it and you have to know that and you can’t ever break that rule.
You can’t ever, ever, ever break that rule. And yet for people who – it surprises me that people come to dynamically typed languages and when the compiler is removed it happens in big shops, where we have new people come in all the time and failures of communication.
And then you get in a situation where they make this rat's nest of message sends where different kind of objects come back and they don’t all conform to the same API and instead of fixing it and making them all behave the same, they just start saying, “Well if you’re in trouble it'll ask you for this and if you are okay it'll ask you something else.”
And so super interesting to me that – so I am answering the call. I really am getting around answering the question about the interesting things in language that I found out when we did the translations because PHP's dynamically typed but you can turn strict typing on and they can also declare interfaces.
[0:16:20.4] DA: And those are runtime interfaces?
[0:16:22.6] SM: Yeah, it enforces them, at runtime. And I would never have predicted that I would say this but it was kind of nice, right? I don’t want all that cruft about declaring. I don’t want type safety if it makes code hard to read but what I can selectively turn it on to keep people from accidentally making mistakes, I don’t know I didn’t hate it.
[0:16:47.3] DA: Yeah I was dragged into something MudPi to my life in Python and after getting used to the muscle memory of thinking about the types of your arguments and thinking about signature of a method name with the arguments and return types and then talking with one of our senior devs who is like a big fan of design patterns. All about the design patterns, all about the Java interfaces, and like strategy pattern, things like that, I was like, "I really I get it."
You can label something it's like having this interface and then swapping them in and out, it is a big eureka moment.
[0:17:39.2] SM: If I could wave a wand and make a thing be true and all dynamically typed shops out there say even Ruby shops, I would ban the use of kind of and say you have to decide what role the thing plays and make it play that role and you just have to do it and the price for you having to keep that straight yourself is you get this enormous freedom and flexibility of those dynamically typed languages. But they’re not without cost.
And so you know I wish that I could – I don’t have to give up dynamism to have interfaces that are trust worthy but it is super important that your interfaces be trustworthy and then the PHP people can sort of have both worlds, which is kind of nice. There were plenty of things about PHP that I didn’t love. Don't get me wrong. I wrote some code for that class that I actually put some comments in the code that said, “This made me cry.”
I was getting up every morning and translating the Ruby curriculum into PHP and then taking it to class and then let them tell me what was non-idiomatic about it. But at least it meant a whole – I had a whole class full of PHP programmers that then got to take the course in PHP instead of Ruby. So it was better for them. But it was harder for me and they were really nice about all my feeble attempts but there is something like it will make you appreciate the innumerable library in Ruby.
[0:19:02.5] MN: I see.
[0:19:03.7] SM: You know? It will make you love innumerables to go try to write those looping things in other languages. It is like how can people live like this?
[0:19:10.5] DA: Right, I think having that language in a library sold me on Ruby. It is pretty nice.
[0:19:16.3] WJ: Was there anything else that you wanted to steal from any of the other languages that you translated the book into? You could get them into Ruby core?
[0:19:25.4] SM: You know that thing in JavaScript where function is just a variable, it is just a block assigned on a variable? Like the syntax that you use to override a method is the same as the syntax you would change — you would use to change the assignment of a variable. It is the same thing.
And in Ruby you can do that. You can override a method say you can create an instance of a class and then go write over a method. And make it behave differently but the syntax is completely different, it is a completely odd, not very common used syntax even though it is allowed would I –
[0:20:02.5] WJ: Which is intentional, like they are trying to discourage you.
[0:20:05.3] SM: Yeah but maybe. But here is the thing, if everything is an object and everything is a method, maybe everything is just an assignment to a variable like the more you can have just a few things and have everything behave that same way, the easier it is to get sort of pluggable function. You can write things that are surprisingly useful in new and unexpected contexts, if they are not special. And one of the things I found out when I was writing JavaScript is that I would sometimes go “Hmm.”
And just take an existing object and change the – rewrite over one of its functions, just on that one. I would decorate one with different behavior for a specific function. Just because it seems so lightweight because it was just doing variable assignment. And that is a technique that I don’t ever use in Ruby because it seems much more heavier weight, not that it is different because it is exactly the same thing but it makes it seem hard because the syntax is special and I don’t know.
Maybe you could say it is a bad idea and like is it a good idea in JavaScript that the language itself led me to do that? I mean it was super useful the time I used that technique and it was surprising to me. It was like the language itself had some expectation about — like the way they put it together indicated to me how they thought I might use it and I was perfectly willing to do that, right?
[0:21:31.0] DA: Just completely lightweight ,like the bare minimum of rules.
[0:21:35.4] SM: Yeah like why have they done it that way if they didn’t mean for me to do it sometimes myself? Just saying.
[0:21:44.4] DA: So like winding back to talk about types for a second, I saw a post recently about how Stride is rolling out a type checker for Ruby called Sorbet. So now that you have the power of types Sandi, are your excited to have that power?
[0:22:01.8] SM: Okay, I want to beg the seen the power of types question.
[0:22:09.3] MN: It felt a little leading, right?
[0:22:11.0] SM: You are totally leading. So let me just repeat, like I don’t object to type safety, would right? That is crazy talk. What I don’t want is cruft to get it and if my choice is and I know like people – I am not saying everybody would agree with this statement but for me, from someone who has lived in the dynamically type world for many, many, many years now, decades. Like the cost of the artifacts that it takes right now to get, it’s type safety, are too high, right?
And I firmly believe I have been able to do it and I firmly believe people can learn to write safe dynamic OO. Now there is always the bigger the shop is younger the people are, the more the communication problem is, the more you probably need some help but there are problems for which it is perfectly fine to write straight up dynamic OO. I have looked at that Sorbet and here is the question I would ask, why do you need this? What is your problem?
What problem are you experiencing that is causing you to feel as if you have to be explicit about your types and that the other forms — what this means to me is that other forms of communication have failed.
[0:23:29.5] DA: The organization has grown to a point where you’re no longer familiar with all of the code and how it should be used in a documentation of it.
[0:23:37.8] SM: And my question would be like, “Was there nothing you could do? Could you have written unit tests if you are using our spec like the shared example groups or are you using mini test?” Any kind of a test like how come you are not test – have a test reduce type that you include in everything that says it plays to that role, such that you can clearly identify which things are played, which things conform to an interface without having to declare an interface and get the compiler to help you, right?
And so I am not saying Sorbet is wrong. I suspect there are places where they really need it but if I have to specify types everywhere, I wonder if I should be using some language other than Ruby, right? Why do I have slow dynamic languages if I am specifying types? Why don’t I just go to aesthetically type language and get the speed if I am going to pay that price?
[0:24:29.6] DA: Right, yeah that is an interesting point. So it is all about tradeoffs. It is a more layer of things to think about and potentially get wrong too. I’ve definitely done thaqt too where I have put my types on something and I am not religiously checking them but they’re there.
It is for me to know what something is and then finding that I have lied myself at some point in the future it’s like, I got that wrong.
[0:24:57.6] WJ: I think it’s marketing. I think the types are hot right now and Ruby needs types in order to stay competitive. People are moving to other languages.
[0:25:06.7] SM: Types aren’t free.
[0:25:08.7] WJ: Yeah even if it is a bad choice, being abnle to list it on your feature matrix I think is better
[0:25:14.6] DA: It's what the kids want these days, those types.
[0:25:17.0] MN: They want the types.
[0:25:18.5] WJ: Got to stay relevant.
[0:25:21.7] MN: I have a question before we go. So you mentioned that 99 Bottles will be featured in other languages such as PHP, JavaScript and Python. Do you have an idea of what the next language would be? Would there be a survey? Is there something you have in your guy that you want to express in 99 Bottles?
[0:25:42.0] SM: Partly it is just what I want to do, what I want to learn next. Survey is a great idea. We should ask people, you know every problem is better solved by crowd sourcing. Despite what I just said about types, I am a little bit interested in TypeScript. I would like to know what it felt like to write TypeScript and if it seem like a good solution for some category of problem and I think the intro there is obviously yes given it’s popularity. But I sort of my feel of the need to know something about it, I want to be able to tell people if someone asks me like, "Should I use JavaScript or should I use TypeScript?" I would like to have an informed opinion, which I don’t have right now.
[0:26:17.5] MN: Right, awesome. Sandi, how can people contact you?
[0:26:23.7] SM: Okay, I am on Twitter as @sandimetz and my website is sandimetz.com. The book that we have been talking about, you can find it by going to the content tab. I feel the need to give some hint that the – where the JavaScript version will be they will just fall. The PHP version shortly thereafter, this would be the second edition. So it is like the book is half again as much book and three languages and what we finally realize is it was just too much trouble to try to deal with separate products.
So we are just going to bundle the beer version and the milk version because there is a milk version since everybody can’t have beer. You know bundle beer, milk, the second edition in all the language of variants together in one package and that will be available this fall. That doesn’t mean that for anybody who is listening, you might want of what’s the Ruby, the first six chapters, the first edition in Ruby. If you get it now, so whatever today is I will look at the calendar and know what to do.
So from now on if you buy it, you will get the second edition when it is released. So no reason to wait is all I am saying. Get it now and you can just catch up on the remaining chapter when the second edition comes out in the fall.
[0:27:37.9] MN: We will definitely have those on the show notes as well.
[0:27:40.7] DA: Yeah, well I’m getting thirsty.
[0:27:42.1]] WJ: Yeah, you heard it here first, ladies and gentleman.
[0:27:44.7] MN: 99 Bottles of beer, milk, juice, water it is all here. JavaScript, PHP, Python.
Sandi Metz thank you so much.
[0:27:53.6] SM: Thank you guys.
[END OF INTERVIEW]
[0:27:54.8] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
