Show notes
Aaron VonderHaar shares the origin, history and plans for the future of elm-format and a new, related tool! Thank you to our sponsor, Culture Amp. Special thanks to Xavier Ho (@Xavier_Ho) for editing and production of this episode! Recording date: 19 Mar 2020 Guest Aaron VonderHaar (@avh4) Show Notes 00:00:00 Intro and sponsors Using Elm in Production at Pivotal Tracker (article) Elm San Francisco (meetup) elm-format 00:04:22 How Aaron got into Elm "Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki (video) 00:06:09 The origins of elm-format “A Farewell to FRP” by Evan Czaplicki (article) go fmt your code (article) Prettier 00:12:15 Avoid configuration options 00:15:53 elm-format's evolution Issue #209: Should single-line if expressions be allowed? 00:17:50 elm-format's parser parsec: Monadic parser combinators 00:20:33 Auto-correct syntax errors 00:21:55 Learn Elm with elm-format 00:23:41 Major “internals” projects 00:25:30 elm-refactor coming soon Migrating to elm/http 2.0 Html.Attributes.style 00:32:03 The Elm version flag 00:35:06 Controversial formatting 00:41:08 Where changes in elm-format come from 5 core principles issues on GitHub 00:47:05 Still beta issues by milestone on GitHub 00:49:00 Inclusion in Elm core elm-test 00:51:12 elm-refactor coming soon (continued) 00:52:50 Teaser: elm-program-test elm-program-test 00:53:54 Sign-off and Outro Transcript [00:00:00] Kevin Yank: hello, and welcome back to Elm town. It's your old friend Kevin, and I'm here today with Aaron VonderHarr. Hi, Aaron. [00:00:07] Aaron VonderHaar: Hi Kevin, how's it going? [00:00:09] Kevin Yank: Very good. Good to have you with us. Aaron is, if you don't know the name, the author of elm-format and, I think, a lot of listeners will be perking up at that because I have yet to meet someone who doesn't love elm-format. After using Elm for a little while. [00:00:27] So I think we'll have a lot to talk about today. Before we get into that though, as usual, I want to acknowledge our sponsors, Culture Amp. They pay my bills and they are letting me record this in the middle of a work day. So thank you, Culture amp. You've probably heard of all of this by now listeners, but as you may already know, we make a web application that businesses all over the world [00:00:50] we're talking 2,500 plus companies now around the world, use our web application to collect feedback from their employees, [00:01:00] to run their performance reviews and to mush the data that comes out of those things together in order to understand their people, their culture, how people are feeling about work and, and how to improve their workplace. [00:01:13] that's a mission I am very excited to be writing software for. And if you would like to write Elm in production on that kind of web app, you should reach out kevin@cultureamp.com is my direct address. Or you can visit cultureamp.com/jobs in order to see what roles we have open at any given time. [00:01:32] And also thank you to Xavier Ho, our producer who makes us sound great by cutting out all of the mistakes and trimming the boring bits from these episodes, so you get the very best Elm Town that we can make, dear listener. [00:01:47] Aaron, welcome to the show! [00:01:49] Aaron VonderHaar: Thanks for having me. [00:01:51] Kevin Yank: for those who might not be familiar with you or might not have heard your story before, tell us about yourself and what led you to Elm. [00:02:00] Aaron VonderHaar: Sure. well, let's see. When I first was getting into programming, I really took an interest and kind of had some mentors that got me interested in user experience and kind of that aspect of development, but web development was kind of the big thing when I was getting out of college. [00:02:17] And, I did a fair amount of that. I did a lot of mobile app development after the iPhone came out and, did some, a lot of big work for some Android projects. [00:02:27] Kevin Yank: Are we talking about native apps for those platforms or still on the web? [00:02:31] Aaron VonderHaar: Yep. Native apps. Actually, I did one project for this Android phone. I was actually in charge of the team that was re-skinning and developing new core apps that were going to be shipped with the phone itself from the manufacturer. I've done a lot of Android and iOS stuff. But yeah, I eventually ended up doing some consulting work at Pivotal Labs and started doing more web development there and I guess got interested in Elm… [00:02:57] …kind of on the side. I started going to the meetups in San Francisco, got to know Evan and Richard Feldman… [00:03:03] and got more and more interested in it. And eventually when I started looking around for a new job, NoRedInk was looking for people to do more Elms. So I ended up working on Elm almost full time, at NoRedInk, after that. [00:03:17] Kevin Yank: Pivotal Labs was one of those names that, when Culture Amp was first looking at Elm and you know, you do the thing of, well, who else is using it? And NoRedInk was obviously on the list, but, Pivotal was one of the early big names, I would say that, you know, they were on the Elm website… [00:03:35] …there were one or two people from Pivotal who had given talks about stuff, that they were doing there or had open sourced projects. Were you exposed to Elm at pivotal at all? [00:03:47] Aaron VonderHaar: I think I was the one that did a bit of the exposing. I'm trying to think back. We did a project, I think for Twitch where we used a bit of Elm, and I had actually brought Richard in to do a lunch talk for a few people who were interested in it. [00:04:00] I think the next thing when they started using it for was the front end for the Concourse CIS system. [00:04:06] And later, I think, I believe it's now used in Pivotal Tracker itself. But yeah, I definitely heard about it outside of Pivotal and started talking about it with a few people there. We had like a functional programming club where we would talk about Haskell and then other functional programming languages like Elm. [00:04:22] Kevin Yank: So tell me about how you got into that FP stuff, cause I do find there are two kinds of Elm people. There are the people who got into FP first. And then Elm was a cool way to, to stretch their FP muscles. And then there were the people who got into Elm first and then realized they had to learn some FP in order to use it effectively. [00:04:41] Aaron VonderHaar: Yeah, well, I would say Java was my language of choice before Elm. I guess largely because a lot of the great, IDE integrations and tooling and automated refactoring stuff that you can do with Java. So I'd say I was aware of functional programming, but had never really used it much, professionally, other than playing around with it. [00:05:03] And, kind of following. Or just reading interesting articles. Actually, the talk that I mentioned however long ago, at Strange Loop that Evan gave was kind of about the nature of functional reactive programming that was back around like Elm 0.15 or something like that. [00:05:20] Over the years and hadn't really found anything that was good for like a work environment until Elm came along. But yeah, I was definitely in the, object oriented worlds, not the functional world until Elm, and didn't really know any Haskell until after I started working on elm-format. [00:05:41] Kevin Yank: Right. Okay. So the, the FP club came later. [00:05:45] Aaron VonderHaar: We didn't really have any advanced functional programming practitioners. There were actually some guys from Walmart Labs who were working out of Pivotal's office for a while and they used Haskell. So they would occasionally stop by and, and, give us some pointers on how to learn Haskell. [00:06:01] But that was kind of more just an educational thing. Nothing that we ever really brought into our work for any of the Pivotal clients that I worked with. [00:06:09] Kevin Yank: how long were you working in Elm before elm-format started to be an itch you wanted to scratch. [00:06:16] Aaron VonderHaar: Yeah, that's a while ago. Let me try to remember here. I definitely started going to the meetups, kind of more heavily than having any big project in Elm when I was first playing around with it. So I was interested in kind of more just toy experiments rather than building any particular side project in Elm. [00:06:38] I think I probably was going to the meetups for maybe six or eight months, maybe even a bit longer before I wanted to start doing something bigger. I guess my motivation for choosing elm-format as a project was that I was really interested in editor tooling, like I mentioned, as something in Java that appealed to me. [00:07:01] And I thought Elm format would be a good opportunity to get familiar with how the Elm parser worked and how the compiler worked, without really having to commit to like maintaining the compiler itself. But I could learn something about the parsing, and have a useful product that other people could use as a side effect. [00:07:20] Kevin Yank: Right, right. I'm less interested in the specific timelines, but it's more what you're getting at there is that not everyone's first reaction when picking up a new language is how can I make the tooling better? [00:07:33] Especially for something like Elm where the compiler and the tooling around it was already considered at least at the time, to be quite cutting edge… [00:07:43] …and quite a highlight for it. most people would go, okay, I've got this new language. It's a toy. I want to play with it. Let's start building things. It sounds like you very quickly kind of gravitated towards a sort of meta project where you would get to learn about the thing by helping to build the tools for it. [00:08:00] Aaron VonderHaar: So one of the things that attracted me to Elm in the first place was similar principles, like the idea of the usability of tools that developers use in their daily work. Especially coming to the meetups where I got to talk to Evan a lot, back in those days [00:08:17] one of his core interests, especially at the time, was really looking at the experience of people trying to use the language and almost like doing user interviews with them, seeing what they struggled with and trying to solve problems. I'm a big example of that was when Elm went from using signals back in 0.15 or 0.16 to the current Elm architecture, which everybody knows now. [00:08:43] The big project of Evan’s to understand, like, what was it that was confusing about signals and made it hard to understand and how could that be solved potentially in a, in a drastically different way, which turned out to be the case there, but make it a lot easier for people to understand, especially for web developers to understand. [00:09:02] And it's that focus on usability that really attracted me to Elm, and also Elm being a relatively simple and straightforward language. And like the compiler is relatively easy to understand compared to like the JavaScript VM or Ruby, or even Python or something like that. I think that aspect of relatively simple tools for the power they're giving you, and also the usability and the experience of using those developer tools. [00:09:30] it's kind of been like a common thread for me. [00:09:33] Kevin Yank: is it a part of it that Elm is a simple enough language that contemplating writing your own parser for it, it felt within reach in a way that it didn't usually for other languages? [00:09:44] Aaron VonderHaar: Yeah, I think that's definitely the case. And having used the language as well, the syntax of Elm is relatively straightforward. Like there's a lot fewer weird edge cases, and weird syntax in it, as a language. So, yeah, I think that was part of it. [00:10:00] Kevin Yank: So did you go straight to the idea of an auto formatter? was that like immediately a need that you perceived and it was the inspiring idea that you were pursuing from the beginning or did you go through several iterations of interests before you landed on elm-format? [00:10:16] Aaron VonderHaar: That's a good question. My memory from then is kind of fuzzy, but Evan and Richard and I were talking fairly often and were having a few lunches, and I can't remember, it might even have been Evan or even Richard who thought that it was a good thing to have in the Elm ecosystem. And one of them had written up a Google Doc kind of listing the rough idea of what it might do. [00:10:42] gofmt was around at the time. So the idea was kind of based on that, that it would be basically no configuration, and kind of one way to do things. At some point, yeah. I think that the idea just appealed to me. I was kind of looking for a bigger project to do and I jumped on it and started flushing it out, started building it, started working on it in my spare time, and went from there. [00:11:05] Kevin Yank: I'm not familiar with gofmt. I would say apart from elm-format, the big auto formatter that I'm aware of that most people will have now heard of is Prettier. And at least as I experienced it, Prettier came after elm-format. But can you talk about what was inspiring about the prior art of gofmt? [00:11:22] Aaron VonderHaar: Yeah. First of all that it was a blessed tool of the official Go tools, and I haven't actually followed it that much in the recent years. So I don't know what has changed since then, but the appealing aspects were that it was an official tool supported by the core Go organization, or I don't know how they're organized, also that it didn't have configuration options. [00:11:48] So there was no customization between projects. And part of that was because it was an official tool. Basically every published Go package, I believe, was, supposed to have their code Go formatted so that any Go code do you looked at, would follow the same conventions. So that was an aspect of it. And the other aspect of it was trying to do the right thing without [00:12:15] getting in people's way. So that's a big thing I've tried to do in elm-format is not have configuration options, but also as much as possible, make everything you type format in a reasonable way without having tons of different choices for you as the person typing the code. [00:12:33] Kevin Yank: What's an example of a choice? [00:12:34] Aaron VonderHaar: One thing that elm-format is restrictive in is if you have a function call and you have the name of the function and then you have a bunch of arguments, each are separated by white space, there's a choice in those white spaces of where do you put line breaks? Do you put a line break between every item between some of the items? [00:12:53] Do you try to group certain items with line breaks? So elm-format is extremely restrictive. In that there's now three options. You can either have all the arguments on the same line as the function call. Or you can have the function name and the first argument on the same line, and then everything else is on separate lines. [00:13:13] Or you can have all the arguments on separate lines. So those are the only three options. So there's no choice to, for instance, like have the first argument on a separate line, then have the second, third, and fourth arguments on a line together, and then the fifth argument on a line. So that's an example of [00:13:30] a choice, like it's restrictive and that you can't control how it formats in some sense, but it also removes the choice, so as you're typing code you over time, learn to not even think about it, not spend time thinking on it. You just type it out, let it get formatted and move on. [00:13:47] Kevin Yank: if you are imagining more flexibility there, apart from like leaving it in the a…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
