Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.

03:09 - Evan Czaplicki Introduction

• Twitter
• GitHub
• Prezi

03:15 - Richard Feldman Introduction

• Twitter
• GitHub
• NoRedInk

03:42 - Elm

• @elmlang

04:18 - Elm vs JavaScript

• dreamwriter

06:52 - Reactivity

07:28 - Functional Principles

• Immutability
• Union Types

09:42 - “Side Effects” (Reactivity Cont’d)

• JavaScript Promises
• Signals
  • React
  • Flux
• Excel Spreadsheet Comparison
• Two-way Data Binding vs One-way

24:19 - Syntax and Semantics

• Haskell
• ML
• ML Family of Programming Languages
• Strict vs Lazy

30:45 - Testing

• Elm-Test
• elm-check
• Property-Based Testing
  • elm-reactor

34:49 - Debugging

• Elm’s Time Traveling Debugger

42:12 - Next Release?

46:00 - Use Cases/Getting Started Resources

• elm-architecture-tutorial
• dreamwriter 48:45 - Why should Ruby devs care about Elm?Picks

The Expanse (Avdi)Git LFS (Jessica)The City & The City by China Miéville (Jessica)Patterns (Coraline)Ruby Remote Conf (Chuck) Find a change of pace (Chuck) Listen to other people’s views (Chuck)Richard Feldman: Functional Frontend Frontier (Richard)EconTalk (Evan)elm-architecture-tutorial (Evan)

Transcript

AVDI:  Alright, so multiple reboots and restarts later.[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRogues.]**[This episode is sponsored by Codeship.com. Codeship is a hosted continuous delivery service focusing on speed, security and customizability. You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed. Codeship supports your GitHub and Bitbucket projects. You can get started with Codeship’s free plan today. Should you decide to go with a premium plan, you can save 20% off any plan for the next three months by using the code RubyRogues.]**[Snap is a hosted CI and continuous delivery that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.]**[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent and their VPS’s are backed on Solid State Drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code RubyRogues you’ll get a $10 credit.]****[This episode is brought to you by Braintree. If you’re a developer or manager of a mobile app and searching for the right payments API, check out Braintree. Braintree’s new v.zero SDK makes it easy to support multiple mobile payment types with one simple integration. To learn more and to try out their sandbox, go to BrainTreePayments.com/RubyRogues.]****CHUCK:  Hey everybody and welcome to episode 212 of the Ruby Rogues podcast. This week on our panel we have Jessica Kerr. JESSICA:  Good morning. CHUCK:  Avdi Grimm. AVDI:  Hello from Tennessee. CHUCK:  Coraline Ada Ehmke. CORALINE:  Hi from Chicago. CHUCK:  I’m Charles Max Wood from DevChat.tv. Very quick reminder, if you haven’t signed up yet, you can get tickets for Ruby Remote Conf. It’s in a couple of weeks. It’s going to be online. You don’t have to go anywhere. You don’t have to get a hotel room. We have a whole bunch of awesome people speaking. So, go check it out at RubyRemoteConf.com. And we also have two special guests this week. We have Richard Feldman. RICHARD:  Good morning. CHUCK:  And Evan, I forgot how to say his name. EVAN:  Czaplicki. CHUCK:  Czaplicki. EVAN:  Hello. CHUCK:  Do you gentlemen want to introduce yourselves? EVAN:  Sure. I’m the designer of the Elm programing language. So, I’m working on that fulltime at Prezi. RICHARD:  I’m a programmer at NoRedInk. We make grammar and writing software for English teachers. And I am a heavy Elm user, including recently at NoRedInk. CORALINE:  Wait a minute, so we’re not talking about the Unix command line mail reader today? RICHARD: **Correct. [Laughter]**EVAN: **So, it was an accident that I overloaded. But it means that if I ever make a successor to Elm, I have a name for it. Pine. We’re all set. [Laughter]**CORALINE:  Nice. JESSICA:  True. So Evan, what is Elm? EVAN:  So, it’s a language for a frontend program. So, when you want to do something in a browser the idea is that it’s a nicer way to do this kind of frontend programming. CHUCK:  Nicer way than JavaScript? EVAN: **Yeah. So, we’re taking a functional approach to try to rule out a lot of the common errors. So, one way to say it is like we’re trying to pick the right default so that when you start making an application things go right in a way where you look back and you’re like, “Whoa. How come everything’s working out?” [chuckles] in a way that things tend to sometimes not when you’re just starting out with JavaScript.**CHUCK:  So, I guess I have to ask then. What is it about Elm that makes it better than JavaScript? RICHARD:  Well, from my perspective one of the biggest things is that I just stopped getting runtime exceptions. So, I have this side project called Dreamwriter which is open source. And I initially wrote it in CoffeeScript. And after several iterations I had this design that I really liked but a codebase that was unmaintainable. And I decided to rewrite it in Elm. And I was totally floored by the fact that, yeah the compiler is just so good at finding bugs ahead of time that I just never got any of my Elm code throwing a runtime exception. And that’s held true through multiple refactors and things like that. And it really changes a lot about programming when you don’t have to worry about things crashing at runtime anymore. CHUCK:  Yeah. I think I’m going to challenge the paradigm a little bit and just point out. So, is it the transpilation process into JavaScript? Or is there something else about Elm that makes it so that you don’t have those errors? EVAN:  Yeah, so the root design that makes that possible is a feature in Elm. So, we’ll compile down to JavaScript. And the code we generate will be free of these runtime errors. And the way we do that is we have a type system in Elm where we can actually infer all the types of everything in your program. So, we can get a contract on any particular function and say, “I expect a string and I’m going to give out a user object.” And we can guarantee that for every use of that function, that contract is respected. And so, that’s something that the compiler is able to figure out CHUCK:  Okay, so type safety and part of the transpilation. I think what you said though was that you get a lot of this, out of it being a functional approach. So, what about the functional approach gives you this kind of stability? EVAN:  That’s part of it as well. So, one thing we also do is we rule out null pointer exceptions. So, there’s no such thing as null. When you want to model a thing that may be there, may be not there, we have a special value that makes that explicit. So, you’ll never be in a situation where you’re coding defensively like, “Will they give me a null? Will they not?” You just know based on the contract of the function, the type of the function, whether or not that will happen. And so, in practice it’s a whole class of errors that can happen at runtime that you just don’t have to worry about in Elm. RICHARD: **And it turns out that class is almost all of them. [Laughter]**RICHARD:  It’s technically possible. You can still get stack overflows and things like that. But in practice, I really still have yet to encounter it either on my side project or at NoRedInk which we’re now using Elm code. CORALINE:  So, you describe Elm as functional reactive programming. And we’ve talked a little bit about the functional. Can you talk about the reactive part? EVAN: **Yeah. So, this is going back to the history of Elm. Initially it was just about taking a functional approach to graphics, like how could we do HTML in a more functional way? And at some point I realized it didn’t move. I had a picture of Yogi Bear and a picture of a pentagon. And I was like, “Oh, well this is cool but I want the pentagon to spin and I want Yogi Bear to dance around.” And so, reactivity came in as a way to bring in event-driven interactions and keep the functional foundation, so keeping the key ideas. [7:33] get any runtime errors. But also being able to interact with the world [in a nice] way.**JESSICA:  You mentioned the functional principles inside it. Which ones are those? You talked about type safety and that you don’t allow nulls. Is it immutability? Is it no side effects? RICHARD:  Yes. EVAN: **Yeah, yeah. [Chuckles]**EVAN:  So, both of those are parts of what functional means in Elm. It’s a contested term, but it comes down to some key features. One of them is immutability. So, that’s one where I guess the key high-level thing that comes from that is if you add new code it can never break old code. And that’s, as you’re growing codebase that becomes an extremely important feature of a language, right? Some guy on your team who’s writing something crazy can’t secretly mess you up. So, immutability’s a big rule. Another one that’s kind of subtle is this idea of union types, of a way to model data in a very precise way. So, we’re able to make little state machines and deal with different shapes of data in a really pleasant way that it seems subtle. It seems like a small feature but it has a really big impact on how it feels to write a larger application. RICHARD:  I think the lack of side effects… to be clear, Elm is 100% immutable and 0% side effects. And so, effects are managed in a first-class way. And what that means is that any given function is just totally safe to work with. You never have to worry about it doing something, like Evan said, to some other part of your codebase. And this has some really interesting implications when you’re looking at code where you can just look at something and when you’re trying to debug and figure out, “Who’s the culprit?” I have this bug, something didn’t work the way that I expected it to, who is responsible? And let’s really quickly narrow that down, because you’re saying, “Oh, well what can this function possibly impact? Could this function have possibly caused this bug?” And you can very quickly say either yes or no based on just looking at its arguments and what’s in scope. If it didn’t get past a particular value, if it didn’t return a particular value, then it just can’t possibly have affected that path. JESSICA:  What exactly do you mean by side effect? What qualifies as one? EVAN:  The broad category is doing stuff, right? So, if you’re printing something out to console or talking to a server or modifying a database, anything that you can observe as an outsider is a side effect. So, I like to make this distinction between effects and side effects. So, when I call a function I know that it’s going to give me back certain values. But if that function had a side effect it may also write something to a database. And as your functions get more and more complex, if you have these backdoors to have these effects, it becomes trickier and trickier to know who actually did do that to the database. So, we separate out this concept of effects so you can explicitly talk about, “Here’s a particular task that I want to do. I want to go talk to the database,” and that, we can talk about as data. And so, we can separate out running a function from having some effect on the world. RICHARD:  The analogy I like is with JavaScript promises. And Elm tasks are a little bit like promises but more awesome in several ways. But imagine if you had in JavaScript, so currently in JavaScript you can have some functions that return a promise. And that’s one way that you can have them do something. But imagine if the only way to do things were functions that return a promise. And that promise that got returned was the only way that that function could possibly have any effect on the world. So, either the function would return a promise, in which case that promise would eventually get run. Or the function would not return a promise, in which case you had a guarantee that that function was not affecting the outside world in any way. In other words, you could call that function passing the same arguments and no matter how many times you called it passing the same arguments, you would always 100% of the time get exactly the same return value. And it would do nothing else. It would not affect the outside world in any way. JESSICA:  And it doesn’t dig around in the outside world to find out what to return. RICHARD: **Exactly, yeah. It just looks at its arguments and at the enclosing scope. And that’s it. And in Elm, that’s how everything is. And it’s really interesting how… at first it’s unfamiliar because you’re used to doing things in a different way. And you have to adjust to that. It takes a second to become comfortable in doing things in that style. But then once you do you’re like, “Man, all of these problems I used to have are just gone.” It’s really great. [Chuckles]**EVAN:  Was the sub-question there though, if you can’t look at the world from the function, how do you look at the world? Was that the subtext there? CHUCK:  That’s what I was going to ask. So, go ahead. EVAN: **Yeah. [Chuckles] That’s where reactivity comes into it. So, the goal of Elm is we have this core functional language that has a lot of nice properties. And essentially the goal is how can we write as much as possible of our code in that way and then connect it up to the world in a way that doesn’t ruin all of those nice properties? And so, that’s where reactivity comes in. So, when you want information from the world, that’s going to be coming into your program through what Elm calls signals, these reactive values where events are streaming in. And you can, you react to them as they come in. So, essentially you structure your program such that you’re reacting to all these events. But the actual code that is responding to these events is written in this functional way. Does that make sense?**CHUCK:  Let me see if I can restate it a little bit, because I was kind of lost on the, okay, so we don’t have side effects. And then it’s like, okay so how do you talk to anything? And it seems that… EVAN:  Right, so I think framing it as we don’t have side effects is not how I want to do it. I know a lot of functional languages say it this way. But it’s like, we have effects. We have managed effects. So, it’s something that’s really important. Interacting with the world is the thing that matters. And so, the goal is how can we do that in a way that’s nice and still keep a lot of the nice properties of this functional core language? CHUCK:  So, I’m getting the feeling that if you, I don’t know, maybe I don’t understand it well enough to even restate it, but it seems like part of it is that if you make the same request or you execute the same function with the same arguments, you can have the same side effect and it just works with telling the outside world, “Save this,” or, “Update these values” if you call that over and over and over again. You’re just going to have the same value in there. And it seems like some of the data comes back through these signals. And I’m just trying to map it out in my head. RICHARD: **From my perspective, I actually didn’t understand signals at all when I came into Elm. So, Evan’s given a number of talks about the conceptual ideas behind Elm which are really cool, but very advanced. I’m pretty dumb. I just make stuff. And I’m just a happy user of Elm, definitely not [chuckles] the designer type. So, I’ve used a number of different frontend frameworks and tools over the years. And the best ones that I’ve come across are React and Flux. So, this is, React only came out last year and Flux was even more recent than that. And basically the paradigm between the two is you have this unidirectional data flow where there’s a user input of some sort. And that triggers this action. And then the action flows through and then causes you to re-render your whole application based on what changed. And then that in turn sets up a new set of ways to react to user inputs. And so, that’s what we use at work at NoRedInk for most of our codebase. And that’s what we’ve been moving towards because it’s been a really positive experience. What’s interesting about Elm is that it basically, it’s as if you took those concepts which are currently just JavaScript frameworks and becoming at least in my experience best practices, and it’s as if you built a whole language around them where instead of these just being a framework that’s just added on, everything is built with this in mind. So, instead of having a library that creates this unidirectional data flow of user inputs getting translated into these abstract actions and then reacting to that and re-rendering, the whole language does it that way. So, you have… signals are just a first-class way to say, “This is the only way to deal with user inputs.” Does that make a little more sense?**CHUCK: **Yeah, kind of. I think I just need to have somebody draw a picture. And I don’t know that we can do that over an audio podcast. [Laughter]**JESSICA:  Oh, I totally wish I could draw a picture. Is it like, there are some signals that are going to come in and that’s the incoming data, like the user clicked or something like that. They clicked in this spot. And then that goes through all of your code. And your code decides how to react to that signal, which might be, “Oh, now we’re going to be this color.” Or it might be, “Go hit the server at this location and find out what it says.” And when that comes back from the server, that itself becomes a signal that then loops around and goes back into your code from the top? RICHARD: **Yeah. You know, it’s interesting that this is one of those things where it sounds more complicated than it is. So, I actually specifically had this [chuckles] come up recently. So, I had our first Elm pull request into our codebase to rewrite a big complicated piece of our application. So, I wanted to walk through it with one of my coworkers who’s actually a junior developer, came out of dev bootcamp and is definitely not a big com sci expert. And so, I was walking him through it and basically just explaining what the code did. And after about an hour and a half, he was up to speed and he was like, “Wow that was easy.” And I think it’s one of those things where it sounds intimidating because it’s different from what you’re used to. But once you actually sit down and look at the code and just play with it a little bit, it’s actually not that far off from where JavaScript’s headed right now. It’s just doing things in a slightly different way. So, I would definitely recommend that people who are interested in Elm take the path that I did which is just sit down and play with it. It turns out that there are a lot of very simple analogs just from… in a lot of cases, just a translation where you’re like, okay, normally I would do this imperative click handler where I say, I’d get my element and I’d say .addEventListener. And then in Elm instead, or even in React, you say instead you’re declaratively saying here’s the element that I want to end up on the screen. I’m going to have an onClick field there. And then that’s going to specify some code that gets run. In Elm it’s again the same kind of thing except just even slightly different where you have the onClick handler. And instead of writing some imperative callback that happens when the user clicks, instead you just describe how you’d want that value to get sent through the signal system. And the code looks pretty similar in all three cases. It’s just, you learn the Elm way of doing it then you’re like, “Oh, okay, I got it.” And then that’s how you do your click handlers from then on.**EVAN:  Yeah. And I think that the core language design choices around immutability and it sounds kind of crazy, but yeah when you actually look at the code it’s not that weird. You just have these extra language-level guardrails that are going to keep you from going astray in a way that you may not even realize that you do every day. And so, I find that there are lessons that Elm taught me as I used it more just by virtue of having some rules. And so now, I try to use that whenever I’m writing JavaScript or Python or whatever. So, there are these… RICHARD: **That’s totally true. I’ve found the same thing, yeah. [Laughs]**EVAN: **There are these… so, I think that’s how I would characterize it. It’s like you’re just writing normal code but there’s just this extra push towards, “Hey, are you sure you want to use a mutable reference here? Is that really a good idea?” And once you get into the spirit of how to structure your code in that way, it’s something you can do in JavaScript or whatever. But having the language guide you to that is shockingly helpful, even when you know that’s what you want to do. [Chuckles]AVDI:  When I try to explain… CHUCK:  Yeah, I have to say, that picture that you put up there really helped, that link that you added. So, we’ll put that in the show notes. I think it’ll give people a little more context. AVDI:  When I try to explain to people the mental shift for reactivity, the example I usually use is a spreadsheet program like Excel. Do you think that’s a helpful comparison? EVAN:  I know that a lot of reactive folks use that one. I personally never have. AVDI: [Chuckles] Why is that?**EVAN:  I don’t know if that captures the thing I was trying to solve with Elm. So, my real goal was I want to do frontend stuff in a functional way. And reactivity is really on the borders of all these benefits where it’s how you feed in events but the primary benefits are coming in the core logic which isn’t doing stuff in a super reactive way. RICHARD: **From my perspective it’s… I don’t think of it in terms of Excel. I think of it more in terms of solving a problem that the alternatives have. So, this is where React itself came from was just that the old way of, or I guess in a lot of cases the current way, but the status quo was two-way data binding was the best way to get things done. And you would have this thing would update this thing, which would update this other thing, which would update this third thing. And as your application grew and grew you would get these cascading updates that were A, in a lot of cases really inefficient because you’re mutating DOM nodes left and right and that’s the slowest part of your rendering pipeline generally speaking. But B, it was something where it was getting really difficult to tell all of the consequences of one user input. And that was definitely what I ran into with Dreamwriter that was [chuckles] I had this horrible experience where I built this really cool thing that I was using all the time. And I broke paste. Like you couldn’t paste things, which for a novel editing program is kind of a problem. But I really like the user experience that I built up around. And so, other than paste not working it was still very pleasant. But I went to fix that and I was like, “Okay I’m just going to fix this problem.” But then in the course of fixing it I introduced other bugs because all of the different consequences of paste, it needed to trigger all these different updates that the code had just gotten so complex. And so many things were intertwined with so many other things. I found that I couldn’t actually fix paste without breaking something else. And just re-architecting in the React and Flux way solves that problem in the sense that you no longer have cascading updates but rather you say, “Okay, we got this one input. I’m going to change the state of the world in this particular way. And then given that new state of the world we’re going to re-render everything.” And that is its own reward. That’s a virtue in and of itself. What Elm does is it makes that the focus and says, “Okay, let’s take it as a given that that’s the right way to do things,” which to my mind in my experience it is. And given that, how can we make that the nicest possible experience? And that’s what’s really great, is that when I compare using React and Flux on their own in JavaScript and CoffeeScript with doing the same paradigm in Elm, in Elm it’s just way nicer because everything is built around that instead of it being added onto a language that’s not really designed for it.**EVAN:  So, to get back to how to think about reactivity, thinking about the two-way data binding versus one-way is the key. And another way to put it might be when you have the ability to do a two-way interaction essentially you’re coupling a bunch of pieces of your program. The current state of this component depends on what’s happening in this other component, depends on what’s happening in this other component. And no one really is in charge. You just have to make sure everyone’s on the same page. And when you turn this into a one-way thing, you’re able to derive a lot more things. So, rather than trying to coordinate between 10 different pieces that are all in different states, you have a more central view of the world. And then you derive any information you need from that. And so, as long as that derivation is right, it’s always going to be right. Whereas if you add something to one of your components in this world where everything is tightly coupled, maybe that means something else has to change in another component to account for that. And then something has to change in another component to account for that. So, it’s really a way to cut this coupling. And so, I feel like the Excel spreadsheet is a little weird in that it doesn’t… I don’t feel like it gets the essence of what reactivity’s giving us, in Elm at least. So, for listeners who haven’t heard this analogy, the idea is when you’re using Excel you can update a cell. And if you have any formulas, those will just automatically re-compute, right? So, you’ve set up this system where things will flow through the Excel spreadsheet in a reactive, responsive way. But what’s tricky there is in Excel you again don’t really have any structure, right? You can put these formulas anywhere and do crazily complex things. And the point of reactivity in Elm is how can we get that craziness down to a minimum and try to do as much of our application in a really simple, functional way? AVDI:  In terms of syntax and semantics, Elm really seems inspired by Haskell. Is that fair? EVAN:  Syntactically, I’d say that that was an inspiration. So, I like to say that Elm comes out of the ML family of languages. So, there’s a tradition that goes back to, I want to say the 70s, of languages that have this kind of type inference. And so, these are languages like Standard ML and OCaml. And Haskell a recent iteration that’s captured some fraction of mindshare. But I think in terms of semantics, we actually share a lot more with stuff like OCaml and Standard ML where to be more specific, Elm is strict. I personally think laziness is not a good default for most cases. So, because we’re in a reactive setting, imagine if we were, whenever a second passed we would increment a little counter. But we only looked at that counter every 10 minutes. So, in a lazy version of this instead of actually incrementing the number, we just say, “Oh, I’ll increment this number later.” And we keep saying, “Oh yeah, I’ll do this later. I’ll do this later.” And over 10 minutes you can build up a really large computation that when you finally observe it you have to do it all at once. And so, that just seems like… that’s a simple example but you can imagine that for more complicated scenarios. So, it just seemed like a bad default for a reactive setting. JESSICA:  By strict versus lazy, what you mean is in Haskell, Haskell is lazy by default which has the consequence that whenever an expression in Haskell is encountered it isn’t evaluated right away. It’s not until the output of that expression is actually used that the code is evaluated or executed? EVAN:  Right. RICHARD:  It’s interesting because syntactically they’re similar. But I know a little bit of Haskell and a lot of Elm. And I don’t think they’re very similar as languages honestly, beyond the syntax. So, there’s the syntax… AVDI:  Okay, so it’s more ML. EVAN:  Yeah. AVDI:  More just part of the ML family. EVAN:  Yeah. RICHARD:  Yeah. AVDI:  I guess the question I was leading up to with that is really just, what went into the decision to base your language on the ML family as opposed to the Lisp family or something like that? EVAN: **So, my personal progression through languages got me to a place where I really fell in love with that kind of language. So, I started out doing Java. And the first thing I wanted to do was like, “Okay, let’s make a game.” So, it’s like static, private, whatever. Like you get past that and you’re like, “Okay, how can I make a command line game? How can I make a 2D game? How can I make a 3D game?” And so, I eventually got into C++ to do OpenGL stuff. And when I got to college, the first introduction of functional programming I had was with Scheme, so with a Lisp. And it just blew my mind where I was like, “Holy crap. This is amazing.” And then the next year I learned Standard ML, just in not an ideal way. I was taking compilers class and the professor was just like, “It’s in Standard ML.” And I was like, “Well, I guess I’m going to learn that now.” And that again blew my mind where I was like, “Holy crap.” This whole kind of debugging experience, this whole refactoring experience is so much improved in this world that it became like, “Oh man. I really love this approach.” And so, my feeling when I was thinking about making Elm was, I was working on a project that was JavaScript, CSS, HTML, and I was running into these problems where I was like, “Man, this really doesn’t need to be a problem anymore,” you know? I’m working at a language that’s 20 years old and I still can’t reuse pieces of my UI. So, I just felt like there were a lot of lessons from functional languages, particularly typed ones, to bring to frontend programming that for some reason a lot of folks in the functional community haven’t been able to focus on. Like, “Hey, I have a real problem that I want to solve.” So, there is this like, there are academically interesting parts. But for me, the thing that’s really interesting is, “Hey, refactoring’s nicer.” I’m able to accomplish my goals in a way that feels more joyful. [Chuckles] I don’t know how to quantify that. But that’s where this is coming from.**RICHARD: **Yeah, I don’t know how to quantify it either, but it’s really been my experience. I remember the first time when I actually, I crossed the threshold from reading documentation to actually being able to build stuff in Elm and I just spent basically the rest of the day [chuckles] programming in it. And it was just, I just had this huge goofy grin on my face that I don’t think I’ve had since I was 9 years old writing Visual Basic thinking like, “I can make UIs!” It’s just this incredible experience. Talking about backgrounds, I started out with Basic and then went to C++ and then to Java. And I actually switched from Java over to, for a long time I was a professional Java developer and then switched to dynamic languages because I was just, I was so sick of all the verbosity and just being like, “This thing is an int and this thing is a string,” just over and over. And it just felt like all of this ceremony that was just not worth it. And so, switching to a language where I could just be concise and just be like, “I want to do these things.” And it was so much nicer. And I didn’t really think about going back until I tried Elm and basically found that, “Oh, there’s actually something even better than that,” which is that you can get your conciseness because Elm has total type inference where you don’t have to write out any type annotations that you don’t want to. You don’t have to be like, “This is an int. This is a string.” You can just write your code. But at the same time the compiler then tells you if you’ve got a problem, which is really cool because that’s what makes refactoring so cheap, is like I would have this experience where I’d be like, okay I wrote all this code. I just realized that I have a better design in mind and I change it. And the compiler would be like, “Here are all the places that you broke stuff. You broke something here. You broke something here.” I’m like, “Oh, good point. I forgot about that.” And I go through and fix that, fix that, fix that. And then when it was done, I would bring it back up and everything would just work with no regressions. And that just was mind-blowing to me. I’ve just never had that experience anywhere else before where it just, I did a huge refactor and everything just still worked as soon as I got through all the compiler errors. And I still have not really had that experience anywhere else and I certainly did not have that experience in Java. Java you get null pointer exception. [Chuckles]**RICHARD: **You get all sorts of, you know. Certainly there’s no shortage of runtime exceptions you could get there. And just having that experience, I’m like, “Man, I want this all the time.” [Chuckles] And it’s fantastic.**CORALINE:  So, you talked about refactoring. And I don’t like refactoring without tests. What’s the testing framework for Elm look like? RICHARD: **Yeah, so it’s called Elm-Test. Basically it’s not included with the standard platform because it relies on Node to execute the tests. So obviously, the Elm compiler, its job is to generate JavaScript. But if you want to run tests from the command line then you need some sort of way to execute JavaScript from the command line. That’s where Node comes in. So, you actually get Elm-Test with ‘npm install elm-test’. Basically it’s pretty a standard testing framework. There is a really cool library for it called Elm-Check it you’re into property-based testing which does shrinking among other things. I don’t know how many listeners are into property-based testing. But I totally am. [Chuckles]**RICHARD: **So, I could probably go on about that for a while. But that might be less of a useful digression. [Chuckles] But at any rate, yeah that’s the…**AVDI:  Well, let’s talk about that really briefly. We have talked about that a few times on this show. Of course, Jessica is a big fan of property-based testing and constantly trying to get us to use more of it. RICHARD:  Nice. AVDI:  Which I appreciate. RICHARD:  Go, Jess. AVDI:  The thing that I always like to hear examples of are really concrete examples of property-based testing that have to do with real-world domain problems, not just like, I tried all possible inputs to this algorithm, this mathematical algorithm and I found an error. EVAN:  So, I think you can probably say more about property-based testing stuff. RICHARD:  Yeah, so the basic idea is that you basically… so, the example that I like to give is instead of writing a test with some canned data, you write the test. And then you say, okay instead of calling this function or whatever it is that I’m testing, passing in this fixed string or this fixed object, I’m going to write a generator that’s going to generate a bunch of different strings or a bunch of different objects with particular characteristics. And then run the tests a bunch of different times with those randomly generated inputs. And then the idea is that instead of just getting one case covered you get a bunch of different cases. EVAN:  Yeah. RICHARD:  And in particular, this is important for edge cases like what happens if you pass in the empty list? What happens if you pass an empty string? What happens if you pass in a negative number? What happens if you pass in zero? EVAN:  So, you can think of it as it’s a way to write tests that you didn’t think of, right? Like… RICHARD: **Yes. That’s a great way to put it. [Chuckles]**AVDI:  So, when I run across cases that I didn’t think of, usually it’s because a user went through a sequence. Or a user and other inputs to the system went through a sequence of events that I never envisioned. So often, it’s less about, “Oh, I never expected that method to receive a zero.” It’s more about, “I never expected that sequence of keystrokes to happen, or someone to log out and then hit that button.” Is that something that you’re able to address with this kind of testing? RICHARD:  I think that usually comes down more to integration tests versus unit tests. EVAN:  To address that directly, I think it is. I don’t know if people have started doing this kind of stuff yet in Elm. But essentially most of your application logic is going to be just a function where you take in some arguments and you give out some result. RICHARD:  That’s true. EVAN:  And so, that means the ability to test that is really simple. So, I’ll take a roundabout way back to your initial question. So, we have this tool called Elm Reactor which gives you access to a time-traveling debugger. And the idea is when you know the inputs to your program you’re able to reproduce the whole execution of the program. So as it is, normally that’s fed into your program with signals. But you could feed that in with a list of actions. So, in that you can generate a list of, do this, do that, do this, do the other, and see what happens in your code. You could use a kind of property-based testing to do this kind of stuff. RICHARD:  That’s fair, yeah. I guess a simpler but less specific way to answer that question is there’s a lot less of a difference between a user taking a series of different actions and having a series of different inputs in Elm and just calling functions with a different set of arguments. So, those are pretty much the same thing for most of your Elm code. JESSICA:  Avdi mentioned combinations of a series of keystrokes and clicks that we didn’t expect, right? And in Elm those are represented by signals. So, you could totally have a generator generate random sequences of signals and run them through your code. And then… EVAN:  Exactly, yeah. JESSICA:  Yeah, make sure that the state that it ends up in is a valid state. EVAN:  Yeah. RICHARD:  That’s totally true. Yeah, in practice for me, I guess what I mentioned about integration versus unit testing is just in a lot of cases if you specifically get… I’ve seen that if users do this, followed by this, followed by this, followed by this, in some cases it’s less about what’s your business logic and more about peripheral things, like maybe even what browser they’re using, if their internet connection is choppy, if there’s latency, things like that. So in a lot of cases, it’s not so much that the code change needs to be, “I need to fix my logic,” but rather that, “I need to change my code to be more resilient to things outside of my codebase breaking.” And in those cases obviously, that’s where you reach for an integration test rather than a unit test. But property-based testing is definitely something that’s useful for unit testing. CORALINE:  You mentioned the time-traveling debugger in passing. Can you talk about that some more? EVAN:  Sure. So, this was a happy accident from my perspective. One of my coworkers at Prezi, he saw a Hacker News comment like, “Oh, where’s the debugger? I can’t use it ‘til we have a debugger.” And he took that as a challenge, not just to make a debugger that we’d seen before in any other language, but how can we use the design of Elm to make something really crazy? And so, he was inspired by Bret Victor’s, I think it’s called ‘Learnable Programming’. He had a post showing how do we start to visualize how our program works in a more interactive way? And this Laszlo who I work with essentially figure out how to make that possible in Elm. And so, the key design decisions of Elm actually make that really easy. So, you’re able to have a slider and just go back through all the events that have occurred and see what has happened. You can even go back and start there and change the path that you want to take. So, one of the things we’d like to start doing this summer is start using as a QA tool. So, if you have someone who’s going to poke around through your application and they’re able to find some bug, we want to add to this a little button that says, “Export bug report,” where the developer gets the exact sequence of events that led to the bug and knows the particular code. And one cool thing is that you’re able to change the code and see how things would go if that had happened. So, you have this reproduced bug, this sequence of events. And the programmer can tweak things and see if the bug still manifests. So, one place where we’ve seen people using this, there’s a university in Leuven, in Belgium where they did a little two or three-week module in Elm. And essentially they had some instruction. And as the final result of this module, they asked all the students to make Asteroids. And they went into it not necessarily expecting that people would be able to do it given that they’d only seen Elm for two weeks. And they found that a ton of people were able to make a nice Asteroids game. And one of the things that was a helpful tool for them was this time-traveling debugger where in a game like Asteroids if you get the negatives wrong, it’s really easy to… the collisions don’t work right or if you shoot a bullet it goes in the wrong direction. You can start to debug these things in a really nice way where you can change your code and see that the game that you just played works out as you expected. RICHARD: **I’m really excited about that QA export button. So, [chuckles] I really hope that they’re able to pull this off over the summer. Because basically that would change my flow from, we push our code to a staging server, our QA guy takes a look at it and then says, “Hey, I…” Currently the status quo is literally ideally he takes a screen cap of it after he does it again. But in some cases, it’s just harder to reproduce where he’s like, “Yeah, I saw this but I don’t know what I did to trigger it.” [Chuckles]**RICHARD: **I have to just watch out for that and hopefully it comes up again. But instead, if he just starts up the debugger before he starts his QA session, and then once he sees something he just hits pause, he hits exports, he just sends me that file, and now I can bring it up locally, reproduce exactly what he saw. And not only that but once I change my code, replay it again with my new code and confirm that it’s no longer reproducible, that just sounds like such a ridiculous improvement. [Chuckles]**RICHARD:  Over what my life is like right now with QA process that it’s comical. It’s just a joke. Who doesn’t want that? EVAN:  And I think part of the philosophy of Elm is functional programming is cool, but what’s really interesting to me is using lessons from that body of work to do really practical things like this where it’s just like how can we make a developer’s day-to-day life better? RICHARD: **Yeah, that’s one of the most interesting things that I’ve found about Elm compared to other functional languages that I’ve used, is that in a lot of cases there, other languages that I’ve dabbled in are very academic. And they’re very about doing math-y stuff and abstractly cool things that look cool in papers. [Chuckles]**RICHARD: **Whereas Elm is just very focused on how can we make the developer experience really good? Literally to the point where right now the next release is going to be making the compiler error messages really nice. Like [inaudible] format…**JESSICA:  Yay! RICHARD: **Right? Like… [Laughter]RICHARD:  Exactly. Like, this is something that if you’re in academia, it’s not exciting. Like, who cares? It’s like, “Oh, well technically it told you what the problem is.” You know, it’s in Swahili, but… EVAN:  Yeah, but to me it’s so exciting. Yeah. RICHARD:  You know, but you will never figure out what it means. But then it told you, so deal with it. EVAN: [Chuckles]**RICHARD: **But Elm’s like, the philosophy is more like, “No, no. Let’s make this nice.” I’ve been building off of the bleeding edge version of the compiler just because [chuckles] things are so much nicer. And I don’t want to wait for the release. But it’s just like you’ll get a message and it says, “Okay, so here’s what the problem was.” It actually has little contextualized snippets of your code with line numbers. And it’s got a little ASCII squiggle under the part that’s problematic. And it explains in plain English what went wrong. And it’ll even make suggestions below that. Like, “Maybe you meant one of these things.” And in a lot of cases, especially when you just had a typo, these things really add up. It’s just significant time savings to… especially coming from JavaScript where my status quo experience is I do something wrong, I bring it up in the browser, and then it says, “undefined is not a function,” in the console.JESSICA: [Laughs]**RICHARD:  Right. CHUCK:  Yeah, that’s always helpful. RICHARD: **That’s [chuckles], that’s what I’m used to. But in Elm, instead what happens is I save my code, I go to the compiler, and the compiler is super-fast. So, it just, I recompile it and then in less than a second it’s like, “Okay, on this line right here, you did this wrong. You were supposed to be passing in a list of strings but you accidentally passed one string.” And that was going to blow up a lot later. But instead I’m like, “Oh cool, thank you.” And then I just fix it [chuckles] and move on. And it’s just so much nicer. I really can’t [laughs] do it justice with words. It’s just, yeah. I definitely recommend everyone try it.**CHUCK:  Awesome. JESSICA:  That’s fantastic. When is the next release? EVAN: **Ideally in the next two weeks. I’m not going to make a promise here. I’m doing my best. [Chuckles]**CHUCK: **You’re going to make Jessica wait. That’s not fair. [Laughter]**JESSICA:  Oh, no, no. I’ll just do what Richard’s doing and build it from source if I have to. EVAN: **Yeah. [Chuckles]**JESSICA:  That’s fantastic, because that’s the killer problem with Haskell, right? EVAN:  Yeah. JESSICA: **People are like, the amazing thing about Haskell is if my program compiles, 95% chance it’s right. But good freaking luck getting it to compile! [Laughter]**EVAN: **Right, yeah. And this is something where I think from a learning perspective, one of the things I think about the most is what does it look like when you come to Elm and you want to get productive in a week? And something that I think a lot of languages in this family have failed to do is really make that a welcoming experience. So, interactions with the compiler feel like there’s this gatekeeper and they’re just like, “No. No. No. No” [Laughter]**EVAN: **And then eventually they’ll [inaudible]. [Laughter]EVAN:  And once they’re happy, you’re like, okay, it was good advice. But I want that to feel more like you’re getting help, like you’re dealing with a refactoring tool or you’re pair programming with this robot that just knows that if you do it this way your program’s going to go wrong. So, in the ideal version of this, I want to feel like you’re pair programming with the best computer scientist of the last 40 years who’s just there and is like, “Hey, are you sure about this?” And I think if we can get that experience really great, it’ll be a really big deal. And that’s why I’m making this a priority, is just little changes really can make a huge difference on how it feels to work in this environment. And so yeah, so Richard start to… RICHARD:  Well, also Elm’s just… you mentioned Haskell. Elm is just so much simpler than Haskell. I never totally finished learning Haskell because there’s all these complicated words. EVAN: [Chuckles]RICHARD:  Like monads and stuff that I don’t totally understand and yeah. EVAN:  I’m five years in and I’m still not done learning. RICHARD:  Yeah. EVAN: [Chuckles]**RICHARD: **But Elm, you could just pick up really quickly. It’s just not that, it doesn’t have those really complicated things that Haskell does. [Chuckles] It’s just, there’s just not nearly as much to learn. It’s a lot more like intentionally minimalistic. It subscribes, as far as I can tell, more to the philosophy of perfection is when there’s nothing left to take away, rather than when there’s no more features you could possibly want to cram in there.EVAN: [Laughs]**RICHARD:  And I definitely appreciate that both as a learner and as a user, just because it’s just less stuff to deal with. But it’s still got all these really nice properties that I love. CHUCK:  So, I want to… AVDI:  So, it sounds like you’re trying to make it accessible to people who aren’t necessarily already familiar with the whole ML family of languages. EVAN:  Yeah. I’d say that’s number one priority. RICHARD: **Well, it succeeded because I wasn’t. [Laughter]AVDI:  Yeah, I remember when I got into Haskell and it seemed like all the tutorials were like, “Well you already know how this works from ML.” EVAN:  Right. AVDI:  “The way it’s different in Haskell is…” EVAN: [Chuckles] Right, yeah. And so, I sort of see it as my target audience. It’s not hard to convince someone who knows an ML language that Elm is an interesting thing. It’s like, “Hey, do you know that thing you know? It’s similar to that.” That I don’t see as the hard problem. So, to me it’s we have these useful engineering practices, useful engineering tools. And somehow we’ve been unable to make that accessible to everyone. And I think that’s the thing that’s the most interesting. And that’s what I’m trying to do with Elm on a day-to-day basis. How can I make it that much easier to learn, that much easier to get started, that much easier to start seeing these benefits that Richard’s seeing as someone who’s put in the week to get familiar with?RICHARD:  Oh, I think it was less than a week. EVAN: [Laughs]RICHARD: [Laughs] To get up and running, yeah. I’ve now spent a lot more time programming in it just because I like it. [Laughs] But…CHUCK:  I want to take this in a little bit different direction. We’ve talked a lot about how it works and how to think about the problems in Elm. I’m curious. What kinds of things are people actually building in Elm? Are there common examples or a go-to app that people should try to build in Elm? EVAN:  So, there is a couple of getting started resources that I’ve made. There’s a thing called Elm architecture tutorial. That will keep you primarily in this functional core writing code that has these really nice testing properties and modularity properties that are kind of shocking. Once you realize this pattern, like, “Holy crap. I can just keep doing this and my application will have these nice properties.” So, that architecture tutorial’s good. There’s a little TodoMVC. That’s the go-to like, “Hey, we can make a website with this example.” And then we have a couple, some commercial users and some midsize applications out there. So, Richard can probably say more about that. RICHARD:  So, there are a number of examples on the website, elm-lang.org that showcase various open source things. So, I guess Dreamwriter the thing that I made is probably the biggest open source HTML-based app. So, there’s a lot of… a lot of people use Elm for its graphics libraries and just drawing on canvas. So, 2D and 3D games and stuff like that, because it’s good for both. It’s good for just normal web application development and also it’s good for games. So, I would say that I think Dreamwriter’s probably the biggest open source application codebase. EVAN:  There’s one out there for like a note application where you can make notes and sub-notes that I recently saw. RICHARD:  Cool. EVAN:  So, we’re starting to see more and more traditional web apps. But you do get this mix of some people are interested in making games and some people are interested in making web apps. And you’ll see examples of both. And they’re getting more and more fancy. RICHARD:  What’s pretty cool is how similar the codebases are for those, you know? EVAN: [Chuckles]**RICHARD:  In a lot of cases it’s just you’ve got your model, you’ve got your view functions, and then you’ve got your business logic or your game logic as the case may be. And those parts all look pretty similar. And then where the diverge is right at the boundary where instead of saying, “Okay we’re going to update the DOM based on reacting to user inputs,” instead you’re saying, “Oh, we’re going to update the canvas based on reacting to user inputs.” EVAN:  Yeah. So, it’s interesting how much you can separate out how to render the stuff from the core logic. RICHARD:  Yeah. EVAN: **So, we have a couple of rendering backends where you can use WebGL or you can use canvas or you can use elm-html or SVG or whatever. And so, you could make a rendering backend for your application in any of those without really changing the core logic of your thing. It’s kind of crazy. [Laughter]**CHUCK:  Yeah. So, the other question I have, and this is more along the lines of, so this is a Ruby podcast and we’re talking about Elm and we’re talking about functional reactive programming which isn’t something we see a lot of in Ruby. Is there a reason why Ruby developers should care about Elm or should go try Elm other than just seeing a different way of doing things? RICHARD: **Well certainly, Ruby developers who also find themselves having to do JavaScript stuff which I would imagine is quite a lot of them [chuckles] would benefit from replacing a lot of their JavaScript code with Elm code if they decide to get on board that train, which I highly recommend. It’s a great train.EVAN: [Chuckles]RICHARD:  But also, so this is something that’s only minimally explored right now, is that you can actually use the same stuff to write server-side logic and get all the same benefits. No runtime exceptions, great refactoring, et cetera. So, actually that’s how elm-html works. Someone wrote some bindings to Node for Elm. And Elm-Test is actually bootstrapped off of that. So, it uses… it’s actually Elm-Test itself, the logic for the test runner is written in Elm. And then there’s a very small little kernel that just compiles that, runs it on Node, and then uses Node to do the command line stuff. So in theory, someone could use that to build a whole bunch of business applications in Elm. I think the main challenge right now would be that because that’s not a first-class intended use case as the UI stuff is, you don’t have any libraries built around that. You don’t have a database access library. You don’t have… EVAN:  Yeah. RICHARD:  Just nobody’s written any of those because that’s not what people are focused on right now. EVAN:  Yeah, so to zoom out. We’ll potentially be doing some server-side stuff down the line. But we really want to focus on getting our niche right on the web, so doing frontend stuff really well. And from a backend perspective I’d say there’s still a lot of… there’s something about this core set of features in Elm that teaches you stuff even if you understand the core features. So, this is something I’ve found as I worked with Elm is I found out, “Oh, if I structure my application this way, it goes better for me.” RICHARD:  Yeah. EVAN:  And what’s crazy is I also made it. There’s this weird feedback loop where… RICHARD: [Laughs]EVAN:  This thing that I designed is also teaching me these more architecture patterns or these kinds of software engineering best practices that weren’t immediately apparent from the core principles. And so, I’d say no matter what your core day-to-day stuff is that stuff is useful. And I find myself when I write JavaScript or Java or whatever it is, there are these little patterns that I pick up that I find really useful. So, I’d say just from that perspective it’s an interesting thing to look into. RICHARD:  One of the other things noting about is that the way that Elm does interoperations with other languages, or I guess with JavaScript really, is really cool and really flexible. And it does so without breaking any of Elm’s invariants basically by treating JavaScript with a client/server type interaction where    you talk to JavaScript by sending data back and forth rather than sharing code like a lot of other compile-to-JavaScript languages do. EVAN:  So, Richard said this and he was like, “Oh, it’s like JavaScript as a service, which really liked.” RICHARD: [Laughs] Yeah.CHUCK: [Chuckles]**EVAN:  When you want to get into that, you can go crazy. RICHARD:  And that’s exactly how we’ve integrated Elm in our work is that obviously it’s a new language. It’s like you don’t want to just dive in, especially because we’re using it on literally the more mission-critical part of our codebase, because we want these really nice invariants. But that’s not something you do lightly. So, we just basically took one little Flux store and said, “Okay, we’re going to rewrote a lot. I say ‘a little’ but it’s a couple of hundred lines of code and really complicated. And we’re just, I’m like, “Okay. We’re just going to rewrite this one thing in Elm and just plug it into the rest of my JavaScript. And it just works out fine. And I would imagine that if, getting back to your question of why would the Ruby crowed be interested in this, I think that’s something that people could look into. If you wanted to put something on the server that was just integrating with Node and Node was talking to Ruby or whatever the case may be. Then you could just write one section of business logic, something that’s particularly complicated. Something where you particularly care a lot about refactoring and about avoiding runtime exceptions, things like that. It’s really easy to jus slice off one little chunk of code and rewrite it in Elm without having to rewrite your whole application in it. CHUCK:  Very cool. Well, let’s go ahead and do some picks. Avdi, do you want to start us with picks? AVDI:  Yeah, I can do that. I think today I’m just going to pick a book series. I recently got into a series called ‘The Expanse’ by James S.A. Correy which I believe is actually a pen name of two authors collaborating. But it’s a series of so far, five books. And sci-fi. I think I already said that. Anyway, it’s good space opera. I’m enjoying it. That’s it for me. CHUCK:  Alright. Jessica, what are your picks? JESSICA: First of all, [for something] technical I’m going to pick Git LFS. If you haven’t heard of it, Git made this extension for large files. Because Git is totally not suited to putting pictures or video or anything big that frequently changes. Binaries, that’s another thing. I’ve always told people, “Don't put those in Git because they will bloat your repository and you'll have to download every version of them that you have even committed any time you pull in a repo.” Well, they made a solution to that that is really cool because it only gives you the version that you need at the time that you need it. So, when you clone a repo you only get the latest version of pictures and media and other things. But the if you check out a previous commit, it'll go fetch the versions that you need. So, everything is in there. The history is recorded. But you don't bloat your repository on your local device. So, that's really cool. Something Git totally needed. For another pick I want to pick a book. It's a fiction book. It's called 'The City in the City'. So, 'The City in the City' is amazing. It's about two cities that overlap geographically. Interspersed or on the same land from block to block you may be in one city or the other. And all the people in the city are raised from childhood to choose not to see the other city. So, you're only in one or the other at a given time. And everyone just chooses not to see anything that isn't in their city. It's really bizarre. It's like taking the human mental capacity to choose what to see and what not to an extreme. But it's a beautiful description, beautiful setting, great book. And it totally applies to the real world because I can see now how I do that in real life when I'm ignoring some of what's going on around me, because it's not what I'm comfortable with.CHUCK:  Very cool. Coraline, do you have some picks for us? CORALINE:  I have a pick today. It's a little application called Patterns which is for Mac OS. It's on the App Store. It's basically a tool for working with regular expressions. So, you write out your expression and you see your matches and replacements in real-time while you edit your pattern. It does reg ex syntax coloring. And there's a built-in reference sheet so you can find all of the arcane reg ex syntax that you maybe have forgotten about. And you can copy match and replacement codes out of the Patterns application right into your source code. So, it's a neat little app. And if you do a lot of work with regular expressions, it's nice to have an interactive editor that shows you exactly what's going to happen when your reg ex is run with different inputs. So, available again on the App Store. And we'll put a link in the show notes. CHUCK:  Alright. I've got a couple of picks but mostly they have to do with lifestyle as opposed to books or anything else. I'm going to throw a quick reminder in to go check out RubyRemoteConf.com and then talk about these other couple of things. And mainly they are, so I went down to do some training last week in Atlanta for a company out there. And one of the things that was really nice was just to get a change of pace. And so, I'm going to encourage you, especially if you're feeling burned out or worn out or anything like that, to just find a change of pace. Just find something different to do for a week or so. It just really helped me out. I was a little bit burned out. I'm still not completely past the burnout. But I'm feeling pretty good about things for the most part. And I think I can cope until I actually have a free week in a few weeks. So, that's one thing I want to throw out there. The other one is, and this is something that's coming up more and more at least in the United States we're getting closer and closer to, we have more people coming into the presidential race. We'll vote next year on that. But a lot of people seem to really just be up in arms about stuff. And a lot of it's important conversations we need to have. But what I want to encourage people to do is go talk to people who have the opposite viewpoint that you have and just figure out what you have in common. And then from there, you can figure out the details of why you believe a specific thing or why you support a particular viewpoint and things like that. I've had conversations with several people over the last few months who don't share my viewpoint politically, religiously, whatever, code, et cetera. And just talking about it, I found that some things I really do have in my opinion good reasons for believing what I believe. In other areas I feel like I don't really have all of the answers or good answers. And so, it really helped me evaluate where I'm at. And I think this is a healthy thing for people to do. Avdi put, just don't do it on Twitter. Yeah, you can't have a nuanced conversation about this on Twitter. But just go to lunch with somebody or have a Google Hangout or something is what I guess I'm advocating here. So anyway, those are my picks. Richard, what are your picks? RICHARD:  I'm just going to pick one. This is a talk that I gave that basically, it's kind of personal for me because it's a combination of how I ended up in Elm and an introduction to Elm. So, I think anyone trying to get into Elm, it would be useful, hopefully entertaining. And at least for me personally, interesting from a background level. CHUCK:  Alright. Evan, what are your picks? EVAN: Okay, so I have two. One is the Elm architecture tutorial which is a really, I think it's the right way to get into Elm and see what the core idea is. And the other one is a podcast called EconTalk that I'm a huge fan of. So, I really like studying economics. And it's a nice way to talk with leaders in economics and finance or from... the host is an academic guy. So, he always has this really insightful questions and is able to put his personal beliefs aside and just ask the hardest question to the person he's talking to. So, you learn really weird stuff, like the economics of milk placement in the grocery store. [Chuckles] which I find shockingly interesting. [Chuckles]CHUCK:  Alright. Well, thanks for coming. If people want to follow up with you guys or get more information about Elm, what are the best ways to do that? EVAN:  So, I am on Twitter at @czaplic. It's hard to spell. I'll give you guys the link to it. And also the mailing list which is called Elm Discuss is a really nice community. Just happy to help out with any questions you happen to have. And we tend to get back to people pretty quick and be really helpful with beginner type questions. RICHARD:  And I'm @rtfeldman on Twitter. It's R-T-F-E-L-D-M-A-N. By the way, NoRedInk is hiring. EVAN: [Chuckles]RICHARD:  And if anyone out there is interested in the kind of stuff we do, we're a Rails shop. So, even if you have no interest in Elm whatsoever, if you're awesome at Rails and are interested in education, you should hit me up on Twitter. CHUCK:  Alright. Well, thank you for coming. Thanks for listening. We'll catch you all next week. [Once again, this episode was sponsored by Braintree. So, go check them out at Braintree.com. If you need any kind of credit card processing or payment processing in general, they are a great way to go and we appreciate them sponsoring the show.]**[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Blubox.net.]**[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]**