Web Platform Podcast about Elm
Guest: Richard Feldman
Welcome to the Web Platform Podcast, a developer discussion that dives deep into all things web. We discuss topics relevant in developing the modern web and the web platform of today, tomorrow and beyond.
All right, hello everyone and welcome to another edition of The Web Platform Podcast Episode 76, The Elm Programming Language. I am your host today, Justin Ribeiro, Danny and Eric are out. Today with me I have Richard. Richard, how’s it going today?
Please introduce yourself, tell us a little bit about yourself, how did you get wrangled in to the wonderful world of web and programming things?
I started out when I was 9 programming BASIC, so the way I got into the web was many years later, there was no web back then. I got into it basically because I wanted to start a company and the company was going to be around that idea that ran on the web and so I figured I’d have to learn it, so I did. Fell in love with it and have been building for the web ever since.
Wonderful, the web is a nice place to go. I actually started in BASIC as well when I was 7. My mom taught me how to make a waving flag. I always find it interesting when people start out and you work on the Elm programming language, so tell us a little bit about Elm.
Yeah so there are a few different options now. Like 5 years ago pretty much all you had was use the fact that CoffeeScript has everything being an expression to write more functions but that was about it. Now you got a couple different options so you have Elm, you have PureScript, you have ClojureScript and then there’s some others that are less popular. Those are the big three I would say and the thing from my perspective that makes Elm the, my preferred choice of the three is two things, one, is that it has type-in prints, so it’s had really great compiler that catches almost all of your errors up front.
We’ve been using it in production at work for 6 months and we have yet to see a single runtime exception from any of our Elm code. It’s like thousands and thousands of lines of code, not just undefined is not a function we haven’t seen any. That’s because the compiler is just really great at catching that stuff so that’s one part of it. The other part of it is just it’s simplicity, there’s just a lot less to learn with Elm than there are with some of the other functional alternatives out there.
Yeah, the only time I ever get no errors in my code is when no one’s actually using my code I feel like most of the time, so it’s always nice to see the compiler does a pretty good job.
We have millions of users answering millions of questions everyday so we’re about as far as you can get from nobody using it.
Yeah definitely. From my perspective the main thing is that it’s difficult to get the guarantees that you get from Elm that make it such a nice experience as far as maintaining code, re-factoring code and having no runtime exceptions. It’s difficult to get that, I think it’s actually impossible to get that by adding on to an existing language. Really what you have to have is you have to start from a language that doesn’t have certain things. The reason Elm’s able to do that is there is no null or undefined, the language is designed around not having that. Then you express the idea of the absence of a value in different ways that can be verified more easily.
Build working software, it’s great.
Feature wise, is there a feature in Elm that people just don’t know about? Is there that one killer feature that you say, if you knew Elm did this you might take a look, like what would that feature be for you?
The biggest one is definitely no runtime exceptions. Something that comes with that is just the re-factoring is really great. Usually when I re-factor something, even if it’s hundreds of lines of code changed, almost always the experience I have is after it compiles again it just works with no regressions, it’s really nice. We write fewer tests and still have better confidence in what we’re shipping because the compiler is really awesome.
Besides that, something that I don’t think people know about, I would say the first thing that comes to mind is Elm format. It’s relatively new, so this is the Go language has had this thing called Go format or Go Func, as they call it and essentially what it does, both of them do the same thing, which is they … you run it on your code and it just formats it, it makes it look pretty.
I use Sublime Text and the Sublime Text Elm plugin has an automatic, every time you save it runs Elm format on your code. It’s great because not only does it make your code look nice but it makes it look consistent across your whole team, so you can stop having debates over how many spaces of indentation to use and where to put new lines and things like that because it will just go through and it will just do that stuff for you, just make it look good.
Now I spend so much less time thinking about that stuff and I’ve actually started using it as a little Vim or Emax style code assistant where instead of pressing enter and then indenting, in a lot of cases I’ll just write some nasty code and the minimal amount possible, hit save and it will just make it look pretty for me.
Stream of conscious programming, that is way to go. That’s the beauty of formatters, right?
In terms of that though, how does Elm fit in today’s workflows? Say you do have an existing app and you want, you’re like, oh man, I’m really tired of this particular piece of that app and I’m going to start to bring Elm into my project, how does that, how has that worked in your experience?
The way I did it was basically just starting by building a small thing and introducing it into our project at work. Specifically what I did, we were on React and Flux and that’s what we’d been using for awhile and so I just rewrote one of our Flux stores in Elm. I actually wrote a blog post about this, it’s called, this is not in the show notes, I guess we could add it to the show notes but …
We will add it to the show notes, it will be so. [ Walkthrough: Introducing Elm to a JS Web App ]
Yeah, I think that’s a powerful story, a lot of times when you see people come into web development everyone has their flavor of what they like to do and a lot of times that requires like, oh you know what, I don’t like your product at all, I’m in charge now, we’re destroying all of it, it goes all away at once. Which is not really a feasible approach if you want to continue to have a job and or be in business for long, so.
It’s always interesting to me to see … because we’ve had other folks on the podcast that take similar approaches, where I have this one small thing, it doesn’t work quite the way I want maybe I rewrite it in this or we have this new implementation it’s fairly tiny, let’s introduce this. At a lot of places that’s hard, right? You end up with pitch forks and torches and please, I don’t want your ASP, version 1 from 1997 in my code base anymore, not to say that I’m writing ASP 1 code base anymore, I mean it happens from time to time. Someone says bring it up and it’s sad but the reality being is that it can be tough, right?
Have you seen a lot of Elm uptick in other businesses? Because I read through quite a few blog posts where people are taking similar approaches when they’re actually implementing Elm for the first time and then all the sudden it snowballs into a much larger thing to where it’s now running on Elm.
Yeah definitely and especially the past year I’ve seen a lot of that. I think the reason for that is that Elm’s been around for about 3 years but only in the past 2 years did it have a React like story where you could have a declarative virtual DOM style renderer and I think that really was the tipping point and now it’s become this language where you can write code for the DOM in the way that people like to and have great performance and yet also have really maintainable code.
It’s been amazing, it’s a bit amazing that it become the thing that it became … but yeah, it is, there is quite a bit of … to that, a lot of people, it’s easy to start a project right? We all, GreenField is a wonderful thing because you don’t necessarily, you’re not encumbered by designs of the past but the problem is that eventually Greenfield does become that past story and then maintenance becomes a big part of that.
I feel like fatigue is a very kind word for that syndrome. I didn’t mean to cut you off, continue.
I’m always curious to see what people’s learning process is around new languages because some … When I was coming up because I’m old and ancient these days, you didn’t really do that so much. You had one core thing that you did and that was the language that you knew. These days you really do have to have quite a few quivers or quite a few arrows in your quiver in the language of things. Not just for the web but for platforms in general.
Yeah, I agree with that, I think there are more and more polyglot programmers out there. I look back at the last decade or so of my career and I can think of, off the top of my head, at least a half dozen languages I’ve used. Several of them sometimes in one given job I’d be using 3 or 4 different languages. That seems to be the way of things now.
Versions are seriously rolling out now.
Yeah, so there’s a lot of documentation around the language itself, there are an increasing number of blog posts and things like that. There’s a great community called Elm-discuss, it’s a mailing list, a Google Group, there’s an Elm Slack channel, and yeah, the community’s just getting bigger and bigger. It feels like every couple weeks now I see somebody posting that they started a new Elm community in some new city. I think Chicago is about to have their first meetup. Seattle had theirs recently, Utah, there’s just like showing up all over the place, it’s pretty cool.
Is building language communities like this hard? Like I haven’t, I’ve never done it to be honest. I run community events and languages, you can get, there can be a lot of arguments around languages…
That grow out of what people have learned in the past, what is good per se, with air quotes around it. Have you found that to be fairly spontaneous, are these things popping up out of nowhere? It seems to me that once communities start to pop up that means that there are projects around that weren’t there before.
Yeah I think that’s exactly what it is. We have these online communities and I think generally what will happen is that someone will start picking up Elm in some particular city and they’ll start getting excited about it, they’ll start building things with it and then they’ll start talking about it to their friends.
I think I inadvertently seeded the St. Louis Elm community because I was at a wedding with a few of my friends and I was sitting at the table and of course we were discussing, what you are up to lately. I started saying well, I’ve gotten really into this language called Elm and she said oh, what’s Elm, let’s talk about it. This is Jessica Kerr, jessitron on Twitter. We were chatting and she started taking notes and then she went back and starting playing around with it and she’s like, this is really great. Now there’s a St. Louis Elm meetup, she’s coauthoring a book on Elm and it’s just like these things just snowballed, just from people finding out about it and trying it out and getting excited about it.
That’s a nice feature.
Yeah I was going to say, like the thing about edge cases.
Right, but being able to ignore them does let you get a prototype out faster, being able to say I’m not going to deal with this right now. In Elm you have to be more explicit and say this thing is here but I’m going to explicitly choose not to deal with it or hack around it or something like that. Elm makes it a lot harder to just ignore those things, which means it takes longer to get prototypes out.
Yeah, prototyping these days is, it makes me furl my brow sometimes when you look at the platform in general because there is this growing … the web platform is too complicated, I need to clone half of npm to make my project build or I need to … why can’t I just drop this in and things work? Is the web platform for even just any prototyping at this point getting too complicated or are we simply making it too complicated?
I think honestly I prefer to go … I like to have 2 extremes, I like to have my nice setup for production that maybe takes longer to get setup so I got Webpack, we’ve got Elm, we got all these modern conveniences. Then I’ve got my prototyping setup, which is just jQuery, like that’s it. I’m like this is something I’m going to hack together, I am knowing from day zero I’m going to throw this away, I’m going to throw it in the incinerator as soon as I get the design that I want.
I’m just hacking this together so that I can try it out with a user. Having those 2 extremes means that number one I don’t feel bad at all about writing horribly hacky, copy pasted code for my prototype. It’s a very simple, minimal setup, just include jQuery on the paste, throw a CD in and then go. I don’t even do a CSSP process or anything because again, I’m not going to maintain this. This is just for trying shit out. Then once I get the design I like then I throw it out and start writing with Webpack, Elm, SAS, stuff like that and it’s nice. It takes longer but it’s … and it’s something that’s totally maintainable.
Yeah and I want to stress the maintainability of it, because I think people … the kicker is sometimes our prototypes become the thing that we have to maintain. In that scenario you do have to be careful or at least with certain types of clientele that are like oh, looks good enough for me, I think we should use this right now.
Ignore the fact that it’s not wired to anything.
Except itself for the most part but the maintainability is huge these days. If you’re not thinking about maintainability you should be thinking about maintainability, please do if you’re out there and thinking to yourself I don’t need to worry about edge cases.
The thing about that is that if you don’t you end up having to worry about it after the fact, right? I mean 6 months from when you started, that’s when the chickens come home to roost whether you like it or not.
Yeah, exactly and then you’re up at 3 o’clock in the morning going I don’t … whose idea was this and then you’re looking at the commits going oh, that was my horrible idea. I made poor choices that day because every choice looks poor at 3:00 AM.
It definitely gets, takes some getting used to being like every single function I have is full of immutable stuff, not reassigning anything, I’m not making any side effects happen but then once I wire it all together then it turns into a running program that works.
I think that’s an important difference too, right? In terms of, it’s a very functional programming paradigm right? It’s functional program…
People often forget about side effects, like even when they’re writing other languages where they’re writing in a functional paradigm and then they’re going, I don’t understand why this is this way? It’s because you have a side effect in there. It’s … no, don’t do that. That’s the whole thing, right? It can be tough when the language doesn’t necessarily form to fit that paradigm.
Yeah and it’s interesting you see things like in React you’ll see it says, like hey, don’t do side effects in your render function. You can but please don’t because it might break things. In Redux you’ll see in the docs that it says when you’re writing your reducers, don’t use side effects here, you can but please don’t.
Whereas in Elm it’s actually basically enforced that you don’t. You never have side effects and if you’re wondering whether or not a particular function might do Ajax, all you have to do is look at what it returns. If it returns a task that, yeah, that task might do some Ajax but if it doesn’t return a task, if it just returns a string or if it just returns an integer or if it just returns some html, you know that that function is not doing anything to do with Ajax.
It’s not doing anything with local storage, it’s not doing any effects whatsoever because it’s just right there in the return type. It’s either a task or it’s not, so when you have your render functions in Elm you know that they don’t have side effects because they don’t return tasks when you look at your stores, the equivalent of your stores or your reducers in Elm, you know that they don’t return a task so you don’t have to worry about that.
Yeah and I think that’s a very powerful feature actually because I think that 50% of what [inaudible 00:35:13] these days is worrying about what’s going to happen when you’ve bundled in so many things together to try to do something that you do end up with something that is unexpected. That’s tough because then you go on the great trail of bug hunting that is, why did I do this, whose fault is this?
Is it our fault? The normal sorts of things and I think Elm plays very strongly to that. I like the idea of tasks and not having to worry about side effects because you’re inherently, your design to not write that sort of code that would frankly come back and bite you later. Again, that 3:00 AM phone call where you’re going man, I made horrible, horrible decisions last month. What was wrong? Did I fail to eat the candy bar of choice that day? What was wrong?
There’s only one way to do it an it’s the nice way, tasks composed together like promises do, you can do the equivalent of promise.all and batch them up and have them run and say I don’t care what order these run in, just tell me when they’re all done, stuff like that. You get all the benefits of promises but all the time, like every one uses it because that’s all there is. You don’t have to deal with this library used a promise and this one used a callback and this did it synchronously. That’s all, there’s just one, it’s just task, it’s just the nice thing.
One nice thing would be much better than 3 not so nice things, I think.
Yeah, I think again, that’s really nice.
It does, for the learning curve to learn about Elm, it does take out some of the learning curve of learning the 27 different ways to do things in other languages.
It’s a love hate relationship for all of us.
Yeah, it’s a love hate relationship for all of us, we… some days are better than others. All languages have these pratfalls and things that make us think twice and it’s nice when languages, and there are a lot of nice languages being designed now that deal with a lot of these problems both for the web and not for the web. What’s your worst thing, if one thing could be fixed in Elm, what would that one thing be? Because every language has got it, that just goes why, why is it this way and you shake your head and learn to deal with it and hope one day. What would that feature be for you?
In to that, a pre-compiled languages for the web, like general thoughts? Good thing, bad thing, why thing?
I could have swore there was a silver jumpsuit moment in our future. I did not get that memo. I was really hoping for one silver jumpsuit, this is what we’re doing in the programming community from now on, that’s it. I’m sorry I’m pretty sure I stole that from Jerry Seinfield, so.
You can write the code that you want to write so I don’t … maintainability wise again, I don’t … I think maintainability these days is really highly underrated because so many new things come out so quickly. It is nice to know that well, this language operates only in this targeted way, not in 27 variation ways, not because you had a minor revision bump.
The minor revision bump ladies and gentlemen is the most annoying thing, please for the love of Pete just properly version your code so that I don’t have to file tickets going please just, I’ll patch it, I will send you the pull request. Let’s all be nice with our versioning so that we all know what exactly is going on in the web or elsewhere.
To the point of this podcast, the web platform is the exciting thing to me. The web is the best app delivery platform the world has ever seen. You literally can’t do better than I type in the name of the thing I want to use and then I’m using it. There’s no download, there’s no installation, there’s no waiting for updates, it’s just you literally just tell the computer here’s what I want to use and the next step is you’re using it, the latest version of it, right?
It is magical and it’s funny because I started just before the web really took off in the mid 90s when we started having dial-up and whatnot and then the web comes in and the dot com boom hits and I remember working on IE4 just [crosstalk 00:45:25]
Netscape Communicator, back in the day.
Yeah those were the days, document.all ladies and gentlemen it was a thing and document.layers. People were like I don’t know what that is. I hope you never have to know what that is again on the web. Even in that environment where there were quite a few differences as the lay of the land was being set. The web continued to win, you’re right, it was this instant delivery of here is your stuff and you can use it and you’re up to date against this thing.
The thing about the DOM that’s really cool is just that it’s a very rich interactive system that has been adopted widely and that is still semantically useful. If you’re just rendering to pixels you can get a ton of bleeding edge performance but if you want to come write a plugin for that you’re out of luck.
I love that fact that I can bring up any web page that I use and I can mess with it, I can add, like the extensions that let me write CSS to mess around with the pages I’m looking at, can’t do that with a native app. I love the fact that I can just search for anything on the page. I’ve had so many native apps where I’m like command F, nope. Please command F right, but on the web it just works and so just having this universal specification for here’s how to make a content rich page.
Yeah, there are lots of drawbacks of the DOM too but fundamentally having a semantic description of your UI is something that we’ve never had in programming before and it’s by far the most successful implementation of that and it’s just definitely an undervalued aspect of web development.
Yeah, I think the debate will always rage on because otherwise what would we have to talk about? On various shows and what not.
Don’t get me wrong, I have plenty of criticisms of API but as a construct it’s a very useful one.
I think it’s always interesting because you start look through the API and a lot of the listeners obviously are building for the web these days and some are new to it, some have been doing it for a long time and I like the community. It’s okay to argue about how APIs work, maybe not on mailing lists because mailing lists are horrible but in other, mailing lists can be troublesome to follow what the chain of logic was. Half the time I don’t know what the original question was on most of the mailing lists these days.
You look at TC39 and everything, the other sorts of bodies and corporations and people who are putting a massive amount of work to bring the web platform up to date. Everybody knows I’m a huge fan of ServiceWorker, I know you mentioned App Cash at the beginning and I cringe because I’m like well we could just talk about App Cash and how much it’s horrible. I don’t think that was the point of today’s episode. It’d be another episode, App Cash the black box that continues to ruin your 2:00 AM, so you could … there is quite a bit of hope even with those sorts of bugs and things that exist today, so it is good times.
We’ve talked about a lot of stuff, Richard. What is the thing that I forgot to ask that Eric or Danny would have asked because I forget a lot of things? What is the thing I missed that I should have asked you that we should have talked about Elm?
One of the things that people ask is that a lot of new languages crop up and then they don’t end up with long term support. You get a language creator wonders off and does something else, you get the maintainers stop having time for it and things like that. One of these questions is that, is Elm going to be around in 3 to 5 years? Previously, Evan Czaplicki is the creator of Elm and previously he’d been working at Prezi and they were paying him basically to develop the language.
Actually just last week we announced, so my company, I work for NoRedInk and we make grammar writing software for English teachers and we’re hiring by the way. We just announced last week that we hired Evan and so now we believe that we are the company making the strongest Elm investment in the world now because it’s been unbelievably great for us and it’s also been a big deal for hiring because people want to just come work here because they get to work in Elm.
We’re like, yeah, you know what, it’s time for us to give back to the open source community in a very direct financial way because we benefited a lot from it and it’s helped make us a financially successfully company so why don’t we use some of that financial success to give back. That should at least a lay some of people’s concerns about what’s the future of Elm. The future of Elm is very bright and has explicit financial support in addition to a large community effort, so.
That’s key, yeah, it can be hard to get behind something when you don’t see that growth. I would say that Elm has shown a great deal of growth, even outside of the commercial aspect of it where people are actually supporting that language and whatever else. That’s a testament to how good it is to write in I think.
I haven’t written much in it, I just started playing with it but I love a new language, so. Got to write some things, just to see and see how it fits into the equation of daily work.
I think that’s fantastic. Wonderful, well we’re running up against time at the moment. Richard, how do people find you on the internet, if they want to bug you about Elm or just random web platform things?
Probably the easiest way is Twitter, @rtfeldman, that will be in the show notes and I’m happy to chat about Elm, not anything else, Star Wars.
I’m going to have to convince Eric and Danny that we need a Star Wars themed episode because there was the polymer of Star Wars bit too this year and I’m sure there’s a whole bunch of web apps that are being built around the Star Wars concept, if anybody hadn’t heard Star Wars came out in December. Just in case you’ve not been on earth…
Highest grossing movie, if you want to look it up, have somebody to look it up.
Yeah, it’s been great having you on the show, Richard. Thank you so very much for taking the time to be with us today.
Yeah thanks for having me, this is fun.
Ladies and gentlemen that has been Episode 76, The Elm Programming Language. I’m your host Justin Ribeiro and this has been The Web Platform Podcast. Thank you very much for listening.