From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
**Charles Max Wood**: [00:00] Are you guys ready?
**Aimee Knight**: [00:01] Yep.
**Eric Normand**: [00:01] Yes, sir.
**Charles**: [00:02] All right, here we go.
**Charles**: [00:14] This episode is sponsored by hired.com. Are you searching for a new job? That can be stressful, scary and time-consuming. Pushy recruiters try to sell you on roles you don't actually want, and the job boards make you feel like you're throwing your resume into a black hole never to be seen again.
[00:27] Sometimes you go all the way through the interview process just to find out at the very end that the salary offer, or company culture doesn't match what you're looking for.
[00:34] Hired is the world's most intelligent talent matching platform for full time and contract opportunities in engineering, development, design, product management, data science, sales, and marketing. We make your job search, faster, focused and stress-free.
[00:46] Instead of endlessly applying to companies and hoping for the best, Hired puts you in control of when and how you connect with compelling new opportunities. After completing one simple application, top employers apply to hire you.
[00:57] On Hired, you will receive personal interview requests and upfront salary information, so you can make informed decisions about what opportunities to pursue over a condensed timeline.
[01:05] Hired offers access to more than 4,000 innovative employers including big brand names like Facebook and small emerging startups. The size and type of company you want to connect with is totally up to you. We help you find new opportunities in 17 major cities in North America, Europe, Asia and Australia.
**Aimee**: [01:44] Hello from Nashville.
**Charles**: [01:45] I'm Charles Max Wood from devchat.tv. This week we have a special guest, and that is Eric Normand.
**Charles**: [01:51] Eric, do you want to say hi?
**Eric**: [01:53] Yes, I do. Hi. Maybe too fast.
**Charles**: [01:55] Nope, you're all good. Do you want to give us a brief introduction?
**Eric**: [01:58] Sure. My name is Eric Normand. I have a company called purelyfunctional.tv, where I teach Clojure and functional programming. The main target market is people who want to transition into functional programming from their current job.
[02:18] I give them a lot of support, show them where to find jobs, convince them that there are jobs out there, give them the skills they need to do well at the interview etc.
**Charles**: [02:29] Makes sense. Functional programming for a while it just felt like, "Oh, this is what cool kids are doing." I think that has changed a little bit. It's not just this mental exercise that cool kids are doing anymore.
[02:45] It's become more of a, "This is a direction that we can go in." It simplifies a lot of programming for people. Aimee mentioned before the show, I don't know if I've heard of anyone deeply using anything other than maybe Elm, that's highly functional in a larger application. Maybe you can address that really quickly.
**Eric**: [03:09] Functional programming is being used quite a bit at a lot of big companies. Walmart, Amazon, eBay, PayPal, they all have Clojure applications running in production. It's also being used at a lot of banks of financial services. It's actually being used quite a lot.
[03:48] Another answer to your question is that yes, people are using it. It's influencing the more mainstream programming industry at the same time.
**Aimee**: [04:01] We were talking about this before we started the show.
[04:05] You had a pretty good talk, and I'll put a link in the show notes called "Building Composable Obstructions." I feel, I know for myself and for a lot of developers, you go from playing with Haskell, or ClojureScript, or something like the Elm, or whatever, in your free time, and they give you these little toy problems to solve.
[04:29] How do you go from that to actually building an application?
**Eric**: [04:36] That's a question that I get quite a lot. Usually, it's phrased in terms of, how do I structure my application? A lot of people are used to using frameworks. Most people don't open up a new file called Main.Java, and type public static void main, and that's the beginning of their program. [laughs]
[05:04] They start from some existing place, some existing app that they modify. There isn't a big framework in the Clojure world. There are several small attempts that aren't going anywhere. It's like a persistent question, how do you actually structure your application? My talk that you mentioned was an attempt at coming up with that.
[05:30] I think that when people are asking for a structure, what they really want is a process for taking a set of features, or some use cases, and figuring out how to turn that into code.
[05:46] So far, it seems that a lot of people who get into functional programming, they have years of development experience under their belt. Not everybody, but if I'm going to generalize, that's what I would say on average, that they've already got a lot of experience.
[06:04] They've already gone through the, "I've used three different frameworks and I didn't like any of them. And I want to start from scratch and build it myself."
[06:13] That is the attitude that people have in functional programming, that they don't want a framework, which I think is a detriment at the moment. We need something that's more beginner-friendly.
[06:25] This talk was my attempt at coming up with a four-step process for, "Here's your problem, now what do you do to turn that into code?"
**Aimee**: [06:36] Is there anything you can expand on here, or should people just go watch the talk?
**Eric**: [06:41] I can give a brief intro to it, or a brief description of the process. There's four steps. First step is to develop a metaphor, some real-world metaphor for what you're trying to do. When you do that, what happens is, you're actually developing the first implementation.
[07:06] Because it's an intuitive metaphor, it's already running in your head. It's running in your co-workers' heads.
**Aimee**: [07:13] I think you said this in your talk. How would you build it if you didn't have code?
**Eric**: [07:19] Exactly. If someone gives you a problem of, "Hey, we want a medical record system, but you can't use a computer," what are you going to do? You'd say, "Paper and pen, I guess. A filing cabinet." You can imagine it really, really easily.
[07:37] If you have that metaphor at first, you've got your first implementation. You can use that intuition about it to answer questions later on. The second step is then to develop the operations. Enumerate them, list them, what are their properties? That kind of thing.
[08:01] You go through and you say, "We're going to be able to add a new patient. We're going to have to be able to query for a patient, given their name and date of birth. We're going to need to sort all of their records chronologically."
[08:14] You can follow along, because you already understand what a big wall of files might look like, and how it might work. Once you've got those operations, you want to develop relationships between them.
[08:29] Very often at this point, you want to just jump into the code and say, "If we're going to need to look them up by name, we need a table with an index." That thinking is going to limit you further on.
[08:46] You're already setting in stone how the thing should work. It's like saying, "We're going to make this filing cabinet 10 feet by 20 feet." It's an implementation detail about how big the filing cabinet is. You figure out all the relationship between the stuff.
[09:05] One relationship might be, "When I file away a person's record, I should be able to get it back out later, by name." That's the relationship between adding a patient and looking up a patient. Then you can start to say stuff like, not only the relationships, but the properties.
[09:25] If I add the same patient twice, they should actually go in the same file. I'm trying to think of another property that would be useful at this stage. There's all sorts of little mathematical properties. Does the order matter?
[09:41] If I'm putting in multiple patients, does it really matter what order I've put them in? Or can I hand them out to different people in the office and they can all file them at the same time?
[09:51] Those properties might be a requirement, because you have multiple terminals accessing this one medical system. Once you've got all of that, you can actually write a prototype at this point.
[10:08] The prototype should be something that is really easy to write, that guarantees all the properties that you want. You can set up test for those properties to make sure that you are not violating some requirement.
[10:25] This prototype, what I suggest, and this is like a functional programming technique, is to not do it in a database, to do it all in memory using functions. The operations obviously are going to be functions. The data should also be stored in functions.
[10:44] Functions are Turing-complete based on...I don't want to say the L word, but lambda-calculus has been proven to be equivalent to a Turing Machine.
[10:56] You are not going to lose any ability that you would if you limited yourself at this point to say, "Oh, I am going to store it all in a HashMap, because HashMaps are much more limited than functions." Finally, you can play with it, test it out and actually run the test on it, see if it does what you want.
[11:23] There is probably other requirements. They are more like operational requirements. It should be so fast, or it should have such and such reliability. It needs to store it to disk so we can access it later. What if the power goes out? All these other requirements that are nonfunctional requirement, they are operational requirements.
[11:45] Now you can take your prototype and refactor it into something that has all those other requirements. My talk is trying to say these first three steps, people talk a lot about, "I am going to write a first version and then refactor it and it will be good." Except you didn't do the first two steps of thinking about what you want to do. You just wrote a prototype and refactored it.
[12:16] You don't know if it is actually doing what you want to do. Refactoring is not enough. Refactoring is like organizing your desk or cleaning your room. It can move stuff around and put stuff in different piles. It doesn't ask the question, "What do I actually want on my desk?" You can't actually change the functionality when you are refactoring.
[12:41] At this point you can call it a refactor because you have got all the tests. Your prototype works. You are not going to change the functionality. You are just changing these other requirements like performance, etc.
**Charles**: [12:53] It sounds really complicated to me. [laughs]
**Eric**: [12:55] [laughs] Anything you start talking about for five minutes is going to sound complicated. If you try to write a process for how you developed in another language, it would be complicated, too.
**Charles**: [13:10] Yeah, probably.
**Eric**: [13:11] There is books and stuff written like, I don't know, the DDD book, "Domain Driven Design." To me that is one of the best books on how to actually write and design object-oriented software, and it is. I can't get through it.
**Aimee**: [13:30] [laughs] I have that book.
**Eric**: [13:32] The first three chapters is, "Yeah, yeah. That's great." Then it is all about pointers and how to organize your methods and stuff. I felt validated why I like functional programming.
**Aimee**: [13:50] I think you started to talk about this at the end, but you also touched it on your talk. Why can't you always make the code better? Maybe I misunderstood in your talk. It sounds like you can't always write code with the thought that you can refactor it later. Is that something you were trying to get at or did I misunderstand?
**Eric**: [14:11] That's right. That's what I was trying to explain just now. The way I explained it in the talk is, there was a system of physics called Aristotelian physics.
**Aimee**: [14:23] Now, that's sounds complicated.
**Eric**: [14:26] It's really complicated. It's a bunch of rules and laws. There is stuff like heavy things move slower than light things. Big things want to...let me think. It's really complicated. It's stuff like heavy stuff wants to find its natural place, which is lower to the ground. Lighter stuff wants to be higher up.
[14:51] That's why if you drop a rock, it finds its place at the bottom of the water. Water's natural place is on top. You can see how this explains a little bit of stuff. It explains why it is easier to walk downhill because my natural place is down there. It explains why pushing a big thing is harder than pushing a little thing.
[15:15] It doesn't explain everything. There's a lot of holes. You can't actually refactor those rules into Newtonian mechanics. There's no way to go from this notion of natural place to a notion of the sum of forces. You actually need different concepts. You had to throw it away and start from scratch. You cannot refactor it.
**Aimee**: [15:49] Tell me if I am summarizing this correctly, because I think you also mentioned this. I feel like we already know the most important step is not to start coding. It's to sit down and have the hammock time to think about what you are doing first.
**Eric**: [16:07] Exactly. We want to think first. The big problem I see with that advice is, as a beginner what you even think about? What process are you going through to think about it? I have seen this joke where someone is, "The hardest part about pair programming is that part where you just sit and think."
**Aimee**: [16:31] [laughs]
**Eric**: [16:31] There is a lot of sitting and thinking and programming. [laughs] How do you do that with a pair?
**Aimee**: [16:39] Or rubber ducking doing back and forth.
**Eric**: [16:41] Yeah. My idea was to try to find something that people could do, which was, look, you already know a lot. You have an intuition about how things work. You should tap into that intuition. Before you jump into the code, you should be thinking about the operations that you are going to need to do on that.
[17:04] You can think about them because you already understand it. You already understand your metaphor. You already understand the filing system. It is just a matter of starting to formalize it and think of it in terms of operations. Like I said, everything else is just like implementation to tales.
**Aimee**: [17:27] For what it's worth, my hammock time is my run in the morning. [laughs]
**Eric**: [17:31] Cool. I like thinking while running.
**Aimee**: [17:36] I did have another question written down. As developers we all know abstractions are usually a pretty good thing. I think they can be taken too far. We actually talked about this last week when you were talking about reusable components. Not the talk that we have been discussing. You gave another talk called "The Elements of a Functional Mindset."
[18:01] If I recall correctly you started talking about this, when are they good. I'd be curious in your opinion, when are they good, and what are your thoughts on when they've been taken too far, and it makes the code harder to read?
**Eric**: [18:16] I have written so many bad abstractions with good intentions.
**Aimee**: [18:21] [laughs]
**Eric**: [18:21] I thought they were great. That might be how you get better as a programmer is just messing up so many times. In my opinion the ones that go too far are the ones that don't have any real basis.
[18:43] You're making something new up. You're coming up with some new idea that hasn't been, like there's no formal math around it. There's no even physical intuition about how it's supposed to work. You think it might be a good idea. It might save you some time. They tend to be bigger because you're handling all these cases inside the deepest levels of the abstraction.
[19:13] I guess the opposite of that would be small abstractions that have properties that you can sink your teeth into. Those kinds of things are just like high school algebra type properties. Stuff like commutative, meaning the order doesn't matter. Idempotent, meaning you can do it multiple times and it doesn't matter.
[19:38] These are things that when you look at a good library, a good piece of software, or a good class with nice methods, it feels well-designed. You notice that these are the properties that it has.
[19:52] It's so convenient that I can call this multiple times, and not worry about whether it's going to have multiple effects, or it doesn't matter how I group these things. That's called associativity, or I have a beginning value.
[20:08] When you're adding stuff together you can start at zero. That's great. You don't have to start with null and do this null check every time. You can start with zero. Those properties are the kinds of things that I think make better abstractions. You can rely on these things, they're very simple properties, they're stuff you can test.
[20:28] They are useful in the sense that when you have something that's associative, it's much easier to break it apart, work on the stuff. Do a divide and conquer strategy and then put it back together. If you didn't have associativity, you couldn't do that so easily.
**Aimee**: [20:47] Is the hammock time when you decide if you want to make something abstract, or do you think you should wait until you see patterns develop?
**Eric**: [20:57] That's a good question. I actually think you should do the thinking before. That's not to say that don't do exploration and stuff, but those things should be little experiments that they never touch production. They never get deployed.
[21:16] I think what you're asking is, if you see the same code repeated three times, does that mean it's a valid abstraction? How many times should you see it before you dry it up? If I knew the answer to that one, I could have a really nice book. [laughs] I guess I want to back it up and say maybe that's good evidence. There might be something there.
[21:43] If it doesn't have a known mathematical property...I just don't feel smart enough to do math and explore something and discover something new in math. I feel like I have to rely on the thousands of years of mathematicians who came before me.
**Aimee**: [22:01] That makes sense. I'm just curious, have you heard of, I think it was Sandi Metz she did a talk on this, the squint test, where if you squint at the code and you start to see it looks the same? That is a trigger that you could start refactoring it. That's not necessarily abstraction, but it's more about refactoring.
**Eric**: [22:20] Yeah. I really respect Sandi Metz. I think one of her quotes was, "Duplication is better than the wrong abstraction," something like that. I really think that's something we should keep in mind.
[22:34] The worst thing is to say, "These things look almost the same, so let's dry it up." Then they need a parameter that makes the thing more complicated. It was actually better before when they were only slightly similar. It's a really complicated thing. I don't have a lot of good insights into that. I know it when I see it.
**Aimee**: [23:04] You gave some good thoughts.
**Eric**: [23:05] What are your opinions on that?
**Aimee**: [23:06] In all honesty, I know this sounds like a cop out inter, but I genuinely believe it. That's why we're paid to think through things because it always depends, and there's not a cookie cutter way to approach it. We have to think through it.
**Eric**: [23:25] That's a really good way to think about it. That's what you're paying me for.
**Aimee**: [23:29] Exactly.
**Eric**: [23:30] If I could write it down and make a machine do it, then I wouldn't be here right now.
**Eric**: [23:54] That's right.
**Aimee**: [25:35] They say Lodash is the standard library.
**Eric**: [25:37] Yeah, Lodash, that's the new one. Did it win over Underscore?
**Aimee**: [25:43] Oh yeah.
[26:14] I would go into one component and start working on it and remove all the state and put stuff in Redux and really clean it up, make it nice and functional. I would commit it and start working on the next one. I'd come back in two weeks and the code had gone non-functional again.
[26:56] [background music]
**Announcer**: [26:56] Don't wait for users to report problems. Raygun gives you complete visibility on errors, crashes, and performance problems affecting your end users. You can replicate issues in seconds rather than digging through log files and having to rely on users to report errors or crashes.
[27:24] [background music]
**Charles**: [27:27] That makes sense. One other thing that I am also curious about. I was talking to Dave Thomas from Pragmatic Bookshelf. I guess he retired so he's doing other things. I was talking to him this morning on Ruby Rogues, and he mentioned, he's teaching a course at Southern Methodist University in Dallas, Texas.
[27:45] He mentioned that he envisions that most of his students within the next five years are going to be writing code in some kind of functional language. That that's the future of software. Do you see that? Do you see things going that way, or do you think that that might be a little bit optimistic from the standpoint of I really like functional programming?
**Eric**: [28:06] It seems optimistic to me. Is he talking about Computer Science students?
**Charles**: [28:11] Yes.
**Eric**: [28:11] Yeah. I could see Computer Science Departments at universities saying if there's enough jobs for functional programmers, we want to do that anyway. Let's teach that.
**Charles**: [28:26] No. His reasoning was that they were going to have jobs. These students that he has now in his class, most of them will have jobs writing functional programming. The functional programming paradigm is going to be something that becomes mainstream, much more mainstream, and is going to overtake object-oriented programming.
**Eric**: [28:48] That would be very cool. I would be very happy with that.
**Charles**: [28:54] His reasoning was that with Moore's Law, the speed of computing is supposed to double every year and a half, or something like that. We really haven't seen that. We haven't seen the speed increases. What we've seen instead is more cores.
[29:11] His reasoning was that functional programming gracefully handles concurrency because of the immutability and a couple of other features of functional programming.
**Eric**: [29:47] I have heard that argument a lot in the last 10 years. I was promised way more cores than I have now. People 10 years ago were talking about a thousand cores in your laptop.
[30:01] What I've heard, this is total hearsay, but I would like to believe it, is that there just hasn't been enough pressure on Intel basically to double the number of cores every year like they were doubling the processor speed.
[30:18] Instead they've been working on stuff like power efficiency because of cell phones. The other thing about that is the operating systems that we run on are all pretty good at using all the cores at the process level. You're running multiple programs, each one is on a different core.
[30:41] They're swapped out and sharing the cores. Stuff like PHP scales really, well horizontally, for each request. The request lasts milliseconds. You run millions of processes.
[30:56] If you need millions of requests per second, you're running a ton of processes that are all running and using the operating system processes. I would love for functional programming to take over the world. I don't see that argument really happening. Things have horizontal scalability already, by running multiple processes. That said, I do think that functional programming has a lot to teach.
[31:29] The main reason to learn functional programming, at the moment at least, is to have more tools in your toolbox. When we're solving problems, and we think of an OO way of breaking stuff up into classes and methods, that might not be the optimal way for the problem you're trying to solve. A functional approach, even in OO language, could be much better.
**Charles**: [32:02] This leads to another question. You gave us a bunch of notes on ClojureScript. We've been talking about, at least, some other things related to things that you've spoken about.
**Eric**: [32:12] That's totally cool as long as you think your audience would like this stuff.
**Charles**: [32:16] It's an interesting conversation to have. My next question, though, is basically if this is a better way to solve some of these problems, why aren't people finding this solution to be more common? Is it just training? Is it just people don't know it's there? Is there more to it than that?
**Eric**: [32:34] There's a prejudice, to be honest. I guess, it's nine years ago, I was getting into Clojure. I was already into Lisp. I would mention that to people. They would be like, "Why are you even wasting your time? Programming is just do this step, then do that step. It's all imperative. The OO stuff is just putting a little bit of encapsulation around that, but it's not doing much for it."
[33:06] I don't know, there're a very jaded view of all types of paradigms. I think people are a little jaded. They see stuff. What they're familiar with is a for-loop, putting stuff into an array and using variables all over the place. When they start to work in something, let's say they had a class in college that was using Scheme or Common Lisp, which is actually a common course, it feels totally foreign to them.
[33:44] It feels unintuitive because they're so used to banging on arrays with for-loops. It's also hard, in a single semester, to develop the fluency with those things that you already have in the for-loops, to get deep enough, to feel the actual benefit of them. It's a big hurdle to overcome. People, they usually start with an imperative language or an OO language.
[34:20] They spend so much time in it. You have one podcast to convince them, [laughs] that they're going to do better with a functional language. It's a hard thing to do.
**Charles**: [34:33] I also wonder a little bit, you mentioned Scheme and Common Lisp. I didn't take those classes in college. I have played with them since. I found that they weren't very practical for a lot of things. I find things like Elixir and Clojure, where they're actually on the GVM or on the Elixir virtual machine.
[34:53] They're installable and runnable, and you can do stuff with them. I find those a lot more interesting, just because there are capabilities there that, I don't know if they weren't possible or most likely they weren't developed for the use cases that I would put them to.
**Eric**: [35:14] For instance, Common Lisp was developed in the late '80s. It just feels old. There wasn't much development going on on that. They standardized, that's where the name Common Lisp came from. They standardized and then they were all so exhausted from doing the standardization process. They stopped working on it. That is at the same point when people started moving to C++ and then to Java.
[35:48] Those languages were getting a lot of uptake, a lot of cash from big companies, like Sun, who developed Java.
[35:55] I think that we are now getting into this renaissance where on the Internet, you can find enough people to get interested, in a little language that you are developing, and start to get some real uptake and labor, straight up work, to make it better and to develop libraries and documentation and stuff.
[36:22] There was this dark period, in the '90s, where to develop a language required millions of dollars. We're now at a point where you don't need that. There's also, what is it, doubling every five years, the number of programmers in the world? Even the smallest language can find enough people to make it worthwhile. It's cool. We're in a little renaissance.
[36:52] That is one of the reasons, why we're seeing a lot of functional programming stuff happening. A lot of functional programmers, they had to program in Java for 10 years. They didn't like it but there weren't any jobs in functional programming. They just did their job. Now there's a choice of languages. They can do Elixir. They can do Haskell. They can do Clojure. They can do Scala.
**Aimee**: [38:40] That's interesting. I like that. [laughs]
[39:19] You are getting people talking about functional programming, and what it means to make your component pure. We're talking about these things now, which is great. People have a vocabulary around it.
**Charles**: [41:02] Was it Jeremy Ashkenas?
**Eric**: [41:04] Yeah. That's right. Also, the guy who made Backbone.
**Aimee**: [41:08] Didn't he do Underscore?
**Eric**: [41:11] Oh, really?
**Aimee**: [41:12] I could be wrong, but that's what I thought.
**Eric**: [41:13] Wow. What a prolific guy.
**Charles**: [41:15] He did do Underscore. I was going to say...I think so. [laughs]
**Charles**: [41:29] Backbone heavily used Underscore.
**Aimee**: [41:31] I just confirmed. I looked it up. I get them.
**Charles**: [41:36] Is there anything else that we should dive into with functional programming before we get to picks. If people want to get started with it, is there an easy way in?
[43:38] We're very into live programming. You type your code. You save it. You see the result right there. You don't have to click around to get back to where you were. You don't have to reload your browser. You can change things in the code and it shows up. I'll give Chuck some links to put in the show notes. We'll have links to all of these things.
**Charles**: [44:01] Sounds good. Let's go ahead and get into some picks.
[44:04] [background music]
**Charles**: [44:07] This episode is sponsored by Angular Dev Summit. Coming September 11th through the 18th, 2017. Hi, it's Chuck from Devchat.tv. I reached out to some of my friends in the Angular Community to put on a completely free, no travel conference for Ruby developers.
[44:21] We have speakers like Rob Wormald, Jeff Walkley and others coming to speak about all kinds of topics in Angular. If you're trying to learn Angular or you're trying to level up Angular, come check it out. The talks are happening throughout the day each day, and we'll have a chat available during each session.
[44:36] Attending the talk is free but you need to register. Go to angulardevsummit.com.
[44:40] Aimee, do you have some picks for us?
**Aimee**: [44:44] Yes. I got two. One of them, I'm actually going to pick from your blog. It is called "The Hidden Cost of Obstruction" from June 13th of last year, almost a year. Believe it or not, I had that saved as one of my picks before this episode. I found it even without prepping for today's show. I thought it was pretty good.
[45:07] The other one, because people ask this question a lot and we've had shows on a lot of different languages. We had two shows on Elm and all kind of stuff. Short read called "What Functional Language Should I Learn" and I'll put links to both these things in the show notes. That's it for me.
**Charles**: [45:27] I'd jump in here with picks, but I can't think of anything at the moment. [laughs]
**Eric**: [45:30] Do you have a hoard of picks because you do so many shows?
**Aimee**: [45:36] I do. [laughs] I have a huge list.
**Charles**: [45:41] I should make somebody go back through all the shows and make an index of all of the things that I have picked over the years, because I've done so many shows, and tell me which shows I haven't picked them on. I can just recycle picks.
**Eric**: [45:55] Awesome.
**Charles**: [45:55] I would have picks for years, I swear. One of the things that I've been fiddling with lately is the Ionic framework which is Angular and web-use to build mobile apps. I tried React Native. I thought it was cool. I'm not as familiar with React as I am with Angular. It made things a little bit easier to go that route.
[46:17] Yeah, I've really been enjoying it, so I'll pick the Ionic framework. Eric, do you have some picks for us?
**Eric**: [46:23] Yeah. I'm currently reading a book by Stephen King called "On Writing." It's non-fiction. It's his memoirs. He's also giving a lot of writing advice. I find it really interesting. I try to write a lot. It's useful to me. If you want to write blog posts and stuff, his advice is really good. It's very practical. He's a very practical guy, very prolific. It's all about finding an honest thing to say.
[46:55] That's what makes things interesting. I've also been getting into this YouTube channel called Tested, T-E-S-T-E-D. It's all about a maker movement and cosplay and stuff. I've always dabbled in making. I'll make one thing every 5 or 10 years. I really enjoy it. Watching some of the shows on this channel, I've been happy to reignite that spark.
[47:31] Watching someone else makes something and see them...I'm always afraid because I don't want to ruin a thing to try to make something else because I'm probably going to ruin it. They just ruin stuff all the time. [laughs] It makes me feel a lot better that that's even what professional makers do.
**Charles**: [47:51] Cool. If people want to follow you, read your blog, see what you're working on, where do they go?
**Eric**: [48:00] The best place to go is purelyfunctional.tv. You will see sign up boxes for functional programming, career guide, or the newsletter. I write the newsletter once a week. It's a bunch of links with my thoughts about them, about 10 links.
[48:18] I have a blog called lispcast.com which I don't write on as much as I would like. That's what everyone says about their blog. It's another source of following me. I'm not that active on Twitter, so don't follow me there. Get on my newsletter, that's the big thing.
[48:34] [background music]
**Charles**: [48:35] Awesome. We'll go ahead and wrap this show up. Thank you for coming, Eric.
**Eric**: [48:39] Thank you so much for having me. It was a blast.
**Charles**: [48:41] We will catch everyone next week.
**Aimee**: [48:44] Bye.
**Charles**: [48:45] Bye.
**Announcer**: [48:47] Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more.