Key Points From This Episode:
- Sandi's latest book and the extended edition that is currently being developed.
- Deciding which coding languages to expand the content of the book into.
- Translating the descriptive language for the different coding languages.
- A few surprises that Sandi experienced along this translation journey.
- Considering the balance of type safety and learning to write safe dynamic OO.
- Why Sandi is interested in exploring TypeScript in the future.
- And much more!
Transcript for Remix - Comparing Programming Languages with Sandi Metz
[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: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: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.
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:49.6] SM: Yeah.
[0:06:50.8] WJ: They want to make it functional or procedural or something else.
[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
[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.
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: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.
[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?
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.
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.
[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:26:17.5] MN: Right, awesome. Sandi, how can people contact you?
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.
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.
Links and Resources:
Our seasoned cross-functional agilists work with you to develop technology, ship product and deliver value. We leverage our diverse expertise across industries and throughout the organizational growth cycle to your benefit. We bring best practices, emergent practices and creative solutions to your problems.