Elm and Functional Programming

I'm Richard Feldman and you're listening to the Changelog. Welcome back, everyone. This is the Changelog. I'm your host, Adams Dakoviak.

This is episode 191, and on today's show, Jared and I are joined by Richard Feldman from no redinc. We talked about elmlang, the best of functional programming in your browser. We talked about functional programming versus object oriented programming, how ELM can boast about no runtime exceptions. We dove deep into elmlang itself and whether or not it's really faster than React or not.

We talked about JavaScript fatigue. We also talked about the best ways to get started with Elm. We have four awesome sponsors for the show. Codeship, DigitalOcean, Outbeat, and also Container World.

Our first sponsor is Codeship. If it works with Docker, it works with Codeship. For those out there with established Docker workflows or those looking to leverage NEO Docker support while automating your testing and deployment, check out Codeship's new docker [email protected] changelog and for those looking for great resources to automate your development workflows with Docker, you should download Codeship's free ebook covering why consistent environments are so important, how a company lost $400 million in 45 minutes due to inconsistent environments, and also how to build an app to run aside an isolated Docker container. Head to codeship.com changelog to check out Codeship's new Docker platform.

And head to resources codeship.comebooks to download that free book I mentioned on automating your development workflows with Docker. And now onto the show. All right, everybody, welcome back. Today we're talking all about elm, a new functional programming language for the browser that's been making some pretty big waves in the open source community.

Joining us to talk about ELM is Richard Feldman, who had hit talk at Strange Loop this year titled make the Back End Team Jealous ELM in production. Richard, welcome to the show. Great to be here. That's a nice name for a talk.

I'm jealous. Yeah, let's get upset. Voices Adam Stack. Adam, what's up, man?

Hey, dude. What's going on? Just excited for elm. How about yourself?

You know, I'm pretty excited about it. We talked about it a little bit with Dan every month recently and a couple shows. We mentioned it here and that we haven't had a chance to dive deep into it. And I think it's always interesting too, whenever conversations like this bubble up from our community.

So again, another great suggestion here from Kevin McGee. He suggested us to talk to Evan a while back, and it was like, September 17th. So, you know, if you're out there listening, you're like, hey, I submitted an issue for a podcast suggestion to your ping repo. Why haven't you responded yet?

Well, it takes us a bit to do some research, and we've got a backlog of shows, but nonetheless, at some point, I believe Richard chime dinner, he was suggesting that's kind of how this. This evolved into a conversation here. Right on. So we should say that, Richard, your involvement with ELM is what.

With elm as an open source project, My contributions have been fairly. I don't know, I don't want to say superficial, but I can't take credit for any of the compiler work or anything like that. I made some tools around it, the most recent, which is ohmcss. Like, I made the original version of the webpack loader, the Grunt plugin, a library that's a node wrapper around the L compiler for use in various projects.

So I've definitely been more of a contributing community member than a core contributor, I guess. Seems like you might even be taking on the role of evangelist to a certain degree. Is that fair to say? The term evangelist is weird to me.

I'm definitely a big proponent, but I mean, I mean, people have said that about me. Really. The truth is just that I'm excited about it and I talk about it a lot, but, you know, I don't have, like, nobody's telling me to do that. I'm just kind of like, I just am excited and I'm loud.

So I guess that's how I come off sometimes. That's funny, Jerry, because back in the day, remember, I think you and I had some conversations about it before you even a part of the chainsaw. We just listened. When I used to say drink, when we'd say Sass or node, and that's kind of how people saw me, was like, hey, Adam's a really big fan of Sass or a big fan of Thor.

And anytime I get a chance to tell something about these things, I'm like, you don't know about this. Oh, my Lord. Come on, sit down. So kind of have some similar there.

I think the term evangelists is. I think it has some connotations of somebody who works officially for something as a marketing person or a promoter. But I was using it in the more denotative form of, like, someone who's out spreading the good news. And it seems like whenever ELM is brought up, Richard, your name is around that conversation because like you said, you are excited about it and you're out talking about it.

So that's all good stuff. So let's get to know you a little bit personally first before we dive into Elm and all of his goodness. We did some research on you, but I think it was in vain because there's a lot of Richard Feldmans out there. But unless you're a 67 year old writer or an American bicycle racer who does mountain bike races, I'm not sure that we found out too much about you.

You have a Twitter on GitHub and that's about it. So can you tell us a little bit about yourself and how you got into the programming game? Sure. So I got into the programming game when I was nine.

I was really into games and I kept bugging my dad to sign me up for some sort of course or something that would let me make games for people. And instead of that he got me a book on basic. Learn BASIC now. And so yeah, but I ended up reading it and I got discovered really into it.

And at first I did was making games and stuff like that. And somewhere in college I always kind of assumed that I was gonna end up making games. And I talked to some people who were giving me some sort of inside scoop on what the actual games industry was like and it sounded pretty miserable. And I was like, wow, I don't know if I want to do that.

And somewhere along the line I learned about the web and developed the web. And obviously I've been using the web, but. And actually, I guess specifically the way that I learned web programming was I started a company that was going to be based on the web and so I sort of had to learn it. And so at that point I got into Perl, this one, I did Java, C, C basic, Visual Basic, and that's about it.

Then I got. So Perl was actually my first introduction to web programming and of course JavaScript. And so I just sort of picked it up and got more and more into it. And the more I did with it, the more I fell in love with it.

And at some point I kind of realized that I really like user experiences. Designing for user experiences, creating users, delightful user experiences. And part of that is just sort of the delivery process. Actually I talked strangely two years ago around Dreamwriter, which is this open source writing tool that I made.

And the talk was basically about, I guess offline first wasn't really a buzzword yet at that point, but that's what it was. It was just a demo of doing, you can bring it up. It works offline using IndexDB and Appcache, because Service Worker wasn't out yet at that point. And that was all just based around my sort of desire for this particular ux.

I was just like, well, I want it to work and I want to be able to bring it up and use it on an airplane. And I still want to be able to sync with servers and just have that nice no installation experience that we've always had on the web and never had with native apps. You just get to take updates for granted. You're just always using the latest version right away.

And so I guess at that point I. I built this big thing, Dreamwriter, and I had sort of been getting a little bit more into functional programming for the first time. I had some friends telling me about it and encouraging me to try programming JavaScript in a more functional way, or CoffeeScript as the case was. And at some point I started looking into other compiled JS languages.

And to make a long story short, I settled on Elm as the one that I wanted to use to do a rewrite of Dreamwriter and get rid of a lot of technical debt that I had accumulated. And I just had this mind blowingly great experience with it. I remember just feeling like it was like I was, you know, 10 years old writing Visual Basic again, just being like, I can make UIs. This is amazing.

Yeah, it was, it was just so much fun and so just delightful. And I've just gotten more and more into it ever since. And it's, it's like to the point where you mentioned the title of my talk, make the Back End Team Jealous. The reason that I called it that was the inspiration for that was having a talk with one of my coworkers at Neura Inc.

And he basically commented, you know, I'm kind of jealous working on the backend here because it seems like, you know, the front end team has gotten so energized and excited about Helm. It's done so many awesome things for our front end that I wish we had something like that on the back end. We're a Ruby on Rail shop and you know, traditionally it's the other way around where people on the front end are saying, God, I wish I had a nice language like Ruby that I could write front end code with. But yeah, it really turned things around.

Curious about the. Just going back a little bit to the company that you first founded writing some pro scripts with some CGI stuff. Back in the day you said you started, you were starting a company on the web. And so you just decided that you should be a programmer on the web?

Is that what you said? Yeah. So at that point I'd only ever done client side programming. I'd never written a server, I'd never done any.

You know, back then rendering HTML on a server was sort of the best practices like 2006. And the idea of building your UI primarily in JavaScript was still a very. Its time had not really come yet. And yeah, ironically, not ironically, strangely.

I guess the reason we ended up with Pearl was because this was me and my roommate and a couple other guys putting this company together and we were trying to find some way to sort of get a code base started and we ended up finding this piece of open source forum software that already had a bunch of features we needed, like authentication and a bunch of discussion features that we want to incorporate into the product. And so we just said, hey, why don't we. Why don't we fork this and just, you know, use it as a starting point? And it happened to have been written in Perl.

And so we're like, okay, well let's learn Perl, use it. So that was our thought process that ended up writing Perl for a couple years. Do you remember the name of that forum software? Yeah, it was mwforum.

Mwforum. All right. It's not. When I was remembering I did do some Perl back in the day, back in my very first blog.

Adam, I think I told you that story was a static site generator called Bloxom. Like a cross of awesome and blog. I'll never say it. And yeah, that was a Perl script that generated static files based on a set of text files.

And I thought that was pretty lame because WordPress had just come out and I thought why would I want satisfy files when I could do dynamic things? Anyways, it was funny when Jekyll and these things started coming out, I was like, wait a second, this is cool now I thought this was what we were doing back in the day and I thought dynamic was cool and now it's tumble circle and things. That's pretty cool too. Anyways, NW form.

Haven't heard from it but I love. I think you would because the homepage is pretty. I'm not. I guess it's somewhat current, but it's pretty sparse in comparison to what you would see for an open source project these days.

It's nw4.org if I got it right. I haven't been there a long time. It's kind of basic. It's still around, apparently.

So. Yep. Based on Pearl CGI scripts, MySQL SQLite. Pretty nice back.

1995. Copyright 1995-2015. Out there rockin'. That's a long project.

It is. The last Release was version 2.29.7, released December 5th of 2015. So he's still rocking it. That's current.

Real current. That's dedication. That is dedication. Yes.

That's 20 years. Let's revive this thing. Everybody go there now. Don't think it's gonna get Hub.

I don't know. This was. I don't think ditto was really a thing yet at that point. Definitely not 1995.

Well, yeah, yeah, 2006, it wasn't a. Yeah. GitHub zero. First year was 2008, I remember correctly.

That's when the git explosion, so to speak, happened. I love the power of open source software where, you know, Mark Wichitil, if that's how you pronounce his name, is just out there rocking his, you know, his burl forum. And a complete stranger from, you know, who knows where can come by and start a business, you know, with that software and use it as a launching point into a business that, you know, sometimes they succeed, sometimes they fail, but it's just cool how much it propels us, you know, into being productive. It never ceases to amaze.

Absolutely. So one more question I have for you before we hop into the ELM stuff, is just to expand a little bit on your Twitter bio because like I said, I couldn't find much in a way of bio for you, and your bio is about as good as we got, which just says, let's go with the ambitious approach. Yeah, sounds kind of like a way of life, like your motto or something. Yeah, I don't know if it's a motto.

It just kind of occurred to me that it's something that I say a lot, I guess, whenever I'm. I like putting myself in situations where we have the opportunity to do something like new and exciting in a way that's never been done before. And then often when getting into implementation details or something like that, we'll find ourselves in a situation where we're asking a question like, well, which of these three or four different approaches should we go with? And usually I'm the guy say, let's go with the ambitious approach.

So if there's an easy route, a quick and dirty hack, and there's something that's kind of like, well, this is quite the nicest user experience, but it'll save Us a bunch of time. I'm usually, let's do the ambitious thing. Let's do something anybody else has done before. And I figured Twitter's all about brevity, so I'd sum myself up that way.

Nice. I like it. Reminds me of that thought. Reminds me of something I used to say all the time, which is temporary.

Solutions aren't. Which is temporary, nor there are solutions. You know, the duct tape approach ends up being permanent, unfortunately. And so I kind of line up with you there about the ambitious approaches.

The way I think was like, let's do it the right way now, and let's take the time, you know, as opposed to doing it again, you know, three weeks from now or six months from now. Reminds me of a line from one of my favorite movies, which is Fear and Loathing Las Vegas. It's the best movie ever, and if something's worth doing, it's worth doing right. Nice.

I love that one. Yeah. I sort of embrace that philosophy with my sort of implementation process, where rather than trying to design my prototype as something that will grow into the production version, I instead try to say, okay, we'll have two distinct phases here. First is experimentation, and I'm just going to hack everything together, usually in jQuery, you know, as fast as possible, just to sort of validate the UI and just see if it seems like it makes sense.

When I try it out and it's completely unattainable, and I know that I'm going to throw it away, and then as soon as I get the design I like, I'm like, cool, throw it away. And then build the real version in L. And then I sort of get the best of both worlds. I get to start off not having to, you know, feel constrained by doing a nice job making something maintainable, because I'm not going to maintain it.

And then the second time around, when I am building something, I can be confident that it's something I want to. Want to maintain, because I already validated that I like the design. It's a similar approach as anybody has for, like, writing, too. Like, when you write something like something, write the novel, for example, they don't start out like, writing the novel.

They write out the outline or they, you know, they put something together with. Without any editing or punctuation. It's just like trying to get the thought out. And that's the same.

I think we have, like, in your case, where you want to get to some sort of validation point. It's like, yes, I should continue. And if I do Continue. I have constraints around that and methodologies and frameworks and things that they can step in and begin to make it long term maintainable and also collaborative with other people.

Yeah, definitely be very effective. I think it takes a lot of discipline to do what you said there, Richard, where you're going to throw the prototype out because it's really easy to fall in love with that prototype even if you don't want to because you got your blood, sweat, tears and that thing right. So kind of like that prototype. Like I'm going to build it with, you know, I'm going to make sure it's hacky, I'm going to make sure it's unscalable, I'm going to make sure it's kind of ugly so that I don't feel attached to it.

Yeah, that's a good point. I mean it's really a selling point of a good prototype is that it's so horrible that you would never want to maintain it. Yeah, but nobody wants to maintain a prototype. I remember doing something like that too.

The Jerry just fall in love with it. And you have to be careful of toeing that line because you could begin down the path of creating it and you plan the throw away. But you're like, I could probably polish this thing. You know, it could not be what it really is.

It could be more special and you kind of get stuck there. But Richard, to your point, having this point of actually creating it and knowing your throw it away, it's probably helpful because it lets you explore because you're like, forget it. If I mess it up, then who cares if I'm just throw it away anyways. You're very deliberate with the exploration process.

Exactly. That's pretty cool. I met a guy a couple of years ago at NG Conf, the very first NG Conf, whose job it was was to build prototypes gonna work projects for a larger company that had a successful business. They were just, you know, trying to try out new ideas and he would build, he'd build like a new thing every week or every couple weeks and they just throw it away.

And he was having the most fun of any way or he loved his job. And well, I can't envy that to a certain degree, but I could easily see how that'd be fun. Well, on the other hand, we want to build software that people use and so like throwing your thing away all the time is also kind of like, I think that'd be dumb. I wonder how many things he built that didn't get thrown away.

That turned out to be big things though, because if you, you know, if you do 10 things a year and two of them are hits but you had fun no matter what, then I think it's still kind of worth it because you're into the process. We forget that. Yeah. All right, well, I think this is a good place to take a break.

We'll come back and we will dive deep into elm, hear all about it. What has Richard so excited about it? And you know, it's not just him. A lot of people are talking about ELM or pointing in ideas from adopting a whole hog.

We will find out why after the break. DigitalOcean is simple cloud hosting built for developers. If you have not tried DigitalOcean yet, in 55 seconds you can have a blazing fast SSD cloud server up and running with your choice of Linux distro, cpu, RAM and even create new droplets based on backups or snapshots. And times is a cool feature for those that operate in teams.

You can invite multiple users to access and manage your accounts infrastructure resources while keeping all of your sensitive information totally private. Head to digitalocean.com and make sure you use our code changelog to get a 10 credit when you create a new account. All right, we are back with Richard Feldman here to talk about elm. Richard, the homepage of ELM says it's the best of functional programming in your browser.

But let's start with the first part of that before we get into ELM itself. Why functional programming? Why functional programming? I guess the main benefit to functional programming is just the fact that it makes certain problems go away.

Some of the biggest sources of bugs can be traced down to particular fundamental things like having sort of excessively large implicit state mutating things, destructive updates, functions that have side effects that you don't realize. And functional programming is a sort of frustrating term to deal with because it's very prone to different interpretations. But certainly what ELM means by functional programming is having no side effects anywhere in the language and everything being immutable. And so those, those two things I mentioned earlier of sort of implicit state updates by side effects of functions and destructive updates, mutating things don't exist in L, and because of that you end up with entire classifications of errors that don't exist anymore.

And we'll get to some other things that L eliminates later. But that's the main draw. It's just certain types of problems that happen, especially as code bases scale, that just don't happen if you use a functional programming style. So L itself is a language.

There's also an architecture, so maybe confusing to some. Some people might think of it as like a framework, so it may compete with React in certain ways, or maybe not. There's a lot of just kind of people wondering what exactly it is and how it's different than all these other things that we find on the front end. I think perhaps the most differentiating thing is it is an actual language, not a JavaScript framework.

Can you explain why ELM is a language? Like, why do we need a whole new thing? Couldn't we just do FP functional programming in JavaScript? Yeah, you can.

That's what I was doing before I found Elm. So basically Elm is a clean break. So JavaScript, we all know, sort of hacked together in like two weeks back in the day and people have been sort of patching it ever since. And ECMAScript, like TT39, all these different committees have been working on different editions of it and they all have to be backwards compatible to a large extent.

And ELM is sort of coming in this in the other direction. So Evan Chaplicki, the creator of elm, basically sat down and said, what do I think is going to be a nice language to make UIs with? And he started off by saying that rather than how can I improve JavaScript, he just said, just forget that just starting from scratch, what would be a great language to build UIs in? And then he built that language with the idea of having a target JavaScript.

But from a design perspective, it's pretty much clean slate. It's just saying, hey, what's going to be a great developer experience? And so there are a lot of different languages that compile JavaScript that go the other way. So TypeScript, for example, is saying, hey, let's take JavaScript and let's add types.

CoffeeScript is saying, hey, let's Take, let's start with JavaScript and let's clean up certain things and let's add significant white space. Dart, it says, let's take JavaScript, let's change it these ways. L is totally different. It's starting from scratch and just saying, let's make a great language for building UIs and let's have that language compile JavaScript so it'll work in the browser.

So maybe you could compare it a little bit with closurescript then where you have a closure functional language on the server. And now we're thinking functional, we're writing closure in this case and we're compiling the JavaScript. Is it more in line with closurescript than say, Dart or TypeScript? Yeah, it's definitely not certainly true.

I mean, Closure Script and David Nolan want me to point out that Closure script is essentially just closure in the browser. They're not really different languages, closure and Closure script. But the main difference between Closure and Closure script and elm, actually there are two main differences. One is that closure is a list, of course, so you have S expressions, lots of parentheses.

ELM is not. It has syntax that looks a lot more similar to traditional language where you have like x plus Y rather than plus xy, things like that. And that closure is not type checked in lbits type check. So I think out of type checking probably comes a lot of the advantages that you guys are espousing and sound like they're delivering on.

Can you explain the type checking, why that's important, what that does for us? Sure. So I actually have an interesting history with type checking. So I started off in a type check rules like C and C and Java, and then I switched from that to dynamic languages, first with Perl, then with JavaScript and later with Ruby.

I actually felt that dynamic was much better. I just remember thinking like, man, I had to do so much work to be like, this is a string and this is an int. And just writing out all this verbosity and just not really getting a ton of benefit out of it. And I remember hearing about languages, modern languages that had type inference and faster compilers.

That's, I guess another big deal is that Java in particular, I remember just like sitting for like minutes just waiting for the compiler to run and just thinking like, wow, you know, in Pearl I could have already been trying this feature, but. But now, you know, I've heard that modern compilers have type inference, so you get the. Basically you don't have to write out all the type annotations all the time. You can just write code that looks like Ruby code essentially, except that the compiler will tell you if you have a type of match you're trying to call something passing the wrong type of value.

And also that they can be a lot faster than those older compilers. And essentially ELM has just by far the best compiler ever used. So not only does it tell you, you know about type of matches and stuff, but it does in this incredibly helpful, friendly way. Like if you have, you know, let's say you're passing a record, which is kind of like an object with like 20 fields in it, it's like a user record and you got like username, first name, last name, address, email, all these things.

And, and you have a typo in one of them. So like instead of phone number, you have like phone number. Like you slot the E and the o or the EMN. And in JavaScript, if you do that, then you're going to, you know, eventually you'll get an error where you're trying to reference phone number and it's going to be undefined.

And then you'll get an error and then be like, why was that undefined? You have to step back and, you know, trace all the way back. But the compiler will just tell you about that immediately and only will tell you about it. But it'll say, hey, here is what you were.

You know, you're calling this function and it's trying to access something called phone number, but what you're passing, it doesn't have phone number. What it has is phone number. And it'll boil down to that one line. It says, it looks like you have a typo.

It's actually something in the compiler that does a little distance check to see if it looks like you made a typo. And it literally will say, it looks like you made a typo between these two fields. And that's just so far removed from my experience with Java and C that I just can't even compare the two. And as far as speed, I mean, it's basically instantaneous.

It's just so fast to compile. It's like usually under a second to compile the whole app. And that's because it's really smart. Caching the first build will take a little longer, it'll take several seconds, but then after that, it's pretty much instantaneous.

I had this one crazy experience with a coworker where we were doing this big refactor and we made a bunch of changes, we broke a bunch of stuff, and we're just going through fixing all the compiler errors that we generated. And we did this for about hours. It was a big change. And by the end of it, once we'd already worked through all compiler errors, we finally were like, okay, let's see if it works again.

We switched over the browser to refresh the page to see if it worked, and we were just struck by, wow. Waiting for a page to load is so slow compared to just hitting recompile and having it immediately tell us what the next problem was. And just remembering back that, like, you know, in JavaScript landmine, what I'm used to is every single time I refresh the page and I look at, you know, or if I have a hotloader, you know, reloading that, and then like looking at the Console for the error and just like how much faster is this to be at the console? Just be like recompile.

It's like, here's the recompile, here's the here. It's pretty nice. I like spotting these kind of trends is this continuum of changes that we kind of go through as a community over time. And it seems like your path kind of corresponds with my own.

Where you start off with Java perhaps or a statically typed compiled language where long compile times, a lot of ceremony. And to a certain degree most of us, some of us kind of rebelled against that and went like full dynamic scripting languages, high level everything. And then we started to realize that you lose some things that were nice in a static type world. Like you said, these compiler warnings tooling as a Typescript folks, I will tell you they have all sorts of great tooling built up around TypeScript because of that.

So now it's like, well, it wasn't so bad, but can we mitigate things we hated, which was slow compile times and all the verbosity. And so these new languages come out with, like you said, really optimized compiling times, type inference and really just things that kind of make it palatable for us and kind of have the best of both worlds. So it's interesting, I want to say that there's a trend, but if I did this as an exercise a few months ago, I was thinking like, what are my like top 10 favorite programming languages to use? And like, you know, basically on the metric of let's say I'm starting a new project tomorrow and it's totally greenfield and you know, what language am I going to choose just based on my own personal preferences just to see if I can learn anything.

There's just no relation between a language's position on my list and whether or not it's type checked. It's just like, like Elvis number one, but like CoffeeScript is number two. And like I've used Scala before which has, you know, a lot of type safety, it has mutability, it has a lot of functional stuff. But the compiler is so slow.

And you know, there I have some other objections to it too but like it's like significantly further down the list than other dynamic languages. And then, but then again you have, you know, other. Yeah, basically when I was doing this exercise I thought, you know, it's really not about type check versus not, it's really about how nice is the compiler. And that's really a very language specific thing.

Like I love ELMS compiler. It's really great. It's really helpful. But I can't say the same of, you know, most of the other compilers I'd use.

In a lot of cases, I'm like, look, I really just got out of my way. You're not gonna be helpful, you know, just get out of my way and I'll take care of it. Just be fast. And elm's one of the first compilers I'd use where it actually seems like it's pulling its weight.

You know, it's actually like something that I would miss if ELM were dynamic. Instead, I miss it a lot. So if you had a rate characteristics of languages that are appealing to you personally, a great compiler is like, really high up the list. What are the other top things that represent your YouTube languages?

I don't know if I would have rated. Compiler is one of my most, you know, sort of prized things until I had the lcm. I honestly, I've. I feel like I've learned a lot from elm, a lot of things I didn't.

It sort of made me challenge a lot of assumptions I had about what I like about programming languages. Because, you know, I. There are a lot of ways in which ELM has different other languages. One is the compiler, but also just the fact that, you know, none of the functions have side effects.

They're all totally stateless. I've never used another language that has. At least not for building anything serious. Again, I mess around with Haskell, but Haskell's too hard for me.

I can't hack it with Haskell. But when it comes to elm, you know, it's like, it's got that same invariant where you have no side effects. And I've never really done programming that style before, and. And now that I have got some experience with it, I actually definitely prefer it.

Same thing with immutability. It's like, well, you know, this is one thing when you're using a library like immutable JS or seamless, immutable, shameless plugins, but it's totally a different thing when that's all you have. You have no mutations ever. And, you know, so the question becomes, how do you deal with that?

You know, what if you have something where you're like, well, what I would normally do is I would mutate some stuff, but you don't have that available. What's it like working a language when that's all there is? And again, it's something where now that I've experienced that, I'm like, oh, yeah, that's totally what I want to do now from now on because it just again, just makes certain problems not exist. Whenever I'm like, okay, this value ended up in a weird place.

I don't know how it got this value and I'm asking like, how did it get in this state? And it's really obvious because it couldn't have been mutated. It's not possible for it to be muted no matter what the value is, there's no mutations ever. So I just look at, okay, well who called this function?

Who called that function? Who called that function? And it's just this very clear chain of functions calling other functions that are the only possible culprits for, you know, how a value got changed. It's really nice.

Yeah, I can definitely relate. I have a Ruby and JavaScript background and been writing some elixir lately and the immutable thing, at first I thought it was going to be a big hurdle for me because I'm used to Ruby where it's like, do whatever you want, man. Instance variables mutate, you know, bang. Methods that mutate the object.

And I just thought that would be really kind of like putting on a straight jacket to a certain degree. And then I've also seen people who try to take Ruby and write, you know, kind of Gary Bernhardt's idea of the functional core and comparative shell. I already call Xavier. She basically keep all your isolation mutations in certain areas and write functional style Ruby, object oriented Ruby wherever you can.

And that just seems like a lot of decision making and you have to like instant institutionalize that if you work with other people. But there's something freeing about like elixirs just like, no, you can't mutate anything, sorry. And so I don't get to choose. And it's only really been annoying like once or twice where I just say, oh, I have to take an extra step or you know, just think about it slightly different.

It has been really kind of freeing to be like, I just can't mutate things. And of course all the benefits with concurrency, concurrency and stuff, all of that are really awesome as well. So I can definitely relate with you and your experience with elm. I haven't tried it with ELM yet, but very interesting.

And I want to talk about the architecture itself too. So the front end architecture of elm, because it's a language, there's also an architecture like here's how you build ELM applications and ELM has a lot of features on the homepage that are really great and it seems like some of those features fall out of the language. Itself and some of those fall out of the architecture. But first, let's take a quick break because I feel like that's a pretty big conversation.

Let's hear from another one of our awesome sponsors. And then we get back. We'll dive into ELM architecture and what that's all about and why it's interesting. We'll be right back.

Our friends at opbeat are all about application monitoring for developers. And today we have some Good news for AngularJS listeners out there. Great performance metrics should not be limited to server side applications. So we're excited to say that our friends at Opbeat have opened up Authbeat for AngularJS and they're accepting beta signups right now.

Head to offbeat.com angularjs to sign up for this beta. Here's what you expect. You'll see the performance of your application in near real time. You'll be able to visualize the distribution of route render time so you can isolate edge cases.

You'll also see a breakdown of your AJAX calls, template rendering digest and more. And you'll also be able to see the actual code that's slowing down your quests. There's also mobile friendly views for when you're on the go. And all you've got to do is head to opbeat.com angularjs to sign up for the beta.

All right, we're back from the break and we are here with Richard Phillman talking about elm. Of course, Jared, we're going to say the funny joke, the dad joke, but we're going to leave that there. But when we think about architecture, when we think about that, that funny joke, we're not going to say, maybe at some point you'll see it, but we'll see, oh, no, I gotta know. You wanna do it?

No, I don't wanna do it. You wanna do it? Okay. I put a dad joke into our notes that I was gonna do because I'm a fan of dad jokes.

And then Adam's just like, I don't get it, I don't think it's funny. And I'm like, I guess we're leaving that one out. So now you're just throwing me the wolves here. No, I'll do a tldr.

Long story short was like when you look it up, when you look up Elm in Wikipedia to kind of find some sort of description of it other than the website, it just has a description of Elm trees. And Jerry's gonna read that and it was gonna be funny, but it'd be a dad joke that wasn't Funny. So there you go. So that leads us to the topic of architecture, though.

Excellent subway. Yeah, perfect architecture. Right. So it's no hidden secret here.

I'm more of a frontender. ELM is invented to create interfaces. You know, we talked a bit about different things of type checking in the past segments, but what is it about the architecture? What is it about that that should appeal to friends that maybe I haven't gotten?

Why am I intimidated? Well, I can't speak for you as to why you feel intimidated by. I would assume it's just because it's very different. Right?

So one of the claims that I'm comfortable making about ELM is that it's much better than the JavaScript experience, but for something to be much better, that sort of implies that it's much different. You can't really have something that's just like slightly different and yet much better, unless the original thing was just missing something glaringly obvious. And JavaScript's been around too long for that. So I think as far as what the architecture brings to the table, essentially you guys mentioned you had Dan Abramov on earlier and yeah, so he basically ported the elm architecture to JavaScript with Redux.

So if you're familiar with Redux, you're familiar with YAML architecture. It's basically a way of doing unidirectional data flow where rather than having each individual component responsible for owning its own state, you have a single state atom, just one piece of explicit state. And to the extent that you want to slice that up into smaller pieces of state for different components, you do that by having each of them sort of be little helper functions, and they sort of communicate state changes back up to the parent, the single state atom. And none of them actually own their own individual local state.

It's just you have one big state atom, which if you think about it, is kind of the honest way to represent things. Like in reality, you do just have one big state. It's just, you know, by sprinkling ownership of that around, you're sort of hindering your own ability to sort of keep track of that. You can make it so that some piece of state is out there, it's part of your application state as a whole, but you've made it more difficult for your program to keep track of it because only one particular component is able to do anything with that.

So the idea of having the single state atom is sort of core to the elemental architecture, and some of the benefits that it gets you, in addition to just being a nicely organized Things and making it really explicit how the unidirectional data flow works is it gets you time travel. So you can actually have a time traveling debugger, which means that you basically bring it up, you run your program, and at some point you're like, oops, wait a minute, I just realized that I wanted to change something. You just hit pause and you scroll back through time, you just rewind time and you make a change to your code and then it hot swaps in. It hot swaps in, your code changes and then you hit play and it's going to replay all of those user interactions on the new code.

So you can actually see a demo this on the ELM website. You search for like Elmario Time Traveling Debugger. There's a little Mario game that you sort of make with like a little in browser helm editor. And it said you make it really just there, you just modify it and basically you just walk around with Mario, like walk left, walk right, jump, and so forth.

And then hit pause, scroll back through time and just watch Mario do all that stuff you just did in reverse. Then you can go in and do something like change the gravity, like change the code so the gravity constant's different and just hit replay. Just watch all that stuff get replayed and all your previous user actions. And currently the current version of the svelte ELM Reactor is the Time Traveling Debugger.

And currently it doesn't support this yet. But I know the guy's working on it and is planned for the next release of it. But one of the really cool ideas and one of the big things I'm excited about with the next release is the ability to hook this into your QA process. So the dream is we have our QA guy trying out some new version of no Red Ink, some new feature that we've developed, and he finds a bug.

And not only can he hit pause and stop right where he found the bug, but now he can actually export the data of all the user interactions that he did to get to that bug and then he can just send that to the developer responsible for fixing the bug. And now you've got not only instant reproduction, you just load it into the ELM reactor and then just hit play. And it's just going to do literally all the stuff that he did to reproduce the bug. So it's guaranteed to reproduce it.

But once you fix the bug, depending on what the fix was, you can scroll back through time and replay it again and confirm that it's no longer reproducible. And of course Then the super duper dream is to put it into an integration test and verify that it doesn't happen anymore. But that is all possible because of the ELM architecture, because it's, you know, everything is modeled around this single state atom. So, you know, all you have to do is say, yeah, just keep tracking that state change, you know, as it changes from one state to the next, and just write all those changes down and it will just replay all those changes and that's it.

And you have instead you have like local components, states sprinkled around. If you want to get that same experience, what you have to do is you have to hook into every single one of those independently and pull them all together and then serialize them into one. Basically. Essentially build up your single state atom on the fly every time and then serialize that.

And then when you're replaying it, pull those back apart and then send it back down all the components. And in a lot of cases you can't even do that because you don't have the ability to, you know, set the components level. Say only the component itself does. And at that point you're out of luck.

So I realized I just said a lot about it without actually describing what the actual architecture looks like. But I guess that's on the website if you want to learn more about it. You can also go back to episode. Oh goodness, I should pull it up.

I think it was 188 with Dan Abram who we go into deep details on how Redux works. And so if you listen to that, or if you like to listen to that, you'll get some background on. In fact, he basically says that he, you know, he yanked it over from Elm. From Elm to JavaScript was pretty much his move.

He pretty much, you know, come on to that plainly. 8. That's not the show, it's why. Thank you, Adam.

Thank you for that. So, yeah, lots of architecture stuff there. What about what does it look like to use? What is it?

Let's just imagine somebody who's used to writing HTML CSS or working with those technologies. Maybe not even so much of JavaScript beyond a little bit of jquery to like, you know, instantiate a calendar or something like that. What does it feel or what's your day to day? Like, how do you write an L marketacted thing?

We talked in just the architecture or architecture plus language or we don't describe the syntax necessarily. But for instance, do you write plain HTML and CSS or do you use ELM things to generate that? How does that work. So it's a lot closer to React.

So basically, rather than writing static HTML or server side generated HTML, instead what you do is elmhtl uses the same virtual DOM idea that React has, where you have a view function that takes in arguments based on the current application state, and then it returns this description of what you want the DOM to look like. So in React, you have JSX doing that, and elm, you just have a little dsl. It's not actually a separate template language, it's just using sort of ELM constructs. So instead of having angle brackets around the word div, you just have a function called diversity.

And in elm you can call functions. In fact, you only call functions, I guess, without parentheses around the argument. So it's just like div space. And then you go from there and then you sort of nest different elements inside them.

And that's all just done with more function calls. So to give you an idea of actually how familiar this can be, our designer Stacey, she never learned elm. Nobody ever actually talked to her, but she knew HTML and css and she's in the habit of just going in and making commits when she wants to change something rather than going and asking somebody on the front end team to do it. And she just went in to modify her ELM code.

You know, she's just like, oh, yeah, I want to change this. And she looks like, okay, div, div, you know, class id, whatever, and just went in and made a change. So if you have an understanding of how these things are structured in a large case, obviously there's a little bit more difference than just going from angle brackets to, you know, no angle brackets. But it's actually kind of surprisingly familiar.

I think if you look at the page of EL code, you'd be like, okay, I see. I see what this is doing. I was gonna say I'm looking at some of the code too. I can probably.

What's name again here? Designer's name. Stacy. Stacey.

I can lament to what Stacey on that because, like, if you jump in, just looking under the list, for example, you can see a white space awareness. It seems that's the case. So correct me if I'm wrong. And it just seems that there's this natural nesting very similar to.

It almost reminds me of like writing the original SAS code, not SCSS code, where you have this nesting. And it's obvious that there's some sort of hierarchy here. And it's very clear. It doesn't look like HTML, but it's not.

But the tree and the Parents and the, you know, the siblings of the whole ancestry model seems to be clearly represented by, you know, when you write it. Yeah, those are actually. They're lists, like they're comma separated with angle brackets. It's just like, you know, JavaScript with arrays.

But so instead of significant by space. But is it by space significance or is it. I mean, is it checking for that? Like, not in general.

There's like one or two cases where it is, but it's not like CoffeeScript where you have, you know, like if. And then indenting means something simply. It's just for cosmetics. Yeah, pretty much gotcha.

Since we're kind of talking about, you know, some of the angles where if you only know HTML, you only know CSS and you can easily step into. And as I did, I went to your docs with learn by example. Check out our list as you're speaking. And aside from the imports and stuff that are ahead in the file, it seems pretty clear to me if I step in.

And for example, Richard, if you are collaborating on a project and you say, hey, I'm go edit this content, I can pretty much get in there, it seems, just by looking at some of the code and doing it pretty well. What other things are just like natural easiness things that Evan's built into this that makes it easy for those who already know HTML CSS to step in and kind of fill ownership or some productivity? I think that's, I mean, that's probably the biggest one is just the way that the MHTL DSL is designed to mimic the actual DOM as much as possible one to one. You mentioned import statements.

So those work pretty much the same way as require, except that there's an additional feature where you can import things into the current namespace so you don't have to use them with a dot. So if you import, let's say you make a library called calendar. Let's just say import calendar. And one way you can use things that you've imported is sort of the same way you use them with requirejs or esxmos or something like that.

You say Calendar, you know, getcurrentday. But in L there's also additional exposing keywords. You can say import calendar, exposing getcurrentday. And now you can use that without the dot.

It's just sort of imported into the current namespace. And you can, you can do that not only by explicitly stating which things you want to import into the current namespace, you can also say exposing, which means just bring everything in which is exactly how you can get that nice HTML TSL with you know, just saying div and class and id. Like I said, there's all those functions but you don't have to say HTML divhtl class, HTML id. Instead you just say import HTML exposing dot.

You just get them all. So it's pretty nice for building DSLs, but yeah, I mean as far as how it works, it's pretty similar to ES6 modules or requirejs. So there's some similarities there. Calling functions is not quite the same as it would be in JavaScript because you don't have the parentheses after the function name.

But again it's just like function name argument, argument, argument. So that can look pretty similar as well. Talked about like infix operators. So comparing to closure where you have parentheses plus XY instead of now it's just X plus Y, things like that.

So JavaScript, I mean it's getting stuff more now but like ES5 missing some like major core features of programming language I think like enumeration type of things, collectibles and looping and different constructs. Like does ELM fill all that in with all the mapping and reducing and all these things that we possibly want? Is the batteries included or are you pulling in libraries to do things like that? Definitely batteries included from the functional programming perspective, obviously there's a very rich third party library ecosystem for other stuff.

But yeah, I mean for like MapReduce, I mean all that kind of stuff, there's a. There's a very rich core library that just ships it down that. Yeah, you just go. The package manager is pretty interesting.

It's a package.l-lang.org and you can browse through the core libraries and all the other community libraries in there too. I guess that's one of my other favorite things about ELM is that. So it doesn't use NPM or bower. It has its own package repo.

And the reason for that is that it's. I'm. I think it's pretty safe to say it's the best package repo in the world, I think. I think that's a pretty safe claim.

I'd say it's the best designed. I mean I guess it's not as. It's not as, you know, large, doesn't have as much stuff in it. It sounds a relatively new language.

But let me know if you've heard of this anywhere else because I certainly have it. So if I go and I make a change. So Nordic publishes a library called Elm Rails and it's just so we use Rails and use ELM Rails. And so we made some helper functions that sort of introduce some Rails conventions into ELM and just does some stuff for you.

And so if I make a breaking API change to that, like I change a public signature and like I make this function, it used to take two strings and an int, and now it just takes a string and an int. If I make that change and I changed it from version, I say, okay, now that we're changing this from version 1.1 to version 1.2, and I go to publish that to the on package repo, it will reject that. It'll say, you did not follow semantic versioning. You tried, you made a breaking change.

You need to bump the major version number. So it actually enforces semantic versioning. It's back then. Yeah, exactly.

And that's true of all the packages in the entire repo. So when you're debating like, do I want to upgrade this? First of all, you can actually rely on the semantic versioning. The second of all is a command you can run called elmpkagediff and you just give it two version numbers in a package and it'll show you an actual diff of what changed.

Like, it'll say this function used to be this in the first version you gave me, and now it's this. Here's, here's what it takes. It takes these things differently. And so when you're deciding whether or not you want to upgrade something, you can just find out very quickly exactly what changed and whether or not that's going to be a safe upgrade.

I mean, obviously any, you know, change of package, maybe introduce bugs and things like that unintentionally, but actually having packages that are reliable is, on that level is, as far as I know, totally unprecedented. I don't know any other language that has that. And it's just like whenever I use stuff from hello other things, it also automatically publishes documentation and it actually requires documentation. So you can't publish something to the ELM package manager, the ELM package repo, unless you've actually added documentation to every single public function that you export.

Now, granted, you can get around to that, you know, if you're, if you're really sure, you can put in empty doc strings for things, but it actually will, it will let you forget, right? So you can do a bad job if you're really determined to, but if you try to publish, it'll say, hey, you forgot a doc string here. You know, you need to put that in before you can publish this. And so as A result when you look in helm packages and you bring up somebody else's library, it's like, yeah, there's documentation for everything there.

Unless the author, you know, really went out of their way not to include it. It's really nice. That does sound pretty awesome. Not gonna lie, it sounds pretty nice.

Yeah. I hope I don't have to give it up. Like I said, I mean, it's, it's so far removed from the experience I've had in JavaScript where not only do things, you know, break all the time. I mean, semantic versioning is just, you know, sort of cross your fingers.

I hope they follow it, but. But also just, I mean, because the standard for contributing something is so low, it's so easy to publish something. Very often I'll be like, man, I want to do this thing. There's like five different versions on NPM and they're all in various different states of disarray.

Generally speaking, with ELM package, it's, it's like there's, there's like one and it's good. Nice. Maybe you can help clarify this, but when I go to the URL for which we'll put the shows, by the way, which is too long to name here, but it's in the L package manager, when I go to the ELM Rails package in there, it seems to me a little sparse since I'm kind of confused about what you just said as far as in what sense. Well, I'm at the 3.0.0 and all that I see there is your logo.

Ah, yeah. So on the right you see where it says module docs, rails and rails.de code try clicking on one of those. So those are different modules in there. What you're looking at was the main page and we didn't, we didn't put out the design part.

You, you apologize about. Yeah. So wait. Right.

So basically what you're looking at is the readme. And we didn't, we didn't really do much. Yeah. But if you look at the individual things, like if you look at.

Get, post, send. I mean, all of those have. Yeah, I'm seeing now this is a lot more clear on what each of these, each of these do. Yeah, they got, you know, code examples and exactly what the types are and all that stuff.

Yeah, that's the part we care about. Right. Is when you're actually looking at what these things do. We probably should have just put up.

Aramia said, hey, these are convenience functions for working with Rails. But yeah, the documentation part that we're proud of is the individual functions all the other semver. I think that's an interesting take to require it, so to speak, on the pack image level. Because if you're in a world where you can't trust semver, which I think is kind of what we all live in anyways, it's like how deep into sunversion do you subscribe, for example?

And to have the package require it to me seems like a really big win because it's a level of trust that you explicitly place to everything in it. And so everyone has to subscribe to the same idea. Yeah, I mean one of the really nice things about that being enforced is also just that everyone follows the same convention and everyone's held the same standard. You know, sometimes in NPM you have some people using three two dots, some people using three dots, some people using one dot, and they all mean different things to different people.

So in a lot of cases you're just kind of like, well, hopefully the latest version is good, but you don't really know. You don't really know what you're getting yourself into, so to speak, without, you know, sort of intimately knowing the package. But now it's just very clear. It's like, yeah, breaking changes mean you increment the major version number.

If you have new features, it's minor and then everything else is patch. That's it. I like this battery is included approach if you guys read it or not. Eric Lemons recently had a blog post called JavaScript fatigue, or on JavaScript fatigue, which seems to strike a chord with how many people are feeling, I think quizzes specifically to the React community, where React is just the V layer of much bigger application, hence things like Redux and the Flux architecture and Relay and these other things.

Pick a package manager, pick this, pick that, and it gets to be a little bit just overwhelming and fatiguing having those situations. So having a solution with ELM where it's a language, it's a package manager, it's an architecture, it sounds like it's a way of life. Yeah, I mean even like unit testing libraries, you get like, you know, to use Jasmine, to use Mocha, to use Node Unit, there's all these different alternatives to, you know, that's it. And that's what everybody uses to write their unit tests.

Is that, is that a top down thing or is it perhaps an indication of the life cycle where it's a young language of the ELM ecosystem? So of course there's only one ELM Rails package because there's just not that many people using it and if it blows up, it'll be 16 elm rails. And of course I'm asking the kind of congestion here, but what do you think on that? Well, I think an important thing to notice is that there's a strong community value about having one nice thing and sort of, I think in large part that's due to a lot of people being familiar with, you know, the problems that JavaScript is seen.

I also think that there's an important difference in that. I think part of the reason that we've seen such an explosion in JavaScript has to do with sort of all of the, sort of the nature of the JavaScript ecosystem where it's, you know, there's not a lot of leadership, there's not a lot of direction, you know, centralized. Like if you compare NPM to like RubyGems for example, you don't see the same. I mean Ruby's also a very big language, very mature language, certainly a very large library ecosystem, but you don't see nearly the level of duplication effort with, you know, several different varieties for every single thing that you do in npm.

And I think the reason for that is not so much the age of the language, but rather the culture around things where Ruby has a lot clearer set of standards for what makes a nice library at a language level. It's also got sort of fewer nice ways to do things. In JavaScript you've got several different ways you can do any particular thing. Just, just off the top of my head, are you going to base your API around synchronous callbacks or promises?

Depending on what point in time you ask somebody, they might have got a totally different answer. Whereas in Ruby, you know, there's no equivalent question. It's always been the same, you know, answer for years and years. And I think you see the same thing in ELM where it's kind of like, OK, here's the standard.

This is how to make nice APIs and if someone's going to make a new library, they're going to adhere to that standard. And so somebody else is not going to feel nearly as inclined to come along and say, well, I'm going to make this, but it's going to be promise based, you know, because there's no equivalent to that in elm. There's only one thing, it's not called promise, it's called tasks. But actually everything in ELM is task based.

All effects are task based. So actually in JavaScript you have, you can do synchronous effects, you can do callback based effects, or you can do promise based effects in elm there's only one way. It's all tasks and they all are composable like promises. Basically it has sort of like the best of all worlds and every single effect API uses them.

So you don't really have the incentive to fragment like that. The other thing I've heard too about, and this is not throwing stones just to state some facts I guess based on opinions to a degree, but they're facts is just this idea that it's the rigidness I guess which is there in the M package manager that isn't there with NPM is that. But also the way NPM sort of spawned this idea of being very Linux like very small components, very small modules that you know, build upon bigger modules and you know, kind of thing, but being able to easily publish something without documentation, without, you know, any sort of longevity promised. It seems like the things that are in place that you like about the L package manager aren't there in npm and maybe that's where the discourses happen there.

Yeah, that's probably part of it too. I mean one of the interesting side effects of having it enforced semantic version is that the first time you publish something to the ELM package it's version 1.0 and that's it. There's no, you know, nothing comes before that. Every package in there is at least 1.0 and you know that once you publish it you're starting with 1.0 and every time you publish a breaking change it's going to be a major version bump.

So there's definitely a higher activation energy required to get on there. So I've been working on this project ELM CSS for a while now and I still haven't published it yet because I know it's not ready and I'm not ready to say this is 1.0 yet. I don't want that out there, you know, being claimed that this is 1.0. It's just like, yes, it's not ready yet.

And it's actually I've already published it up to version 3.01 npm, even though it's not ready yet. Because I'm like, yeah, you know, that's no downside, might as well. And that's kind of an interesting field cultural preference, I guess I just kind of feel like I might as well put it out there on npm. Why not?

And I gotta wait till this is good before I publish it there. Yeah, you know, one more note before the break on just a response back to that. I think that's some of the beauty of npm. So that's what does worry me a bit about the rigidness is that I think that that lack of structure has been embraced by the community.

It's also why MPM blown up to the degree it has and kind of maybe even why Jared has said that's tall words of you saying that you would venture to say that the unpacked major is the best is that that lack of, that lack of requirement has led to the same explosion that happened when GitHub came around. I was like, this is your permission to mess up. Git. Being branching, you know, focusing on, you know, all these different things that we love about git sort of allow the developers of the world to say, okay, it's okay if I mess up and because some will fork it or some will change it and you know, somewhere down this path it will, it will get made right, I guess to a degree.

So kind of no to me that's the role that GitHub plays. I don't think we need to package, you know, I think exactly, I think like, you know, and LCS is a good example of that. Anybody, you know, it's all up on GitHub. If anybody wants to try out this, you know, pre 1.0 version, it's right there.

GitHub, they can totally do that right now. And in fact, my coworker actually already is doing that for internal projects and he's having to, you know, deal with all my briefing changes every time I change something on it. Well, then you have people saying that, you know, GitHub isn't a package manager, for example, but I guess pre 1.0 are pre, you know, in the words that you have on your BME is that it's not production ready, you know, so you have that clear disclaimer. There are some that you don't subscribe to GitHub being the package manager, but before it's ready for the package manager itself, it's kind of sitting on GitHub repo or git rep on GitHub.

Yeah. And that division makes a lot of sense to me to say, I agree, GitHub as a package manager, but sometimes you want to try something out that really doesn't belong in a package manager. And if it went out, you know, to a package manager, it would, you know, mainly serve to confuse people and you'd have, you know, people showing up saying, I used this thing and it didn't work, what's going on? Or I use this thing.