Functional Geekery Episode 18

In this episode we cover my background in Clojure, my Clojure videos, core.async, teaching new topics to people, the Pre-Conj Prep for 2014, and my Clojure Gazette.

Functional Geekery Episode 18 [PODCAST]

Transcript

**Steven Proctor**: [00:00] Proctor, here, with a quick announcement before we get into this episode. Bruce Tate's new book "Seven More Languages in Seven Weeks" has been sent to the printers. It has been updated to include Elixir 1.0and the latest available version of Elm. If you enjoyed Episode 15 and are curious about the seven more languages mentioned, now is the time to get it.

[00:19] [beeps]

**Proctor**: [00:21] Welcome to the 18th episode of the "Functional Geekery." I'm your host, Proctor. This week with us we have Eric Normand. Eric, would you mind telling everyone a little bit more about yourself?

**Eric Normand**: [00:29] My name is Eric Normand. I live in New Orleans. I'm a software engineer. I also write "Clojure Gazette" and I do the "LispCast" videos.

**Proctor**: [00:40] I've known you from your LispCast blog and some of your LispCast videos. Just for some background, how did you get in to Clojure?

**Eric**: [00:50] Man, I got into Clojure because I was into Lisp. I've been into Lisp since 2000, 2001. I went to the Lisp's 50, this was back when Lisp was still very fringe. The Lisp 50 was the 50th anniversary of the publication of the paper that introduced Lisp.

[01:13] There was a panel on the future of Lisp. Rich Hickey was there, and he gave a talk. He presented Clojure and what was different about it from Common Lisp and Scheme. It was intriguing. I was a little skeptical, but I went home and I tried it, and just started getting into it, and I never looked back. That's how I got into Clojure. That was back in 2008.

**Proctor**: [01:37] You did have Lisp experience before that, right? When you were going to the Lisp's 50 and everything?

**Eric**: [01:43] Yeah, I used Lisp. I wrote my own Lisp, because I heard that you could do it in a weekend, and I wanted to have my own language. I used Common Lisp. I actually had a little startup, lasted a couple of months, and I wrote a web server in Lisp. I did all my school projects in Lisp, once I learned about it, in University. I've been using it for a while.

**Proctor**: [02:08] You seem to have gotten into the functional programming pretty early on, if you started doing college projects.

**Eric**: [02:15] Yeah, and it wasn't even the functional programming that got me started. It was mostly that it was a better option than Java. Even Python was obscure back in those days. I used Python too, but I just really liked the Lisp abstraction, the list, the console, that you use everywhere, and so your functions can tag team on the same data structure. It just gives you a lot of power.

[02:41] What happens in Clojure is you actually have more data structures. Instead of a list, that's a data structure. You have the seek abstraction that gives you that same power, but over multiple different data structures. I feel like it's a much more modern approach to that same problem.

**Proctor**: [02:58] As I said, I found you via your LispCast blog, which you seem to do a pretty good job of regularly pushing out content. Subscribing to Planet Clojure, and stumbling across that when I started looking at Clojure, the LispCast blog was one that came across frequently. It was very helpful when I was getting into Clojure and finding resources.

**Eric**: [03:20] Well, I am glad. I feel like I'm not doing such a good job at that, and it's because of my perspective. I feel like I am more experienced and I didn't really share my whole learning process on a blog.

[03:35] It's still early days in Clojure, but I feel like the Clojure blog space is lacking in a lot of those beginner things, like someone exploring "This how you merge two maps," because I know how to do that.

[03:50] I have done it hundreds of times, but I can imagine a beginner doesn't know that there is this huge core library out there that they could just find it if there was somebody at the top of the Google search results.

[04:03] Actually, to come back to Planet Clojure and stuff, one of my goals is to start dumping everything I know into my [laughs] blog and just having small, bite-size, "Oh, here's how you solve this problem. Here's how you solve that problem," because...I don't know. If no one else is doing it, I guess I have to do it.

**Proctor**: [04:21] Yeah, it's one of the things that I've noticed myself, just with me growing as well in my knowledge of different languages. We start to make assumptions about, "Oh, here's what we know from the perspective of knowing it now versus," as you said, "merging two maps."

[04:37] It's something that's obvious when you know it, but when you don't know it, you don't realize it's there. It's one of those great sources of fresh content that seems like it should be easy to produce pretty quickly.

**Eric**: [04:49] I'm going to give away a whole bunch of secrets here. I'd love for other people to take on this task. If you're looking for content, just go through the standard library alphabetically for each function and write a post about it. Just link back to the official documentation, and just write a post about the function vector that is a variable number of arguments and creates a vector.

[05:15] Just write a little post about it and three or four different ways of using it. That's so much content right there. You could fill a whole year with that and fill up your blog, get some hits, get some Google Guice, help some people out.

**Proctor**: [05:29] Yeah, that sounds like a really great tip that seems obvious once you say it, but is one of those, even giving away your secrets, hopefully this audience is a lot wider than just the Clojure.

[05:40] If we have people going Scala, Haskell, Erlang, Elixir, and Elm, and any of these other number of languages, that seems like it would help the whole functional community as a whole and being able to just produce massive amounts of content in a relatively shorter time frame than what it might normally take.

**Eric**: [05:59] Sure. Like I was saying before, I don't know if I made this point very clearly, but because of my perspective, I have trouble figuring out what I should write about because I wanted to be smart and insightful, and all these things that are about me. Really, it should be about the audience and what they need.

[06:19] What they need is obvious because it's not there. They just need people talking about the basics. I go through every now and then and I'll just randomly flip through the clojure.core documentation because there's still stuff I don't know in there. There's still stuff that I don't use often enough to use all the time even though I should, like the function juxt.

[06:42] I didn't know that was there for years, and it's been there a long time. At some point, I started seeing it everywhere. I was like, "What is this function? Why are people using it all the time?" I started using it. Then you forget about it and then it goes away from your own code base and you stop seeing it. Then you see it again like, "Oh, I should be using in that. That'd be perfect right here.

"[07:04] I wrote my own custom thing." It's a good practice for yourself, and it's a good practice to get that stuff out there for other people. Part of what I really appreciate about blogs, especially when you are first starting, was it started to get to...You could just type in an English description of that problem and it would come up in Google, somebody's blog post on it.

[07:25] I don't know Bash, the shell scripting language, but I can solve any problem just by typing it into Google, and someone has written a close enough Bash script that I can cannibalize it. I love that. I think that's great. We just need more of that with these more obscure languages.

**Proctor**: [07:42] That's really good advice for people no matter what your expertise is because, as you said, there's always stuff that you forget about or you don't even realize is there and one of those refreshers.

[07:53] If I'm not taking on the perspective of the beginner and trying to figure out what the beginners needs, which leads me into one of your other projects was, was it a year-and-a-half ago maybe or maybe a little longer, you had a Kickstarter for some intro to Clojure videos that actually were part of your list cast off and that you were promoting.

**Eric**: [08:14] That's right.

**Proctor**: [08:15] I believe you met all your backers. I got the videos because I backed it, so I'm thinking you had enough backers to actually meet that Kickstarter thing and release them.

**Eric**: [08:27] Sure. The Kickstarter was successful. It's all on the website. My goal was 3,000 and I made a little over 4,000. I don't remember the exact number. I was totally happy with that and did some background.

[08:45] The reason I did a Kickstarter was I didn't want to start making these videos because they are time-consuming, etc. I didn't want to make them if I wasn't going to get enough customers. It was a way to test the market. If I couldn't get $3,000 then I wasn't going to do them and I'd be happy. I'd be happy, "OK, there's no market, I just won't do them." That was my test.

[09:12] What I didn't think about was that I didn't really want it to be at $3,000. Because I set the price of $5, I thought it would mean that I would have a certain number of backers and not a certain number of dollars. I was hoping for, I can't remember now. What? 300 people backing and it turned out that...I'm not doing the math right, I'm sure.

[09:40] I wanted a certain number and it turned out to be way less than that because some people gave too much. I had a five-dollar level, that was it. Just one five-dollar level and a 500-dollar level for a corporate sponsor.

[09:52] At the five-dollar level, I was like, "Oh. Well, if I get so many backers then I'll hit the number and I won't have to do the videos [laughs] if they're lower than that." Some people were like, "Oh, I just want to see this happen, here is $100." I was like, "Oh, no. It's cool that he's really excited about it, but that's 19 backers [laughs] extra that he's counting for.

[10:16] He wouldn't buy 19 more videos. It didn't answer the question I wanted to answer, which was, "Can I get X number of customers?" Instead I got another thing, which was, "A lot of people are excited about it. Not sure about the number of customers." That was the thing. It was still like, "Oh, it hasn't really answered the question, so it's still a big risk. It's still a risk to do these videos."

**Proctor**: [10:41] It sounded like you were trying to use it to, essentially, be like a lean pub approach of trying to just gauge interest.

**Eric**: [10:48] Yeah, trying to gauge interest. That was exactly right. Trying to see if I could multiply it out and say, "Well, if I could get so many people in 30 days, well, I'll be able to make a living at it," or something like that.

**Proctor**: [11:01] I mainly bring it up not about the Kickstarter point, but the fact that you actually started with the "Intro to Clojure" videos instead of going off and saying, "OK. Here's some Clojure tips and tricks for the intermediate to advanced." You stared out with the, "Here you go. Let's start out with Clojure," and assume you don't know Clojure and I will help walk you through it.

**Eric**: [11:26] Right, and that gets to the heart of my objectives with the business. One thing is, I really like teaching the basics a lot more. It's more satisfying to me to see someone who had no knowledge and maybe even no way of getting that knowledge now having the knowledge, whereas a lot of the intermediate books, they assume so much knowledge.

[11:49] Like, "Yeah, you could have read a different book and gotten this same information," let's say, but with the intro ones you're guiding someone through the whole issue with the syntax and the parentheses that they're not used to. A different kind of thinking with functional programming and the immutable data structures.

[12:08] It really is different from, say, JavaScript or Java. I don't know. I really like that. I like breaking down the material into a step-by-step learn this, then that'll let you get to this next level where you learn this, and then get that ingrained, then you can go to the next level.

[12:25] I really think that's missing in a lot of material, that teaching. People will write down what they know, but they don't actually take the time to put it into the form that's easily learned.

**Proctor**: [12:37] I thought that was really good just to be able to have that as a good resource for...I had started to get into it but it's one of those...Again, reading the books, it's still in relatively the early days of learning. It's like every different perspective you can get gives you the potential for that many more insights because someone else thinks about it differently.

[12:56] Everybody's going to use different metaphors when trying to explain how the immutable data structures work. You could have 10 different people explain it to you and you may not still get it until you get the 11th who happens to have the perfect metaphor that you understand based off your shared context.

**Eric**: [13:15] Right, and that's true, too. That's actually really good advice to anyone out there who was thinking about writing a tutorial or something. The more, the merrier because some people will prefer yours and some people will prefer another one. Some people want both. Don't say "Oh, Cal Kingsbury wrote this really great intro to Clojure. I shouldn't write one."

[13:36] No. You should write one, too, from your perspective. The stuff that you wish you had known going in. The stuff that you see other people struggling with when you teach them. All those things are really great.

**Proctor**: [13:47] After that, you also did another one, which was the Ring adaptors and building a Web server using Clojure, right?

**Eric**: [13:56] That's right. I called it "Web Development in Clojure." It's basically the stuff that I would assume that someone knows when they say, "I do Web development in Clojure." It's Ring — you pretty much have to know Ring — and the three concepts of adaptors, middleware, and handlers and how they all compose together.

[14:17] Then you have Compojure which does your routing and Hiccup which renders your HTML. Those are the three main things that you learn on those videos. How to put them all together and make a Web server.

**Proctor**: [14:32] I believe you've got a few more videos out. Do you have another set out or are they coming soon?

**Eric**: [14:37] Core.async. By the time this podcast is published, my video should be out. It's a core.async videos. More business side of it because I think that's interesting. It's interesting to me when I listen.

[14:49] I did the intro. Like I said, I like teaching the basics, but, also, it works out well because, at least in theory, the intro market is always bigger than the people who already know the content. That was my idea there, to help bring people from outside into the Clojure community.

[15:10] I did Web development because I felt like it was an obvious series that needed to happen. I wasn't expecting very much, but it sold so much better than the intro. It could just be because of my reach, because people who listen to me already know Clojure, so they obviously are the ones who are there.

[15:32] It made me think that maybe there was a market or intermediate material for people who already know Clojure. That led me to think of the opposite extreme from intro which was a one...I would call core.async an advanced library. Not that it's hard to use, but that it's new and it's not something that everybody is going to be using already.

[15:57] Yeah, core.async teaches the fundamental concepts of core.async. Breaks it all down into bitesize chunks with exercises that help you train yourself to just type it and think in that way automatically without having to use too much of your forebrain. You should be thinking about the problem not about core.async.

[16:19] We go through a whole process where you're...I like to have stories in my videos, so you're helping a toy factory make more toy cars. You're helping them make their process more concurrent. They only have one worker. They need to hire more, but they don't know how to get them to work together. You're helping them by using core.async.

[16:39] You're learning the concepts as you need them. By the end, you should have everything you need to go further, to start reading the documentation. You'll understand the main concepts. The main concepts in core.async are go blocks, channels, time outs, and then what's called alts, which lets you select off of multiple channels. Put in tape those basic operations.

[17:04] You learn all that. Core.async is nice because it has small core set of concepts that everything else builds on. Once you learn those concepts, you can go and read the documentation, read a blog post about what someone has done with core.async, and you'll be in. You're now a core.async programmer.

**Proctor**: [17:21] Is that just core.async as the language feature or is that core.async and the philosophy of concurrency in Clojure?

**Eric**: [17:30] It does talk quite a bit...I don't know if I'd call it philosophy, but it's the practical side of using core.async, not just...You could read a bunch of blog posts and say "Oh, this is how you do a put. This is how you do a take."

[17:44] In these videos, it talks more about how you analyze your problem so that you know where to put your concurrency. You know how to break it down into different processes and when and how they should communicate.

[18:01] You've got your channels and you've got buffered channels. What kind of buffer do you want? Well, how can you tell? Core.async, it's not deadlock free. You can create deadlock situations. How do you detect those and how do you mitigate against them? All those things are in there.

[18:16] It's not just like a technical reference manual, this is how you do a take put, this is how you do a take. It's practical.

**Proctor**: [18:23] I think you covered what I was implying by philosophy. More about the how do you think about concurrency being that you're in Clojure versus how do you think about concurrency if you were in Haskell, or how do you think about concurrency if you're in Erlang, and muddle that problem set.

[18:41] It sounds like you are covering that aspect where it's like, "Look, here's how you get your appropriate granularity and when you might want to be concurrent versus do all these things..."

**Eric**: [18:50] Sequentially.

**Proctor**: [18:51] sequentially, together, and possibly think about Amdahl's law — I think that's the right name of it — which is you get locked by the slowest part of your system at that point.

**Eric**: [19:05] Right, and you have some external systems that you can't change and so you have to deal with those properties. There's some struggle when you go from a sequential program into a concurrent program. You've made some assumptions when you write that sequential program that now are no longer good assumptions.

[19:26] Yeah, there's all sorts of...I don't want to call it discussion. They're all present practical problems in the factory, so we work through them. We just work through them. We don't discuss.

**Proctor**: [19:37] I'd seen some teasers of it, again. Having some things at the bottom of your blog post with the different things where you say, "Coming soon, a new series."

**Eric**: [19:49] By soon I mean [laughs] someday. They took a long time to come out. Much longer than I thought. I actually started working on — this is my third set of videos — back right after I released the web development videos. I released the web development ones right before Clojure/west in 2014.

[20:08] Then I went to Clojure/west and basically didn't work on them, but I started right after I got back. That's been like seven or eight months. It's shameful how long it's taken me.

**Proctor**: [20:20] That actually sounds pretty impressive by my standards, considering editing audio only and what it would have to take edit audio and video, and probably join audio and video together the way I hear most people do screen casts.

**Eric**: [20:35] Yeah, well, I actually talk to you more about process. I spent a lot of time, while working on these videos, trying to get the process better because I do want to make them faster. I want to make more. That was one of the things, this animation, this screen cast format, it just is so time consuming.

[20:56] I tried so many things, like delegating it. I researched animation studios and how much it costs. It actually turns out to cost something like $1,000 per minute to do animations. Now, I think that they do much better animations than I would do and more complex animations, but it just goes to show that it's not something that I could even hire out to do.

[21:19] That was a detour, trying to just storyboard it and send it to someone to do. That didn't work, so I wound up trying it myself. I bought some animation software that's used for cartoons and I started doing it. It was like two months later I had like 10 seconds of animation. [laughs] I was like, "No, this isn't going to work either."

[21:39] My vision was to have this really great video with characters that have voices and all these things that you would expect from a really high-end video, and it was just never going to happen. I was never going to finish it. I just pulled everything back and started doing very basic animations, the kind of stuff you can do in Keynote.

[21:59] I just dissolve between two different hand positions. It's still effective. It's certainly not as fun as seeing stuff walk around on the screen, which is what I wanted to have.

**Proctor**: [22:10] I was thinking of just going back and having to rerecord or reedit things, especially when you've made it. It sounds closer to what I hear about books — by the time you get to an idea, it's like, "Oh, we've got to completely rework this whole example again and start from the ground floor because we need to throw this in.

"[22:27] Which means all or that time recording or shooting video or whatever has to be reedited now because we've got this other feature."

**Eric**: [22:35] Right, and that contributes to the length of the time, certainly. You've got to do all your prep work up front. You've got to write out all the code that you're ever going to type. Make sure it all works, you don't have any typos, that it actually does what you're expecting. Because you're typing, you try some code, and, "Oh, that didn't work." Go through all of it from the beginning to the end.

[22:55] Record it all in a text document so you can refer to it later. That's basically where I start. I might be writing down little ideas here and there for metaphors, imagery, and stuff, but the backbone of the videos is the code that I want someone to be able to type at the end.

[23:13] Then you have to go through and break it all down. How did I choose this code? How did I know to use a go block here? How did I decide to break it up at this point into two go blocks instead of having one big go block?

[23:28] Those kinds of decisions are really hard to externalize, but that's exactly what you have to do as a teacher, figure out what concept does someone need to be able to do this. What skills do they need? How do they know how to apply them?

[23:41] I start with that code. Break it down. Sometimes you have to change the code. You're like, "Ah, this step is too big. I have to do three steps to get here." Maybe I'll write longer code and then I'll refactor it down to that, even though eventually they should be able to write that one directly, but it's just too many concepts at once.

[23:56] It's this long process before you even start recording. I don't want to record anything until that's all done because I'm going to have to go back and rerecord it anyway. It's unfortunate because I'd like to do something where I could release one as I'm working on it and by the time I get to the end it's a whole series and it makes a lot of sense, but I don't know how to do that.

**Proctor**: [24:17] What's even more impressive to me is the fact that, hearing from people how much video production takes, you're still able to put out other content as well. You've got your Clojure Gazette and, for the Clojure/Conj that will probably be happening around the time this comes out, you've also been doing posts at least weekly, if not a little more often, about...

**Eric**: [24:40] [laughs] The pre-conj stuff?

**Proctor**: [24:42] Yeah.

**Eric**: [24:42] The pre-conj stuff was every day. Every day was something.

**Proctor**: [24:46] I was about to say, it seemed pretty often.

**Eric**: [24:47] I'm so glad I did it, but that was a rough, I don't know, three or four weeks of...What I did with the pre-conj was...My friend Marcus suggested to me that he's going to the conj, but he's kind of new to Closure, so he's looking at the talk descriptions.

[25:06] He's like, "I mean, I could start looking all this stuff up, but I just don't know where to start and I don't think I'll finish by the time the conj comes around." He said, "What if we had something that had a longer description with references to other things." I was like, "Oh, that's brilliant."

[25:22] I just started working on it knowing that it was a ton of work and it would also delay the videos, but I took each description and I wrote out an email explaining what I could gather of the background of the talk. I'm only guessing, too, what they're going to talk about from that description.

[25:41] Then I went and I found videos or other posts about those topics that I thought would be useful in understanding the context. I always thought about Marcus as the perfect audience for this because he's a smart guy, he's into Clojure, he's learning it, but he hasn't followed the thread of Clojure as far back as I have.

[26:03] I've watched every video from every Clojure/conj, every Clojure/west. I know the thread of conversation. I know how it's evolving. I know what's important to know to be able to understand where we're at now, which is what the talk it going to be, and the trajectory that it's going in.

[26:21] Perfect example is — I think it was a couple years ago — there was a talk that was called (not= DSL macros) because, from Common Lisp, Clojure inherited this idea that you can write your own DSLs with macros. It's very powerful and it's a good practice, but in Clojure, because we have a wider variety of literal data structures, it's actually easier to do data-driven programming.

[26:48] Christophe Grand's talk, this was (not= DSL macros). That introduced this idea that only use macros if you have to. We should be doing DSLs in data structures because we have so many that usually you can fit it into the data structures.

[27:04] Now there's a talk at the conj that is taking that to an extreme, which is saying you can define your whole system in data structures. He's going to give an example of how that's done, but that thread is kind of lost if you just read the abstract from the talk page, from the speaker's page.

[27:24] I try to give someone that. Like, "If you're interested in this idea, you just take a step back, watch this video from a few years ago and you'll see that this is a point on the line that's going on." I did all those. There were 19 talks. I wanted to make it even bigger, so I started asking all of the speakers if they wanted to do an interview. [laughs]

[27:47] Not everybody said yes, but I was doing 15 or so interviews at the same time, which was kind of intense, but I got them all done and they're out there now. If you want to sign up for it, it's on my blog. If you do, lispcast.com/pre-conj-2014, with hyphens — pre, dash, conj, dash, 2014. You'll get the page with the sign up form.

[28:10] If you sign up now, you'll get one a day starting with the first one. You should do that if you want to get ready for the conj.

**Proctor**: [28:16] I'll make sure to include that link in the show note.

**Eric**: [28:18] Sure. Thank you, yeah.

**Proctor**: [28:19] It sounds really interesting, the perspective you're taking there. This goes back to the beginning with starting to document for beginners, but what you're documenting is not just the features of the language. It sounds like you're also documenting the lore of the language.

[28:39] It's like, again, you're telling the story of Clojure and its history or part of the history of Clojure instead of just the data about the closure of, "Here's this function and what it does," but, "Here's the story behind where we are now."

**Eric**: [28:55] Right, and that perspective is something that I've tried to cultivate, even in the Gazette. It sometimes happened because it's just through laziness. I'll write a Gazette issue that's basically, "Well, here's some links I found today. This one is about this. This one is about that."

[29:12] What I try to have is...There's obviously going to be multiple threads happening at the same time, but I try to give this sense of where the ideas in the blog post or the video that I link to, where they tie in to the history that we've got behind us. I think it's so important to have a sense of history. We're not just web developers.

[29:35] It's also one of the things that makes Clojure so special, that it does have such an interesting history coming from Lisp. It's got all these influences that postdate Lisp, which is a great thing. It's still a Lisp, but it's got it's got influences from Haskell. It's got influences from Java. It's got influences from all sorts of places.

[29:56] Why not give people a perspective when they're reading something? I don't know. That ties back into the pre-conj, which is...Yeah, Clojure is on a trajectory. The interesting thing about Clojure's trajectory is it really does feel like it's still evolving. It's still making waves in the broader software engineering world, which is one of the things I'm really excited about with Clojure.

[30:19] I've said this before. I don't think Clojure's the perfect language, or the best language possible, or anything like that. It's simply so fascinating to watch, I don't know, 30 years of software engineering and programming language theory bake into this language. I really appreciate that.

**Proctor**: [30:38] That's one of the things that fascinated me about Clojure, too, that you mentioned is they've taken all these old views that people have forgotten about and have brought them in and put new twists on them because it's...Now, we've gotten a little bit with this influencer a little bit, or we take these ideas because we're so bad as an industry about knowing our history.

**Eric**: [30:58] It's true.

**Proctor**: [30:59] Rich and the clojure.core seem to be able pull out some of those gems of history and make them fresh, especially with things like Datalog where it's like, "What is Datalog?" Datalog has been around forever, but you see Datomic and it's like, "Oh. Oh, oh!"

**Eric**: [31:14] Right, definitely. The coolest thing to me is that I grew up with Java. It was taught at my university. The thing about it was you always felt like, "Yeah, you could do this X, Y, Z in Java, but, first of all, it's going to be just really hard. You're just going to have to start from scratch and do everything yourself."

[31:35] Then, the next thing was that it's not going to be compatible with anything else. You can't just make something that can be consumed by another library or this other library you want to use. Uh-oh, you have to make an adapter just for that library for everything that you've got in your library.

[31:53] It really was like, "Java's it." When I say, "Java is it," what I mean is, so often, for practical reasons, it is better just to make a for loop and loop through an array. When you look at the trade-offs that you're given, "Oh, I could implement Datalog in Java," versus, "I could just join in memory with a few arrays by hand," I'll just hack it by hand instead of implement Datalog.

[32:21] When you get into something higher-level like Clojure, that Datalog thing looks like, "Wow, that's actually competitive with writing it myself," making this more general solution.

[32:34] I feel like it's something where, because of the choices made to have immutable data structures by default and a strong sense of abstraction — the sequence abstraction, the assoc abstraction, all those things — they let you think at a higher level and program something that, from a high-level description in a paper to the Clojure implementation, is pretty short.

[33:00] It's not the shortest they could be, but it's not intractable like Java. It's something you could write yourself. This is actually something that all Lisps have claimed before, and I think it's true. It's the curse of Lisp, actually, that instead of having a set of really good libraries like Java has, it was so easy to just roll your own for the one quarter of the problem that you needed to solve.

[33:23] It's going to be interesting to see how that plays out with Clojure.

**Proctor**: [33:27] When you said, "Java is it," it made me think about more the early days of Java. It was like, "No, Java is it. This is the thing we've been waiting for." It made me think about, "Look, we got garbage collection. We don't have to manually point this stuff. We got this other stuff."

[33:41] This is what I love about your Clojure Gazette, as with your links. You like, "Look," because you do it for Clojure. The Java when it's, "Java is it," you didn't hear about, "No, garbage collection's been around for years." Not just years, but decades, and we're just now getting the ability to appreciate it.

[34:00] You got it in your Gazette, because I've seen you go from Alan Kay to Haskell to all these other things and essentially tying that history of, "Look. Yes, Clojure's special, but here's these other things that we may be able to get inspiration from."

[34:17] As you said, the curse of Clojure's so small. We could take that and actually put it into Clojure, because it's reasonable to do from this other language.

**Eric**: [34:24] Right. I don't think you should discount an actual useful implementation of something. A research paper is just a research paper. I totally agree with what you're saying. It's very good to see, "Oh, this was something that Lisp has had for years."

[34:43] It's so easy to fall into this smug Lisp weenie problem. I've done it before myself where you're looking at Java and you're like, "Why are they celebrating getting lambdas? Why don't they just use Clojure? We've had lambdas since day one, and what's the big deal?"

[34:59] I think that you should rotate that attitude. Instead of saying, "Why are you so happy?" [laughs] I feel like this sometimes, like, "Why are you so happy for getting some automatic reference counting on your iPhone? You should have had that, [laughs] you know, 10 years ago."

[35:15] I know that it doesn't make sense, but that's the kind of attitude that I get sometimes. I don't know. I think it's a harmful attitude. You should rotate it and start thinking like, "What are the things that I'm missing now that other people are being smug about?"

[35:31] There are lots of good ideas out there in other programming languages, other research papers. We have this platform now. Clojure is a really great platform for abstraction, and we should be finding those abstractions and building them in. There's my little motivational pep talk.

**Proctor**: [35:52] You answered the question of why is everybody celebrating in Java that they got lambdas, is because they've got lambdas. For the longest time, they didn't and they're doing the, "What have we been missing from these other languages?"

**Eric**: [36:04] Right, and there's also something to say of the stability of Java. The byte code hasn't changed. They've added a couple of byte codes in 15 years. The other thing is Guy Steele. Guy Steele wrote the Java Spec. He's one of the writers. He also invented Scheme. When he did that, people were horrified.

[36:26] They were like, "Why did you do this to us? You kind of set the industry back so many years. You should have just given them Scheme and been done with it." He said, "Wait, I brought all the C and C++ programmers halfway to Lisp. Like, shouldn't you be happy? Shouldn't you be rejoicing that now they have garbage collection, now they have safer pointers that's not gonna core dump on them?"

[36:51] It's true that we should celebrate that thing instead of leaving them with just their pointers. At the same time, we need to — something I really love about Clojure — go out there and tell them what they're missing. Not in a smug way, like, "Oh, we had that for years. I'm just going to go back to my code."

[37:09] No, we should be telling them. You see Rich Hickey going around, giving talks about immutable data structures. He talks about values. I think it was RailsConf. I'm probably getting the name wrong. RubyConf or RailsConf, he keynoted. What did he talk about? He didn't talk about Clojure. He talked about immutable values, the difference between identity and value.

[37:30] We should all be doing that. We should go around and say, "Hey, Java, your lambdas, they need work." [laughs] Right? "They need to be better." I know that they've got a lot of constraints on them, but they don't solve this problem that we've got — dysfunctional programming problem. They're just sugar.

[37:45] Sorry, I didn't mean to dis on Java, but we should be going around and helping out. We should be writing Clojure libraries that can be consumed from Java. "Hey, this is something in Clojure that is actually pretty nice to write in Clojure, but I don't think you'd ever get to it in Java, so here it is."

[38:00] I think that Clojure is very quickly approaching the point where people are going to be doing things with it that will stun and amaze people from other languages very quickly. A lot of people will say something like, "Ah, man. I'm gonna start picking on other languages."

[38:16] PHP is basically running the Web, and so many big sites use PHP. There's this question of, "Oh, do we need anything more?" If Wikipedia, one of the biggest sites in the world, can run on PHP, and Facebook is PHP, and all these huge sites are running PHP, does your programming language choice really matter? I think that it's up to us to prove that it does.

[38:42] I think it does, but we have to do something that you couldn't do easily in PHP or maybe even ever in PHP. That's the other problem. With enough work, you can write the same Turing-equivalent program in any language. That's what you see happening with PHP.

[39:00] A really good example is when Rails made this big splash, at least on my radar, with this video that DHH released that was like, "Write a blog in 15 minutes." It wasn't just a blog because anybody could write a blog pretty quickly. What it was was it had all this interactivity. The forms were made for you. The database was all done for you.

[39:22] It had those flash messages, which, to a PHP programmer, he would have to write that all himself, every single line of it. It would take hours to even get started writing a blog. What it really indicated was, "Wow, a small team or one person can make a splash with Rails and get something started and maybe have a first move or advantage if such a thing exists.

[39:49] Then that started the whole frameworks thing. PHP people were like, "Wow, we really need a framework that would let us do that." Now, they've caught up. PHP has caught up just through sheer work. Even though, if you look at it, Ruby is probably a better language to write that framework in. They hacked it together in PHP.

[40:09] I remember, at that point, PHP was very much still form posts. You would get a form, you'd fill it out, and you hit submit. That's how you got data back to the server. Ajax was easy in Rails because it set up those endpoints for you, those rest endpoints. You could just start scripting in JavaScript and have a fully interactive Ajax app in 15 minutes.

[40:34] It took a long time for PHP. A long time. People hours to bang on the stuff enough to get all the rest endpoints, to get that JavaScript written. All of that took time. Now, a PHP app can actually be that interactive.

[40:50] What we need to do as Clojure people is...I don't want to call it a killer app because that's such a bad thing. It's just find those things that you can't do in other language, and we're getting there. We're getting there. I write core.async in ClojureScript. I don't think I could ever write these coordination solutions that I've got with timeouts for multiple things.

[41:13] Start four things at the same time, but I need them back in a certain order. One of them has a timeout and use this default value if I don't get it in time. All these things are really hard to do in Vanilla JavaScript, although now you can do core.async CSP thing in ECMAScript 6. Maybe that's it. Maybe that was Clojure's contribution.

[41:35] Like I said, I don't think it's about Clojure being better, but it's about driving these ideas back into other languages, sucking in good ideas, and making a big wave with it to let that idea spread.

**Proctor**: [41:49] Again, for anybody who doesn't follow his Clojure Gazette, he may sound like he's hitting on some of these languages. If you actually read his Clojure Gazette, Eric talks a lot about the good influences from other languages as well.

**Eric**: [42:04] Yeah, sorry to rant. [laughs]

**Proctor**: [42:06] For those who are listening that may think it's a rant, he actually brings along a lot of that, turning that view in his Clojure Gazette. It's something definitely to check out because it's that. From my perspective, you do a very job of turning that sideways and looking at where can we find inspiration across languages.

**Eric**: [42:26] Thank you. I do make mistakes. I have had bad experiences in PHP, I just have to say, but I also think that there is something to the idea that it is on a significant number of websites. There's something to that, so we got to learn from that.

**Proctor**: [42:41] I want to circle back around just because your core.async videos should be coming out around the time of the podcast. Is there anything else that we didn't talk about there that we should cover just to give people the expertise of...

**Eric**: [42:57] Ooh, a tease.

**Proctor**: [42:59] why they should check it out or even worth checking out even if it's from other languages besides just Clojure, and what people might find interesting about the way Clojure approaches things?

**Eric**: [43:09] Yeah. Go uses CSP. Go is very popular and is gaining in popularity, I think for a good reason. I think it's a well-engineered system.

[43:22] The thing about CSP in Go that I was shocked to learn...Like I said, I'm not knocking on languages, but I was using core.async and I was like, "Oh, I wonder if Go has any resources about learning some patterns or blog posts about cool channel patterns and stuff like that.

[43:41] I started researching it, and it turns out that the hardest part of CSP in Go is that you have to manually stop them. Otherwise, they will never get garbage collected. We don't have that problem in core.async. Unless you do an infinite loop in a go block — that's certainly possible — they will never get garbage collected.

[44:02] Core.async is cool because it uses a lot of just purely syntactic compile time transformations. It's got a Go macro. It's a macro that transforms your code into a bunch of callbacks, basically. Those callbacks are just objects. They're just functions. Those callbacks, if the thing that they're attached to gets garbage collected, the call back will get garbage collected, too, so it just disappears.

[44:29] You get a higher level of abstraction. You get garbage collected Go blocks, which it makes it feel very nice to work with. It feels like a first-class abstraction that you can deal with all the time. Only have to think about these cases of infinite loops and things like that. Like I said before, I think it's transformed my ClojureScript code.

[44:49] I don't go into ClojureScript in the videos. The reason is getting set up with ClojureScript would be a video itself, and I didn't want to do that. Luckily, it's the same interface, the same functions and macros in Clojure as in ClojureScript. I think, for learning, learn it in Clojure. Then, if you're using ClojureScript, start using it as soon as possible.

[45:15] I have a blog post about it, where it's actually a solution to callback hell, if you've ever experience that. Now, callback hell is often talked about like all the indentation that you have to do, because you're like, "Callback with a callback with a callback with a callback." That's not the real problem with callback hell.

[45:33] The real problem with callback hell is that you don't know now when your callback is going to be called. You've lost control. You've given up control to the function that you're calling with that callback. You can't coordinate back again. You need to create a new coordination mechanism to bring all those disparate callbacks back together, because they really belong together.

[45:55] Core.async gives you that. It gives you that locality. You can have a loop that spawns off all these different processes, but, when they come back, you can decide what order to process them in. You can say, "I'm not ready for that one yet. I'm just gonna hold on to that channel, and not even gonna look at it.

"[46:11] I'm gonna start doing a loop over here and processing this," and like, "Oh. Now, I'm ready for it, so I want it. Is it back yet? Well, I'll just wait for it until its back." It makes your code look like straight-line sequential...It's not asynchronous. You're not doing callbacks, but you are. It just opens up a world of possibilities. I hope that's a good enough teaser.

**Proctor**: [46:34] It sounds good to me. Hopefully, it'll be good enough for everyone else listening, too. I'll make sure to include the link to that PodPost in the show notes as well for everybody.

**Eric**: [46:43] Yeah, please do.

**Proctor**: [46:44] Is there anything else you want to cover or plug that we haven't mentioned? Anything you think people listening would be interested about?

**Eric**: [46:51] You know what book I'm reading now, which it's shameful that I haven't read it before. It's called "Java Concurrency in Practice." It's written by Brian Goetz, who's the Chief Java Architect, something like that. A high-level architectural role for Java at Oracle, and a whole bunch of other big names contributed to the book. He's talking at the Clojure/conj coming up.

[47:15] It's also on Rich Hickey's reading list, so that's why it's shameful that I haven't read it before. Oh, man, Concurrency in Java is so hard. Not to knock on languages again, but just a fact. They made a bet back in '94 or '95 on sequential processing. Now, it's 2014 and we're starting to do more and more multi-core, more and more threads, and it's painful.

[47:45] I would not want to have to do concurrent stuff in Java. I would rather spawn up two JVMs and have them talk than to do it. About the book, it gives you some guidelines for how to keep your code safe in a concurrent situation. It's by the high-level guys in Java, so it's robust. Luckily, Clojure avoids a lot of these problems. It's still good to know about, especially if you're a Java guy.

[48:12] If I was hiring Java people, I would force them to read the book. If they came for an interview and they hadn't read the book, I'd be like, "OK, here's a copy. Come back when you're finished reading the book." [laughs] It's so important to get this concurrency stuff in from the beginning and to understand all the problems with it. That said, I'd like to ask you a question if I can.

**Proctor**: [48:33] OK.

**Eric**: [48:35] Have you ever used core.async?

**Proctor**: [48:36] No, I have not messed with core.async yet.

**Eric**: [48:39] Is it intriguing to you in any way?

**Proctor**: [48:41] Yeah, it's intriguing to see. It was one of those things I was playing with Clojure until the last job I was at and started learning Erlang. I shifted my learning more to that because of the job, but it is one of those things that is on my radar to see how Clojure is taking care of...because it almost sounds more of a reactional style.

**Eric**: [49:05] You could do that.

**Proctor**: [49:05] I'm not quite there, but making a step towards that reactional style of thinking.

**Eric**: [49:10] It's important that you mentioned that. David Nolen, when he was experimenting with core.async, was trying to build some browser components using core.async to do the coordination between them. Sometimes that stuff can get really complicated, but he called it...It reverses the control flow problem of callback hell of giving up control.

[49:31] It gives you your own event loop, a local event loop, so it's not a global. It's like, "These are the things I care about right now. Let me listen on them, and I'll take some action, do some logic, send out some more messages, and then loop." That's what you want a lot of the time. The logic is really clear and concise in one place.

[49:51] Once you spread it around to all your callbacks, you've smeared it all over your code and you can't read it anymore. Then you also mentioned Erlang. A lot of people compare core.async to the actor model, but it is slightly different in an interesting way. In Erlang you can send a message from an actor to any other actor as long as you know the pointer to that actor.

[50:14] I don't remember what they call it. Reference? In core.async, it's one level abstracted. It's anonymous now because that channel — you don't know who is listening on the other end — is not direct process to process. It's, "I just had this channel. I just put the stuff in there," and then someone might or might not read it on the other end."

[50:37] Which, in my experience, it gives you some interesting possibilities like passing channels down channels and treating the return channel that comes back like a return value. It's got some interesting properties.

**Proctor**: [50:50] Yeah, but definitely interested in seeing more about how the Clojure async stuff works. We'll be looking forward to the videos when they come out.

**Eric**: [50:59] Yeah, cool.

**Proctor**: [50:59] Where can people listening find you and those videos if they want to check out more?

**Eric**: [51:08] My blog is lispcast.com. That's my hub. That's where I got everything. You can find all the links to everything else on there. Clojuregazette.com. Sign up. It's free, and you can easily unsubscribe if you don't like it. All the old issues are available, archived away. PurelyFunctional.tv is where I sell my videos and I'm Eric Normand on Twitter. I think that covers about everything.

**Proctor**: [51:35] We'll make sure to get all those in the show notes then.

**Eric**: [51:38] Cool. Thank you.

**Proctor**: [51:39] I'd like to give a giant thank you to David Belcher for the logo. Once again, I'd like to thank Eric for giving us time to join me today. It was a pleasure talking with you.

**Eric**: [51:47] Yeah, you, too. I had a lot of fun.

**Proctor**: [51:49] Until next time, this has been Functional Geekery.