NOEL:  Hello and welcome to Episode 34 of the Tech Done Right podcast, Table XI’s podcast about building better software, careers, companies, and communities. I’m Noel Rappin. 

Table XI is now offering training for developer and product teams. Topics include testing, improving legacy JavaScript, career development, and agile team processes. For more information, email us at workshops@tablexi.com. 

We also have a free email course and tools on improving your company’s career growth and goals strategy which you can find at http://StickyNote.game. 

And my book ‘Rails 5 Test Prescriptions’ is now shipping. The book is up-to-date with the latest Rails, RSpec and MiniTest features and has some great non-dogmatic content on how to get value from testing your Rails applications. You can buy the book at PragProg.com or wherever fine technical books are sold. 

Today on the show I’m talking to Kerri Miller. Kerri’s a senior developer and Ruby community member who’s also one of the organizers of the Open Source & Feelings Conference. Kerri posted on Twitter a while back about how Smalltalk was the Old English of programming languages. And I was intrigued and that wound up being the starting point for a great free-ranging conversation about programming, languages, and communication. 

Kerri, would you like to introduce yourself?

KERRI:  Sure. I’m a software developer and engineer based in Seattle, Washington. I currently work for Travis CI helping people run their tests and continually improve their software. 

NOEL:  The last episode I did was with Justin Searls and Sam Phippen and we wound up having a lot of advice for CI products on how to take advantage of multiple test runs, data across multiple test runs. But that’s just a plug for previous episodes. I wanted to talk to you about programming languages and I guess programming languages over time. Because you had written something online about Smalltalk being like Old English. And I’m fascinated by Smalltalk and English. So, I thought that would be a good place to start, at least. So, would you like to say what you were talking about and where you came from with that?

KERRI:  Sure. I don’t remember the exact tweet, because I was in the middle of a Twitter rant there. Or a Twitter stream. Excuse me. But I recently gave a talk at Bath Ruby Conf in Bath, England. And as I was working on it, I decided to do the local... localize the talk a little bit. So, I was looking into the history of the English language. Now, I’m kind of a Shakespeare nerd so I’ve done a lot of reading in Elizabethan English and a little bit Middle English as well, like reading Chaucer and Canterbury Tales. But researching the history of the English language, like how has the English language gotten to be as weird as it is. Because the English language as a spoken language is kind of singular. We tend to think of it as a very easy language to learn. It’s very flexible. But it stands out in linguistic terms in that English is one of the few languages where there’s practically no other language that is derivative enough that a native English speaker can understand it. So for example, if you speak Spanish, you can figure out most other Romance languages. Italian, Portuguese, French, et cetera, Romanian, all those. 

NOEL:  Yeah. They’re all basically dialects of Latin.

KERRI:  Exactly. They have the same grammar structures. The vocabulary comes from more or less the same roots. You can probably get about half of what the other person is saying. For English, a modern English speaker, the only language that you can get about 50% of is Frisian, which is a kind of obscure northern European coastal language. Nobody uses it. You probably haven’t heard of it before. But, you know.

NOEL:  I have never heard of it before.

KERRI:  Yeah. And so, that got me really interested in like, well how did English get to be this weird language? And the reason is because Vikings spoke poorly. So, Vikings in the 9th and 10th century, they come back to England. Except this time, instead of just running around and making a mess of things, they decide to settle down. And so, they marry local English women and they raise families and build farms and try to become part of the community. And part of that is adopting English as their language. And what happens in that process is that they were adults trying to learn a language in a society that didn’t have literacy, that didn’t have schools, that didn’t have language tutors. What was most important was them getting their meaning across to the people that they were now living with and next door to. And what they did was they knocked off all of the weird edges of English. 

Old, old English is a standard European language. It has tons of verb conjugations, these fancy verb endings. It has gendered nouns. All these things that modern English doesn’t have. Because the Vikings, when they settled down, they ignored all that. They focused on getting their meaning across to their neighbors. So, they spoke bad Old English. And over time, their communities grew and became so economically and socially, really the drivers of English culture at that time, that that became the English language. It dropped all of these other things and became this very flexible, simple language. We lost a lot of our fancy grammar. We lost a lot of, like I said, verb endings and noun gendering and a bunch of other things. 

NOEL:  Right. But there’s a generational effect there too, right? Because there’s a standard generational effect when a group of people who don’t have a disparate language are thrown together. There’s a very common structure where the parents come up with... The people who have existing language create, what’s the term? One of them’s a pidgin and one of them’s a creole and I can never remember which is which. 

KERRI:  Yeah. I can’t either. I am merely, you know. 

NOEL:  Yeah. So the parent, so it’s a really fascinating thing. The parents create this very simple common language with very few tenses and things like that. And the children build off of that and create a real language with full tenses and all kinds of meaning. So, you’re suggesting that basically something like that happened within English. It sounds like a very similar process. So, okay. 

KERRI:  Yes, yeah. And so, in a similar way, I was thinking about Smalltalk and how Smalltalk is to Ruby as Elizabethan English is to modern day. You can look at a Smalltalk, if you’re a competent Ruby developer or excuse me, an experienced Ruby developer, you can probably read most Smalltalk and figure it out. It’s a dialect, in a lot of ways. It’s heavily influenced in terms of its grammar and its syntax and its nouns. But as you go further back to like, well what influenced Smalltalk? What other influences are there? It gets more obscure and stranger and harder to read. So that, if you go back to C and Fortran and those things that were influencers and coming along at the same time as Smalltalk, those are like Old English at best. It’s like trying to read Beowulf and it’s a foreign language. You cannot read it. And then so, thinking ahead, looking at that lesson of how spoken languages evolve over time, we can look forward at our programming languages and see how they change into the future in terms of when you go to a new language, you write it in the style of the languages that you already know.

NOEL:  Sure. A long tradition of Ruby developers basically writing Java in Ruby. 

KERRI:  Exactly. And vice versa, too. As the Ruby diaspora happens, we bring Ruby-inflected programming styles to other languages like Rust or Go or Elixir. 

NOEL:  Yeah. I actually almost once had a development team very nearly want to murder me because I was doing Python and Java at the same time and brought a bunch of Python data structures to Java. They were not having it at all. Could not get it. So yeah, so this is kind of interesting to me because I’m old enough to have learned Smalltalk before I learned Ruby. So, I learned Smalltalk. Smalltalk was my first object-oriented language and I learned, I actually built a program in Smalltalk that was used by people who were not me. I did some graduate-level, like student-level programming in Smalltalk. And then came to Ruby and then came back to Smalltalk, not professionally but just to sort of explore it. And it does have the feel of like, coming back to Smalltalk after working in Ruby for a while, it is interesting to see what still seems sort of fresh and what seems sort of arcane, mostly the environment. The language itself actually still seems pretty workable. 

KERRI:  I would be curious, because I don’t have that history with it. I went from Ruby to being, I’m a hobbyist in Smalltalk. I dabble with it and write personal programs. It’s interesting to me. I feel there are some things that are more difficult to do in Smalltalk. And I always wonder like, did Smalltalk not go far enough? And how much influence Smalltalk was, what it was referring to.

NOEL:  Yeah, let me back up a half a second for people who are not familiar. Smalltalk was developed at the legendary Xerox PARC research group in the late 70s and early 80s originally. And it was notable in that it was not just a programming language but also a live environment. So, if you’re programming in Smalltalk, you’re programming in what is effectively a development environment that is also your runtime environment. So, all of the things that you’re using to – and there’s also a very elaborate and arcane set of ways for you to browse the code. You can look at the live code that’s running the system while the program’s running. And it has a number of, essentially a self-contained environment that you are both working in and executing. As a language, it’s very simple syntactically. I think it’s fair to say. Almost all of the complication is in the object-oriented library. Is that… 

KERRI:  I would agree with that. 

NOEL:  Oh, with me. So, agree so far? So, it became influential in Ruby largely because a lot of Smalltalk developers – so Smalltalk, a lot of the original agile XP development, classically the original XP project, was a Smalltalk project. And a lot of the developers who were associated with that came to Ruby fairly early in Ruby’s development and influenced some of Ruby’s development ongoing, which is one of the reasons why Ruby and Smalltalk feel so similar. So, Smalltalk was very, very viable as a professional, enterprise language even, for a long time in the 80s and early 90s. For a long time, it was very big in the aviation industry. A lot of the airline ticket systems, at least some of the airline ticket systems, were built in Smalltalk. And it became less popular I think as open source Linux systems became more popular in part, and also as thin client systems became more popular. Smalltalk’s a very all-in-one system. It does not play very well with Unix-y small pieces loosely joined kind of systems. Smalltalk is a one big piece.

KERRI:  That’s fair. 

NOEL:  Everything mixed together kind of system. And so, it doesn’t play, historically didn’t play very well with databases. It didn’t play very well with a lot of strong collaboration open source. At least it didn’t for a long time. For those reasons, it has tended to get pushed out by other languages, just in terms of environment and ecosystem, not so much the language itself, language and the language tool itself. 

KERRI:  Yeah. No, I think that’s fascinating to me especially. If I go back to the metaphor of spoken languages and how we think of English as this super successful language because it’s flexible and easy to learn and anyone can pick it up and creolize it and pidgin it. But really, English is successful because of economic forces external to the quality of the language. You can think of other languages that are exceptionally complex and they may have some amount of “success” in terms of how well do they spread and maintain themselves and how many native speakers they have. But a lot of that is determined by economic forces or social forces than is this a quality language? So, Smalltalk could, I think in part of existing in the – what influences do the economics and the externalities to the language itself? What was the environment people were trying to develop it in? The economic forces controlling IT departments and vendors and all of that sort of stuff. 

NOEL:  Right. Smalltalk was very, for a long time – now there are open source Smalltalks – for a long time there were not. And when I taught an undergraduate sophomore-level class in Smalltalk in 1997 or ‘98 or something like that, and you had to buy a license from IBM’s Object Smalltalk and it was not cheap. And it was obviously targeted at enterprise-y kind of stuff. And so yeah, so that’s an economic force that quickly all kinds of commercial programming environments had trouble about that time. And Smalltalk was definitely one of them. 

KERRI:  Yeah. I mean if Smalltalk was – obviously we can’t go back and like, it’s almost a pointless mental exercise. But what if it had been open source at the time or easily available and had played nicely with more distributed systems?

NOEL:  So rather, it quickly became open source about that time. Because there was Squeak. I don’t know if you’re familiar. I don’t know what open source, what Smalltalks you’re familiar with. Squeak is actually a really cool story because it actually was the original – a lot of the original Smalltalk team from Xerox PARC wound up at Disney kind of randomly in ‘95 or ‘96 or something. No, it was earlier than that. It was earlier than that, because eventually they kind of moved on. So, but Alan Kay I think was – I’m going to get this wrong and I’m going to say I’m going to get this wrong and we’re going to get emails. But honestly, I’m going to get this wrong and nobody’s going to know. And… 

KERRI:  Oh, don’t let the facts get in the way of a good story. 

NOEL:  I’m trying to piece the timing of this. They were working at Disney and they took the source code from the original Xerox PARC Smalltalk and basically downloaded it and embedded it in a new system that made it legally open. Like, they did something. I don’t remember exactly how they did it. But it’s Squeak because they were working at Disney at the time that they came up with it.

KERRI:  I did not know that. I didn’t realize that. 

NOEL:  And I’m going to have to fact check. I’m going to fact check all this and I’m going to put in a note at the end. All the corrections that I’m going to make from this lore. I worked with a couple of – I have met a couple of the original Smalltalk team over various times briefly. And one of them was at Apple the summer that I interned there, which was also a ridiculously long time ago. And so, that team was using Squeak. There were people there that were using Squeak Smalltalk. They took the Smalltalk source and they wrote a Smalltalk to C translator and they wrote a kernel in Smalltalk, wrote it out to C, and then compiled the C to the various operating systems that they were trying to port in. 

Because Smalltalk is – 95 to 98% of Smalltalk is written in Smalltalk, which is a very, very small bootstrapping kernel that’s not in Smalltalk. So, that was what they did. And they wrote that kernel in a very minimal subset of Smalltalk that they felt like they could compile to C. They wrote out C code, compiled the C code, and then suddenly they could relatively quickly bootstrap Squeak Smalltalk on any platform they wanted. Which they then did fairly quickly. It was available for Windows and Mac at the time. It was ported. I remember seeing a presentation where they ported it to a bare Motorola chip that had no other operating system on it. So, it was widely available. But it did not interact – it was very, very hard to get it to interact with an external relational database, for example. Which made it very hard to do web development in it. 

Okay, so I think the larger point here is that languages have utility in their moment. And then they also have influence. Like, Smalltalk has been very influential, I think it’s fair to say. 

KERRI:  Yeah. I think so. It’s always mentioned in every history of programming languages that you look at, or those infamous family history charts or the genealogy of programming languages. Smalltalk is just, it’s always right at the root of so much. Because in a lot of ways, it was – and correct me if I’m wrong – it was the first object-oriented language, right? Or it was the one certainly that cemented a lot of that. 

NOEL:  It wasn’t technically the first object-oriented language, but it was the first to get wide – there’s Simula or something from the 60s. It’s was technically object-oriented. But I think it was the first late-binding runtime language. Like it was the first language that dynamically dispatched methods at runtime, I think. If not, it was the first popular one. 

KERRI:  Right. Well, and it’s been around since the early 70s?

NOEL:  Yeah. The version that became – there was a 72, a 76, and an 80. This is among my most arcane piece of knowledge, is arcane pieces of Smalltalk history. And I’m just – this is the whole reason why I wanted to talk to you Kerri, was just an excuse for me to… 

KERRI:  No, you know, you’re on my programming bar trivia team. 

NOEL:  Yes.

KERRI:  You’re my first pick. 

NOEL:  The four people that care about the history of Smalltalk. But those people really, really care about the history of Smalltalk. So anyway, the point is that the people who programmed in Smalltalk and became expert programmers in Smalltalk came to think about programming in a certain way. As something that was very flexible, as something that did not have a compilation step. And they came to think, I think a lot of them came to think about software projects in a similar way. And those things are really influential. And I think it’s kind of interesting to me to think about how – the programming version of the Sapir-Worf hypothesis – how the programming languages you work in affect how you think about programming. So I guess, what would you say? What do you think about that? How do you think that the languages that you’ve used affect the way that you think about projects and larger systems? I’ve been talking a lot. 

KERRI:  No, I would agree entirely. And I think that’s kind of where I was going when I mentioned that did Smalltalk go far enough? In that Smalltalk develops in the context of everything else that’s happening around it. And it was a reaction to that. I’ve often said that as much as Rails, Ruby on Rails for example is a ubiquitous Ruby-based framework for developing websites, but it starts as, at least the legend is that DHH, the original author, got tired of doing the same boilerplate to build websites. So, he builds the framework to do that. So, Rails starts as a reaction to all of the pain points that he was feeling in that moment. So, it’s a product of its time. And everything that we do is kind of a reaction to the things that pain us, or are problems that we need to solve. Our forward thinking is completely shaped by the context that we bring into the situation.

NOEL:  Yeah. I think that one of the interesting things about Ruby in that context is that Ruby was created to solve a particular set of problems, too. And they were mostly problems having to do with systems administration, the kind of things that scripting languages were being used for when Matz created Ruby 20 years ago. It picked up a lot of features from Perl which was the system language of choice. I don’t remember the reason why Matz didn’t just use Perl. But I’m sure there was a reason. I would imagine. As it became used in contexts outside of that scripting language and it became used for web development and became used for other kinds of software design, other features, that brought other features to the language. It brought other ways of thinking to the language. And the people who had come of age learning Smalltalk for instance found the fact that Ruby was also a late-binding object-oriented language a very – it made it a very comfortable place for the way that they thought about software in a way that Java was not. 

KERRI:  Right. And I think, I was thinking about how that shapes it, the context of how those languages were used being very different. Like especially around systems administration. You’re thinking around servers. You’re thinking around communication between systems. Java is a compiled language and it was very much at least in my initial exposure to it in the mid to late 90s, it was all about, we’re building a big exe, a big compiled bin that you run and there’s your application. It wasn’t about piecing – that Unix-y thing of piecing these things together. So, it wants to glom in all these libraries and compile it all together.

NOEL:  I was going to say, and classically Smalltalk was used to build systems that had GUIs. So, a GUI was a very – the user interface was a very integral part of the programming environment and a very integral part of the language library. And it was never really meant for headless kind of things like server-side code, or even just – it’s a terrible language to write a quick script to manipulate text in. There’s no mechanism for doing that easily in Smalltalk. 

KERRI:  My initial exposure to Ruby was coming from Perl and PHP. And the Perl and PHP that I was writing at the time was not object-oriented. I had exposure to object-oriented and it was through Java. But I wasn’t writing my Perl that way and I wasn’t writing PHP that way. And so, my early Ruby very much was not taking advantage of objects. But I grokked what objects were and I could use them. But it wasn’t what I was writing. 

NOEL:  So, was that a question of the translating – if you had done object-oriented stuff in Java, when you came to use objects in Ruby, did you build on that knowledge from Java? Or did you come of think of objects in a completely different way?

KERRI:  I came to them through Java. So, I’m very comfortable with – we can make the jokes about factories and all that. I’m actually pretty comfortable with that because that’s my early exposure to objects, that objects aren’t – we always teach object-oriented thinking to students, especially as “Think of a car. And a car has a door.” And we’re really teaching a platonic model where objects relate to a physical thing or a concept. Whereas Java taught me to think about objects in terms of also as verbs that you can have. You can create an object out of a process. As a – I mention this in a lot of the talks that I give, this idea that all software carries around its entire lineage. And it’s not until something about this feature or bug fix or something is a problem that we actually remove it. So, software has all these weird little evolutionary adaptations that it carts around.

NOEL:  Yeah. 

KERRI:  And it’s my understanding of that, of this idea that like, “Oh, well you can encapsulate a business process as an object. You can do verbs, not just nouns,” that never hurt me. But when I came into doing more microservices and service-oriented architecture and especially event-driven architectures, that idea of being able to extract business processes as objects that I can also pass around and treat as nouns but they’re really verbs really helped me in that environment. So suddenly, I had this weird thing that I was carrying around, like the ability to roll your tongue. All of a sudden, “Oh wow. I’m in this situation where that’s actually useful.” So, it let me accomplish more than perhaps some of my peers. 

NOEL:  Yeah. I do think there’s a big moment when you learn object-oriented that you start with the idea that objects are like a reflection of items in the world. And you come to learn that objects can be used to represent abstract concepts as well, like processes and like workflows and like transactions and things like that. And that turns out to be extremely useful and also extremely hard to teach in non-contrived examples. So, it’s the sort of thing that you either we’re really bad at teaching it, which is entirely possible, or it’s just something that you have to come to by seeing it done or looking at other people’s code or experimenting on your own with different techniques. 

KERRI:  I think it gets down to the pedagogy of teaching, in some ways. We have to say things – when we’re teaching a new concept to somebody, you have to start with what they know and relate it. Because we humans communicate and understand things narratively and through metaphor. So, we teach object-oriented, as I mentioned before, this idea of like, “Okay, here’s a car. And all cars are vaguely the same, except they’re individual instances of this platonic ideal of a car.” And you can kind of go from there. But if you hear that lesson over and over again but from different perspectives but slight variations on that theme, eventually you expand the window of the possibilities of what that means. Are you familiar with – there’s something in political theory – the Overton window? 

NOEL:  Yes. But you should explain it. 

KERRI:  The Overton window being the idea that we have certain things in our political life that are verboten. We cannot speak about them. We cannot even suggest that this is a possibility. But then somebody does. And all of a sudden, now it’s okay to talk about that thing, because somebody has expanded the window of possibilities for us, of what is politically feasible. In our knowledge base we have a very similar thing where the structure of what we’ve learned before, the context of it, constrains our thinking. But as we expose ourselves to new and surprising ways of thinking about software, thinking about our languages, it can expand that window of what we find to be possible. 

NOEL:  Yeah. The aha moment.

KERRI:  Exactly. 

NOEL:  One of the things that’s specifically a challenge in object-oriented, and I also see this when I try to teach testing, is that in small examples, object-oriented programming looks like ridiculously convoluted. And you don’t really see the benefit of it unless the example has been extremely well-chosen. You don’t really see the value of it until the code is too large to be used as a teaching example. To me, that’s one of the biggest challenges when I’ve tried in the past to teach object-oriented thinking/design/programming to people, is that there’s just this – especially if you come from the concept of the best program is the simplest and the smallest. There’s a recoil from seeing a really elaborate OO system on a small problem.

KERRI:  Yeah. You can have hundreds of these little tiny objects and files floating around. And who knows what they do? But yeah, until you assemble it together, then you can’t see.

NOEL:  Until you have to change it. And then you see the value of it, hopefully. 

KERRI:  That’s one reason why for me, Ruby was such a wonderful discovery. It’s wonderfully verbose in a way, and it prioritizes that human to human communication of code where what we’re doing is we’re documenting a process in a way that a computer can take instruction from. So, compositional styles of formatting your code become very useful. Good Ruby code, you could read it aloud and it tells you more or less in understandable English what is happening. And you can begin to like, think about the metaphors and you can personify or anthropomorphize the objects and think about, “Well, this object is talking to this object who goes off and does this little thing and comes back.” You can tell the story of what’s happening, engage with it on that level. But you have to get there, though. 

NOEL:  Yeah, yeah. Python has always been talked about as executable pseudocode, which is a very similar kind of principle. 

KERRI:  I’ve heard that before. 

NOEL:  Yeah. Alright, what’s the most recent programming language that you picked up for the first time and what did you learn from it?

KERRI:  In a serious way, it was probably Go. I had worked in a little bit of C doing some string processing and it was the first time I had ever written C, which is so strange. To come to C after 20 years of being a very successful engineer, to finally work with C. And I was very excited. And honestly, it was six weeks of being frustrated that it didn’t do what I wanted it to do. 

NOEL:  C is terrible. And I have not programmed production, I have not programmed C professionally. Actually, I’ve never programmed C professionally. I only programmed C as a student. I think I edited C professionally but I’ve never generated C professionally. I mean, it’s very, very good for the various set of things, for a small set of things I guess that it does. Anyway, alright. You were talking about Go. 

KERRI:  Oh, no. So anyway, yeah. 

NOEL:  I don’t know anything about Go. I’ve never actually used it. 

KERRI:  Well, the reason I mentioned it is that I went to Go and I started a Go project for where I was working at the time. And I realized that six or seven weeks of C had fully prepared me, despite that frustration, had really prepared me to read and work with Go. But all of a sudden, the things that I disliked about C were gone. It had been kind of abstracted away. So, Go in some ways to me feels like, “What if we rewrote C but as a Ruby language?” It has some Python-isms and some Ruby-isms embedded in it, in that way that these other languages – again, it’s that Smalltalk lineage. It’s coming back now into these other languages.

NOEL:  I think that one of the things that’s really interesting to me about languages over the last few years is the extent to which there are a number of languages in the last four or five years that have come out that are basically trying to be C but better. I would classify that as Go. I would classify that as Rust. I would classify it as Swift.

KERRI:  Yup.

NOEL:  And I think that’s really interesting, that for a long time nobody really tried to do that. That the new programming languages were all scripting languages and were meant to be not trying to compete with C on speed or that kind of programming. But now, relatively recently, it seems like those kinds of things are building. I also think that Objective-C is probably the biggest Smalltalk borrow language of all time. But that’s beside the point, I suppose. So, what did you learn from Go?

KERRI:  Well, C got me to think down at a different level. It’s like moving bits around and having to think about memory addressing and claiming and releasing memory and all that kind of custodial work of the language.

NOEL:  Yeah.

KERRI:  That you have to do. I found it painful. Go has a lot of that same power, but it is more flexible and expressive. What it was I wanted to do became closer to the front of my mind in the work that I was actually doing. Whereas in C, I would often forget, “What the heck am I even trying to do?” because I’m like four files deep and I’m thinking about like, “Wait, is this a reference or a pointer?” or like, “What’s going on here?” Go put the thing that I was trying to do closer to the work that I was actually doing, in that way. Because it removed a lot of that little rabbit holes you’d have to go down in C. 

So, doing that and then coming back to Ruby and how much, “Oh, now I understand much more of what is really happening with a lambda, or when you’re passing something by reference,” or all these sort of CS foundational conceptual bits that you can kind of gloss over, quite frankly. Because that’s just the way Ruby does it, blah, blah, blah. But being able to see more intrinsically some of the more esoteric bits of Ruby that a lot of people avoid – procs and lambdas, working with threads and thinking about what’s actually happening in the memory stack – that became much more clear to me when I had to move down these levels. And then Go became the place where those two ideas are synthesized together. Where all of the painful parts of C, working at that particular level of abstraction, combined with the more friendly user-friendly stuff I was bringing in from Ruby and other scripting languages, melds it together to give me a much richer sense of what’s happening here, under the hood. 

NOEL:  Did it change the way you wrote Ruby? 

KERRI:  Oh, completely. Absolutely. It demystified a lot of that lower-level stuff. So, thinking around what is the importance of thinking about cycles of processing. What is faster? What is cheaper for memory? What is more efficient? And balancing that more appropriately against clarity

NOEL:  Yeah. I have not picked up Go. The most recent language I’ve picked up, I tried to pick up in any kind of serious way, was Elm. Which was very interesting. And I feel like it crystalized a lot of things about functional languages that I had kind of dismissed, partially because the functional languages I had worked in did not really necessarily make those advantages super clear. But it was interesting to me to come to a – so Elm is a functional, very strictly typed language that is a frontend language that compiles to JavaScript. 

One of the things I got out of it was that it was the first functional programming language that I’d used, pure functional programming language that I’d used in quite a while that I’d actually been able to get something done in, which was very exciting. And I feel like I learned a lot about how strong typing and functional programming go together to change the way that you structure a program. Because if you’re coming from an object-oriented program and you’re coming to a functional program, the relationship between the data and the code is completely different. And if you don’t understand that, and I don’t know that I completely do, then the functional program’s going to be terrible. The first couple of Elm things that I did were terrible because I was trying to emulate the Ruby constructs that I was comfortable with. 

KERRI:  I had almost the exact same experience trying to learn Clojure a number of years ago where it was everyone’s excited about it. People were doing interesting things with it. It didn’t click for me. It doesn’t resonate with me the same way, because why doesn’t it do what I wanted it to do? Why can’t I express the things? I don’t have the right grammar. I don’t have the right syntax.

NOEL:  I have a very strange relationship with Clojure and I can’t completely explain this, because I wrote – another thing that I did when I was a student was I spent some time writing Lisp. I wrote some relatively good-sized stuff in Common Lisp. And at that time, there was an exceptionally good Common Lisp environment that produced native Mac programs. So, you could actually write native Mac GUIs in Lisp. And I wrote a terribly structured program that was half objects and half not in Lisp. So, I had some comfort with Lisp. And for some reason, Clojure, which is like 90% overlap with Common Lisp, I just could not – it kept bouncing off my skull. The differences, the things that made it different, it just made it look weird to me. And my brain in some way refused to learn things that are different between Clojure and standard Lisps. And I can’t explain why at all, except that there was something about setting up the environment or having the parentheses and square brackets interspaced that my brain just recoiled from. I just can’t explain it. 

KERRI:  That’s like me and Haskell. Somebody – there’s a developer in the pacific northwest area who’s very into Haskell and who I’m friends with. And he’s tried to explain Haskell to me two or three times. And I get it. I get it. He explains it to me. And then we just get to this one point and I’m just like, “You lost me.” Like I just, there’s something about this one conceptual leap, this one – the implications of how Haskell does something requires so much more context or understanding or you’re not going to get this point until another two chapters forward. It’s similar to the book ‘The Silmarillion’ by Tolkien. I’ve tried to read it three or four times. I’m a huge Middle Earth nerd. I tried to read this book and it’s around page 54. And I know it’s page 54 because my bookmark is always in the same spot. And I’m like, “I’m with you,” and then there’s one section where it’s like, “Nope. I’m done. I can’t read this anymore.”

NOEL:  Okay, so alright. Many, many things. I have never, I haven’t seriously tried to learn Haskell but Elm has been described as like a less academic Haskell and it might be a way in. It has a lot of similar – the Elm compiler is actually written in Haskell. But Elm is somewhat simpler, I think. But I also probably, I would – I tried ‘The Silmarillion’. It’s been a long time since I tried it. But I would be willing to bet that I noped out at about the same.

KERRI:  People who really, really enjoy it always say like, “Oh, well you’re reading that first part. Yeah, that’s horrible.” And I’m like, “Well.” [Laughs] “Is it important? Do I need to know this stuff?” And it’s this whole list of like the elvish gods and who begat who. It’s the Genesis of the Tolkien...

NOEL:  So, what we’ve come to is ‘The Silmarillion’ of programming languages. 

KERRI:  For me, anyway. Yeah.

NOEL:  Yeah. And Ruby is ‘The Hobbit’ of programming languages.

KERRI:  Oh, somewhere in there, I did actually think of what I got when I came back to Ruby from Go. 

NOEL:  Okay. 

KERRI:  A really good example was I understood types. Like, I know what types are. I know what type-safe languages are. I know why they’re there and they’re good. But I had written enough Go that I came to rely on types. And I suddenly got very leery about Ruby and it doesn’t have types. 

NOEL:  You know, I actually – again, my Elm experience was similar in the sense that Elm is very strongly typed. And so, the compiler does not let you do all kinds of things that you otherwise want to do, including the compiler does not let you, if you have a case statement, the compiler requires that all possible outcomes are covered.

KERRI:  Interesting. 

NOEL:  And it did make coming back to – and I’ve programmed in Ruby for a long time. And I very rarely have the kinds of problems in Ruby that type safety will protect you against, although interestingly enough I did have one today where a multiplication was happening on a string instead of an integer. Anyway, but I came back to Ruby and it felt unsafe again for a little bit. I don’t know that the way that I programmed Ruby necessarily changed a lot. But I did have this – I had kind of lost the reflex of understanding how to keep things safe in Ruby. 

KERRI:  I think it emphasized Liskov Substitution for me, more than – which I will explain. Liskov Substitution Principle, it’s the L in SOLID. And it’s the idea that a subclass of an object should be replaceable for its parent. But it’s that idea, that if you don’t know – you don’t have to know the type of an object. You just kind of have to know what it can do, in a way. And people I’ve talked to have spoken to this idea in Ruby around not inquiring what is the class of an object, but what methods does the object respond to? What is this object capable of doing? That pushed me down the path of looking at null object patterns, the idea of if you try to fetch a user object from the database and you don’t find that user, instead of returning just a nil primitive object, why don’t you return a null user object that responds to all of the methods that a regular user object would. It just, if you inquire about its name, it says, “I don’t have a name. Nil.” But you don’t… 

NOEL:  I’ll put in the show notes a really good Sandi Metz talk on that, on null objects. 

KERRI:  Totally. Avdi Grimm first exposed me to null object pattern, but Sandi’s a great resource for that as well. 

NOEL:  Yeah, sorry. So you were going on at null objects.

KERRI:  I started taking advantage of this pattern in Ruby. I wouldn’t say it’s an obscure pattern, but it’s not one you see very often in Ruby.

NOEL:  Yeah. Usually you have to explain it to somebody if you’re using it in Ruby. It’s not idiomatic the way that using a module as a mixin would be idiomatic in Ruby. 

KERRI:  Yeah, yeah. For sure. But I got that from Go. I got that because, “Oh, I actually like types.” I understand as a programmer I can trust there’s this thing. And so, there was a couple of weeks where Ruby felt unsafe. And I start littering more guard statements into my methods where I’m like, “Okay, well I’ll make sure I’ve got all this stuff.” Where really, what I needed to do was to think more upstream about where things were coming in and what objects – how was I working with these objects?

NOEL:  Right. 

KERRI:  So, that has really restructured what I do.

NOEL:  Yeah. Programmers who are new to Ruby have a tendency to write more guard statements, I think, than they will come to. I also think programmers who are new to Ruby tend to go a little bit crazy with leaving off parentheses for a while. But that’s separate. Some people never recover from that. 

KERRI:  Well, whenever I encounter something new like that, like a new way of thinking about code like, “Let’s leave off all the parentheses,” I actually will try to embrace it for two to three weeks. And all of my – I actually did that with the parentheses-less style for a while where I just, I’m not going to use them. And so I very quickly over the course of two or three weeks really learned what benefits there were and also, what the pain points were. So, I was able to make, actually have a more informed decision about whether that was good or not. 

NOEL:  Yeah. One of the things that I talk about when I teach object-oriented, and I teach a very aggressive OO style, is that you don’t learn the boundaries of a technique until you overuse it. And you can’t tell where something’s applicable until you tried it in a bunch of situations and see that it’s not. And that goes for parentheses and it goes for semicolons, I suppose. And it also goes for OO. Eventually, if you start thinking of everything and creating small objects, you will go, “Oh, I have finally found the point where there are too many objects.” 

KERRI:  My latest adventure on that has been Ruby’s singleton library. For a while, I was making everything singletons. I’m like, “Oh, I have to write a wrapper for an API. Well, that sounds like a singleton. Let’s do that.” And I quickly learned a lot of pain points with Singletons.

NOEL:  Yeah. There’s a reason why everybody doesn’t do that all the time. There are two Ruby techniques that I oscillate between I never use it and then I use it all the time until I find the pain point. And I never seem to get to the equilibrium. And one of them is using doubles -- mocks -- in testing. And the other one is simple delegator in Ruby. And in both of them, I will go through phases where I like overuse them and find the pain point and then I will back off way too far and come back. And I never seem to find the medium point where I’m using either of those techniques the right amount.

KERRI:  Let me ask you this: do you feel that the pain points come from the implementation in Ruby particularly? Or from… 

NOEL:  Of simple delegator?

KERRI:  Yes. Or is it the pattern/concept of simple delegator?

NOEL:  That’s a very good question. I would say more the pattern. That I get in a habit – so, the general use case of using a delegator here, at least the way I use it, is one of several techniques that I use to split complexity that’s all sort of related. So, I’ll have a user and I’ll have a bunch of functionality for the user that’s only used in one place. So, I’ll write a billing user or something and it’ll be a simple delegator to user. And simple delegator is great there because it’s – as opposed to – it’s great, it’s very easy. You don’t have to explicitly expose any part of the underlying object. And then I realized that sometimes there’s a reason why you might want to have to explicitly expose or not expose parts of the underlying object. 

But do things until they become annoying is a really good learning tool. I do that up and down. I’ll do that with techniques. I’ll do that with – like, I’ll try Visual Studio Code for a couple of weeks until it becomes annoying. So, yeah. 

KERRI:  I had a coworker who loves the RubyMine IDE. Now, I don’t know if that’s even in existence. 

NOEL:  It is, yeah.

KERRI:  But he loves it. And so, I was like, “Okay, Chris. I will try it.” And so, I gave it a try for two or three weeks. And I was like, “Okay. I can see the benefits here.” It didn’t suit me particularly. But it was just like a practice in humbleness I guess, and empathy, where I’m like, “Hey. You have a preference for this thing or you’re excited about this,” whether it’s a language or an IDE or a pattern or whatever. I have enough respect for other people to say like, “You have valid experiences and opinions and I’m curious. I want to learn more about, how have you formed that and what has gone into your understanding there?”

NOEL:  Yeah. I often, I will often try to pick up techniques that I hear other people doing, that I hear other people being excited about for a while. On a long-term codebase, that tends to lead to a certain amount of like, “Well, I must have written this two years ago, because that was when I liked form objects.” But overall, it’s generally, it’s a good strategy to try things. 

KERRI:  Yeah, definitely. Yeah, I dabbled with the DCI pattern, which is injecting contextual methods into objects, cellular-based views, all sorts of these ideas that people have. We have to try them.

NOEL:  Right. Because otherwise, how do you know? Yeah. Yeah, because sometimes they stick. Some things stick.

KERRI:  Yeah. James Edward Gray a few years ago in one of his talks said something along the lines of like how we just happen to hit the language jackpot by picking up Ruby at the perfect time. 

NOEL:  Yeah.

KERRI:  And like, who knows why? You can’t look ahead and decide, as a student, what do I need to learn today that’s going to be really popular in five years or whatever? You can make some guesses. But you really, you never know. And similarly, with the things that are inside of languages, you just don’t know. You have to try them out and see how they work.

NOEL:  Kerri, where can people reach you online if they want to talk about this more?

KERRI:  Well, I’m Kerrizor pretty much everywhere online, especially Twitter. And you can also, I have a blog that I don’t write as much as I used to at kerrizor.com.

NOEL:  Great. Well, thank for being a part of this conversation. And we’ll see everybody else in a couple of weeks.