Functional Geekery Episode 117

In this episode, we catch up with what I have been up to since last episode, talk re-frame in ClojureScript, my newsletter, Clojure SYNC, online community discussions, and more.

Functional Geekery Episode 117

Transcript

**Steven Proctor**: [00:03] Proctor here with some announcements before we get into this week's episode.

[00:04] The first LambdUp, a meeting on functional programming, will take place on December 6th, 2017, at MeetFactory in Prague. They want to create a space for discussion, change the paradigm for the community of programmers, and above all, to open the path for innovation.

[00:20] The event is supported by the organizers of the meet-up groups, Prague Lambda, FSharping, and elmPrague. For more information and to register, visit www.lambdup.io. That's L-A-M-B-D-U-P dot I-O.

[00:37] Clojure SYNC is a new conference by the creator of purelyfunctional.tv, Eric Normand. Set in New Orleans on February 15th and 16th of 2018, Clojure SYNC is all about the craft, business and culture of Clojure. Go to clojuresync.com. That's clojure S-Y-N-C dot com, to sign up.

[00:54] Lambda Days 2018 will be taking place February 22nd and 23rd in Krakow, Poland. Tickets opened up as of November 1st and are currently available. For more information, and to register, visit www.lambdadays.org.

[01:08] BOB 2018 is in Berlin on February 23rd of 2018. BOB is a developer conference on what's best in software development. Naturally, it has a strong focus on functional programming. For more information, and to register, visit bobkonf.de. That's bobkonf.de.

[01:29] BOB is immediately followed by ClojureD on February 24th, also in Berlin. More information on ClojureD can be found at clojured.de.

[01:39] Cross-registration discounts for BOB and ClojureD are available.

[01:44] Lambda Squared has been announced. Lambda Squared is a single day, single tech functional programming conference held in Knoxville, Tennessee on March 30th. Early-bird tickets are on sale for 50$ until January 7th. For more information, and to register, visit www.lambda-squared.com.

[02:02] If you know of any other conferences around functional programming, email contact@functionalgeekery.com, and I'll be happy to announce them.

[02:11] Also, some of you have mentioned that you would like to show your support for Functional Geekery. In that vein, Functional Geekery now has a Patreon page. If that's how you would like to show your support, you can find out more at www.patreon.com/fngeekery. A giant virtual hug goes out to all those who are already supporting the podcast.

[02:30] Lastly, if you're enjoying Functional Geekery, please help spread the word. If you would leave a rating and/or review on iTunes or your favorite podcast directory or even share your favorite episodes on social media, I need your help to spread the word about Functional Geekery.

[02:45] If there are any guests or topics that you want to hear from or about, please reach out and email guests@functionalgeekery.com, and I'll put them on my notes for future episode ideas. Thank you for listening and for all your support.

[02:57] [beeping sound]

**Steven**: [02:57] Welcome to Functional Geekery. I'm your host, Proctor. This week with us, we have Eric Normand. Eric, welcome back. It's been a while, so would you mind giving everybody a little bit of update since the last time we've talked?

**Eric Normand**: [03:11] Hey, Proctor. I'm really glad to be back. It was a couple of years ago I think when I was on last. I know we talked a lot about functional programming and my videos. Now, I'm working on purelyfunctional.tv. That's where I sell my videos. I'm doing that full-time.

[03:31] Currently, I'm recording and writing a lot about Re-frame. Re-frame is a framework in Clojure for the front-end. It's like a full application framework. I think it's currently the most popular ClojureScript front-end framework. I could be wrong about that, but I really like it, so I'm making a lot of courses about it.

**Steven**: [03:58] Shortly before we started this call, I saw you on Twitter. You were just going through about how it was clicking for you and you felt very productive. What's different about some of these things? You sited a bunch of frameworks you've worked with in the past. What's helping this click?

**Eric**: [04:16] In that Twitter rant — I think that's what they're called — I was talking about my history and how I feel like Re-frame is a culmination of all the stuff I've been through. I've written service-side rendered apps, where every click was a round-trip to the server.

[04:39] Then I started getting into JavaScript but had no place to put states. You just cram it right in the DOM and dig it out later using jQuery and then adding Backbone, just remembering like, "Wow. All this stuff, all this experience that I've got of hacking these features in a system that wasn't really meant to do it."

[05:02] Then when you get ClojureScript with the mutable data structures, then build that on top of React. On top of that, you get Re-frame. Everything just falls into place.

[05:17] All this stuff that I've been doing and trying to do and having to do it in a stateful way, a mutable way, storing state in the wrong places. All that stuff goes away when you have the right way to see it. Re-frame just really matches the way that I wish it would work.

[05:39] Just to go on about Re-frame and the ClojureScript ecosystem, I know a lot of people complain about React and JavaScript about how it's not going to solve all of your problems. I think that's true, but having done some work in React, in pure JavaScript, I also see that all of the problems of JavaScript are still there.

[06:04] Then that's all about the mutability of your state, being able to use confusing effects and the view. All sorts of stuff just gets mixed up and creates other problems, new problems. The reason I bring up all this React stuff in JavaScript, in ClojureScript we don't really have that problem.

[06:31] We use React for a very specific purpose, which is to make generating the HTML, generating the DOM, give it a functional approach. We can just write a function that generates virtual DOM nodes and make sure that it updates whenever the state updates. That's it. That's a huge problem in the browser in making front-end apps. Your state and your view get out of sync.

[07:03] You have this two-way thing where you could change the DOM, and now it doesn't reflect the state. You need to re-render the whole view, and it's a big mess. In ClojureScript we're solving that problem finally once and for all, and we can move on. I really feel like that's the reason we can get to Re-frame because we've solved the problem. It's done.

[07:30] Let's move to the next step and solve the next problem whereas I see in JavaScript Land there's just a lot of recapitulation of the same problem. "Let's do React." "Well, let's rewrite it in Angular." Angular is very much the same idea as React now, the new Angular. Then View is the same ideas but in a different way. I don't know.

[07:52] This wasn't meant to be a rant about JavaScript fatigue or anything like that, but if you come to ClojureScript, give it a try. You will see that a lot of those problems go away. I don't know of anyone using View in ClojureScript just because React was there first. We chose it. It's stable. It works. We've moved on solving more interesting problems.

[08:21] There's my little Re-frame-ClojureScript-React rant. [laughs]

**Steven**: [08:25] We've been doing React using JavaScript mainly for the native stuff at work trying to do apps across platforms. Having done and played with a bunch of functional programming languages myself and having talked with all the guests at this point now, it's nice and refreshing what React brings, that it helps push you towards.

[08:47] You still have all of the problems as you mentioned the mutability and side effects. We're thinking about if I have sagas or something, I can at least separate the side effect full stuff from the non-side effect full stuff with some of the React there.

**Eric**: [08:59] Right.

**Steven**: [09:00] I can see where that starts to put us down and appreciate that. Of course, they would like to go further to some extent on some of this stuff. Given where React covers, and a lot of people may at least be familiar with React, what does Re-frame bring to the table and add to the React mindset?

**Eric**: [09:17] Re-frame has re-build components. They're functions, and they're built in Reagent. They're just borrowed straight out of Reagent. Re-frame gives you a little bit more recommendations for how to use them. Then one of the problems with building an app is, when you start building, you don't really know the state you're going to need. You really don't have any idea until you start building it.

[09:47] Also, requirements are going to change. When you think of an app framework, it should at least make that easier on you. This app is going to evolve over time. One thing that you can do is to isolate the parts from each other so that they don't have to all change. If something changes in the view, like you're going to rearrange your UI, you shouldn't have to touch the rest of your app.

[10:11] If something changes — you need some new state or you're going to add a cashing or something — you shouldn't have to change the UI part. What Re-frame does is it gives you these boundaries to isolate those parts.

[10:26] Of course, at first, it seems like this is totally unnecessary. Why would I put in layer between these two parts when it's so much direct to just change it? If you have a button and you want it to change some state — just an increment button — you want it to add to a thing in the state, add one.

[10:45] In Re-frame, what you're supposed to do is make an event then fire it in the click handler on the button. You're firing this event — dispatching is what they call it — Re-frame will catch the event and handle it. You have to define an event handler.

[10:59] Already, you think, "I just need to add one to a number and save it somewhere. Why do I have to make an event, name it, then write a handler that is just going to add one to some number somewhere?" It all pays off.

[11:14] You got this isolation between the view and the state. The view knows the name of the event, and then the handler knows where to put that state in the database. The database is just a map. You can do whatever you want inside that database. It's just a Clojure map.

[11:34] Now, when you finally do change it, when the thing gets handled, you need to re-render your UI. You need a way to react to that change in the state, so you make a subscription. A subscription is, again, a thing with a name. You have to write a function that says how to calculate the value that that subscription gives you from the database.

[12:01] If you store the count under the count key in the database — just a number at the count key — then you would have a subscription that just takes the thing out of the count key, just gets out of the map the count key.

[12:16] Every time that number changes, the subscription is going to fire. Your component, which is using that subscription, which is deref-ing the subscription, is going to re-render. Of course, for a little number, it looks like this isn't worth it, but that's going to evolve over time.

[12:36] Notice, if I wanted to move that counter in its database, what I want to do to, I'm restructuring my database. It's getting messy. I want to reorganize it. I don't want to change it from the count key to some really deeply nested thing, like four keys down. Now, I have that number.

[12:59] I don't have to touch my view. I don't have to touch my components at all, because the component is just saying increment the count. That's an event. Then the subscription is called count.

[13:12] It doesn't matter where it is. All I have to do is change the handler for the event — now it has to know where the thing is — and I have to change function that calculates the value for that subscription.

[13:24] I just changed those two things, and my database is now the way I want it, again, without having to change my UI code at all. That's the big benefit. It separates those two things out enough and gives you...

[13:40] What I like to say is that your events and your subscriptions are actually going to become the bedrock, because your UI is going to change. You're going to need a move buttons around, add new buttons, change the layout. That's going to happen over the lifetime of your app.

[13:58] Your database is constantly changing, because you're adding new stuff in there. You're saying, "Oh, we need a index that's better. We can't iterate through vectors anymore. We need to put it in a map." You're just constantly turning that.

[14:11] What stays the same is I want an increment. Whatever you name the event — let's call it increment count — and then whatever you call the subscription or just called count, that's going to stay the same.

[14:24] It's easy to name those, because you're actually capturing the intent. You're saying whatever the UI element it is — it could be a button, it could be a swipe, it could be whatever — it's always going to increment the count. You just name it based on the intent that the user has.

[14:44] In an e-commerce app, that intent could be Add to Cart, add the item to the cart. You don't say Click Buy Button, because it might not be a button next week. Or on mobile, it's not a button anymore. It's something else. You name it based on the user's intent.

**Steven**: [15:06] It sounds a lot like Redux and Elm Architecture from what you're describing, which is also funny because it also sounds very object-oriented. Now, you're doing the message passing and the true resets.

**Eric**: [15:23] Message passing, right.

**Steven**: [15:24] Not the, "I'm going to call a method on an object," but, "I'm going to publish a message," the Add to Cart or increment counter, something somewhere, via either publish-subscribe or some other mechanism is going to listen to that thing and act on it accordingly.

[15:40] It sounds like, again, back to some of those ideas of this is the implementation of the pure ideas from both functional programming and the pure object-oriented where you've got that boundary and you pass the message.

[15:53] I don't care how this happens. I just know I need to add this to cart and I know I can get a message that says, "What's in my cart?"

**Eric**: [16:01] It's funny that you mentioned the Elm Architecture and Redux. Probably others are converging on the same thing. To me, that gives me a lot of confidence that we're all on to something. We definitely are inspiring each other.

[16:19] It's all done in public and open source projects. We see each other working and we take good ideas where we see them, but I also think that it's confirmation that the people working on these individual separate projects but co-inspiring each other.

[16:36] They're all very smart people. They're coming out at these things and judging them themselves whether they are good ideas. They're all saying yes. To me, message passing thing is definitely object-oriented. I think the difference where I would disagree with making a point-to-point message passing.

[16:58] You're not saying this object can send a message to any object it has a reference to. What you're doing is taking this taking this message and putting it on a queue. Just like with Redux and with the Elm Architecture, there is this idea that we're centralizing the state.

[17:15] We're going to have one place to put this mutable state, because it's so hard to manage. We need it though, so we're just going to...One thing that's mutable, one big thing, and manage it.

[17:27] That's the thing. We're also managing each individual piece, each individual message. You have a thing that it is easier to manage and reason about and evolve over time.

**Steven**: [17:41] The two things with the message passing that [inaudible] from what I've done with the Redux side where it's nice is it is more of the publish-subscribe, which means anybody can act on that event. If you need to have another so-called listener or someone that's a subscriber, you can hook that in too. You can keep those things isolated and decoupled.

[18:04] Leaning a little bit towards the object-oriented side is, you have the one global mutable state, but you the smaller parts that you chop up and say, "OK, well, only this thing is going to be responsible for messing with that counter."

[18:18] It's still mutable, all your mutable is in one place, but you've got the small focused responsibility of where that mutability happens. If it's the counter, it happens here, if it's the shopping cart, it happens here.

[18:31] It seems nice in that sense, where, if you're going to deal with these mutabilities and acting on these messages, you know where that responsibility lies.

**Eric**: [18:38] Exactly. To me it just feels like if you just went back to first principles and you applied functional programming principles, like, "OK, we need state, so let's manage that centrally and we have effects, so how are going to deal with those?

"[18:53] We have this view that has to update based on the date." You just pull it all apart and figure out the dependency graph, and like, "Well, that's it. It's done." This is what we needed all along. It just feels really nice.

**Steven**: [19:08] As you said, it's a lot of the back down to finding some of those common principles. Everybody's agreeing with these ideas. I think it was Pablo Picasso who said, "Good artists borrow, great artists steal."

[19:22] The fact that all these people are stealing these so-called new ideas from each other and doing it, but also being able to look at it and say, "OK, well, some of this is reminiscent of Smalltalk's message passing, or Erlang's message passing," or some of these older systems that you also cite in your newsletters occasionally.

[19:43] Where we're also pulling backs some of these things that say, these are working for us now and we could see hints that they worked in the past.

**Eric**: [19:52] It's all just good ideas. I don't know what else to say about it. I do know that when I have done a Redux app and I saw the ideas. As a functional programmer, it's nice. It's like, "Oh, this is a good implementation of this idea. Let me use it."

[20:15] The trouble I had was, the other developers were not functional programmers and it didn't click with them so quickly. It was hard to convince people of, yes, this boilerplate is beneficial. It is OK. Define this action instead of just calling the thing directly in the callback.

[20:39] Send off an action and have a handler that handles the action. You have to put into your reducer. It was an uphill battle convincing people, and honestly, teaching them how do it as well. I'm sure that that's the case in reframe.

[20:55] Why do we do it this way or that way, when, when I look it, I'm like, "Wow, this it. This is what I wanted all along." It's probably not so clear to other people.

**Steven**: [21:07] You mentioned bringing the team up, that weren't functional programmers. With your background that we've touched on with teaching in your videos, you said it was a little bit of an uphill battle.

[21:17] Did you find that once they got to a certain point, they really started to appreciate these ideas, or did they never get there? Where there still other ways of thinking? What was that eventual result like?

**Eric**: [21:29] Yeah. They did eventually appreciate it. That they could tell that from one thing, that things were organized. That when sure, it's OK to do a little thing in a callback, and maybe to modify some states or something.

[21:46] It's just one little thing. [laughs] After you have 10 or 20 of those, you can't remember what's going on anymore. They start to say, "Oh, I see, this is just a mess." Luckily, they were organized people and so they wanted to have something.

[22:05] Some system for where to put everything, and Redux had that for them. It worked out. There's another issue, which is, I don't want to say anything bad about Redux, but it has too much boilerplate.

[22:24] So much of developing an app is the experimentation. People talking about iterative development, but it's not really that. It's that you try something and you realize it's wrong, but it took a lot of code to get there.

[22:39] The boilerplate isn't right the first time, which means you're not going to move...It actually slower to get it right the first time than it is to get it wrong three times, and then get it right. When I look at it, I'm like, "Why don't you just wrap this up? [laughs]

"[22:56] Wrap it up in something easy like a one function thing, instead of building out a whole bunch of stuff." That that adds to that reluctance to use it, that it's got too much boilerplate, and you don't get that fast feedback that you can with a well-organized system.

**Steven**: [23:15] We touched on your Purely Functional newsletter, and we've covered that in the past. You still been with going that?

**Eric**: [23:20] Yeah. Every week.

**Steven**: [23:22] You're still pulling things from different languages occasionally for inspiration, as we talked about stealing good ideas, whatever language they are.

[23:30] Or getting inspiration from those good ideas to find out it works in Clojure, or just whatever you going to be working on if you're not in Clojure and you'll still following your newsletter. You also dig back into the past and the community.

[23:44] Where I'm going with this is, along those lines, you've now put together Clojure SYNC, which I've been helping to announce, so I'm sure the audience has at least heard of it. You've now taken the newsletter and seems like you're trying to put a purely functional TV newsletter as a conference.

[24:05] Is that an appropriate field for anybody who's read your newsletters?

**Eric**: [24:10] Yeah. That's a really good insight, because I don't know if I've ever really just come out and said it. I don't know if I really understand it that well myself. Yeah, when I do the newsletter, my basic idea is that the Clojure community really likes good ideas.

[24:31] They like a variety of ideas from wherever they come from, and that we're philosophical about our programs. That we're practical as well. We're looking to the future, but also, we want it to run now.

[24:50] We look in computer science throughout history, but also, we look outside to trends in history, philosophy, art, science, the humanities, all the fields. That's most evident in [inaudible] talks, that he does manage to draw reds from all those different fields.

[25:14] I also try to do it in my newsletters. My idea with the conference was to base it on some themes, some broad themes. The themes should be practical now but also make you a better personal in general. The themes are the craft or code.

[25:37] I don't think in the Clojure world we talk enough about the craft. For instance, I've watched quite a few Ruby talks that are all about style, and how big should your methods be, and how do you refactor, and stuff like that. We don't talk that much about that at the conferences.

[25:57] Maybe the organizing committee is not that interested in them. I just don't see that talked about too much. This theme is all about writing the code, building abstractions, architecting your system, that kind of thing. We've got three great speakers about that.

[26:15] We got Zach Tellman, who's writing a book on Clojure code style, called "The Elements of Clojure." We've got George Kierstein, who is going to talk about an issue that is really important in programming, which is, we write programs, but as soon as we stop running them, they start to bit rot.

[26:37] You pack some code on GitHub, and six months later, you try to run it on your system and it doesn't work anymore. It's like your dependencies have changed, the OS has upgraded. Things have just broken. That a real danger, I feel like.

[26:54] We invest all this time and energy into the code, and then it doesn't work in six months. It's not even that long. She's going to be talking about how to help prevent that. She doesn't have a perfect solution that will make it work all the time.

[27:09] She's going to elaborate the issue and talk about that a little more. She has a paper on recommendations and a process for improving survivability of code. Then we have Emily Ashley, she's native to New Orleans.

[27:27] She's going to be talking about time and place. This is such a great topic, because time and place, we think, "Oh, we need to just put a time stamp. A timestamp TZ, the post address data type, and we're done."

[27:44] Except it's not that simple, because as soon as that abstraction meets the human concept of time, it doesn't work anymore. It's down to the millisecond. No one thinks that precisely about time. Sometimes you just want to say, "This thing happened in 1984. I just want to say 1984."

[28:04] She works on dates and times and places at her work and in her side projects. This is right up her alley, and a really great talk. OK. That's that the craft. How do we build these abstractions? How do we code? There's a career track.

[28:23] It's all a single track, it's a theme. This one is about, OK, we have to make money. People have to build businesses on this thing. Who do we need to know? We have Rebecca Kinsella. She works at Funding Circle, they're a big Clojure shop in San Francisco.

[28:42] It's all about hiring, Clojure hired her as a Clojure developer. Should be really interesting. Then we have Elana Hashman. She is working on getting the Leiningen package. We need to realize how dependent we are as a programming community on all of the ecosystems that already exist.

[29:03] The work it takes to make sure that you can type a one line and get Leiningen installed on your system, a working Leiningen. We have Baishampayan Ghose, I'm sure I'm pronouncing his name wrong. Also known as BG, because I'm sure a lot of people get it wrong.

[29:22] He's built a company on Clojure, Helpshift. He's going to be talking about that. He actually had the first Clojure code in production. This is a long time ago. Maybe nine years ago. All right. That's the career theme.

[29:40] The final theme, which is the one I'm super excited about, is context. We're programmers. We live in the world. We're a spec in the history of humanity. How does this fit it? This whole programming thing is exploding.

[29:59] We invent the computer, and then now so many people are employed typing into these things all the time and making them do things. What is going on? We just want some context for how we fit into this stuff.

[30:13] We have Gerald Sussman. Dr. Sussman is one of the co-authors of "Structure and Interpretation of Computer Programming." He's a professor at MIT. He's going to be talking about the effect of programming on humanity.

[30:29] I don't know all the details, because we talked about what topic he would talk about, and he was like, "Oh, that's given me so many ideas. OK, I'm going to go and write them down now." [laughs]. I don't know things that he is going to say.

[30:42] He's an awesome speaker. He's spoken at Strange Loop. He gives lots of lectures at MIT and just a great guy.

[30:51] Will Byrd, he's the guy who invented or wrote miniKanren. That's the logic engine in Scheme, which core.logic was based on. I talked to him at one of the Clojure conferences. I asked him like, "What are you interested in right now?" He said that he was really into the history of writing.

[31:13] Alan Kay talked about how important writing was as a technology, as an invention, so he started reading all these books. When I came up with this idea for the context theme, I was like, "He's going to talk about the history of writing, and what it teaches us about software."

[31:31] He's a programmer. He's a computer science professor. He is going to relate the evolution of writing and how it's changed history and relate it to software.

[31:43] David Nolen is going to talk about the future of programming. Again, it's one of those, I just trust him as a speaker. I don't know exactly what he's going to talk about.

[31:53] Then the final speaker is Kim Crayton. She is going to be talking about AI and what's going to happen in the future, where AI is going to start eating jobs and how we can prepare for it now, how we can compete with AI.

[32:11] It's going to better and better. We're building the AIs now that are going to take our jobs, so what do we do? Anyway, those are the speakers. I'm super excited about this conference. It's in New Orleans. It's in February. You can buy tickets, clojuresnyc.com.

[32:30] Actually, I'm going to give your audience a 10 percent discount if you put in the code "geekery" when you checkout for your tickets, 10 percent off.

**Steven**: [32:43] How did the idea of this conference come about? You mentioned you started having this idea, but what took it from wanting to see this and thinking some things were missing to going in and deciding to put the conference together and actually putting it on the conference and making that leap?

**Eric**: [33:05] That's a really difficult question. I've been going to conferences for a few years now. Every time, I had this idea like, "Oh, this would be awesome to have mine, my own." I would talk to people, and it's not that common I don't think.

[33:26] I just liked the idea of hosting people and giving them a good time and helping them feel welcome and all that. Also sweating all the little details like, "Oh, is it gonna be single-track or multi-track, and are we gonna serve lunch, and what would it be," and all that stuff.

[33:46] Then whenever I talked to someone who had organized a conference, they were like, "Ah, It's kind of a lot of work." I knew I didn't have time to do it, so I just always put it off, thinking one day I might do that. Then the team at Cognitect announced that they are going to be merging Clojure/west with the conj.

[34:09] What that meant was that they were opening up the calendar at the beginning of the year, because the conj was in October and November. The Clojure/west was always the other end of the year, so it's February, March.

[34:28] Opening up that calendar meant I'm not going to be competing with Conjure/west, so now is the chance. I better take that spot on the calendar before anybody else does. That lit a fire under me. I looked at a whole bunch of venues, had someone helping me with that.

[34:47] I had all these venues just to help the other person figure out what I was looking for. We made a list. It has to have this and that and that. We found a bunch of venues that checked most of the boxes, but then we found one that checked, not all of the boxes, but all of the other boxes that the other ones weren't checking.

[35:11] For instance, it's in the French Quarter, and it's a good price, and it's small but nice, and it's just having all these little things checked. I was like, "I have to see this one." The other ones are all the same, but they don't check all the boxes. They would be fine but let me see this one.

[35:34] We went to see it and we just fell in love. The location, the building, the people are very nice. It was just perfect. It's a little theater. It's about a hundred years old now. It's built right in the French Quarter. You couldn't be more central. It's right by the cathedral and the square in front of the cathedral, Jackson Square.

[36:02] As soon as I could, I was like, "OK, I'm going to put a deposit down." Of course, that took longer than I wanted. I was like, "I have a check." They were like, "Well, we need a contract, and we need to get your event approved and stuff."

[36:17] I was like, "Ah, but I want to grab that spot on the calendar." Anyway, it worked out. I put the deposit down, announced the conference, then started putting it together. Once you have a date set, you can start inviting people and selling tickets and stuff like that.

**Steven**: [36:35] You reached out to me earlier on just to let me know that you were starting to think about it getting close, and then some of the details. I've been following the progress for a while, and you've been announcing it in your newsletter and updates with it as well.

[36:51] On the topic of hosting and enjoying people and making sure that they're going to have a good time, you even put together a food guide at New Orleans.

**Eric**: [37:01] One of the things that the French Quarter, that this location, did not check off was that it's not so easy food-wise. Let me explain, because there's plenty of good food. We were looking at other places that are more like central business district. There's a lot of office buildings. There's a lot of hotels around.

[37:26] When people get off for lunch, they want to go to a restaurant. There's plenty of options, and they're typically all really great options. You can tell which ones are good just by like, "Oh, that's the kind of place I want to eat in."

[37:42] The French Quarter though doesn't have all the offices. You don't have this giant exodus from office buildings, so it can't just absorb 200 people all at once leaving one door. That was one of the challenges.

[38:00] The other one is the French Quarter has a mix of quality, because a lot of the restaurants are just tourist traps, just to be honest there. It's even hard to tell which ones are which. Locals seem to know.

[38:17] What I didn't want was for someone to come to New Orleans and wind up at a tourist trap thinking, "Ah, the food's all right." New Orleans has great food, so that would be a real shame. Then even worse would be, "Ah, my lunch was OK." Then the person that's sitting next to them in the theater is like, "Oh, my lunch was amazing," because they went to the other place.

[38:42] I didn't want someone to turn left, have a bad experience. Another person turn right, have a good experience. I wanted to fix that, so I contacted the Southern Food and Beverage Museum that is here in town in New Orleans.

[38:59] I asked them to put together a restaurant recommendation list. They did, and it's a great list. It's mostly centered around the French Quarter, because that's where the conference is. It's also stuff around town that you would want to go to. That worked so well.

[39:18] Then the hotel issue. There aren't a lot of big hotels in the Quarter. The bigger hotels are on the outskirts of the Quarter. They're like your Marriotts and your Hiltons there, the bigger chain hotels. I wanted something closer to the venue and a little bit more of a Quarter feel.

[39:39] I also got in touch with a group of hotels called The New Orleans Hotel Collection. They don't have a big hotel, but they have several smaller hotels. We're actually putting together a group rate from four different hotels.

[39:59] They're different styles. They're in different parts of the Quarter. You can pick and choose what you want. This was working so well. It doesn't have everything I want but I could put it together into little pieces, like the guide and the hotels. I could just build the conference up that way.

[40:22] I was looking at venues for a party. Unfortunately, they were all way too expensive. The venue itself wasn't expensive. It's always like, "Well, then we require you to have $7,000 worth of food." [laughs] I was like, "Well, that's a significant amount of the money that I'm gonna get from the tickets, so I don't think I can afford that."

[40:42] Anyway, I said, "Well, maybe I can put something together in the same way." What we're doing is we're getting local volunteers to organize some kind of social event. Instead of a party in a big room, everyone's in the room.

[41:02] Some people don't like parties. Some people who know each other are just going to hang out with each other or that kind of thing, just a awkward cocktail party thing. I think it'd be really awesome to have smaller groups like, "These 10 people want to go see a jazz show and these 10 people just want to do a bar crawl. That's like that's their thing. These people want to go take a walking tour."

[41:26] Just have it so that you can have a much more intimate time with people who share interests with you and just be together. I'm putting it together piecemeal, but it's actually turning out to be a positive thing. It's not like you're losing something. You're gaining something by having these different experiences.

**Steven**: [41:46] We've run the gamut of what you've been up to between the conference, some of your videos, your newsletter. What haven't we covered? Is there anything that's been going on that we haven't covered, or that you want to at least raise awareness about?

[42:02] Touching on the fact that Clojure/west and the Clojure/conj has now been combined was news to me. I missed that announcement, but is there anything either in your world or just the larger community of Clojure that you think we should at least mention or bring up?

**Eric**: [42:18] Yeah. I would like to bring up something. There has been some talk online about the Clojure community and whether — how do I put this — it's in decline or whether it's not friendly to beginners. That's what's going to be its downfall, that kind of thing.

[42:40] That worried me, because from my perspective I don't see that happening. I don't see it in decline. I joined into that discussion, trying to understand people's perspectives. Then when I was at the conj in October, I was just so taken aback as to how you see people online.

[43:08] They're talking, they're complaining, they have issues, and they want to air them. The posts and the tone of the comments and everything is just very negative. When you're in a room with people and they're together and discussing it, the same people who seem so negative online just seemed like, "No, they're just trying to build a good community."

[43:34] It really made me realize that the Clojure community is stronger than ever. All the stuff that was happening online with all the blog posts and people rage-quitting the community because it didn't satisfy some need they had, that these are just part of a community starting to become aware of itself, becoming like, "Oh, what are our problems? What could we work on? What are our strengths?"

[44:05] One of the things is people don't really complain about strengths that much, so you don't see all that stuff. When I was there at the conj, people love Clojure. They want to invest themselves in it. They love the community. They want to make it better. I just felt like there's never been a better time to be part of the Clojure community.

**Steven**: [44:30] You mentioned the dichotomy there between what you saw in person and what you've seen online. How do we help balance that dichotomy? Is there anything you've seen that says, "Here's how we balance that dichotomy."?

[44:43] If all they see is online and they don't get to attend these conferences, how do we not scare people away from this community? Is there something that you've seen that works well, or is that still one of these problems that we, as the larger programming community and possibly everybody on the Internet, still needs to figure out?

**Eric**: [45:02] Yeah. I think there's a little of the second. I don't have any answers. It's an issue for any community. If you go into Slack and everybody's really nice, that doesn't ever leave the Slack channel. No one's writing a four-page blog post about how nice they were treated in the Slack.

[45:26] You might see that in the comments or the Twitter feed about the topic like, "Oh, no, but people are really nice." You might see it as a comment, but it's on a 10-page blog post that got to the top of Hacker News. That's what everyone's going to see. They're going to see the negativity.

[45:46] I don't know. I just feel that we're learning also as a culture what kind of stuff does make it online, that it's so much easier for a negative post to get onto the top of Hacker News. Even if it could be counteracted by another positive post, it just wouldn't be so popular.

[46:10] We just have to learn that like, "Yeah, you're going to hear complaining, and that's just a sign of a healthy community." Let me put it another way. In my 20s, I was in a group of people. I'm in a group of friends, and we were all really concerned about gossip, people talking about each other behind their backs.

[46:32] I then read an article about gossip and how gossip is really important for a social group that it helps the people in the group understand where the group stands on things, the ethics and the morality, like, "Oh, he slept with her. Is that OK?" that kind of thing.

[46:54] We're like, "Was that OK?" Then they're like, "No, I don't think that was OK." "Oh. OK, OK." That's the gossip. Also, the gossip is always about the more significant people in the group. They're more prominent. They're more talked about. People analyze them more, every little thing they do.

[47:16] What it means is if you're hearing more and more of the negative stuff, it doesn't mean that thing is terrible and more and more and more negative. It's just picked apart more and more. What it really means is that that thing is significant. The thing itself, the subject of the gossip of the online chatter, is the thing that's important.

[47:39] When you see people talking about Clojure in a negative way, it means more people are using Clojure. It means that they want Clojure to be better. I think we need to come to grips with that as a culture that when things are being picked apart, it actually is a positive thing.

[47:57] That it means people care. It means people are paying attention. It means the thing is being used. It means we're shining lights on things, parts of it. We just need to appreciate a little more that the negative stuff is the stuff that spreads than the positive stuff. We just take it for granted.

**Steven**: [48:16] We're coming up on time. We covered a lot. You just gave some great food for thought about...

**Eric**: [48:25] Online communities? [laughs]

**Steven**: [48:27] community building, creating the balance of being welcoming but also knowing that a community is present. I guess if nobody's actually talking about it, nobody's probably in that community. Having some noise about something means something's happening.

[48:44] Is there any other things or upcoming projects or things that are on your radar in the future that you want to let people know about just more specific to you? I know you're going to be probably occupied through middle of February with Clojure SYNC, and you've got your videos and newsletter. Anything else people should be keeping an eye open, maybe new videos, maybe something else?

**Eric**: [49:05] Like I said, I'm working on Re-frame right now. That is going to be a big course. I'm sure it's over four hours. It might be five hours already. I'm recording every day, so I don't really keep that close track.

[49:19] This is going to be a comprehensive tour of everything about Re-frame, including the React lifecycle all the way through best practices and little patterns that you do in your UI and how to implement them in Re-frame.

[49:37] I don't know when that's going to be over because I just keep finding new stuff to talk about in there. I'm going to have to cut it off at some point. For right now, it's going to be really big. Then that's not the end of Re-frame. There's more to do. I want to build an app and record it and show people all that.

[49:56] I'm giving a talk I think the day after this comes out. December 6th is my talk. It's at LambdUp. That's in the Czech Republic in Prague. That's going to be awesome. It's a one-day meeting conference thing. Workshops in the morning. Talks in the afternoon.

[50:15] I'm sure a lot of beer, because it's a very beer-oriented country. [laughs] That'll be fun. Let's see. What else? I'm just occupied right now. I'm really busy. I feel like I'm being very prolific right now. I'm writing every day, recording every day. I'm selling tickets to Clojure SYNC, selling subscriptions.

[50:41] A thing about my videos that might be interesting to people, especially international people, is I just pushed a feature to my site where certain countries that, let's say, their economies are not as strong, I'm giving sometimes very significant discounts on memberships and individual courses.

[51:04] If you go to the site, there's going to be a banner up at the top. If you're in one of those countries when you access the site, it'll detect your country. It'll show you a banner and your coupon code and tell you how much you're going to get, because I do appreciate that.

[51:20] Right now, my membership is $49 a month. I do appreciate that $49 a month is a lot of money in some places.

[51:30] I don't think of it as charity. I think of it as just meeting people where they are. It's probably still a luxury to be able to afford even five dollars a month on something like learning how to program Clojure better, but it's an investment. It's something that you can improve your career with. It's something that should pay off in the future.

[51:56] That's another big thing I pushed. Is that the kind of thing you're thinking about?

**Steven**: [52:01] That sounds good. I just wanted to make sure we covered and plugged any updates that you had that we didn't manage to get a chance to cover and let people know about. If you're listing somewhere else, you might have the ability to get that discount if you had that currency that may not have that great exchange rate with the US.

**Eric**: [52:22] Yes. Exactly. I'm trying to think of anything else. I'm sure there's stuff in the pipeline, but not ready to talk about it yet.

**Steven**: [52:31] We can always get you back on in the future.

**Eric**: [52:37] People can always jump on the newsletter. It's still going strong. I started back in 2012. It's weekly, it's got a mix of stuff I find on the web, stuff that I'm working on and it's not always all about Clojure. There's other stuff, other computer science topics, other things that just are capturing my interest at that time but stuff that Clojure programmers would appreciate. Jump on.

**Steven**: [53:09] We'll get links to all these resources that we talked about. Other resources, things like the newsletter and your purely functional TV site.

[53:19] Everything else, Clojure SYNC and the like so that people can come back, track it down, we'll get your Twitter or GitHub, all the other links we've had for you in the past and get those in shout-outs as well so people don't need to go find the old episodes of you just to track down where to find you.

[53:36] We'll get those episodes so they can listen to you, but that way they don't have to jump through show notes and show notes to find a resource for you.

**Eric**: [53:43] Awesome. Proctor, I should thank you because you are a great resource for the whole community and it's nice that you're putting the hard work in to go around documenting what people are working on and what they find interesting and talking to interesting people.

[54:03] It's really great to hear the podcast, and I'm always excited when there's a new episode that comes to my phone. Thank you so much.

**Steven**: [54:13] Thank you. Your newsletter was one of those things that made me interested in reaching across the different boundaries when you call in somebody's topics from different aspects of the communities.

[54:25] The large early exposure to Clojure where a lot of the Clojure community in the early days would reach across domains or across the computer science history to pull the ideas and find where those are. Thank you for your part of it as well.

**Eric**: [54:41] You're welcome. I enjoy it, and it's been a cool adventure.

**Steven**: [54:45] I'd like to thank David Belcher for the logo. Once again, thank you, Eric, for joining me today. It's been a pleasure talking to you as always. I'm sure we'll get you back on in the future, either if I notice you coming up with something new or I have one of those projects you're working on that are ready to start talking about.

[55:03] In the future, feel free to reach back out. It's been a pleasure talking with you today.

**Eric**: [55:07] Awesome.

**Steven**: [55:09] Until next time, this has been Functional Geekery.