Functional Geekery Episode 41 [PODCAST]
From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
We talk about teaching ideas around functional programming, digging down into finding the motivations of why someone should care enough to want to learn something, and we end with some tips to keep in mind when teaching.
**Steven Proctor**: [00:01] Proctor here with some conference announcements before we get into this week's episode.
[00:04] First, Compose conference will be taking place Thursday, February 4th, and Friday, February 5th, in New York City. Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. To find out more and to register, visit www.composeconference.org.
[00:21] On February 18th and 19th, in Krakow, Poland, Lambda Days will be taking place, and registration is now open. Visit lambdadays.org to find out more or to register, and make sure to use code funkygeekz4dwin. That's F-U-N-K-Y-G-E-E-K-Z-4-D-W-I-N, for 10 percent off registration.
[00:44] Right after that, on February 20th, :clojureD will be taking place in Berlin. :clojureD is an independent, non-profit conference from the Clojure community, for the Clojure community.
[00:54] Focus points will be interesting developments and ideas in the global Clojure community, as well as introductory level talks highlighting the fun aspects of learning and messing with Clojure. Visit www.clojured.de to find out more.
[01:09] ElixirDaze will be taking place March 4th, in St. Augustine, obviously, in Florida. ElixirDaze is a one day conference with a nearly full day of talks, and helping hack session to close it out. The CFP is open through January 15th, and early bird registration is open as well. Visit elixirdaze.com. That's elixirD-A-Z-E.com to find out more.
[01:29] ErlangFactory, San Francisco, will be taking place on the 10th and 11th March, with training on the 7th through 9th March, and the 14th through 16th March. Tickets to the conference are available now. Visit www.erlang-factory.com/sfbay2016, to register and to find out more.
[01:50] LambdaConf 2016, will be taking place May 26th through the 29th, in Boulder, Colorado. The call for proposals is now open and will close on January 15th. Visit lambdaconf.us to keep an eye out for updates.
[02:04] If you know of any other conferences around functional programming, email firstname.lastname@example.org and I will be happy to announce them.
[02:12] Lastly, if you are enjoying "Functional Geekery," please help spread the word. If you would leave a rating and/or review on iTunes, or your favorite podcast directory, or even share your favorite episodes on social media. I need your help to spread the word about Functional Geekery.
[02:25] If there are any guests or topics that you want to hear from or about, please reach out and email email@example.com and I'll put them on my notes for future episode ideas.
[02:34] Thank you for listening and for all your support.
**Proctor**: [02:38] Welcome to Functional Geekery. I'm your host, Proctor. This week with us, we have Eric Normand. Eric, you've been on before, but would you mind giving everyone a little bit of background about yourself for those who didn't catch the previous episode?
**Eric Normand**: [02:51] My name is Eric. I help programmers become Clojure professionals. I have a website called lispcast.com where I write articles. I run the "Clojure Gazette," which is a weekly Clojure newsletter. I also run PurelyFunctional.tv where you can learn Clojure and, hopefully soon, more functional languages.
**Proctor**: [03:15] The previous episode we had you on was episode 18. If anybody wants to go and listen to that episode as well, that's the episode we're going to be, probably, referring back to when we make mention to some of the stuff you've been doing.
[03:28] Since that episode, previously you were doing PurelyFunctional.tv as individual videos, or video series. You were just getting into core.async around that time. That was coming out. You were working on that.
[03:42] In the time since, which has been about a year, was, you started making the move to more of a fast feedback, more frequent videos, smaller segments, to be able to help address people's real questions instead of making a big video upfront, and then hoping the feedback was receptive.
[04:01] Do you want to go in and elaborate, in your opinion, as to what you were doing, the driver of that, and how you found some of that feedback coming from the videos that you've been making now?
**Eric**: [04:15] When I was last on I was in the middle of making core.async, I think right at the end. The course was really well received. It was really high quality. I taught what I wanted to teach. It just took too long. I'm trying to build this into a real, sustainable business.
[04:39] For the number of customers I got, based on the size of the market and everything, people who want to learn Clojure, it's not that big. I just couldn't do it. I think it took six to nine months to make that course.
[04:58] It came out in November. I spent the end of November and December trying to find a better way to make the courses so that they wouldn't take as much time, but would keep the same quality. I released two more courses in that new format with the new process, but they still took a while. The fastest one took three months to make. It was still too long.
[05:30] While I was making the last one, I realized that I wasn't ever going to be able to make these big courses work that way. The real problem is that while they don't take that many hours to make, it's enough hours that it starts getting spread out in my free time over weeks and months and I can't just keep it all in my head all the time.
[05:54] Then, there's all these overhead about taking notes where I left off and figuring out where I left off when I start again. I was talking to some friends about this issue and they started talking about all these subscription services that they either knew about or they subscribe to, like RubyTapas or Elixir Sips.
[06:14] They're talking about how great they were, and so I started reaching out to the people who created those. They said that they were working well. After talking to my friends, I actually ran home and gave it a shot. I was like, "How long would it take to make a 10- to 15-minute video that was on a single small topic?" 10 to 15 minutes, you don't have a lot of time, so it gets to be really focused.
[06:49] The first time I did it, it actually took about two hours. Two hours — I have a kid, I have a full-time job — two hours is like the maximum time that I can find consecutive to be able to work on these things. I thought, I could do this once a week. I can make one of these 10-to-15-minute videos every week.
[07:13] Basically, I started realizing, "Wow, this is perfect because it's small enough that I can start talking about topics that maybe wouldn't have fit into a bigger course." With a bigger course, you have this big goal of, for instance, being able to write a whole Web server after a few hours of study, a few hours of practice. That's a big topic.
[07:39] You don't want to go on a tangent about some detail of the HTTP API or something. I try to make a beeline and I have to leave all these topics aside, but I could talk about one of those things in a 10-to-15-minute thing. All of a sudden, it just exploded with all of the things I could talk about and teach. Once I wrapped up the last course, I decided to make that change.
[08:07] It opened up less than two months ago and it's had a big reception. It's not big enough, I want more customers, [laughs] but it's a good start. I've been super excited because I feel like I've hit a nerve. People email me saying, "Oh, I've been wanting something like this. This is great," and so I'm really happy with it.
**Proctor**: [08:30] You started with the short topic and did the experiment. I remember hearing you...I don't know if it was "Thoughtbot" when you on it recently or the "Ruby Rogues" episode you were on recently, but part of that was looking for the faster feedback and making sure you're actually addressing people's needs versus coming up with the course.
[08:52] Did you find you got a lot of good reception about the structure of that 10- to 15-minute episode when you put it out there, and, in the past few months of doing this, that you've been able to quickly fine-tune and hone some of the way you've been presenting this and figuring out if you're too niche for this 15 minutes, or you're too broad and you needed to niche down more on these topics?
**Eric**: [09:16] That's a really good question. Like I said, I've been doing it less than two months now, but I have found that, basically...Let me give the background. If I was doing a course and it took nine months, no one saw any of the material as it was coming out. At most I might have talked about where it's at in an email to my email list or something like that.
[09:43] When it came out finally, people would have questions and it was too late. I had spent all this time putting it together. I can't just go back and fill it in. I would answer the question in an email or something, but the course was what it was. With this, I have been getting questions like, "Oh, can you talk about this, too," or, "Can you go deeper into this?"
[10:08] That is something that I really cherish because, as a teacher, it's hard to know whether what you're saying is making sense without that feedback. Yeah, I've really appreciated that.
**Proctor**: [10:21] You found this 10- to 15-minute episode is also the sweet spot for you as well as to what kind of topics and comfort or ability you can get. I know there's people who do the longer form, as you've mentioned, then they do a little bit, or the 20 to 30 minutes, and you're doing a 10 to 15. Then there's some that do the 5-minute ones.
[10:43] Have you found that the 15-minute is your sweet spot for getting to cover the stuff that you're wanting to cover while not spending too much time and going broad, and actually being able to give the appropriate level of detail for this, from the teaching perspective?
**Eric**: [10:58] Yeah, so far. I'm a big believer that, when you're teaching something, you can always break it down further. This is going to sound mean, but you can never underestimate the level that you should be teaching at.
[11:15] It doesn't really mean that your audience is dumb and they need everything explained to them. What it means is, as someone who's been doing this for 10 years, it's so easy to forget that this might be new to somebody. You just have to remind yourself, "Yes, going over this very basic idea is beneficial to somebody."
[11:40] Obviously, not all of my audience is at the same level. That's a challenge in itself. Those two things, being able to break everything down further and also being able to talk about these more fundamental and basic building blocks of functional programming, yeah, I find that 10 to 15 minutes is perfect.
**Proctor**: [12:04] That's where I was getting at, was more the as you start breaking it down, as you start exposing the ideas to people who may not have that knowledge base for whatever it is.
[12:14] Whether they're purely new to functional programming or just new to Clojure in and of itself, is saying, "OK, I can probably go off in the weeds for a good while just talking about the difference between thinking in a for loop, and thinking in an each, and building up the map, and reduce, and everything on top of that."
[12:36] Finding that balance of, "I'm giving you information that's applicable," while still having enough time to go down and actually target that versus split that out and to say, "Look, here's a whole episode of understanding how reduce is built out of an each, and getting that stuff, and getting away from a for loop," or something like that.
[12:56] I know you've also done articles about reduce and how you're going to do a whole bunch of stuff on top of a reduce that you might not even think about when you look at the basic pattern because it's just a fold, but then it's like, "Well, if I don't understand, really, reduce and how reduce is working..."
[13:12] Going to down into the weeds at that level and striking that balance between just digging down deeper for people who don't have that experience and it's brand new to them versus addressing those ideas at a higher level and saying, "Fine, you have reduce, but here's how you push reduce further to its limits."
**Eric**: [13:31] The thing that that makes me think about is my process. I always find that the first time I teach something...Someone asks me question in a conversation, face to face, I just am terrible at it the first time. I stumble, and I don't know the best way to explain it.
[13:53] It's not until I do want to throw it away that I realize that there's something there that I'm trying to get at, and I'm not just hitting it, I'm not getting to the meat of it. That 10 to 15 minutes is backed by maybe another half hour of bad attempts. I just did something over the weekend, recording three videos, actually — map, filter, and reduce.
[14:28] We can talk about this later, but I feel like they're the backbone of good functional programming. I did a couple of tries. I was just like, "I'm just talking about map. Why would someone want to hear this? Why would someone want to learn this?"
[14:44] I went through an intro, and I just wound up throwing away all of that and trying to find some real-world hook into an instant understanding of when you would use map, why is map important. Eventually, I found it. It just requires that exploration. Once I did it for map, I was like, "Oh, filter. I can do the same, right? Filter's easy."
[15:12] Reduce was a challenge. I wound up pacing around the house, talking to myself. "What is reduce? Why is it so hard? How do I make the name, reduce, stick?" Eventually, I found some art that I had done and that my daughter had done. I was like, "This is it. It's art. It's a collage. Reduce is..." Well, I'll give it away.
[15:36] Reduce, the name, is terrible. To me it either sounds like you're taking a stock, a broth, and you're reducing it down to some really thick essence of it because you're boiling all the water away. That's not really what you're doing in functional programming, or you reduce something, you make it smaller, and that not what's happening either.
[15:57] It's more like you're assembling. You're taking a bunch of parts and you're combining them with some base. The example I give in the video is my daughter made some macaroni art. You have three parts of a reduce. You have the action, the function you're calling on it, which is glue. You have the initial starting value, which, in this case, was piece of cardstock.
[16:29] Then, a collection. In this case, it's a collection of macaroni. She went through one piece of macaroni at a time, calling that action, glue, onto the initial value. At the end, she had a piece of macaroni art.
[16:48] It's things like that that I'm really searching for. Something visual because it's a video, but also because people can imagine it. Any other explanation of reduce is just going to be boring. It's not going to stimulate that real understanding so that you can start using it.
[17:07] The cool thing is, once you have something like that, you can write it on the...I have a whiteboard, so I write it on the whiteboard in Clojure syntax and say, "Look, reduce — glue, cardboard, macaroni." It's all there. Now you can start saying, "OK, well, what if we wanted to do something in the computer?"
[17:27] Well, we're just going to sum up some numbers, so it's reduce. The action is plus. The initial value is zero, and you have a collection of numbers. You can start with something real world that people can relate to.
**Proctor**: [17:43] It's one of those things that I found when I try and write my blogs. At least, two steps for me for understanding is — just to flash back to our previous conversation — was, I asked how you get so many ideas for being pervasive when you have a bunch of articles and blogs, and you said, "Look at the standard library and you'll have an endless source of things to talk about."
**Proctor**: [18:04] Right.
**Eric**: [18:05] I started taking and applying that, but I did notice that was one of the things of, "Well, if I'm trained to understand this for me..." At the beginning it was still very much, "This is just me trying to understand how this works," but there was no "Why?" There was no, "Why is this useful," or, "Why is this important.
[18:22] As I started going on, it's trying to figure out that understanding of the why and why this is valuable, especially when bringing it to other co-workers. Some of these ideas of whatever language it is and just bringing these functional concepts is, "Why do we want to do some of these operations versus a for loop?
[18:57] That's one of the things, as you're talking about, is just figuring out, "What is the motivation? Why is this valuable? What is the motivation here that makes someone want to pipe up and say, 'Oh, yeah. That does seem useful. I get it now.'"
**Eric**: [19:12] Yeah, that's something I've been thinking about a lot, for obvious reasons. I know someone who learned programming in an object-oriented way. She's actually really good, but the leap to functional is fraught with a lot of these questions. Why should I just have some data that I'm reducing over?
[19:39] It's a huge abstraction leap to go from a well-named object-oriented method, let's say a class with a bunch of well-named methods on it, and being sure, "OK. I know what this is doing because it's got a good name," to abstracting to another level where you're calling reduce with first on a list of lists that represents something in your domain.
[20:11] It's a huge leap to go to that next level. Why would you want to do that? The best answer I can give...Well, it's actually two answers. These are the two best ones so far. I don't really have a better answer.
[20:28] If you just go through the code and you count the number of temporary variables you need or the number of mutations you need, you'll start to see that, when you're using for loops or something, you need a counter variable or you at least need the variable because some languages have for loops that can operate over a list.
[20:52] You at least need that variable that holds the current value. You're going to have some mutation in there because you need to get the value out of that loop. You need to have the initial value. It's stored somewhere and you're going to be mutating that thing.
[21:08] If you count those things and you say...It's not bad in itself, but once they start getting more of them, you start to see, "Wow! This is a lot of state I'm keeping around and changing." You can see a pattern there that this is only going to grow.
[21:27] If you count, in a functional program where that same loop might've been just a map or that loop was just a filter or reduce, you notice, "Wow! I didn't need to have a variable that I initialize." If those things are bad in any way, you're reducing them to a minimum.
[21:50] The other answer is that for loops don't compose well. Meaning, if you're going to compose them, it's like a bespoke loop now. Filter, and map, and reduce, they compose really well. You can chain maps together. You can put filters in between. You can have a reduce at the end that operates on the result of that whole chain.
[22:15] You can't really do that with a bunch of mutable state with local variables. To say they compose well I know is another big leap. I've written programs in Clojure that, when I talk about it, people are, "Well, how did you even do that in a week in Clojure?" The answer is always, "Because it's composable. I didn't have to write that much."
[22:44] Once you get the basic abstraction and data modeling down, it's just composing stuff that already exists. Whereas in an object-oriented...I don't mean to pick on them, object-oriented languages, but in an object-oriented style the data modeling takes a long time because you have to make a new class for each little thing.
[23:05] Then you need accessor methods. Now you've made one class. Now you have to make another class and another class. They don't compose well because often we'll have to copy method from one class to another because you wanted to have the same operation available on that class. Whereas, if you had used a map, the operation would work on both.
[23:28] You have a lot more reuse, a lot more composability of existing stuff. You can operate more quickly and more safely.
**Proctor**: [23:39] That composability is something that I've found and didn't discover I was trying to do until later. I read, I believe it's Joel Spolsky, one of his articles about some of the ideas you get from learning other languages where you've got patterns.
[23:59] If you're in a more procedural or O-O world of a for loop, is that you've got that filter pattern, but you may not recognize it because you got your for I equals zero to length of a ray if I is this thing. Then I need to continue, or break, or whatever and then you've got your other stuff.
[24:21] You start to break out the parts and say, "OK. Maybe there's just the part of the for loop." I get this is going to suffer performance if this is a long list because we're iterating over this item multiple times in an O-O or procedural world, but we'll hit that problem when we hit that problem and not optimize prematurely.
[24:42] I've got my for loop which does the filtering. Then I've got my for loop which does some other processing and starting to refactor out the internals of the for loop a little bit cleaner.
[24:53] Then, once I started looking at SICP and some of these others and actually seeing that there were actual patterns around that behavior that I started to appreciate that composability and say, "Look, there are patterns here but, you know what?
"[25:06] Some of these languages you can't actually get to take advantage of these patterns because they don't support some of the features that are needed like lambdas and functions as first-class citizens."
**Eric**: [25:18] Right. There's also in some languages...I'm going pick on it because it's OK to pick on Java. Java has a lot of good features, but one of the things that happens in Java is abstracting something in Java makes it take more code. In a good language, for abstraction, you would be able to make it take less code.
[25:44] Once you have an abstraction, if it's a good abstraction, you can reuse it. In Java it just makes it so hard. You mention for loop as, "Maybe it's a filter. Why don't we just write filter if we're using the same pattern everywhere?" Well, if you wanted to do that in Java, you would probably have to make a filter class.
[26:08] Then you would need some way of representing the body of that filter, which would be like a lambda, I guess you could do, in Java 8 or you could sub-class it. You need another class every time you call it. The thing is that the whole language is telling you, basically, "Don't do this. It's shorter to just write a for loop."
[26:32] You don't ever get to the point where you're abstracting the important stuff. You just write the same for loop over and over. I think that's one of the things that people like about Ruby. I don't know Ruby myself, but I know that doing what they call meta-programming is really common. I don't know. I would like to learn Ruby one day and see what that's all about.
[26:58] I guess what I'm trying to say is it's not object-oriented programming in general. It's the things the language makes easy or hard and, then, the tendencies of the community. I think that that's a big part of it, too.
[27:10] For instance, what would a programmer in the community say if they saw my filter class? What would they say if I started abstracting stuff that wasn't part of the domain, but it was part of programming itself? I have a post on my site about...There's this classic problem that is given in Computer Science classes to talk about data modeling.
[27:38] It's about you have a school, and you have different classes and different students. You need a many-to-many relationship basically, because each student has multiple classes that they're taking and each class has multiple students. How do you it? You have this method where you're saying, "Register." Where do you put that method? Does it go on the student?
[28:01] Then, the class has to know that you've registered so it has to call a method back. You're trying to, basically, represent this relationship as pointers going back and forth between the class and the student, and they have to be set correctly.
[28:18] I think that that's a proper object-oriented way to model it, but I think it's wrong. You shouldn't be worried about your two domain nouns, your class and your student. What you should be worried about is the use case of why do students have to register for classes and stuff. Well, how does it work in the real world?
[28:40] You have a book. The book has a page for every class. It lists the students that have registered for the class. You look up the class that you want to register for. You write your name in the book. That's how it used to work before computers. You're not pointing at stuff. You just have an identifier, your student number. The class has an identifier. There's this table where everything is there.
[29:07] It's a purely data-oriented thing. It always was before people started modeling it incorrectly. What you're really modeling is a many-to-many relationship. That book can represent any many-to-many relationships. It's actually an abstraction away from the specific example, the specific domain. It can represent any many-to-many relationship.
[29:32] My first instinct as a functional programmer in an object-oriented world, I would want to make a class called many-to-many, [laughs] or something like that, that took identifiers for students and identifiers for classes, and made a little table that showed their relationship. Not try to model it in terms of pointers.
[29:54] Wow, now we're off in the weeds of object-oriented versus functional. That's an example of the kind of thing, to come back to the topic. That's a big leap if you're not used to functional programming. "Why would I use this abstraction? Why would I use map and reduce instead of a for loop?"
[30:12] Well, why would you use a new class that represents that relationship instead of just pointing to each other and maintaining those pointers correctly? I think it's a cleaner abstraction to just put them in their own class.
**Proctor**: [30:28] With some of these teaching things and talking about bringing some of these ideas of functional programming to people who might not be exposed to them, might have a pure procedural background or more O-O background, whether it's procedural O-O or the stronger O-O that was preached originally when the term was defined.
[30:49] You've mentioned you were doing pairing as well with people, and remote pairing on top of that. You've got to be able to pick up and bring these ideas to others and help, at least, enlighten them that there are other ways of doing it.
[31:02] How do you do that without coming across as the person who smugly sits in their tower preaching functional programming, or the smugless weenie, or whatever it is that says, "Oh, you're just being a jerk because you think your way is better than mine"? How do you just educate and inform without saying, "Look, there's many ways to do this"?
[31:25] In this case, this way made by some other trade-offs. This other way made by these trade-offs. How do you bring those ideas to people who may be exposed and may not even get it the first time, especially if you're doing this with your teammates when you're having to pair and you notice that they're struggling?
**Eric**: [31:43] Wow. There's a lot to that. The first thing I want to say is I try not to sell functional programming in my courses. Functional programming or Clojure, but that means something specific because there's a lot of levels of my selling and marketing stuff. In the course, I assume you want to learn the thing, that you are motivated and that you want to learn it.
[32:09] You paid money for this. Let's just get started. The same goes for the marketing copy. If I'm teaching core.async, I'm not really selling you on core.async. I'm selling you on what you can do with it and how I can teach you that, but then I do have a lot of articles that will talk about the benefits of core.async. Those are, in marketing, called the first touch.
[32:41] The first time I have an effect on you, maybe you just saw one of my blog posts about core.async and you're intrigued. Then the next time you're like, "Well, I think I might want to learn this thing." Then you read the sales copy and it tells you about how this is going to teach it to you. Then, when you're finally in the course, you get to learn it.
[33:03] That's one thing from my business side. When there's people that are curious and I'm pairing with them, I don't have a good answer for how not to come off as a functional weenie. I think the thing that I do, which I don't know if that's great, is I like to separate out the two roles of pairing — one person is driving, the other person is navigating.
[33:36] The driver is determining the style and the approach to the problem. The navigator is only there to help. If you're pairing with me and I'm driving, I'll take input from my navigator and everything, but, in the end, I'm the one deciding if there should be a for loop, or a filter, or whatever.
[33:58] The same goes the other way. If the person likes for loops better, then that's what they get. I'm not going to try to discuss style and stuff in a pairing session. There is something that I heard in the question that maybe wasn't directly there, and that there are people who want to learn functional programming. That's not a question.
[34:20] They want to learn it, but they just don't know where to start. I've had a lot of people email me and they say stuff like, "How do I get a functional mindset? I've been learning object-oriented programming for years. I'm a good programmer, but I just can't figure out where to begin to get a functional mindset."
[34:40] I think that it took me a while to figure out what to say to them. First of all, it's just a stranger out of the blue asking me a question. I don't know what their level is. I don't know what their previous experience is. It's hard to just say, "This is what you do."
[34:57] After pairing with people, it goes back to this. You can't underestimate your audience's level. I was assuming that they knew a lot more about functional programming than they did. They really just needed the basics. They just needed to focus on doing stuff immutably — avoid mutation, minimize mutation.
[35:22] They needed to think about using the three main functional tools — the map, the filter, the reduce — and really knowing when to use them, and what you could do with each one. Even as simple as, "What is the return type of map?" They can't answer and I'm like, "Well, you're asking about functional mindset, you need to just learn these things. These are the basic tools."
[35:47] Of course, I say it like I was surprised. That's why I said it that way. Then I realized, "Oh yeah, there's nothing out there that teaches this." Even the classics of functional programming, they don't break it down into, "Look, start with these. Use them for three months and then come back and see what you think about them and whether you want to use for loops anymore."
[36:14] There's just no one out there drilling home the basics of functional programming. I think that's my thing for the moment, making sure that these basics are being driven home just through repetition and different examples, and trying to get people to develop the habit to, whenever they face a problem and they're stuck, just think, "Wait, can I use a map? Can I use a filter? Can I use a reduce?"
[36:42] If I was interviewing someone for a job, and they said they were a functional programmer, but then they didn't know map, filter and reduce, I would seriously doubt that they were telling the truth. It's the kind of thing that is so fundamental. If you can't use them, it's similar to if you don't know how to make your own class in an object-oriented language.
[37:09] Really? That's basically what you do. A map, filter and reduce are that basic. They're that fundamental that you need to know them. Also, it's way easier to forgive someone who maybe rewrote the function in core that, in a standard library, that they didn't know existed and they rewrote it. I've done that a lot of times. They rewrote it as a reduce.
[37:34] That's fine. They know what they're doing. They just didn't realize that this function already existed. Really, if you, the audience, if you're thinking, "How do I train the functional mindset? How do I change from object-oriented to functional?" just start asking, "Can I use a map here? Can I use a filter here? Can I use the reduce?"
[37:56] Other things will fall into place. Things like reducing the amount of mutation, trying to use higher-order functions, reducing the number of global variables, that kind of thing. Those things will fall into place once you've got the foundation of...It's basically these are the tools that'll get you through the jungle.
[38:15] You're going to take a hike and I say, "It's just on the side of that jungle." You don't know where to begin because you need a machete. Here's a machete. You can chop through vegetation. Here's a canteen so you can have some water. It's just these basic things. Once you're loaded up, you can make it to the other side. These three tools are what are going to get you there.
**Proctor**: [38:39] That sounds like good advice for anybody who's even familiar with functional programming and has those concepts, but as to what to focus on for helping their co-workers or other people that they are involved within the community of just exposing those ideas, and saying, "Look, you've seen the for loop. Let's show this in a filter".
[39:00] Show that pattern and say, "Can we understand what the filter is at a basic level? Can we understand what the map is at the basic level? Can we understand what the reduce is at the basic level?"
[39:37] Just be able to demonstrate those differences and say, "We're not going to cover anything else but these three fundamentals and just show you how that changes some of your thinking."
**Eric**: [39:49] Yeah. If you are working at an object-oriented place, chances are you do refactoring, and you have design patterns. Both of those things are great hooks for adding new things. One thing that you might notice is, "Hey, look this class has some duplication. There's three for loops in here that look almost exactly the same."
[40:15] They're different enough that they were written differently. They sound like the same method three times, but they only differ by the body. You could say, "Wait, this body could be a lambda." It could be a proc, or whatever it's called in your language.
[40:35] Why don't we try to get rid of this duplication? Try to phrase it in terms that the person you're talking to is going to understand and be enthusiastic about. You could call a tree walk a visitor pattern. There's a lot of similarity there.
[40:54] If someone is already involved in refactoring or involved in design patterns, look for ways to — I don't want to say sneak in — just use your functional knowledge, but in a way that they can understand, in the terms that they understand.
**Proctor**: [41:11] I guess some of that is, as you describe that. I think the term comes up in my head — a teachable moment — of, "Look, we found this. There's a code review going on," or someone else has this problem and are like, "God, I got to change this four or five for loops now because of the way it's structured. We need to go update this."
[41:31] I guess it's to look for those teachable moments whether or not they're refactoring to a new code that needs to be done, and just expose some of those basic ideas that the fundamentals of, "What if we were able to pass up functional method to this for loop, and how would that change, and what does that become?"
**Eric**: [41:49] Right. This is actually giving me a great idea for a lesson to put in on my mentoring. A lot of places will have style guides and metrics. We want to reduce the number of lines of code or we want to increase the code coverage or something. Hook it into one of those things.
[42:09] Say, "Look, if I do this refactoring, basically converting all these for loops into its new method I've created, called filter, look how many lines of code are removed," or, "Look how much more coverage we get." I've tested my filter method. Now it's only one line to call whereas, before, maybe you weren't calling everything.
[42:36] I think it's possible to bring them in without a total paradigm shift in your company.
**Proctor**: [42:44] Just one more thing I could see would be, as far as the metrics, is the cyclometric complexity. You're now removing a lot of these conditionals out, and so the branches for your code in that place that you've introduced the filter is now just a straight one path through the system instead of a whole bunch of paths because you've got the if checks buried in there as well.
[43:04] Whereas, the conditional checks are now in the logic of that lambda or that proc that you're passing to somewhere.
**Eric**: [43:11] Right. You might have had a nested for loop for something. Now it could be that you've pulled that into a data transformation chain and everything is simple again. It's two separate things happening one after the other instead of two things happening intertwined with each other.
**Proctor**: [43:31] Bringing this back around to your online mentoring and everything, is your online mentoring...You're focused on Clojure. At this point of the online mentoring, is this something that's more general to functional programming, but using Clojure as a tool? Is that more towards the, "Here's Clojure" side?
[43:49] Is it somewhere in between that balance of, "We're using Clojure, so I'm going to show you Clojure stuff, but I'm also showing you some of these more fundamental stuff. Even if you're not quite interested in Clojure, but you're interested in functional programming, these are still applicable to you in general.
"[44:05] Clojure's just the tool that we're using to demonstrate some of the stuff"?
**Eric**: [44:08] That's a good question. To be honest, it's still very Clojure-centric. I've got the domain named PurelyFunctional.tv. I would like to have any number of functional languages in the program and make it an interchange between different functional languages. You'd have one price and you would get to learn everything. At the moment, I just can't do that.
[44:37] I don't know that many languages. Even Clojure, right now, is enough for me. One day, I would like to have other people in there that are experts in their languages and we could teach more fundamental concepts. That's not to say I'm not teaching fundamental concepts, but they are focused on Clojure. There is still a lot of stuff that's just about Clojure libraries.
[45:03] I've got a course in there right now that's Om. A lot of people have been asking for Om next. People say, "You taught Om. Wow, can you teach Om next?" or, "When are you going to teach Om next? I've been following a tutorial and I just want you to teach it." That's not going to be applicable to a Haskell person or an Erlang person, but I'd love to have it all. That would be great, one day.
**Proctor**: [45:29] That's part of the reason I was asking. You mentioned at the top of the show that, on your future road map, at some point you'd love to have a broader range of functional programming topics and languages and what-not, as far as the general ecosystem goes.
[45:45] I didn't know when you're starting, wanted to make sure that people listening could understand where you were focusing. It sounds good because there's a lot of stuff that even the ideas in Om and React are applicable, probably, across multiple languages.
[46:01] I'm just wanting to figure out where that baseline was drawn for where you are now and where you're looking to be in the relatively near term to the longer term.
**Eric**: [46:12] Sure. That is a good question. I am trying my best to, basically, make enough to make my full-time income. I'm not there yet, but I'm getting closer. I'm closer than I've ever been. Once it's at that point, I'll be able to dedicate a lot more time to it and, hopefully, use that extra time to find other people and get them up and running with more material for different languages.
[46:47] That said, you out there listening, if you like this kind of work of teaching, and you know a functional language that is not Clojure, then you should get in touch. I'm creating a page, literally as we speak. It will be at LispCast.com/geekery. It'll have notes for some of the stuff we talked about.
[47:16] It'll also have a form to submit, a little survey to ask you what language you know and if you have any teaching experience. Teaching experience is not necessary, but something that you can show that you've been involved in trying to explain things — a blog, conference talks, that kind of thing. I just like to see your style.
[47:40] Get in touch. It's not going to be tomorrow, but it'll be soon that I want to start expanding. Please sign up.
**Proctor**: [47:50] We're getting close to our time, but I want to make sure to give you time to bring up any other topics that we didn't get the chance to cover, or that you thought we didn't actually dig in deep enough. Is there anything that you think we need to dive a little deeper on, or that you want to make mentioned to you before we start wrapping up the episode?
**Eric**: [48:08] I do want to say that I think that this is really a great podcast. I know that I'm like brown-nosing now, but I really enjoy every episode. I like the variety of guests that you bring on — people I've heard of, people I haven't heard of. It's really expanding my perception of functional programming. I really like the clarity and depth of the questions that you ask.
**Proctor**: [48:39] Thank you. That means a lot. I've been following your stuff, as I mentioned in 18, for a good while from early on and getting into Clojure, and the clarity that you brought to it, which is one of the reasons I want to get you back on, and follow up, and see how your stuff has evolved, so that means a lot coming from you as well.
**Eric**: [48:56] Cool. Thank you. Something that I thought of that would be good topic is I've been teaching for a while and just have some tips to teach. One tip that I've mentioned before is...Another reason I brought this up is because you mentioned that you took one of my tips and started blogging about stuff in the core library of Erlang. I think that's awesome. I've been following that.
[49:27] Another thing is to answer people's actual questions. I'll often go to Stack Overflow, or Reddit, or someplace where people are just talking and asking for help, or IRC, or whatever and someone will have a question, so I just write a blog post answering the question.
[49:51] This is my own introspection. It's fairly easy to lose patience because I think that's what happens in IRC, why some people have a bad experience when they ask a beginner question. People are like, "Oh, you shouldn't do it that way. You should do it like this." It's easier in a blog post. Don't answer right away.
[50:13] Start writing it out where they can't see it. Flesh it out, and all those things where you're like, "Oh, but you don't understand this thing." Great. That's great. That's another paragraph that you can talk about. It's therapeutic. It's helpful for the community. It's helpful for yourself building an audience and getting credibility and reputation.
[50:34] Just answer people's actual questions because those are the stumbling blocks that people are having with the language. It's so hard to just come up with a topic that's a genius thing that everyone's going to want to read. These things are real. People are really having a problem with them.
[50:51] What do you do with that topic? You break it down. You find the things that...You might have some term that you're using. Like, "Wait. What does that even mean?" You got to break it down, break down further. Relate it to something in the real world that everyone has experience with.
[51:09] You don't know this person on IRC, but you that they, for instance, have been in a building. It's universal. If you can relate it to being in a building, boom, you've got their understanding. I used the example before of macaroni art.
[51:29] I don't know how many people have done macaroni art, but it's pretty universal. It's gluing pieces of dried macaroni onto a piece of paper and calling it art. That kind of thing, it's very physical. People have done that before. They've done some kind of crafty, art, gluing project. It just instantly gets people.
[51:51] Just dig deep. Dig really deep. Get out of the computer land and into a world where everybody has shared experience. The last thing is make it practical. Even when you have some abstract concept, give a real example. I made this mistake before and I corrected myself.
[52:16] I don't remember what I was saying, but I was talking about something just abstractly. Then I realized, no I have to give an actual filter example. So I gave...was it a filter or reduced? I don't remember, but give a real example. Don't speak abstractly. That's such a common thing to want to just talk about the abstract, because in the abstract you are always right.
[52:40] Make it a real example. Use actual functions and values, and show what it's going to do. Those are my tips for teaching. That's basically all I do. I just do it a lot, and I throw out stuff that doesn't really work with those principles.
**Proctor**: [53:01] Those are all good just to be reminded of. I would guess that everybody's heard those tips at least once in their life, for trying to explain stuff. It's good to have that reinforced and just be reminded of those things because, when you are in the moment, trying to get something out.
[53:18] Because you are just trying to get something cranked out in the same way that we can try and crank out code, we can lose sight of the bigger picture. It's helpful to have those tips just reinforced until they actually become permanently ingrained.
**Eric**: [53:31] For sure. I experience that crank out thing all the time where I'm like, "Oh, these things I am writing are just so boring, and dry, and abstract." If I just spend 20 more minutes thinking about making it real world, using examples from the real world, breaking it down, taking all the jargon out and I do that, first of all it becomes way easier to write.
[53:58] It's way easier to write about macaroni art than it is to write about an abstract concept like reduce. It flows better, it's easier to write, I'll get done faster, and I get a 100 times more people reading it. I'm helping more people. People are interested in it. I think that it's worth every minute you put into doing those things.
**Proctor**: [54:23] You used a given word in there a number of times. That's, I think, something else that we forget is that we're actually writing for people. We're not writing this just to write stuff. Ideally, we're writing this for other people to be able to consume and learn and get value from.
[54:40] Keeping in mind that we actually are talking to people and not just writing stuff on a computer screen, it seems like another subtle thing that you've mentioned without explicitly calling out, but is useful as well.
**Eric**: [54:51] Right. I'm guilty of this, too. I have this idea that, if I just say only correct stuff, I will sound smart, and people will trust me, and they will learn from that. It's just not the right focus. It's not about me sounding smart. That's just not what I should be thinking about. I should be thinking about the other person.
[55:16] The other person does not care so much about the minutia, of details of what I'm talking about. If I could say, "Oh. Well, a reduction is like a left fold." They don't care about that, not in the moment. They can learn that later. They want to understand it. That doesn't mean anything to them, to say it's a left fold and not a right fold.
[55:39] Thinking about, "What do they need to get this in their head? What is something that they've done that they can say, 'I already know how to do that. I just need to practice it a few times so that it becomes a tool I use in my programming.'?" That's what you want.
[55:55] It's so easy to focus on sounding right. That's what I was trying to get at when I was saying speaking abstractly, it's easier to be right because you're not talking about anything real, [laughs] in the real world. It's all mental constructs and stuff.
[56:11] You're more likely to be right, and so you're not going to make a mistake. Then you sound smarter, but that's really not the goal. You should be invisible. You should make the material and the transfer of it to another person should be the focus.
**Proctor**: [56:28] That all sound good. We've covered a lot. Is there anything you want to plug that you didn't get to mention a plug or call out specifically?
**Eric**: [56:34] Well, lispcast.com/geekery will have a link to PurelyFunctional.tv and the mentoring course. It's also at PurelyFunctional.tv/mentoring if you want to go straight there. Get on the mailing list. There'll be links to that. Sign up if you're interested in learning Clojure.
**Proctor**: [56:56] Where can people find you, specifically, online? You've mentioned LispCast. You've mentioned PurelyFunctional.tv. Where can people find what's going on more around you and your updates, outside of those two?
**Eric**: [57:07] The best way is to email me, firstname.lastname@example.org. I do have a Twitter, but I don't use it very much. I'm @EricNormand. All of that is linked to from my website.
**Proctor**: [57:21] I'll get all of those added to the show notes as well.
**Eric**: [57:23] Cool. Thanks.
**Proctor**: [57:25] I'd like to give a giant thank you to David Belcher for the logo. Once again, thank you Eric, for taking your time to join me today. I know you had some scheduling problems that were on my end, but thank you for being flexible and getting this episode recorded with me.
**Eric**: [57:37] You're welcome. It was a total pleasure.
**Proctor**: [57:40] Pleasure talking with you again. We'll have to get you back on in the future at some point again to come back and just keep up to date with what's going on and your progress of helping to bring some of these ideas just to the general audience.
[57:54] Until next time, this has been Functional Geekery.