A weekly newsletter and podcast diving into Clojure programs and libraries by Daniel Compton.
A weekly newsletter and podcast diving into Clojure programs and libraries by Daniel Compton.
Download: MP3 - 00:42:12
[00:00:00] Daniel Compton: Hello. Welcome to The REPL, a podcast diving into Clojure programs and libraries. This week, I’m talking about teaching Clojure with Eric Normand, the creator of PurelyFunctional.tv. Welcome to the show, Eric.
Eric Normand: Hey. Thank you, Daniel. It’s great pleasure to be here. I’ve listened to your podcast since the beginning and read your newsletter, and I’m just very happy to finally get to talk to you.
Daniel Compton: Yeah. So, it’s great to be able to talk with you, too. I’ve been reading your newsletter and all the other things that you’ve been doing since basically when I started using Clojure quite a long time ago and, yeah, you’ve been kind of there all the way through my Clojure journey. So, it’s great to finally be able to talk.
So, the first thing I wanted to talk about was a recent course that you created and released just a week or two ago called REPL-Driven Development in Clojure. So, I wonder if you could talk to us about that course and then about sort of what it is you do in the Clojure community.
Eric Normand: So, REPL-Driven Development in Clojure is a video course. It’s about nine hours of video.
Daniel Compton: Wow.
Eric Normand: Yeah, pretty long. You know, you never know how long it’s going to be when you first start and it just keeps going. So, one of the things that I think is a good sign of a healthy Clojure programmer is that they use the REPL a lot, and by REPL, I don’t mean it’s just like the prompt and you type a lot of stuff in the prompt. I mean, you are using the fact that you are interacting with a live system. And so, that might be redefining functions; it might be testing out an expression or two to see what it does; it might be even looking at documentation, docstrings that are already in the environment, and doing this live, right?
Let’s say you’re working on a web server. You got your web server running and you connect up to the REPL, usually through your editor, and you modify it. You make it do something else and it’s completely different from the sort of rest of the world, the non-LISP world where you would, say, modify your files on disk and then either compile them and run them so you’d have to shut down the server. Or, you might have something that’s more like a scripting language, does not compile—let’s just call them noncompiled language—where it reads in the file and runs it anew on each request. That would be something like Ruby or PHP. And so, what you don’t have is any kind of state saved between requests, right? You don’t have a memory, a shared memory. Whereas on the JVM, you do have that, except if you’re doing a compiled program you’re going to have to shut down the JVM and start it up again, lose all your state.
So, Clojure gives you this really nice ability, this nice workflow, where you’re compiling running very small units. You can test things as you edit them. You can kind of grow a function at every step, know that it’s working. It’s like a superpower of Clojure. I don’t think any of the other mainstream languages do it as well as Clojure does.
[00:03:19] So, a lot of people have made the leap from not using REPL-driven development to doing REPL-driven development, you know, somewhere along their journey learning Clojure. But, a lot of people hadn’t and there’s not a lot of good material out there. I think there’s just a lot of mentoring going on. People figure it out by watching other people, but a lot of people don’t have a mentor in Clojure. And, I started getting requests for it. People have just been asking for like, “How do you do this thing that people keep talking about?” Stuart Halloway had a couple of talks about REPL-driven developments and blog posts and videos and his material was great, but it wasn’t like a complete course, a complete guide. And so, I decided I needed to make it happen. So, I did that.
You know, one thing that a lot of the material out there does not address, which I think is very important, is how intimately you need to understand the semantics of the language, so the semantics of vars and how defs create vars or modify vars, depending on if they already exist, how names’ bases work. Those kinds of things, you really need to understand those so that you understand what’s going to happen when you reevaluate this function, reload a name space and what is that doing. You need to understand that so that you can choose the right steps to interact with your live system. So, I made sure that that was a very prominent part of the course.
So, the course is available for purchase now or you can become a member of PurelyFunctional.tv and get that in all the other courses.
Daniel Compton: [00:05:02] Nice. And so, PurelyFunctional.tv is I think the main way about you since the beginning, which is your training, teaching, mentoring sites. Yeah, what can we do at PurelyFunctional.tv?
Eric Normand: Yeah, so PurelyFunctional.tv is, it’s a membership site where I publish video courses. I also have other content that’s free like text guides, textural blog posts if you want articles, things like that. But, the main content is the video courses and you can get a membership and you can also buy the courses individually. So, this is my main source of income right now. I know you said you wanted to talk about more the business side, but this is my job now, is creating courses and supporting the members that I have and trying to get more people to learn and enjoy Clojure.
Daniel Compton: Yeah, I think REPL-driven development is such an obvious, in hindsight, course to do but, as you say, I don’t think there’s been sort of scattered blog posts or people talking about it or different sort of facets of the problem. But, I remember when I first started using Clojure that it took me quite a while to paste together what does it look like to develop a Clojure system.
Eric Normand: Right.
Daniel Compton: Even now, there was Clojure-verse thread about a year or maybe more ago about different REPL workflows that people had and there were so many different ways that people did the REPL, how they interacted with programs, and it was really interesting to sort of look at how different ideas—because I sometimes wonder, am I doing this the best way I could? Are there tools or techniques or ways that I should be debugging or developing that I’m not using? So, every now and again I sort of look around and see what tips and tricks I can pick up. So, yeah, having a comprehensive, from the beginning, like here’s all of the things you need to know about Clojure development, this sort of seems like the missing link in many ways from a junior Clojure developer to an intermediate one, possibly.
Eric Normand: [00:07:13] Yeah, yeah. I hope I don’t sound mean because I really love beginners, but I’ve seen this happen so many times—it’s one of the things that inspired me to actually do the course—you’ll see someone come into let’s say Slack or the IRC channel and they have a question. In a lot of languages, you might say, “Go read the manual.” It’s all in the manual, so you just link to documentation. But, it’s not even something like that. It’s something where they say, “What happens if I pass an empty list to this function?” and it’s surprising because, well, if you’re doing Clojure, you can just type that into the REPL. Why would you switch over to Slack and ask people and hope that the right people are online and hope that you can ask it the right way and that they give you the right answer when you could just type that in and see what happens? And it’s those kinds of interactions where you realize, “No, people don’t know about this REPL-driven stuff.”
It’s the same thing that happens when they complain about—this is totally justified—complaining about the startup times of Clojure, and when you dig into it you realize, “Oh, they’re restarting their server like every change.” They don’t realize that’s not how we do it in Clojure, that we don’t just have a better way than the restarting, it’s like a better way than every way, right? It’s completely—you never restart your server or rarely. Let’s just say it’s so rare you don’t even think about it. Not only can you do the whole, like, “Oh, I’ll reload this page and I’ll see the change,” before you even do that you can test that it’s going to give you the right thing before you look at it in your browser, right? And you can query, I mean, even simple stuff, like you can create a new atom while the server’s running—you’ve a got a bug, right—so you can create a new atom and you say, “Okay, every request that comes through, I need to be able to inspect it, so just add it to this atom.” And so, then you hit reload, everything is saved in an atom, and now you can look at the data right there. I mean, who else can do that? It’s just an amazing thing that we’ve got.
Daniel Compton: [00:09:48] Yeah, I completely agree. So, you’ve been teaching, mentoring people sometimes directly and sometimes indirectly through your courses in Clojure, so I would guess you’ve seen probably a pretty high number of new and developing Clojure programmers. Are there any sort of common things you’ve seen, things you’ve learned, maybe sort of common things that people get tripped up on that you’ve seen over time?
Eric Normand: Yeah. I think people get tripped up on how simple Clojure is. Let me give an example of something I’ve seen. Again, a lot of this just happens in like Slack or IRC, right? Someone just comes in and asks a question, and these are kinds of questions where it’s like, “Okay, am I really going to go down to the basics and teach this stuff?”
So, here’s an example. Someone was trying to use an atom and they had made an atom in the normal way, right? They probably found some code online that showed how to do it, so it was like defx is atom with a vector in it, right? And, they knew that atoms were used for mutable state and they were trying to modify the vector inside. So, they thought that atom was some kind of syntax that makes the thing inside mutable.
Daniel Compton: Hmm. Right.
Eric Normand: That’s what I mean where they don’t realize how simple it is. It’s like, no, the vector is a thing and atom is a separate thing and they don’t really cross. You can put anything in an atom. The atom doesn’t do anything to the vector. right? The atom is just an object. You could actually look at the source code. It’s just a function that constructs an object. And those kinds of things where it’s like, “Oh, you don’t have magic syntax for this and that and the other thing, it’s just a function that constructs an object?” I think those kinds of things trip people up quite a lot.
I also see people doing a lot of, oh, they use def inside of a function. They’re implementing imperative code. They see that def creates a variable and assigns a value to it, and so they just use that everywhere instead of using a “let”. Things like that, where it’s like, “Okay, you’re getting there.” It solves the problem. It gets the right answer.” And that’s great. I think that that’s awesome that they are able to get through that initial part of learning where things really are tough because there’s so much to learn to get into a new language. But then, you kind of have to step back and say, “Okay, now you’re at this point where you have to know that def should not be used like that. Def is for top-level things.”
So, now you get into like, well, what do you use instead? And now, it’s sort of like a fork. It’s like, okay, so what are you really trying to do? Are you trying to just give something a name for this little local context? That’s a let. Are you trying to create something so that you can get data out of this function? Because that’s a whole other discussion. Do you really need that? Or, maybe you do. For instance, if you could have an atom and you’re sharing data between two different functions. I’ve done that before. It’s a possibility. Or, are you implementing an imperative algorithm and really, to do it in an imperative way, you need mutation inside of a loop or something? That’s another discussion.
And so, those are the things that I really like getting into because it shows you how deep this goes, like, how did the people on this side of that divide who are capable Clojurists, how did we get here? How did we get from global variables everywhere to knowing like, “Oh, sometimes I need an atom and sometimes I need to use a loop. I can change the state every time through the loop. Sometimes it’s just a let.” How did we get here where we’re able to see all these different uses for things?
[00:14:05] Okay, so you’re asking me about teaching and mentoring, and I have made some notes about things. The thing about REPL-driven development that reminds me of this is I was hesitant to make this course at first, the reason being like, if you had asked me a year ago like, “Would you make a course on REPL-driven development?” I’d be like, “Yeah, but what does that really mean? Everyone’s got a different workflow and there’s all these different editors, and is there really one thing called REPL-driven development?”
But, the more I think about it and get into it and really engage with people who need to learn it, the more I realize, “Yeah, there is a thing and I know it.” And now, through seeing what these beginners do not know, I see, “Ah, yes, this is how I can teach it.” Is there a thing as REPL-driven development? I’m not sure because, like you said in this Clojure-verse thread, “There were so many different workflows.” Everybody’s got a different thing that they’ve picked up over time. It’s evolved over time, but what is common? What is the thing that they are able to point at that this is where it’s REPL-driven development? “Oh, that’s just a workaround because I’m using this editor that doesn’t have this tool,” but you could figure it out. It just takes a lot of thought and deep digging. But, what I’m saying is like, the more I teach, the more I realize I do know more than I think I do. It’s all in there. I did have to research some things like different editors that I don’t use, but the core stuff was totally—I already knew all of it. I just hadn’t organized it into a course yet.
Another point that I’ve learned over time is that programming is too hard. It just really is. And I don’t mean the, I guess the cool part of programming, which is where you get to make ideas real and anything you can imagine you can create. That part is cool and that’s always going to be hard. I’m talking about the, like, get your editor set up, you got some weird thing going on in your machine and you google the error message and no one else has had it before, all the package managers you need to get anything working. All that stuff is just too hard, and I feel we’ve really over the last 20 years painted ourselves into these corners in every language community. It’s not just Clojure. It’s everywhere. It’s just this amount of stuff you have to know is just too much, like, how does someone learn Git? How does someone learn all the UNIX command line stuff? All that is just incredibly arcane, and I just feel for anybody starting today. It’s really hard.
[00:17:07] Okay, another thing that I have learned over time is that people are smart even if they’re beginners. I know there’s a lot of dissing of users. I’ve heard a lot of people say, “Oh users, are stupid. They don’t know what they’re doing and they need all this help.” And the more I create courses and teach people online, the more I realize, “No, they’re smart. There’s just a lot to learn and they’re kind of overwhelmed continuously when they’re learning. There’s just so much stuff to learn. But, they’re smart people. They want to be spoken to like intelligent people. They can tell when you’re oversimplifying or dumbing something down. They want a deep experience. They want to be told the straight dope about the thing.
And I had this period where I was thinking, the value I bring as a teacher is to find a path through all the myriad things you have to learn and just stick to that path and get them to a place. And so, I’ll give you an example of one of the courses where I did this, is Web Development in Clojure. I taught just enough material to get someone to be able to make a to-do-list app and deploy it to Heroku, and a lot of people found it successful but a lot of people were like, “Oh yeah, but what is a GET request? What is actually going on there? You say that this Ring request is an HTTP request, but what is that? What are all these header things that you keep talking about?” So, I didn’t explain any of that stuff. And this is kind of going to be a deep thing, but I realize now that one of the reasons that we like Ring in the Clojure world is because it gives us access to the raw HTTP request but in a very convenient format for us—it’s in a hash map—and we like the control. We like to write our own middleware that does exactly what we want it to instead of relying on a framework where half of our time is spent configuring the framework, the other half is spent finding a plugin for the framework to do what we want or like figuring out, “Where can I plug this thing in to make it do this thing?” And since what we want is that control and that, I guess, deep engagement with the protocol, “Just give me the raw HTTP and I’ll stream back raw HTTP, and it’ll be this glorious thing where I’m interacting with your browser,” I have to teach that. That is the thing to teach, the protocol and how browsers make requests and, “Why is it that with a form you can only do GET and POST but there’s DELETE and PUT that no one talks about? What is a method?” All these things, “What is MIME? What is a MIME content body? What is this stuff, MIME-type content, Accept /, what is that?” all these things that I somehow have picked up over the years of working on the web and, now that I know them, I love being able to get in there in the raw HTTP request and raw HTTP response. I love it. And so, that’s what I have to teach how to get someone to love that so that they don’t want the framework, because that’s what the framework does, is it hides that from them but now they’re safe. They don’t have to—not that they don’t have to learn it, it’s that they can start working without learning all that stuff.
[00:20:57] So, anyway, in my next version, which I’m not announcing—I don’t know when I’m going to do this—but the next version of the web development course will be that. It will be the web from the perspective of Clojure, a Clojure programmer. So, you heard it here. I’m not announcing a date. I’ve not even really started working on it yet, but I know that that’s what it’s going to have to be.
Daniel Compton: That’s a massive topic, yeah, the web is just so big. It’s kind of in some ways a little bit cruel that you’re saying there’s so much for beginners to learn and there is in any language, but I think the web in particular is just so what it means to do web development is so sprawling and you have to learn many different languages, environments, concepts, client-server, HTTP, a little bit of networking. There’s just so much stuff there. So, if you can simplify that and explain that, that’s a lot of work.
Eric Normand: Yeah, I mean, that’s the challenge, and I know I’d said my last course was nine hours – this might be 20 or 30, a hundred hours. I have no idea. And, of course, you have to chart some kind of path through it so that they’re not overwhelmed. You can’t just start with everything. But, I think that there is a path. It’s kind of been brewing in the back of my mind. I’m seeing it more and more like I have to create Clojure programmers. Instead of saying, “Okay, you’re a Clojure programmer and you want to learn how Ring works,” which is kind of how I saw it before, it’s more like I have to make it so that someone can finally appreciate why Clojure programmers like Ring so much, because a lot of people don’t. I mean, a lot of people do appreciate it who are coming at it from a certain place, certain amount of experience, but a lot of people look at it and they’re like, “What? That’s it? That’s all I get? It’s the HTTP request? Where do I go from here?” I want to get them to the point where they’re like, “Oh, all I get is the HTTP request and that’s perfect because now I can do what I need to do.”
[00:23:11] So, I feel like that’s one of the great things about Clojure, is that we don’t overcomplicate things. We add a very small layer of indirection and it’s a high-leverage layer of indirection, and then we say, “Okay, here it is. You don’t have to parse this HTTP request from raw character streams. We’re giving it to you in a really nice format and that’s all we’re doing.”
It’s similar to how the CSV parser is in Clojure. It’s just like, “Here’s a vector of string,” if it’s a vector of vectors of strings or it’s a lazy list of vectors of strings. Whereas I know in other languages, they’ll do things like turn it into hash maps for you, assume that the first row is a header and do things where it’s like, well, you’re making assumptions now. CSV does not specify that. CSV is just commas. It’s on the new lines and quotes in case you need them. There’s not much more than that. And Clojure, as a language, very much—I feel, as a community, we recognize that. The useful thing that this library can do is as little as possible and let the end programmer do what they need to with it.
Daniel Compton: [00:24:35] Hmm. I like that, that idea that the useful thing is to do as little as possible, kind of distills a pretty key aspect of a lot of Clojure libraries, which I’ve never quite heard expressed in that way. So, yeah, I like that.
Eric Normand: It’s one of the things I really love about our community, and it’s not the kind of thing that you can shout about like, “We do as little possible and that’s why we’re great!” I think that there’s a lot of I guess magic in some other language communities where it’s like, “We do the right thing 90% of the time! And that other 10%, go find another library.” And those kinds of things, I don’t know, I feel like they’re not for me because I somehow am always in the 10% and, yeah, I just want—just parse me those commas out and handle the edge cases and that’s it. Just give it to me raw. That’s the kind of person I am.
Daniel Compton: So, you’ve been working in the Clojure community for a while and video courses is something you’re pretty well-known for, but what are some other things people might have gotten from you or want to get from you in the future?
Eric Normand: Right. I’m probably best known for my newsletter. So, it’s a weekly newsletter, email newsletter that is made to inspire Clojure programmers. It used to be like 10 links, 10 things that I liked during the week, but it’s evolved now to be the more teaching, more kind of like, “Here’s some useful Clojure knowledge.” But, of course, it evolves over time. It’s been many different things. So, get on that if you’re interested. If you haven’t gotten it in a while, I know that as your list grows it’s more common to get put in spam folders and things, and I have met people who are like, “Hey, you haven’t done your newsletter in a while.” I’m like, “Uh, yeah, it’s every week. For the past five years, I haven’t missed a week.”
Daniel Compton: [00:26:38] You’re up to episode 327.
Eric Normand: That’s right. I typically don’t miss any. So, yeah, you might want to re-subscribe. You might not be getting them anymore.
Let’s see. What else? So, I’ve got a podcast and the podcast is about functional programming in general, so it’s called Thoughts on Functional Programming. It started as me working on ideas for a book that I’m writing for the general programming community, not Clojure specifically, about functional programming. I feel like functional programming has not really broken out of academia in a useful way. Of course, a lot of ideas have come out of academia and are now being applied in production, but they’re still very academic. It’s still people reading papers or textbooks about functional programming, and the people who read them and study them become like academicians, like sort of armchair academicians, and I think that there’s a whole army of people who are doing functional programming in a software engineering as opposed to the computer science. So, software engineering stuff with it, that’s just not being written down. Their perspectives and things are not being talked about in books. So, you know, books are like a literature. They’re like a discussion format. If you look at object-oriented books, there’s all sorts of books about design patterns and how to architect your O code. There’s just a lot discussion there, but there’s a lot of functional programmers and we don’t have a lot of discussion. And so, I wanted to make a book that kind of opened that discussion up, like, “Let’s talk about this in a much more practical and friendly way and talk about, what are we doing as functional programmers that is different from object-oriented programming?”
[00:28:50] So, my podcast is me exploring those ideas, and then recently I kind of went to, I call it season two, where I’m going through functional programming ideas, explaining them. It’s much less just my thoughts and much more a systematic, like, “Let’s just teach this thing.” So, that’s what it is now.
I have a lot of subscribers. I get a lot of good feedback on it. Not trying to toot my own horn, just saying like you just check it out. If you’re interested in hearing functional programming ideas but from a much more practical perspective, yeah, there’s going to be a link in the show notes.
Daniel Compton: Great.
Eric Normand: And so the book—I think I can announce this now—it’s very close to being in the early access.
Daniel Compton: Wow.
Eric Normand: Right. So, it’s going to be published with Manning and they have a program where, before the book is 100% ready, you can buy a PDF version and also the online HTML version. You get it at a discount, and then you get updates as they come up, right? So, new chapters come out or I edit an older chapter or something, that will come out and you’ll be notified and you can bask in the novel chapter.
Daniel Compton: We’ve kind of mentioned a few times, you’ve been doing this for a little while and I feel like you’ve probably got a decent perspective on sort of what’s changed especially in terms of people new to the Clojure community over time and maybe people’s attitudes coming to Clojure. What’s stayed the same, what’s different that you’ve seen?
Eric Normand: Right. Well, the big thing is that it is now much more mainstream. Clojure itself is like a viable option and, I think just in a larger context, any non-top-three language is now a viable option. When I started with Clojure, if I mentioned that I did Clojure to another programmer, they’d be like, “Why don’t you just use Java? How is it better than that?” right? And it was just very hard to explain. They’re like, “Different languages are better at different things,” and the idea was that Java has everything you need and like, “Why are you searching elsewhere?”
And this is the same for Ruby. If you mentioned you were into Ruby or—man, I don’t even know if Erlang was on people’s radar back then. I don’t know if it’s just the number of programmers has exploded or what, but it’s now possible to not be a Java programmer, right? And so, that’s great. You can just be much more open about liking Clojure.
The community is way bigger, that’s for sure. I lost track. I think back in 2011 I started making a list of everyone who was active enough to have a blog or like seen them in a conference talk, you know?
Daniel Compton: Mm-hmm.
Eric Normand: And I had a list going with like, “Oh, here’s the link to their blog and here’s the book they wrote and here’s their conference talks,” and man, that’s impossible now. There are just too many people. I mean, if you look at the number of companies that claim to use Clojure, it’s just enormous. There’s just no way to reconcile that with like, “Oh, I want to keep up with all these.”
[00:32:11] And then, so there are more projects, too. I don’t know, it must have been three or four years ago where I was following, just to get ideas for the newsletter, like things to link to in the newsletter, I was following some people who were pretty good at keeping up with all the projects that were coming out and I could keep up with that feed and sort of figure out, “Oh yeah, I see what this is about. I see why I would need this.” But now, it’s just too much. I cannot keep up.
And I’ve realized it’s not the kind of thing I like doing anyway. My newsletter was never really about news. It wasn’t like, “Here’s the new thing!” like how I guess you have to do in the JavaScript world. It was much more about fundamentals about even like, “This talk was given in 1972 and we just found a recording. Everyone should watch this,” more so than like, “The new Clojure-con videos came out, so let’s watch those.” No, “This old talk is actually much more useful, so watch that.” And so yeah, I just gave up following stuff.
I still get people asking me questions like, “Hey, I’m trying to connect this library to this database and I’m having trouble. Do you know how do it?” I’m like, “I’ve never heard of that database, that library,” like, “Oh, I guess it is a thing. Look, it’s on GitHub, but I don’t know what that is.” And they’re like, “What? You never use this?” They’re like, “How can you live?” And I’m like, “I don’t know. I don’t try every new thing that comes out. I try to find stable things that I can rely on for a long time and this one just never crossed my radar.” So, that has changed.
I remember back in the day—I got into Clojure in 2008—back in the day, when libraries would come out, they were mostly wrappers. So, it was someone made a Clojure idiomatic wrapper around some existing Java library, and that was a big deal. That kind of tapered off because I guess the important ones got wrapped and then that phase was over. We didn’t need to do that anymore. Then, we had this kind of explosion with, I think David Nolen entered the scene and we had this explosion of like core.logic and all these things that were like, “Oh my goodness, we’re going to have so much power versus other languages, compared to other languages, that it’s not going to be fair.” And I just was waiting for this time when it would just all get connected together and we would just, I don’t know, be so much more productive than any language it’d be obvious that you’d have to go into Clojure to compete. But, that of course never happened. And now, it’s just like new things popping up here and there but I don’t see any real patterns to them, which is fine. I think it just means that our community’s big enough that there are sub-communities. There are little pockets in it and you can’t really be in all of them.
Daniel Compton: [00:35:21] Yeah, interesting insights over time. I sort of [00:35:25 have been] around quite as long as you, so I certainly remember those days of it felt like every other week there was [00:35:32 something groundbreaking,] like, “Here’s core.async. Here’s core.logic. Here’s this program rewriting program rewriting program.” And, yeah, I definitely think we don’t see quite as much of that anymore and, yeah, I mean it’s probably interesting to sort of look at why. Is it just all of the good ideas have been had? Or, probably not. I hope we’re not out of good ideas. But, certainly I think Clojure feels like it’s at a more stable or mature place in terms of those kinds of innovations.
Eric Normand: Yeah, that’s a really interesting phenomenon. I’m not sure what’s going on because a lot of it, like if you plotted stuff on a timeline, would you see this big bunch of closely grouped spikes like, “Oh, look at all this creativity!” and it just kind of tapers off into where it’s like, “Oh, now it’s like every year or every two years where there’s a big thing.” I’m not sure if that’s the case, right? We’re only working based on our memories.
Daniel Compton: Yeah.
Eric Normand: A lot of times when you look at the past, what happens is when you started learning Clojure, you had to learn all the existing stuff and all the new stuff coming out at the same time. You could choose between all of them. So, it all seemed like, “Oh, there’s so much,” in the early days. But, you don’t really think about how much time it took to create those things that were new to you but had already existed.
So, I always look at those kinds of things with a grain of salt when people say like, “Oh, things are slowing down.” It’s like, no. For instance, I feel like—this is a personal perception that I do not trust—but I feel like conference talks are not as good as they were before, and I watch a lot of conference talks and I find myself getting bored faster. I find myself stopping or skipping in the talks. But, what I wonder is, is it me or is it the talks? Because I’ve watched so many, I’m a different person from when I started. And there are definitely more and more talks online now. More and more conferences are recording their talks, and there are more conferences. So, maybe that idea of getting bored is more that there might be other ones that I could be watching instead that I’m drawn to. I just don’t know.
[00:38:04] I just remember finding so many great talks when I first started getting into YouTube. This is like 2007, right? There were just so many great talks. But, I just wonder if I haven’t grown as a person and learned from those talks that now it seems like, well, you’re just going over old material now. If that same person gave that same talk today, I’d be like, “Ah, this is old stuff. You’re just rehashing the stuff everybody knows.” But, maybe people don’t know it. That was kind of a rant, but I’ve watched a lot of talks to do newsletter stuff and I’ve just found that I’m not as interested in it anymore, one of the reasons why I evolved my newsletter away from that.
Daniel Compton: Yeah, that’s an interesting thought, more data probably needed.
Eric Normand: Yeah.
Daniel Compton: So, is there anyone you’d like to thank or mention in closing?
Eric Normand: Yeah. So, I think the Clojure community is better than it has ever been. I know that there’s often drama in communities, but that’s just the nature of communities. We just have interpersonal things that come up and we have to talk about them. I think that the number of people getting into Clojure, the number of books coming out, the awesome stability of Clojure, it’s just amazing, and I just want to thank everyone who works on Clojure core, everyone who works on open-source Clojure libraries, everyone who blogs, who answers questions in Slack. All of that is just so awesome. You all rock for doing that and just thank you. Thank you so much for making it an awesome community.
Daniel Compton: Yeah, I agree. And, anything you’d like to plug?
Eric Normand: Yeah. So, actually, I have two things I’d like to plug. I’d hear a lot about it if I didn’t mention that there’s a YouTube show I do with three fine co-hosts.
Daniel Compton: Of course, yeah.
Eric Normand: It’s called Apropos and it’s just us. We talk about some news. It’s a lot of opinions, and then we get into the REPL session. So, we have a problem, a little programming problem we work on, and we just dive into a REPL and try to solve it live like we usually have not done before. And we answer questions in the YouTube chat and it’s just a fun time. We always joke that the number of watchers goes up when we start on the REPL, like people don’t want to hear us talk. But, you know, a lot of people like to join in the discussion, and we don’t know everything so we often ask our nice audience to help us figure out the right answer. So, do find that. If you’re into that, if you’re into more Clojure content, I feel like there’s always room for more.
[00:41:07] And then, okay, the next thing I want to plug is PurelyFunctional.tv. If you want to learn Clojure, I consider it the most comprehensive thing available online. I’ve lost count of how many hours of video there are on there. There are multiple-books amount of text available for free on there, and you can get a membership and get access to everything. See if your job will pay for it. If you’re working in Clojure, they might have a budget, a training budget, for you, and yeah, check it out. Ask me if you have any questions about it. You can find my email address and I’d love to just get in touch.
Daniel Compton: Great. I really appreciate all you have done and are doing for the Clojure community in helping grow the next generation of Clojure programmers.
Eric Normand: Well, you’re welcome. I do what I can. Daniel, thank you. You’re another one out there spreading the word about Clojure, so thank you for everything you do.
Daniel Compton: Great. All right. Well, have a great day.
Eric Normand: You, too.
[00:42:12]