Go After the Hard Stuff
Ben and I talked about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming "killer demo" will present itself.
Transcript
**Announcer**: [00:00] This podcast is brought to you by Upcase. Want to become the sort of developer top Rails shops like thoughtbot fight over? Join Upcase today to get the PUR training, insider knowledge, access to thoughtbot developers and a community of like-minded learners you need.
[00:15] Hone course skills like Vim, tmux, Git, and Rails by visiting upcase.com/halfoff to get 50 percent off your first month of Upcase. Let's get that junior out of your title and start leveling up today with Upcase.
**Recording**: [00:29] [robotic voice] "Giant Robots Smashing Into Other Giant Robots."
[00:32] [background music]
**Ben Orenstein**: [00:33] Hello, everybody, and welcome to the Giant Robots Smashing Into Other Giant Robots podcast. My name is Ben Orenstein and I am here today with Eric Normand. Hey, Eric.
**Eric Normand**: [00:44] Hello. How are you?
**Ben**: [00:46] Good. Why don't you start by telling me about what LispCast or PurelyFunctional.tv is. Which of those is what? Which is which?
**Eric**: [00:53] That's a good question. LispCast is really where I post articles and stuff. I try to identify LispCast with me. I'm LispCast. It's also this umbrella company for all the other stuff I do. PurelyFunctional.tv, it's courses and mentoring program for teaching functional programing, including the LispCast branded stuff.
[01:24] I had this idea at one point — and I still want to pursue it, it's just too early right now — to have other people make videos in other languages. It'll be like an empire of other courses and stuff.
**Ben**: [01:38] PurelyFunctional.tv is mostly teaching Clojure stuff, yes? Is that true?
**Eric**: [01:43] Yep. Right now, that's what it's got. There's a five longer courses and I've just started an online mentoring program where it's about once a week. I publish a shorter course and I'm getting lots of great feedback from members that are requesting and asking questions. I can tune the courses much faster than I was doing before.
**Ben**: [02:08] Are you familiar with Brennen Dunn?
**Eric**: [02:11] Yeah.
**Ben**: [02:12] He has some great writings on how to do those type of courses.
**Eric**: [02:15] OK, I should check those out. I'm familiar with his freelancing stuff.
**Ben**: [02:19] At least, I know he is doing a lot of them. I assume he's been writing also about how to do them, because that's definitely his style. Actually, I haven't seen it explicitly, I suppose. You could even just watch what he's doing and model him, would probably be a useful technique.
**Eric**: [02:32] Yeah, for sure. I'm always on the lookout other business tips and stuff.
**Ben**: [02:36] PurelyFunctional.tv, LispCast, this is your main gig or is a side-hustle?
**Eric**: [02:43] At the moment, it's a side-hustle. I am working on a step-by-step plan to get it [laughs] to be a full-time thing, but that's going to be a ways away.
**Ben**: [02:54] One of the things that I struggle with when it comes to having these side businesses that are related to teaching is you kind of need to keep doing the work in order to keep teaching the stuff, I think. You agree with that?
**Eric**: [03:07] For sure. It was actually kind of a problem. Problem's a good word, but when I was started LispCast, I was working in Haskell. I wasn't too fresh from my day job. I actually had to kind of work it back up to be able to teach this stuff.
**Ben**: [03:30] This is actually perfect. You have Clojure and Haskell experience then?
**Eric**: [03:34] Yep. I worked in Haskell for over two years, professionally.
**Ben**: [03:40] Excellent. I talk back and forth with Joe Ferris who's our CTO here. He is a big Haskell fan. I also like Haskell although I have less experience there. I'm a pretty strong proponent of Clojure as well. Clojure excites Joe less because he is a huge believer in the Haskell type system, and the power of that, and its ability to prevent bugs.
[04:04] How would you compare and contrast working in Clojure versus working in Haskell? What do you miss when you're in one of them or the other?
**Eric**: [04:10] That's a really good question. I'm glad you didn't pit the two against each other because they're both really great languages. They're very well designed. The thing that I miss when I'm in Clojure is the compiler. The Haskell compiler forces you to be very systematic. You always have to be thinking about, "What type do I have? Is this the right type that I need right now?"
[04:39] You don't have that in Clojure. In Clojure, you can just play loose with the types and pass anything around, which sometimes feels very nice because, sometimes, in Haskell you'd make a mistake, and you'd use the wrong type, so you'd get three or four function calls in, and you realize, "Oh, this is wrong. I wish I could put a string here."
[05:00] In Clojure, you can just do that. I actually noticed that quite a bit. I pair a lot in my day job, and I see that a lot where people are just not systematic enough with their thinking. I think that's the main distinction, in Clojure you can be loose. Sometimes it's really dangerous, but sometimes it's just what you need because the type would be more complicated than the code.
[05:29] That's, I guess, my main criticism of the Haskell type system, is, often, to do what you need to do well, you need a lot of type. You need to express this really well. You don't need to do that in Clojure. You can keep it in your head, basically. There's a type, but it's just in your head.
[05:51] Then, sometimes, "Oh, a type is perfect." Having a discriminator union, a variance, several cases and each case has different data. That's perfect for a lot of problems. In Clojure, you don't have it. You just use a hash map and you deal with the mismatch.
**Ben**: [06:11] Yeah. It seems there are certain things in Clojure like Prismatic's Schema, which is like, "Uh, it would be nice if we had types ISH on this data," or core.typed, of course.
**Eric**: [06:23] Yeah, Schema's really interesting. We use it and I like it. It's run time, and so there's obviously a cost for checking that your data is correct. They even have a system for turning it on during your tests and then turning it off at run time and production. I think that's interesting. I like that you can test stuff in Schema that you can't build a type in Haskell for.
[06:54] Because, if you have all full run time information, so often you want to know not only is this a string, but does it match a certain regex, for instance, which you can't do in the Haskell type system.
**Ben**: [07:09] Do you feel like the Haskell type system lets you write fewer tests?
**Eric**: [07:15] No. The simple answer is no, but I was trying to think of why. I guess because I normally don't write a bunch of tests for all the cases that I don't expect to ever happen in Clojure...I don't mean type C. This is where it starts to get fuzzy because a Haskell person would just automatically call it a type error.
[07:41] Whereas in Clojure it's not a type error, it's a data error. It's the wrong data. You have the wrong input. You test your corner cases and everything, but then you don't test like, "Oh, what if someone passes in a Java util calendar?" You don't test that. You don't need to test that. Also, I even have an article about this. It's about nil-punning.
[08:08] With the nil-punning, if your system is designed well, and I think closure is, the nils work with the way everything else works. The nils get threaded through everything and it's not a problem. Whereas in other languages you do need to test. What if someone passes in a null to your JavaScript, for instance, in a test?
[08:31] A well-designed language with certain kinds of punning and stuff like that, maybe you don't need so many unit tests.
**Ben**: [08:39] Do you do test-driven development then, in either of those languages?
**Eric**: [08:44] I do, yeah. I like TDD. I use a lot of generative tests, too, in both languages.
**Ben**: [08:50] I want to talk about that. For me, I also do TDD. I'm writing a lot of test code a lot of the time, and I would love...A lot of the times I'm writing unit tests that feel a bit mechanical. It makes me feel like, "OK, there should be a way to have a computer do this for me, for sure," which sort of feels like the type system in Haskell.
[09:13] It's like, "This is kind of what I want," which is I want confidence that my code works. I want confidence that I haven't forgotten things. I want to poke at it in certain ways and have it respond correctly.
[09:23] My hope is that the type system it is good enough or can become good enough, that one day I'll write almost no unit test and just write a lot of integration type acceptance tests.
**Eric**: [09:35] Yeah. I think I've said this before in other places, but that I think that typing, static typing, strong typing, is going to be the future. In some ways, I feel like it's not there yet. There is things in Clojure that I do that I wish I could express in a type. Then you've also got this trade off. You're talking about wanting that type system to handle it.
[10:07] You can often make a type that does exactly what you want. For instance, you could make a non-empty list. If you try to take the first element of an empty list, that's an error in Haskell. You could make a type that contains a list, but the constructor throws the error when you make it and it's empty. You pass it a list, and if it's empty, it throws the error.
[10:35] It throws it when you construct it way back, like at the beginning. Then you can be guaranteed later on that it's got elements in it. You can do all these things. I think we had a type at the Haskell company I worked for that was an email address. It was a string, but it was wrapped up in this type.
[10:57] When you constructed it, it did a regex on it to make sure it looked like an email address. It also lower cased it and everything, normalized it. The tradeoff is that you've got all of these types, and could you have just gotten away with a unit test? The type is sometimes non-trivial to amount of code, and the test is an amount of code, too, so there's often a tradeoff.
**Ben**: [11:31] To you, it's not there yet? It could be one day. We'll have a type system that's good enough that you feel more confident without writing tests, but you don't have that confidence yet, or you feel that the tradeoff is maybe not quite in that favor yet.
**Eric**: [11:45] It's way more complicated than that.
[11:49] [laughter]
**Eric**: [11:49] We're comparing Haskell and Clojure.
**Ben**: [11:54] Not necessarily. Considering just Haskell in isolation. If I want to write fewer unit tests, can I just write Haskell and then have more confidence that my code works and, thus, move faster because I don't have to spend time writing those tests?
**Eric**: [12:07] I think if you spent a lot of time, and this is the tradeoff, maybe an equivalent amount of time getting your types exactly right, then yes, you could do that. You would be dealing with all these little corner cases, like empty string.
[12:23] I don't want empty string in my...I want to disallow that, so I'm going to have to make a new type for it. For instance, if you went to something like Idris that has dependent types, you would be able to say that in the type, but you can't say that in a Haskell type.
[12:42] Then you have this aggregation of more and more types. They don't compose that well. To have a non-empty string that only contains the character A, only As. That's four new types. You have the string, now you have a type that doesn't allow empty strings. You have a type that is only As, but maybe has empty strings. Then you need another one that's non-empty As.
[13:16] They don't compose too well, so you want to stick with just regular strings. Then you still have to do your unit tests. Those are the kinds of things that you get into when you're programming Haskell. Like real-world stuff, it's like, "Oh, I'd rather just deal with it at run time. Check at run time if it's empty."
**Ben**: [13:40] Any other stuff that you notice you miss when you're using one or the other?
**Eric**: [13:44] When I was using Haskell, I really missed the number of Java libraries that were available in Clojure. There's a lot of Haskell libraries, but they're of varying quality. Also, I should say this was three years ago that I stopped working in Haskell. A lot of stuff could change in three years. For sure, I had a lot of trouble finding libraries that I needed.
**Ben**: [14:15] Have you done much Ruby work?
**Eric**: [14:17] Nope. Never.
**Ben**: [14:18] No Ruby.
**Eric**: [14:19] Not even, what is it, Rails start or something. Just make a Rails app...
[14:24] [crosstalk]
**Ben**: [14:26] Rails new?
**Eric**: [14:27] Yeah, Rails new. See, I don't even know.
**Ben**: [14:29] Gotcha. Is your day job Haskell now, or is it Clojure now?
**Eric**: [14:32] Clojure. We have Clojure on the back-end, ClojureScript on the front-end. It's really nice.
**Ben**: [14:40] How is that, having the same in the front and the back?
**Eric**: [14:44] [laughs] The whole same, same. It's not only that, it's that it's a nice language on the front and a nice language on the back. [laughs] We do communicate Clojure data structures between them, but that's not the big deal.
[15:00] I know a lot of people talk about, "Oh, JavaScript on the front-end, JavaScript on the back-end, it's the same, and so you get some advantage there." You're still in JavaScript. I think that's the biggest problem. Not that there's anything...How do I say it?
[15:20] There's a lot of great stuff in JavaScript, but it doesn't have a lot of the modern amenities you'd want from a language today. Let me just say it that way.
**Ben**: [15:32] Sure. It's a very diplomatic of you.
**Eric**: [15:34] Yeah, thank you. I have to be.
**Ben**: [15:37] Small business owner trying to attract a bunch of people.
**Eric**: [15:40] Yeah, exactly. I don't want to...
**Ben**: [15:42] You don't want the lawyers to fight these lawsuits off for libel?
**Eric**: [15:45] I've heard people turned away because someone makes a joke about a language, and they're like, "Well, what's wrong with that? I program in that language." The joke had a lot of complex nuances behind it. It just sounded like an insulting remark.
**Ben**: [16:03] Definitely. I'm trying to talk about the positive things that I like, as opposed to bash the things that I don't like as much.
**Eric**: [16:10] Yeah, for sure. Another example is, when I stopped at the Haskell job, which I learned a lot. I'm going to quote myself, but I was really down on Haskell. I was really down on static typing. It took me a while of talking to people who were into it...Really, it was piecing apart. "Is it Haskell? Is it typing? Is it the way we coded at the company?"
[16:39] That was my first real exposure to professional Haskell. I started to piece apart, "Oh, that's not how other people do it," and, "Oh, that's not the only way you can do typing. Haskell by itself is actually OK."
[16:54] It was just trying to find the borders between what I knew of Haskell and what was possible in Haskell, versus the realities of...It's all there, all separated out now. I feel good about Haskell again.
**Ben**: [17:11] Nice. Let's talk a little bit about PurelyFunctional.tv.
**Eric**: [17:17] Sure, yeah. I'd love to.
**Ben**: [17:19] How is that going as a business? Is it growing at a rate that you're happy with?
**Eric**: [17:23] Of course not.
[17:24] [laughter]
**Eric**: [17:24] How could it be? It's growing, and I'm on some kind of track. I'm not on the track I want to be. I would like it to grow faster. I just started this online mentoring program. I'm moving from a buy each course separately approach, to all you can eat subscription model. The real reason behind that was that it would take me months to get a course out.
[17:58] During that time I was not engaging with people. It would just be me making material and refining it, and refining it, and finding two hours here, two hours there to make some progress. All that time, I had all this material that I just couldn't get out there, so I finally said, "This isn't getting any faster."
[18:26] I go it down to three months, but that's still a long time, and it's not getting any faster. I would rather be able to make a 10-minute video. Even if it's imperfect, get it in people's hands. They can watch it. They can ask questions. They can give me advice, and then I make another one, and it's another 10-minute video.
[18:50] One day, I was hanging out with some friends, and they said, "Oh, yeah. I'm really into these like subscription video things." I thought about it and I said, "I'm gonna go home right now, [laughs] and try it out. I'm gonna do one," because I was in the middle of this three- or four-month long video production process.
[19:08] I actually went home and did it, and two hours later I had a 10-minute video, and something that was good enough to release to the world versus three or four months of late nights and stuff and then I have an hour, an hour-and-a-half of video, and no feedback in-between. Once I realized that, I finished up that other video and I gave myself a little break, and I started it.
**Ben**: [19:40] How long have you been running that?
**Eric**: [19:43] One month. It's not even like a whole cycle of subscription, and cancellation, and all that, so I don't even know how well it's doing really. [laughs] I've gotten nothing but positive feedback, so that's good. I'm also very lucky I have a lot of people who just want to see it exist, I guess. They're willing to fund it even if they're not interested for themselves.
**Ben**: [20:11] Yeah. It doesn't seem like the Clojure educational resources market is very saturated, I would say.
**Eric**: [20:18] No. There's plenty of room. If anybody else is out there who wants to get in on this, I think now it's the time. I don't know if you knew this, but the first video I did was a Kickstarter.
**Ben**: [20:32] Yeah, I think I did see that one when you launched it.
**Eric**: [20:35] That was back in 2013. My initial idea was to do it for $50,000, and quit my job, and do it full time. It was going to be longer than it turned out to be. It was going to be like 10 hours or something, and they would be released over the course of a year, and I would have that $50,000 to burn.
[21:01] Then my friend convinced me, "That's too big. Wouldn't you be satisfied if you could do like two hours for $3,000?" I said, "Yeah, I guess I would be." He said, "Don't risk it, 'cause there's so many people who start a Kickstarter and it's too big, and they don't have the audience or whatever." That's what I did. I did a $3,000 Kickstarter for one video.
**Ben**: [21:26] Interesting. You think now's the time, is what you're talking about?
**Eric**: [21:30] Right. When I did that, I was watching...I also have the "Clojure Gazette," so I'm like, "I have to have my fingers in the..." What do you...?
**Ben**: [21:38] In the pie?
**Eric**: [21:42] No, not in the pie. I have to keep a pulse. There we go. Fingers on the pulse.
**Ben**: [21:45] Oh, fingers on the pulse. There it is.
**Eric**: [21:47] I have to keep my finger on the pulse of what's going on.
**Ben**: [21:50] Isn't there a finger in the pie thing, or am I crazy?
**Eric**: [21:52] There's a thumb in the pie, right?
**Ben**: [21:54] Thumb in the pie? No, finger in the pie is definitely an idiom. Google agrees with me.
**Eric**: [21:59] [laughs] Yeah. I started it at that time because I was like, "It's now or never." Things are starting to grow and, of course, they take time to develop, so you have to be in on the stream before, but I started seeing another newsletter come around, and people publishing free screencasts, and I'm like, "OK, I gotta do this before it's too late."
**Ben**: [22:21] Do you have signs that the Clojure world is growing?
**Eric**: [22:26] I did keep track of that for a little bit, but I've lost the habit of it. I don't have anything specific. No, I don't really. I think it is.
**Ben**: [22:36] That's your sense?
**Eric**: [22:37] That's my sense. I know that when I started this online mentoring program, I wrote a sales page with copy and stuff. In the copy it's...The point of a mentoring program is to help programmers become Clojure professionals. That's the language I use.
[22:58] Once I put that page up and got people to sign up...When they sign up for this mailing list, they get sent an email, and the email asks a question, "What are you working on? What obstacles are you dealing with? Where do you want to be in 12 months?"
[23:17] Many people, in that "Where do you want to be in 12 months?" say, "I wanna be a Clojure professional. I wanna have a full time Clojure job," something like that. Just the number of the emails I get on that, it's amazing.
[23:31] I must have hit a nerve that people want...They see the cool stuff in Clojure, they see the functional programming, they see the immutable data structures, they see the concurrency, and they want to do it. They believe in it.
**Ben**: [23:49] It's interesting. I see that happening in Clojure, too. I think it's familiar to me because it looks just like what Ruby used to look like, which is people are fleeing, or people that were passionate about their tools were leaving other languages because they were inspired by Ruby and how much they like to use it. Only there weren't enough jobs for them to get.
[24:09] Early on, there was more demand for the jobs than the jobs existed. Then, eventually that shifted. Rails came along, basically, and then flipped that upside down, and suddenly there were enough jobs.
**Eric**: [24:21] Interesting. Rails is what made the jobs? How did that happen?
**Ben**: [24:26] It made the jobs because suddenly people were using Ruby in a professional way all of a sudden. It came down to how good Rails was. It was like, "We can build web apps faster than before using this crazy language. It's called Ruby. Don't worry about it. There's this awesome framework called Rails. It's going to make us faster."
[24:42] That was the killer app for Ruby that changed that situation, I think
**Eric**: [24:45] Really interesting. All these startups were, "I can do this in a weekend on Rails."
**Ben**: [24:52] Yeah. It straight up did improve development speed. If you knew that, then that's pretty huge. I think Clojure is in its pre-Rails phase right now. It feels, to me, a little bit like it's in the pre-killer app. Actually, killer app for Clojure might be ClojureScript.
[25:12] That might be what does it. It's suddenly like that market is 10X or 100X what it was before, because suddenly it compiled into JavaScript, which is a whole different ballgame.
**Eric**: [25:21] Right. I feel like it's leading the way in compiled to JavaScript languages. What's possible that it's not just...Copy Script is great, but it's simply a syntactic transformation. It's not adding very much to the language semantically, but ClojureScript really is.
[25:40] I don't know if you noticed. There was a video at Clojure/conj this year that just came out. It was talking about how you can do the module splitting. Using the Google Clojure compiler, you can split modules just automatically.
[25:59] You just say everything that this file needs and requires put in this one. Everything that this file needs, put in this file, and then all the common stuff put in this third file. You can split out your code that goes on your home page that doesn't need all the stuff that runs your app. It's just the home page stuff.
[26:22] Once they log in, they get this other JavaScript that has the meat of the application. Your home page will load really fast, and there's no good way to do that in JavaScript. You have to do it manually.
**Ben**: [26:36] Yeah. I think ClojureScript is an extremely compelling story for, "If you need a lot of JavaScript, just write this instead and life will be better."
**Eric**: [26:44] Yeah, for sure. I've actually been waiting for, wow, a couple years now that someone is going to go into one of these big popular hackathons like the ones where you make a website and everyone is like, "Wow, look at what they made."
[27:00] That someone is going to go in with Clojure and ClojureScript and they're just going to rock it, because their productivity will be so much higher, and they'll be working in Om or some other React-based system. They'll be able to make something so much more interactive than people using straight up JavaScript. I'm waiting for it to happen. It will.
**Ben**: [27:22] Yeah. It seems like the more compelling technology, and so you would expect to see this happen eventually or to see people migrating over there. The reason I think Rails did so well is because it was such a step up from where people were in terms of speed.
[27:37] So far, I don't get the sense that people are stepping up to the plate or are having quite the same experience in Clojure SASS, ClojureScript. It seems, so far, like another good option for developing systems, and people seem to really like it, but I don't see quite as much people saying, "This was like a step change over the past." Do you have that sense?
**Eric**: [28:00] Interesting. No, I don't have that sense either. I feel like it's still in the making, but we don't know what it would look like yet. Omnexus is coming out soon, and the promises of that are totally simplifying your application and the communication with the back-end.
[28:23] I'd love to see that happen. I'm still not convinced. I feel like a lot of it...This is just me speaking with...Just watching the talks and looking through the tutorial. I have no real experience with it, but it looks like a lot of it is just moving the complexity back to the back-end.
[28:41] A lot of the dispatch of where your data comes from is going to be on the back-end, but it might be pluggable. You can say, "Here's the Datomic back-end piece and it just works, and here's the Postgres piece and it just works." It might be that simple.
[29:01] When you have these large single-page apps, you're doing a lot of dispatch on the front-end like this AJAX call, and this AJAX call. All the logic is in the front-end, but, if you move that to the back-end and you say, "Well, this is the data I need, the back-end is gonna find it for me," you are moving it to the back-end, but it might be simpler than I'm thinking.
**Ben**: [29:23] I'm very bullish on Clojure and ClojureScript. I think they have a really good future, and they're really compelling, but I think we still want that...There was a famous presentation where the creator of Rails demonstrated making a blog in 15 minutes or something like that. I feel there's not quite that for Clojure yet.
**Eric**: [29:45] Well, yeah. I was really impressed when I saw that video, and I think it changed the world really. Before that, making a blog was four weeks, [laughs] something that is a week-long project, and he did it in 15 minutes, and it changed the world. He made it like, "This is what you should be able to do in 15 minutes. You already know how it works. You just wanna get started with it."
[30:14] To be fair, now, other systems have caught up with that. I could write a blog in Clojure and ClojureScript in 15 minutes without a lot of scaffolding, so I don't know if there's going to be another step change. It's obviously not going to be write a blog in two minutes.
**Ben**: [30:33] [laughs] Right.
**Eric**: [30:33] It's not going to be something like that where, "How fast can you write a blog?" It's going to be something like, "How fast can you write a scalable Twitter?" or something like that, where...This actually took a lot of time to make Twitter scalable. It could be something like that. Maybe it's something like, "How long would it take you to write a game?"
**Ben**: [31:02] One way I could see it happening is the shape of applications change. Maybe it's this rich client thing, or hopefully not, [laughs] or something along those lines, where it's like, "Look how fast we can make this new kind of thing, which is better than the old kind of thing?"
[31:17] You're right. I think we're not going to do the blog in two minutes. Maybe it's not a blog anymore. Maybe it's something else.
[31:22] Eric Maybe it's like Google Docs in 10 minutes, where you have peer-to-peer communication, and everything is synced up properly and there's no conflicts. That kind of thing.
**Ben**: [31:33] Yeah, we'll see. It will be interesting.
[31:36] Eric Yeah. It's exciting.
**Ben**: [31:37] Yeah. What haven't we covered that we should talk about?
**Eric**: [31:40] I think we've talked about everything I wanted to. The online mentoring program, I certainly want to plug that. I still need more subscribers. The more the merrier.
**Ben**: [31:50] Do you have a URL for us?
**Eric**: [31:53] Yeah. I've been collecting notes here and there during our conversation. You can find it all at lispcast.com/giantrobots. That's one word, giantrobots. I'll have some goodies there.
**Ben**: [32:09] Excellent.
**Eric**: [32:10] One thing I might want to talk about is teaching, technical teaching. Teaching is what I'm doing now. I've noticed that a lot of technical teaching is not really teaching. It's more just discourse, talking about what you know. The difference between teaching and just talking about what you know is that when you teach something, you don't expect the learner to have to do as much work.
[32:45] I could talk about what I know, make a book, just write everything I know down. Then, boom. They have to go off and do a lot of self-study, interpret what I said, and figure out what I meant, and that kind of thing. With teaching, the teacher does a lot more of that work.
[33:01] Breaking it down, making the exercises that the person just has to follow, so that it's automatically learned just by the doing the exercises, or good metaphors and visuals. That's really the kind of stuff I'm trying to focus on.
[33:22] I feel like it's one of the competitive advantages that I've got, is that I've got teaching experience and I know how to make these things. I'd love to get other people doing these things, too. There's so much great stuff out there. There are so many great people with all this knowledge. It'd be really cool if they could share it more easily.
**Ben**: [33:45] Yeah, totally. Is your long-term dream some sort of platform then?
**Eric**: [33:50] Yeah. That's really long-term. I try not to think about it too much because it's long, long-term. No, it'd be great. I have a vision of totally transforming education, but that's going to be different.
**Ben**: [34:06] That would be a killer app for Clojure. [laughs]
**Eric**: [34:08] Yeah. Clojure's the answer to everything.
**Ben**: [34:10] If you transform education, then bam. You get some converts right there, I think.
**Eric**: [34:16] I'm sure. I did it with Clojure. That's what I'd say.
**Ben**: [34:18] There you go. Awesome.
**Eric**: [34:22] Back to that other topic, WhatsApp is done in Erlang. That's a killer app for Erlang, is some kind of global communication system.
**Ben**: [34:31] WhatsApp is probably going to inspire some number of people to try out Erlang, and maybe use it for their next whatever. I feel like, now, a lot of people are writing WhatsApps, probably.
**Eric**: [34:45] That's true.
**Ben**: [34:48] Rails was like, "Here's a thing that we all are going to do a heck of a lot of in the next decade, and it's going to be better than it was."
**Eric**: [34:56] That's really interesting. I hadn't thought of it like that. I was thinking of it more like expensive problems and how do you solve them, but not super common problems.
**Ben**: [35:08] If you could make a better Excel, for example, Excel, only 10X better somehow, and still usable by normal people, that to me is the kind of thing that you're going to change the world on a scale Rails was doing.
**Eric**: [35:20] Right. Honestly, I think where Clojure really shines...The last company I worked for, it was a totally new startup. It was in Clojure and it was two programmers. We were doing so much amazing stuff. Just the power we were wielding. At one point, we were on Heroku.
[35:43] We had 40 workers controlled from my computer, scraping millions of websites, aggregating all the data, putting it into a database, and saving the pages in a search engine. When you're scraping at that scale, you have to be careful not to take down the server you're scraping.
[36:08] We learned that quickly. We were monitoring the number of 500 errors [laughs] that we were getting from each server.
**Ben**: [36:15] [laughs] Oh my God.
**Eric**: [36:15] We could lower down how much we were hitting that, and use those same workers on another website. All of that was just two people. You couldn't do that in other languages.
**Ben**: [36:31] That might be enough. If it is just more powerful and great to use, and you can do these crazy things with small teams, who cares that it's not a killer app? Who cares if it doesn't even get that popular, really? Aside from libraries, you need a certain amount. If it's just this great, awesome tool that all new people that are clued in use, then fine. That's OK.
**Eric**: [36:50] It's where it's positioned now, actually, when I think about it. The barrier to entry on Clojure is pretty high. People talk about the first run experience and how hard it is even to get set up to run your one plus one, [laughs] to try it out. I wouldn't say it's done on purpose, but it's certainly not a priority to make that better.
**Ben**: [37:22] Yeah, we'll see. It would be interesting to see a change. I remember seeing some informal poll of people at the Clojure/conj asking, "How many of you are working professionally in Clojure?" That's been going up every year.
**Eric**: [37:33] Oh, that's nice.
**Ben**: [37:33] That might be the best indicator, actually.
**Eric**: [37:36] Yeah. We're going to see some of these early startups get successful who have been using Clojure and who will talk about how Clojure was instrumental.
**Ben**: [37:49] Hopefully so. If there's a technology like Clojure, where a lot of people that are very passionate about their tools and are strong developers are going to, eventually, people will start doing things in Clojure to be able to recruit those people.
**Eric**: [38:05] Yeah, for sure.
**Ben**: [38:06] You, basically, couldn't hire me to write Ruby at this point. I have a ton of Ruby experience, and there's almost no Ruby job where you would entice me to go write Ruby, I think. If were like, "We got Clojure over here. You could do some fun Clojure at this thing," that's a whole different kind of compelling. I think there are a number of people that are in a similar boat.
**Eric**: [38:25] Yeah, definitely. I've done a couple of rounds of hiring, and there are so many people who are ready to work in Clojure, even willing to take a little pay cut. There's just not enough jobs for them all.
**Ben**: [38:40] Interesting problem. There's probably some businesses in that problem right there.
**Eric**: [38:45] Yeah. I actually watched a talk. Kind of tangential, but I watched a talk that someone had a big insurance company. The talk was about how to bring functional programming and formal methods into these larger enterprises that already have a stack and they're not going to invest in another language. His approach was to go ask people, the managers, for the hardest problems.
**Ben**: [39:15] Nice. I like it.
**Eric**: [39:16] You just say, "What is the thing, the thorn in your side, that you never thought you could get rid of, like some old..." He actually got some old XML-based system. It was like a rule engine, but everything was expressed in XML.
[39:33] He just attacked it from all sides with F#. He was generating C# with his F#. He was having fun. He was using functional programming and he was doing something good for the company. They never thought they could get rid of it, but he was able to attack it with better tools. I think there's a lot of room for Clojure in that kind of system.
**Ben**: [39:56] Yeah. I like that tactic, go after the hard stuff.
**Eric**: [40:00] I never thought of it that way. You always think, "Oh, get in easy. Get your foot in the door." No. Go after the hardest thing because you've got the sharpest knife. Just go after the hardest problem.
**Ben**: [40:12] Yeah, prove the knife is sharp by doing the hard stuff.
**Eric**: [40:15] Exactly.
**Ben**: [40:16] I like it. Awesome.
**Eric**: [40:18] They wouldn't care if you failed because, "Oh, well. So many people have tried and failed already."
**Ben**: [40:24] All right. That's a great place to stop, I think.
**Eric**: [40:26] Cool. Thank you so much.
**Ben**: [40:28] I appreciate you coming on. It's been fun chatting with you.
**Eric**: [40:30] Yeah, it's been a lot of fun on this side, too.
**Ben**: [40:32] Cool. Let me know if you solve that Clojure problem for the world, and we can all start working in Clojure full-time.
**Eric**: [40:36] Yeah. OK. On my spare time. My spare, spare time.
**Ben**: [40:40] Just tweet about it. I'll retweet it once.
**Eric**: [40:42] It'll fit in a tweet. It's a concise language.
**Ben**: [40:45] [laughs] Definitely. Exactly. You want to plug that URL before we go?
**Eric**: [40:50] Sure thing. If you want more information about LispCast, PurelyFunctional.tv, please go to lispcast.com/giantrobots. Giantrobots, one word. Get on the Clojure Gazette. Subscribe to that. Get on the mailing list, you'll see them there. Give me a shout-out. Send me an email.
**Ben**: [41:11] Awesome. Cool.
[41:12] [background music]
**Ben**: [41:12] Cool. Today's show was produced and edited by Thom Obarski. If you'd like to access the show notes for this episode, you can go to giantrobots.fm/172. Thanks for listening.
[41:19] [music]