NOEL: Hello and welcome to the Episode 17 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and would like to encourage us to continue, please follow us on Twitter at @Tech_Done_Right and leave a review on Apple Podcasts. Reviews really do help new listeners find our show and we really appreciate them. You can also leave comments on our site, TechDoneRight.io and read our blog at http://medium.com/Table-XI. Thanks. Hey, before we start, a quick message from Ruby Central. RubyCentral has asked me to remind you about this year's RubyConf and the Opportunity Scholar and Guide program. RubyConf offers a limited number of scholarships for people who might otherwise not be able to attend the conference, and they are also looking for volunteers to help guide the scholars during the conference. I’ve acted as a guide at this conference for the last few years, and it’s a great way to enjoy the conference and also improve the experience for new people entering the Ruby community. RubyConf is November 15 - 17 in New Orleans, and for more information on being a scholar or volunteering as a guide, visit rubyconf.org/scholarships. Applications are due by August 25, 2017. Thanks. Today on the show, we have Corey Haines. Corey is a long time member of the Ruby community, the creator of code retreats and the author of the book, 'Four Rules of Simple Design.' Corey is currently the CTO of Hearken, a company that allows news organizations to engage with their audience. Hearken is written using Elm, a pure functional frontend language and framework that's a replacement for React/Redux or Vue or the like. We talked about what the Elm language is, why Hearken chose to use it and why they're really happy with it. I hope you like it. I've been super interested in using Elm recently. I took it up as a test challenge and I have been really trying to work with it more and I was super excited to talk to Corey about it so I hope you enjoy our conversation and here we go. Corey, do you want to tell everybody who you are? COREY: Hi! I am Corey. I am currently the CTO/Co-Founder of a company here in Chicago called Hearken. I'm a software developer at heart and I was actually just writing some Rails code before we started this. And I love cats. That probably sums me up. NOEL: Many of you may know Corey as a person who started the idea of code retreat. Corey were here to talk about Hearken and Elm programming language which they're using in Hearken to build Hearken so maybe you could start by telling us exactly what Hearken does and let's start from there. COREY: Sure. Hearken itself means, 'to listen' and we work with newsrooms around the world to help them better listen to their audience, prior to doing all the work around reporting. At the abstract, the kind of idea is to help newsrooms with techniques to give their audience a seat at the editorial table, all the way from the pitch process of what possible stories we could do, all the way through figuring out which stories are the ones that the reporter should be spending their time on and then through transparency during the reporting process, all the way leading up to publication. While there's a lot of tools out there for tracking what the audience has gone and read, which is post-publication, we really work with them and we consult with them and give them best practices and then supporting technology for those best practices to work with your audience prior to publication and prior to doing all of the work. Our goal is really to open up the newsroom, increase transparency and via increased transparency, increase the trust that the audience in the newsroom has. NOEL: How long have you been building the app? COREY: Jennifer Brandel who is my co-founder and I started Hearken at the beginning of 2015. She had been working at the local public radio station here in Chicago, WBEZ, and had spent a couple of years creating a series called Curious City which was the breeding ground for a lot of the initial ideas around Hearken. We've then, over the last two and a half years, expanded our best practices, brought on other newsrooms, helped them, consulted with them. NOEL: And the frontend of the site is built in Elm? COREY: Yeah. We've been working in Elm for a little over a year now. We have one product in one big section of the system that is entirely Elm. We started building that a little over a year ago and then the other part -- the old standby part of the system -- has a very, very raw jQuery, JavaScript frontend with some libraries that we wrote and we're rolling Elm back through that as we update functionality. We're just replacing pages with Elm. NOEL: I don't know how many people listening to this are going to be familiar with Elm. I want to talk about Elm because I've gotten super curious about it lately. Actually, it started when you told me that that was what you were using at Hearken was one of the first things that got me really curious about it. Let's start with Elm is first of all a frontend language that compiles down to JavaScript and you can go from there. COREY: Yes. It is a pure functional, ML language. I like to say it's Haskell without the academia. NOEL: Actually, the compiler is written in Haskell, I think. COREY: Yeah, the compiler itself is written in Haskell. NOEL: By pure functional, that means that all of your interaction with Elm takes place in functions. It's not an object oriented programming language where you have objects that have methods. What you have are functions that take in values and return a value and the values are immutable, correct? COREY: Yeah. There's always this little discussion about what it actually means to be pure functional and whether or not the definition is that you have higher order functions or that you separate your data from your functions or all of your functions are pure, meaning they have no side effects, whether data is immutable. It always ends up in the big discussion about what that pure functional means but from an Elm perspective, everything is based on around functions and like you said, you pass data in a function can't mutate the data. If it needs to return something new, it has to create that new data instead of having -- NOEL: A new string or a new record or something like that? COREY: Yeah. The thing for me that is really, really great about it is part of that immutability and sort of augmenting it is this idea that Elm is very strict about the functions not having side effects. Meaning, if you call a function with a given set of parameters and a given set of inputs, you know that you're always going to get the same output. It's not going to change the world around you. It's not going to change some state somewhere, which makes it interesting because you can't have a function that returns the current time, for example, because that function has a side effect. Meaning, it actually grabs the time from the world around it so you can't be guaranteed that a given input through the output. NOEL: Maybe not so much as a side effect as it is that you can't guarantee the value. COREY: Yeah, I think of both input and output side effects. To me, a side effect is anything that interacts with the world around it. But that's a really good clarification because if you think about returning the time, most of the time we do think about side effects as something that changes the world versus just interacts with the world. NOEL: There are two other features about Elm that I want to just talk about quickly before we start talking about why you wanted to use it. One of which is that relative to many of the scripting languages that people who listen to this might be familiar with, Elm is also very strictly typed and has a somewhat, well it's not unique but if you're used to Ruby and JavaScript, a somewhat different approach to how you define types and how strict the type is along with a compiler that gives pretty detailed error messages if you step aside from it. COREY: Yeah. It's in that ML family. If you are coming from something like a JavaScript or Ruby or even like a C# or Java, you tend to think of types in terms of the template for an object, either at your classes or you tend to think in types as the noun, sort of these are the things that I worked with are my types. Whereas, in these type systems, oftentimes I think of the types as more they're the things but they also have the representation of the state around the thing as well. There's this idea of what a type constructor looks like in one of these type systems where that type constructor is actually more representing the state of the thing, rather than the thing itself. That actually doesn't make a heck of a lot of sense. Let me give you an example. One of the types that we have in our system and this is a very common problem, is when you're editing something. On a webpage, you might have a piece of text and when you click on it, you want to turn it into an input box, you want to have a buffer so that while they're typing it in, you could cancel it and get back to the original value. This is a common situation that you have when you have a UI. What we've built is a type called 'editable' and what its aim is to counter that case where you might have something that is not being edited but still has a buffer. For example, the way you might model this ordinarily is you would have a Boolean that says whether you're editing or not, you would have the value of the thing and then you would have the buffer, which is of the same type of maybe a string or something. As you're editing, you'd alter that buffer and then when you want to save it, you would copy the buffer over into the value. You can get into a weird situation where your Boolean that specifies if your editing is set to false saying, "I'm not editing," but you still have data in the buffer and this is a weird and inconsistent situation. It's an inconsistent state for your application. If you are not editing, you should not have a buffer. You can create a type in our system that is called Editable and it actually has two constructors for it. One, you can construct something of this type by just saying, "Not editable," and give it a value or "not editing" and give it a value. At that time, your thing itself, your data is in the state of not editing. Then when you want to switch into editing, you can create an instance of this type or create the data as another constructor called 'Editing,' where you have both the value and the buffer. These states can bounce back and forth. When your data is in the not editing state, there is literally not a buffer variable at all. NOEL: So you're actually in the situation where the type system is enforcing your business logic? COREY: Yeah and that's one of the things I really love about it. There's this concept called 'make impossible states impossible.' The idea is that you can build your type system so that literally, your application cannot get into an inconsistent state. NOEL: It's much, much easier in an OO language like Ruby or whatever JavaScript is, to have a bunch of different flags or different things and then have it be very easy to set, any combination of those flags, whether or not they're logical or not. But in Elm, it's much more straightforward to have the type system and the compiler verify for you the legal states of the application. Is that --? COREY: Yeah. You know, it's important to realize that none of this stuff is impossible to do in an OO language. You can build your system. If you build a really good, kind of pure OO-ish, everything is encapsulated, you don't leak internal state to other objects and things like that, you can build systems that literally can't be in an invalid state but it's a lot more complicated when you have to enforce that and you have to put the logic around it. Whereas, in a really expansive type system like Elm's, you can literally encode it into the types themselves. It's a much more simplistic way to look at it or a simpler way to look at it, at least for me. NOEL: One of the things that has struck me about Elm, relative to some to other JavaScript tools is that I haven't done a whole lot of that yet but the Elm code seems to have a whole lot less incidental complexity, compared to some of the JavaScript frameworks. COREY: Yeah. NOEL: You are much closer to working with a logic itself and not a bunch of sort of yak shaves that you need to do to get the tool to be aware of where your logic begins and ends. COREY: I was thinking about it the other day and I kind of went on a Twitter tirade, maybe a couple of months ago, about how the more that I build systems like in Elm and kind of fool around with these more expansive type systems, is it's more complicated like you're saying. It is just plain harder to build a really safe system in a language like JavaScript. JavaScript is such a free-form like you can do anything you want practically. It doesn't seem like it has a lot of constraints and because of that, you have to really do a lot of work to be safe. NOEL: You're treating flexibility for safety, which is sometimes the right thing to do. Sometimes, it a perfectly valid way to go. COREY: I'm not sure anymore. That's the thing, like I've said that and I've thought about all of those things and then I realized, I build web forms. I build websites and most of the people I know and most of the people that, honestly I'll say the most people out there, are building business applications. They're almost always slightly more complicated but effectively CRUD apps, like there's some business logic in there and things. But if you really sit down to it, like I have some complicated stuff, I wrote a little fraud detection subsystem in our app but it was for the most part, kind of a CRUD system. I think I'm coming to the conclusion that we keep fooling ourselves into thinking that we need a lot more power because when I'm working in Elm, it feels like I've got the guard rails up at a bowling alley and I'm throwing the ball down the bowling lane and it's bouncing off the little rubber things and then gets down and hits and gets me a strike. More and more, I don't want to have to worry about the complexity that comes with more power. I'm really enjoying when my language just basically says, "I'm not even going to let you do that because that is dangerous or it doesn't make sense." NOEL: One of the things that was striking to me, my first experience with stricter-type languages was really my first experience with a really powerful programming language at all was Pascal and then later Java, which is nominally strictly-type. In those languages, the type system often really gets in your way. It doesn't necessarily give you the guardrails. It just is there to make the compiler happy, at least that's the way it often felt. With Elm in part, because I think the compiler is really, really good at telling you what the problem is when it can't compile, you really do feel the type system is there to enforce safety and make impossible things impossible. COREY: Yeah and the kind of anecdote I tell is I used to do C#. I did C# from 2001 to 2008 or so. Around 2007, 2008, I was shifting over into Ruby and I loved the freedom that came with the duck-typing and a much more loose language. Ruby still is the language that I go to for a lot of my coding. I remember at a conference, I was at the CodeMash Conference and in a late night hangout with people, I was talking about going to Ruby and we were talking about the types in C# and how the types worked in Ruby and all of this stuff and how it was so much better and that the types were getting in my way in C#, which they were. A friend of mine, I think it was Eric Smith, I'm not 100% sure, he just looked at me and he goes, "You don't know what you're talking about," and I was like, "Really?" And he said, "Let me show you a type system," and he sat me down and brought up some F# code. NOEL: F# is another pure functional language in the Haskell, ML. COREY: Yeah. NOEL: Yeah, that kind of very intelligent type system corner in the world. COREY: Yeah and he showed me some of the things you can do and I was like, "Oh, I understand now that it's not really static versus weak or strong versus dynamic and all of that." It's really, do you have a type system that lets you do things in it or do you have a type system that is simply there to say, "This is a noun." NOEL: Yeah, is the type systems is simply there so that the compiler can work? COREY: Yeah. NOEL: Is it a part of the interface to the programming language? COREY: Yeah, like when you move into a type system that actually has a few more features around it, where you can encode different states and things like that into it, it becomes a part of the programming thought process and part of your design process is thinking about the states that your type can be in and encoding those into your type constructors. NOEL: So specifically, just to make this a little bit more concrete, specifically in the case of Elm, a couple of things that lets you do is what in C++, we'd refer to as template types and with Java, we would call it generics, where you could say this is a list of X as you can declare something to be a list of X, where X is specified whenever you actually instantiate one of those list. Then, also in Elm, you can create types that are the unions of multiple different types. A really common one, an Elm is a 'Maybe' type, which is either null or just a value. That's actually the keyword to use, 'Just the value.' but the maybe type is the union of those two types and there's another one where there's -- COREY: There's just one thing real quick. It's not actually the union of those types. The 'Nothing' and the 'Just something' are the type constructors. Those actually construct... both of those are of type 'Maybe.' What a union type is, is I've got a type and there are several ways that you can construct effectively in instance of this type, either by just saying Nothing and using that's effectively a parameter-less type constructor or 'Just' and give it a value and that's a constructor that takes one value to it. Both of those return you something of type 'Maybe'. NOEL: That's a more accurate way of putting it. That's the kind of thing we're talking about when we say that the type system in Elm is more intelligent. It gives you the opportunity to create your own types in a way that lets you specify the valid and invalid states of the system. COREY: Yeah, like that editable or one of the common ones is a thing called 'remote data' where you can actually have your thing be either "not asked" or it's loading or it's loaded or it's error when loaded. Using these type constructors, you can use them to encode the different states of your type. NOEL: Right and then, it's relatively easy to have the program switch based on the state of that type and handle remote data differently, if it's loading versus if it's already input. COREY: Exactly because it's really easy. You just use pattern matching to figure out what constructor you used to create it and thus, what state you're it. NOEL: Right and then you can easily grab the piece of data that's there. COREY: Yeah. NOEL: The other thing about Elm is it's not just a language, it's also a web framework. It also has its own MVC -- Model View Controller -- structure and its own way of responding to events that happen and using that to change state and re-update the webpage. Do you want to talk about how that works a little bit? COREY: Yes. Elm does have the language part of it and then it also is the runtime and my understanding is that Redux is based on the Elm architecture. NOEL: Yeah but it's a lot more complex. COREY: Yeah, I mean it's not as tightly coupled to everything. What the Elm runtime does is it puts you into this update view loop. It handles virtual DOM and the virtual DOM diffing and it handles all of what are called 'managed side effects' in Elm. It's responsible for when somebody clicks on a button, it captures that and you define to it what messaging you want Elm to send to you when that happens. It handles this loop, it calls your update method with the current state of your system, gets the current state back from you, handles any side effects producing things that you need to do. If you have a language that has no side effects, seriously absolutely no side effects, then there's nothing you can really do except basic calculations so you need a wrapping framework that can handle any of the side effects that you need to do. For example, one of the big side effects is making HTTP calls. You don't actually, in your Elm code, make an HTTP call. What you do is you define an HTTP call and you return it back to the Elm runtime and the Elm runtime knows how to interpret that and make the HTTP call. Then when the result comes back, you give it a function that it will then call so it then knows how to send the results back to you. Another common example is I sort of frame it in this way, other people frame it in different ways but I frame it as Elm has no actual JavaScript interop story, meaning you don't have JavaScript interop. You can't just call a JavaScript function. What you have to do is you treat it similarly to how you would make an HTTP call and that you set up a definition of what it means to call the JavaScript function and then you return that back to the Elm runtime and it calls it. You can't call a JavaScript function and get a return value from it. It's impossible to do in Elm. NOEL: I'm going to get this wrong but in practice, what happens is you set up these different messages that the Elm runtime knows how to handle and one of those messages is I'd like to make a call to this external resource HTTP or JavaScript op and the other one is, I have received data from this and do something with it. COREY: Effectively, yeah. NOEL: That's the "I haven't really done very much with it" definition. COREY: Yeah, it's nice because every single one of your functions on Elm is pure. It will return the same value for the given inputs. By just returning definitions or saying like here's all of the information about the HTTP request that you need to know in order to make it. Then the interesting thing is that the JavaScript being the way that you call a JavaScript function, for example is you don't actually call a JavaScript function, you create what's called a port in your Elm code. That port, Elm can trigger that port. It can call out to that port, you define it and say, "I want you to call out to this port", then you give it back to the Elm runtime. Whether or not a JavaScript function gets called is entirely incumbent on the JavaScript, on your JavaScript. You have to set up to listen to that port so it's not even that you are defining a JavaScript function that you want to let Elm runtime call, you're simply saying, "Here is an opening in the safe box that Elm has constructed for me. Some external system might be listening to it. Usually, it's a JavaScript subscribes to that. NOEL: What made you decide that Elm was the solution to the problem you had? What made you decided to go with it in the first place? COREY: Last year, we were starting work on this new product and we wanted it to be very client-side interactive. Our existing system has some interactions. It's got an overlay library we've built and some stuff around that and it does some AJAX calls but because none of my team -- there's three of us on my dev team -- really want to write JavaScript. Just our personal preference, we don't really like writing JavaScript. Because of that, we didn't do a lot of it. When we were going to build this new one, I wanted us to have a really rich client-side interaction story so we were looking out at what options were. We looked at ClojureScript or we kind of put that on the board. ClojureScript is one possibility. I had, maybe two or two and a half years ago, gone through the Pragmatic Studio's Elm video course. It was an introduction to Elm back then and was really intrigued. This was an older version of Elm. I had looked at them... Some of the defining things that we wanted to make sure... we didn't actually want to write in a language that still had to use a JavaScript ecosystem framework, like in React or in Angular or something. We didn't want to just say, "Let's do CoffeeScript or PureScript or one of these that still resided in that ecosystem because -- NOEL: You wanted to opt out of the entire ecosystem? COREY: Exactly, and Elm and ClojureScript were kind of the two big ones that we looked at briefly. We briefly looked at ClojureScript but I had a little bit of experience in Elm and really liked it a lot of the philosophy around it. We all shifted over to Elm. We worked for about six weeks with 8th Light and they worked with us on a lot of the initial Elm stuff. They were learning Elm too and we just dove in and went all in on it. NOEL: You're still excited about it so I gather it's overall going well but what are some of the things that if somebody was looking to switch to Elm or start using Elm, what are some of the thing they should look out for? COREY: If you are shifting over... It's going spectacularly. We love it and we're never looking back. We're expanding it to basically, everything we do on the frontend is now in Elm. If you're coming straight from an OO language and you don't have a lot of experience with functional languages, there's a couple of places in our system where we made a couple bad design decisions around trying to make things too generic. There's one part of our system, this one piece, which effectively tried to shoehorn an object into the system. It's got functions. It's a record that contains the data and the functions to operate on the data, which at the time seems like a pretty good way to make a generic thing. In the end, it has caused us just tremendous pain. I think it's less about Elm and more about the unlearning curve of some of the habits wanting to come in, especially if you're coming from an existing JavaScript framework. If you are coming in from React or something, a common question that comes up in the Elm Slack is the idea of how do I build a component, how do I build a component that encapsulates its own state. It's shifting over into this thought of everything's just a function. There are patterns that we use. There's design patterns around the functions but the things that you do normally in an OO language, don't translate as nicely. NOEL: You don't really have components in the same way you have state and you have functions that turn that state into DOM elements. COREY: Yeah. It's easy to think in terms of components of like, "I have this reusable calendar widget," and it's like, "What you have is a reusable set of functions that know how to build the HTML for a calendar." That set of reasonable functions may be associated with a standard set of data that they need. NOEL: Have there been technical limitations and things that you wanted to try that were either very hard or not possible, given the state of the ecosystem or things that you needed to build that you would have had to build in another tools? COREY: We do use a WYSIWYG JavaScript library, a WYSIWYG editor. It was a bit complicated to interact with or interface with it so there's not a lot of things like that but we've never been big on pulling a lot of those things. There's no binary data type which makes uploading and file manipulation cumbersome at best. In our system, we have situations where we want to upload images and we run into some problems around that. We've been able to occasionally workaround with it by, I don't know what the term is, switching it over into its data URL representation, which is then just a string of characters but that's kind of a hack. It feels very hack-y. When we are doing image uploading, we've had to workaround a few things and jump out into the JavaScript side to do some of the stuff there. NOEL: How hard has it been to work with styling or work with designers? I know that one of the things about Elm is it generates HTML and it doesn't use templates. The framework doesn't use templates by default. Everything, the HTML is generated from functions. Has that been a problem? Do you have non-technical designers on the project? COREY: We have our design and he's our designer, frontend dev and he writes Elm. If you have somebody who writes like ERB, and can do things like if statements and you take a little bit of the time, you can teach them to write Elm. Writing Elm's HTML generation looks a lot to me like Haml. NOEL: Yeah, it does. It's a lot like Markaby, if you want to pull back a little bit from a deep cut Ruby. It's like writing Haml but a little bit stricter. COREY: Yeah and you have a function called 'div.' It takes a list of attributes and then a list of child elements. If you just treat it that way, then it's fairly straightforward to write any then you get the full power of a programming language like Elm and the safety and the type safety and stuff like that. Our designer codes and so he has jumped in, there are certain parts of the system that are a little bit, I won't say advanced, as maybe like esoteric type things that we do in the system, that he doesn't quite get yet. He doesn't work in that part of the system that often so jumping into it can be confusing. He like, "Well, let's work on that together," or, "Let's jump on a screenhero call real quick." But he does it just fine, he cranks it out and we do a combination of straight up CSS and then we just add class names to our elements just like you would in anything else. But also, there's a library called Elm CSS that is effectively a type safe way to generate CSS. We do that. We use Elm on our new embed modules, things that get embedded onto our client sites so they're small little forms that sit on our client's websites and the new ones are written in Elm and we generate the CSS and shove it onto the page using this library. The nice thing too is that when we started, we just were straight up using classes. We wrote SASS and everything just worked fine so if you have a non-technical or non-developer designer, they should be able to just work the same way as normal. NOEL: What's the community like, the Elm language community? COREY: I find it incredibly friendly and incredibly helpful. There's the Elm Slack, which there's so many people there who are both of the beginners and the general channel that are constantly answering questions and discussing things. There's a very little push back for new people coming in and since it is a somewhat new and small community, everyone's just happy that people come in. It's interesting because you have sort of two funnels in, one from the Haskell side and one from the JavaScript side and their backgrounds or perspectives are usually so different that a lot of the questions that come in are really, really different. Like the people who come in from the JavaScript side are seems like, at least once a week, somebody is asking about components and how do you build components. Then on the Haskell side, people come in and then they are generally complaining about the type system because it's missing some of things that the Haskell type system has that Haskell makes extensive use of like type classes so it comes in like, "How come Elm doesn't type classes. We need type classes." But it's almost always, especially in the Elm Slack, I don't spend a lot of time on the mailing list, it's always a friendly environment and a friendly atmosphere there of people answering questions. NOEL: Where would you recommend somebody to get started, if they wanted to start picking up Elm and using it? COREY: If you go up to Elm-Lang.org, there is a guide introduction to Elm. It's http://guide.elm-lang.org and it's a quick, walks-you-through building some of the basic stuff and definitely, go to the Elm Tech Slack. If you go into the Elm Slack, you go through the guide. That's what everyone's going to point you to first is the guide and then ask questions. A lot of people while they're going through the guide will ask questions in the Slack and that's where people answer them. Then there's a whole range that leads you to... people will suggest stuff in the Slack. I like the Pragmatic Studio videos but there's lots of people now doing some introduction videos and how to do this and that. There's a remote meetup that happens from time to time. There's a few of those and there are some interesting talks from people about stuff they're doing but the language site is a good place to start. NOEL: What haven't I asked you? What do you want people to know what Elm or working with Elm? COREY: I think the big thing is if you are coming from like a JavaScript background, to come in a very, very open minded and take on that proverbial beginner's mind and come in, pretend that you know absolutely nothing and then just start building up and not come into it saying like, "How do I do X because that's what I do in JavaScript," or in another language and instead come in and say, "How does Elm do it?" NOEL: It's sort of funny... this is how I came into it, like I started playing with it because I was evaluating the code example problem that we give to our prospective hire candidates at Table XI and I was trying to evaluate how hard it was for a novice. I thought that it wouldn't be fair to compare how I would do it in Rails so I thought, I'll do it in Elm, a language I do not know and that will give me a sense of how complicated and how long I'm going to expect a novice to take on this. With Rails 5.1 and Webpacker, it's super easy. Elm is a privileged language in Webpacker. Rails 5.1 gives you a default Elm set up out of the box if you want it. COREY: I did hear that, I did. I've seen people talked about that. NOEL: Yeah, it's super nice. You web pack install and basically, it's there. You can start writing Elm in the framework, and it gives you the framework skeleton and you just go. I expected to be a little skeptical because of the type thing but the more I used it, the more fun I was having doing it and the more I felt like the absence of the kind of incidental complexity that I get when I try to do Vue.js or the other JavaScript frameworks and I was able to do it without a whole lot of frustration, especially for a language that I hadn't really touched before and that how I was got to know it. COREY: Yeah, you have a good point. It reminds me of when I started doing Ruby and the joy that I had when I would write Ruby and I still, for the last week or so, I've been back building some stuff in our Rails app and I love Rails. I love working in it. Elm has that similar feeling to me. It's just like it just feels good to write and the compiler is nice, the compiler is friendly, there's a lot of effort on making the error messages friendly and actually useful. NOEL: Yeah, the error messages almost always say like, "This is what I saw. This is what I expected to see. This is probably what went wrong, where you should look." It's really handy. COREY: It's really good. I love it. I really enjoy working in it. The thing that I would tell a lot of people is it's a really great functional language to move into if you've never done one before. I made a comment at the very beginning that I like to call it Haskell without the academia and not as a dig or a better or worse kind of thing. But Elm is a very, very much focused on making it a out of the box experience, productive, build your web app. It's focused on building web apps. Evan, the creator, he keeps up a pretty good laser focus on making it useful to build web apps right now. You don't come into Elm and then suddenly there's all of this complexity in the language that is not focused on building web apps. It's a great way to just come in, learn about writing functional code in a language that immediately you're going to start seeing results. NOEL: Yeah, I think that's a really good way of putting it. It's a very practical, academic-y kind of language, if that makes sense. A lot of the times the pure functional languages do feel like they're designed for an abstract world that doesn't really exist but Elm really does focus on trying to get DOM elements on a page. COREY: Yeah and it's that idea. Say, you take a language like Haskell, there are lots of things you can use it for. The Elm compiler is written in Haskell so clearly, a compiler you can write in it. There are web frameworks. You can do AI, all of this stuff in it. Elm is basically for one thing, which is like you said, it's getting DOM elements onto a page and then making AJAX requests back and forth. That's pretty much what it is for. It does it really well and it's a laser focused on making that and enjoyable and productive experience. If you keep that in mind, it's a really fantastic way to come in and learn what it means to have like no side effects of what pure functions, immutable data and things like that. NOEL: Cool. I think we're at time and seems like a really good place to stop. Where can people reach you online if they want to say, "Hi," or ask you more questions about Elm? COREY: The best place is Twitter. I'm just @CoreyHaines on Twitter. It seems like I'm paying attention to Twitter more frequently than I should. I have a blog that I haven't written on for a couple years at CoreyHaines.com. But pretty much Twitter is the place to find me and reach out to me. NOEL: Great. Corey, thanks so much for being on the show. I'm really glad I got a chance to talk to you about this. I've been having a lot of fun playing with it and trying to figure out places where I can use it in my day-to-day work too. Thanks for being on the show. COREY: Awesome. Thanks a lot. NOEL: Tech Done Right is a production of Table XI and it's hosted by me, Noel Rappin. You can find Table XI on Twitter at @TableXI and me at @NoelRap. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded via wherever you get your podcasts. You can send us feedback or ideas on Twitter at @Tech_Done_Right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us and we still do have a software development position open that you can apply for at TableXI.com. We'll be back in a couple of weeks with the next episode of Tech Done Right.