Podcast appearances and mentions of Richard Feldman

Elm pioneer Richard Feldman returns to explain why he made Roc, a direct descendant of Elm. He notes a distinct trade-off of choosing not to have persistent data structures. Later, he shares how his experience teaching Elm informed Roc's design. We even learn about the power of platforms.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2024.05.23GuestRichard FeldmanShow notes[00:00:20] Non-introductionRocSoftware Unscripted"Making Impossible States Impossible""Scaling Elm Apps"Elm in ActionElm courses on Frontend Masters[00:01:47] Motivations to make Roc[00:04:53] Back to the beginnings in 2018[00:15:25] How Roc compares to ElmAaron VonderHaar's elm-formatElm Style Guide"Bret Victor style reactive debugging" by Laszlo Pandy at Elm Workshop 2013 (YouTube)"Functional Semantics in Imperative Clothing"[00:25:18] Minimizing the erosion of simplicity (governance models)"BDFN" on roc-lang.orgEpisode "Programming and Industrial Design with Greg Wilson" of Software Unscripted[00:31:36] How teaching Elm informed Roc's design[00:40:34] Design processEpisode "The Roc Programming Language with Richard Feldman" of Software Unscripted[00:45:04] Working at Zed IndustriesZed[00:50:28] Platforms[00:58:03] PicksRichard's picksPerformance-Aware Programming Series by Casey MuratoriSoftware You Can Love (SYCL) Milan 2024 playlist (YouTube)"Hybrid-Level Programming" by Richard Feldman at SYCL Milan 2024 (YouTube)ReliqaJared's picksUmphrey's McGeeBret Victor

This week we're joined by Richard Feldman, the author of Roc lang, a futuristic functional programming language. Richard is a software engineer at Zed, a company that making a new code editor that's built on the Rust programming language and integrates AI. We talk about all the crazy feature that Roc lang has, and how it might change the way you write code. https://www.linkedin.com/in/rtfeldman/ https://github.com/rtfeldman https://x.com/rtfeldman?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor https://www.roc-lang.org/ Episode sponsored By MUX (https://mux.com) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

In this episode, Conor and Bryce catch up via phone tag and chat about an algorithm.Link to Episode 185 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachShow NotesDate Recorded: 2024-06-04 to 2024-06-06Date Released: 2024-06-07Craft Conf 2024ADSP Episode 157: The Roc Programming Language with Richard Feldman'Declarative Thinking, Declarative Practice' - Kevlin Henney [ ACCU 2016 ]Dave Thomas YOW! Vector Talk (can't find the link)C++Now 2019: Conor Hoekstra “Algorithm Intuition”Better Algorithm Intuition - Conor Hoekstra @code_report - Meeting C++ 2019C++ std::nth_elementC++ std::partial_sort_copythrust::partitionIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël! Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development. Christopher Alexander and Design Patterns (https://www.designsystems.com/christopher-alexander-the-father-of-pattern-language/) Rails guide to choosing between belongsto and hasone (https://edgeguides.rubyonrails.org/association_basics.html#choosing-between-belongs-to-and-has-one) Making impossible states impossible (https://www.youtube.com/watch?v=IcgmSRJHu_8) Transcript: We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I learned a very interesting tidbit. I don't know if it's historical; I don't know if I would label it that. But, I recently learned about where the idea of design patterns in software came from. Are you familiar with that at all? JOËL: I read an article about that a while back, and I forget exactly, but there is, like, a design patterns movement, I think, that predates the software world. STEPHANIE: Yeah, exactly. So, as far as I understand it, there is an architect named Christopher Alexander, and he's kind of the one who proposed this idea of a pattern language. And he developed these ideas from the lens of architecture and building spaces. And he wrote a book called A Pattern Language that compiles, like, all these time-tested solutions to how to create spaces that meet people's needs, essentially. And I just thought that was really neat that software design adopted that philosophy, kind of taking a lot of these interdisciplinary ideas and bringing them into something technical. But also, what I was really compelled by was that the point of these patterns is to make these spaces comfortable and enjoyable for humans. And I have that same feeling evoked when I'm in a codebase that's really well designed, and I am just, like, totally comfortable in it, and I can kind of understand what's going on and know how to navigate it. That's a very visceral feeling, I think. JOËL: I love the kind of human-centric approach that you're using and the language that you're using, right? A place that is comfortable for humans. We want that for our homes. It's kind of nice in our codebases, too. STEPHANIE: Yeah. I have really enjoyed this framing because instead of just saying like, "Oh, it's quote, unquote, "best practice" to follow these design patterns," it kind of gives me more of a reason. It's more of a compelling reason to me to say like, "Following these design patterns makes the codebase, like, easier to navigate, or easier to change, or easier to work with." And that I can get kind of on board with rather than just saying, "This way is, like, the better way, or the superior way, or the way to do things." JOËL: At the end of the day, design patterns are a means to an end. They're not an end in of itself. And I think that's where it's very easy to get into trouble is where you're just sort of, I don't know, trying to rack up engineering points, I guess, for using a lot of design patterns, and they're not necessarily in service to some broader goal. STEPHANIE: Yeah, yeah, exactly. I like the way you put that. When you said that, for some reason, I was thinking about catching Pokémon or something like filling your Pokédex [laughs] with all the different design patterns. And it's not just, you know, like you said, to check off those boxes, but for something that is maybe a little more meaningful than that. JOËL: You're just trying to, like, hit the completionist achievement on the design patterns. STEPHANIE: Yeah, if someone ever reaches that, you know, gets that achievement trophy, let me know [laughs]. JOËL: Can I get a badge on GitHub for having PRs that use every single Gang of Four pattern? STEPHANIE: Anyway, Joël, what's new in your world? JOËL: So, on the topic of completing things and getting badges for them, I am a part of the Boston bike share...project makes it sound like it's a, I don't know, an exclusive club. It's Boston's bike share system. I have a subscription with them, and I love it. It's so practical. You can go everywhere. You don't have to worry about, like, a bike getting stolen or something because, like, you drop it off at a docking station, and then it's not your responsibility anymore. Yeah, it's very convenient. I love it. I got a notification on the app this week that said, "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." STEPHANIE: Whoa, that's actually a pretty cool accomplishment. JOËL: I didn't even know they tracked that, and it's kind of cool. And the achievement shows me, like, here are all the different stations you've visited. STEPHANIE: You know what I think would be really fun? Is kind of the equivalent of a Spotify Wrapped, but for your biking in a year kind of around the city. JOËL: [laughs] STEPHANIE: That would be really neat, I think, just to be like, oh yeah, like, I took this bike trip here. Like, I docked at this station to go meet up with a friend in this neighborhood. Yeah, I think that would be really fun [laughs]. JOËL: You definitely see some patterns come up, right? You're like, oh yeah, well, you know, this is my commute into work every day. Or this is that one friend where, you know, every Tuesday night, we go and do this thing. STEPHANIE: Yeah, it's almost like a travelogue by bike. JOËL: Yeah. I'll bet there's a lot of really interesting information that could surface from that. It might be a little bit disturbing to find out that a company has that data on you because you can, like, pick up so much. STEPHANIE: That's -- JOËL: But it's also kind of fun to look at it. And you mentioned Spotify Wrapped, right? STEPHANIE: Right. JOËL: I love Spotify Wrapped. I have so much fun looking at it every year. STEPHANIE: Yeah. It's always kind of funny, you know, when products kind of track that kind of stuff because it's like, oh, like, it feels like you're really seen [laughs] in terms of what insights it's able to come up with. But yeah, I do think it's cool that you have this little badge. I would be curious to know if there's anyone who's, you know, managed to hit a hundred percent of all the docking stations. They must be a Boston bike messenger or something [laughs]. JOËL: Now that I know that they track it, maybe I should go for completion. STEPHANIE: That would be a very cool flex, in my opinion. JOËL: [laughs] And, you know, of course, they're always expanding the network, which is a good thing. I'll bet it's the kind of thing where you get, like, 99%, and then it's just really hard to, like, keep up. STEPHANIE: Yeah, nice. JOËL: But I guess it's very appropriate, right? For a podcast titled The Bike Shed to be enthusiastic about a bike share program. STEPHANIE: That's true. So, for today's topic, I wanted to pick your brain a little bit on a data modeling question that I posed to some other developers at thoughtbot, specifically when it comes to associations and associations through other associations [laughs]. So, I'm just going to kind of try to share in words what this data model looks like and kind of see what you think about it. So, if you had a company that has many employees and then the employee can also have many devices and you wanted to be able to associate that device with the company, so some kind of method like device dot company, how do you think you would go about making that association happen so that convenience method is available to you in the code? JOËL: As a convenience for not doing device dot employee dot company. STEPHANIE: Yeah, exactly. JOËL: I think a classic is, at least the other way, is that it has many through. I forget if you can do a belongs to through or not. You could also write, effectively, a delegation method on the device to effectively do dot employee dot company. STEPHANIE: Yeah. So, I had that same inkling as you as well, where at first I tried to do a belongs to through, but it turns out that belongs to does not support the through option. And then, I kind of went down the next path of thinking about if I could do a has one, a device has one company through employee, right? But the more I thought about it, the kind of stranger it felt to me in terms of the semantics of saying that a device has a company as opposed to a company having a device. It made more sense in plain English to think about it in terms of a device belonging to a company. JOËL: That's interesting, right? Because those are ways of describing relationships in sort of ActiveRecord's language. And in sort of a richer situation, you might have all sorts of different adjectives to describe relationships. Instead of just belongs to has many, you have things like an employee owns a device, an employee works for a company, you know because an employee doesn't literally belong to a company in the literal sense. That's kind of messed up. So, I think what ActiveRecord's language is trying to use is less trying to, like, hit maybe, like, the English domain language of how these things relate to, and it's more about where the foreign keys are in the database. STEPHANIE: Yeah. I like that point where even though, you know, these are the things that are available to us, that doesn't actually necessarily, you know, capture what we want it to mean. And I had gone to see what Rails' recommendation was, not necessarily for the situation I shared. But they have a section for choosing between which model should have the belongs to, as opposed to, like, it has one association on it. And it says, like you mentioned, you know, the distinction is where you place the foreign key, but you should kind of think about the actual meaning of the data. And, you know, we've talked a lot about, I think, domain modeling [chuckles] on the show. But their kind of documentation says that...the has something relationship says that one of something is yours, that it can, like, point back to you. And in the example I shared, it still felt to me like, you know, really, the device wanted to point to the company that it is owned by. And if we think about it in real-world terms, too, if that device, like, is company property, for example, then that's a way that that does make sense. But the couple of paths forward that I saw in front of me were to rework that association, maybe add a new column onto the device, and go down that path of codifying it at the database level. Or kind of maybe something as, like, an in-between step is delegating the method to the employee. And that's what I ended up doing because I wasn't quite ready to do that data migration. JOËL: Adding more columns is interesting because then you can run into sort of data consistency issues. Let's say on the device you have a company ID to see who the device belongs to. Now, there are sort of two different independent paths. You can ask, "Which company does this device belong to?" You can either check the company ID and then look it up in the company table. Or you can join on the employee and join the employee back under company. And those might give you different answers and that can be a problem with data consistency if those two need to stay in sync. STEPHANIE: Yeah, that is a good point. JOËL: There could be scenarios where those two are allowed to diverge, right? You can imagine a scenario where maybe a company owns the device, but an employee of a potentially different company is using the device. And so, now it's okay to have sort of two different chains because the path through the employee is about what company is using our devices versus which company actually owns them. And those are, like, two different kinds of relationships. But if you're trying to get the same thing through two different paths of joining, then that can set you up for some data inconsistency issues. STEPHANIE: Wow. I really liked what you said there because I don't think enough thought goes into the emergent relationships between models after they've been introduced to a codebase. At least in my experience, I've seen a lot of thought go up front into how we might want to model an ActiveRecord, but then less thought into seeing what patterns kind of show up over time as we introduce more functionality to these models, and kind of understand how they should exist in our codebase. Is that something that you find yourself kind of noticing? Like, how do you kind of pick up on the cue that maybe there's some more thought that needs to happen when it comes to existing database tables? JOËL: I think it's something that definitely is a bit of a red flag, for me, is when there are multiple paths to connect to sort of establish a relationship. So, if I were to draw out some sort of, like, diagram of the models, boxes, and arrows or something like that, and then I could sort of overlay different paths through that diagram to connect two models and realize that those things need to be in sync, I think that's when I started thinking, ooh, that's a potential danger. STEPHANIE: Yeah, that's a really great point because, you know, the example I shared was actually a kind of contrived one based on what I was seeing in a client codebase, not, you know, I'm not actually working with devices, companies, and employees [laughs]. But it was encoded as, essentially, a device having one company. And I ended up drawing it out because I just couldn't wrap my head around that idea. And I had, essentially, an arrow from device pointing to company when I could also see that you could go take the path of going through employee [laughs]. And I was just curious if that was intentional or was it just kind of a convenient way to have that direct method available? I don't currently have enough context to determine but would be something I want to pay attention to. Like you said, it does feel like, if not a red flag, at least an orange one. JOËL: And there's a whole kind of science to some of this called database normalization, where they're sort of, like, they all have rather arcane names. They're the first normal form, the second normal form, the third normal form, you know, it goes on. If you look at the definition, they're all also a little bit arcane, like every element in a relation must depend solely upon the primary key. And you're just like, well, what does that mean? And how do I know if my table is compliant with that? So, I think it's worth, if you're Googling for some of these, find an article that sort of explains these a little bit more in layman's terms, if you will. But the general idea is that there are sort of stricter and stricter levels of the amount of sort of duplicate sources of truth you can have. In a sense, it's almost like DRY but for databases, and for your database schema in particular. Because when you have multiple sources of truth, like who does this device belong to, and now you get two different answers, or three different answers, now you've got a data corruption issue. Unlike bugs in code where it's, you know, it can be a problem because the site is down, or users have incorrect behavior, but then you can fix it later, and then go to production, and disruption to your clients is the worst that happened, this sort of problem in data is sometimes unrecoverable. Like, it's just, hey, -- STEPHANIE: Whoa, that sounds scary. JOËL: Yeah, no, data problems scare me in a way that code problems don't. STEPHANIE: Whoa. Could you...I think I interrupted you. But where were you going to go about once you have corrupted data? Like, it's unrecoverable. What happens then? JOËL: Because, like, if I look at the database, do I know who the real owner of this...if I want to fix it, let's say I fix my schema, but now I've got all this data where I've got devices that have two different owners, and I don't know which one is the real one. And maybe the answer is, I just sort of pick one and say, "Oh, the one that was through this association is sort of the canonical one, and we can just sort of ignore the other one." Do I have confidence in that decision? Well, maybe depending on some of the other context maybe, I'm lucky that I can have that. The doomsday scenario is that it's a little bit of one, a little bit of the other because there were different code paths that would write to one way or another. And there's no real way of knowing. If there's not too many devices, maybe I do an audit. Maybe I have to, like, follow up with all of my customers and say, "Hey, can you tell me which ones are really your devices?" That's not going to scale. Like, real worst case scenario, you almost have to do, like, a bit of a bankruptcy, where you say, "Hey, all the data prior to this date there's a bit of a question mark on it. We're not a hundred percent sure about it." And that does not feel great. So, now you're talking about mitigation strategies. STEPHANIE: Oof. Wow. Yeah, you did make it sound [laughs] very scary. I think I've kind of been on the periphery of a situation like this before, where it's not just that we couldn't trust the code. It's that we couldn't trust the data in the database either to tell us how things work, you know, for our users and should work from a product perspective. And I was on a previous client project where they had to, yeah, like, hire a bunch of people to go through that data and kind of make those determinations, like you said, to kind of figure out it out for, you know, all of these customers to determine the source of truth there. And it did not sound like an easy feat at all, right? That's so much time and investment that you have to put into that once you get to that point. JOËL: And there's a little bit of, like, different problems at different layers. You know, at the database layer, generally, you want all of that data to be really in a sort of single source of truth. Sometimes that makes it annoying to query because you've got to do all these joins. And so, there are various denormalization strategies that you can use to make that. Or sometimes it's a risk you're going to take. You're going to say, "Look, this table is not going to be totally normalized. There's going to be some amount of duplication, and we're comfortable with the risk if that comes up." Sometimes you also build layers of abstractions on top, so you might have your data sort of at rest in database tables fully normalized and separated out, but it's really clunky to query. So, you build out a database view on top of that that returns data in sort of denormalized fashion. But that's okay because you can always get your correct answer by querying the underlying tables. STEPHANIE: Wow. Okay. I have a lot of thoughts about this because I feel like database normalization, and I guess denormalization now, are skills that I am certainly not an expert at. And so, when it comes to, like, your average developer, how much do you think that people need to be thinking about this? Or what strategies do you have for, you know, a typical Rails dev in terms of how deep they should go [laughs]? JOËL: So, the classic advice is you probably want to go to, like, third to fourth normal form, usually three. There's also like 3.5 for some reason. That's also, I think, sometimes called BNF. Anyway, sort of levels of how much you normalize. Some of these things are, like, really, really basic things that Rails just builds into its defaults with that convention over configuration, so things like every table should have a primary key. And that primary key should be something that's fixed and unique. So, don't use something like combination of first name, last name as your primary key because there could be multiple people with the same name. Also, people change their names, and that's not great. But it's great that people can change their names. It's not great to rely on that as a primary key. There are things like look for repeating columns. If you've got columns in your schema with a number prefix at the end, that's probably a sign that you want to extract a table. So, I don't know, you have a movie, and you want to list the actors for a movie. If your movie table has actor 1, actor 2, actor 3, actor 4, actor 5, you know, like, all the way up to actor 20, and you're just like, "Yeah, no, we fill, like, actor 1 through N, and if there's any space left over, we just put nulls in those columns," that's a pretty big sign that, hey, why don't you instead have a, like, actor's table, and then make a, like, has many association? So, a lot of the, like, really basic normalization things, I think, are either built into Rails or built into sort of best practices around Rails. I think something that's really useful for developers to get as a sense beyond learning the actual different normal forms is think about it like DRY for your schema. Be wary of sort of multiple sources of truth for your data, and that will get you most of the way there. When you're designing sort of models and tables, oftentimes, we think of DRY more in terms of code. Do you ever think about that a little bit in terms of your tables as well? STEPHANIE: Yeah, I would say so. I think a lot of the time rather than references to another table just starting to grow on a certain model, I would usually lean towards introducing a join table there, both because it kind of encapsulates this idea that there is a connection, and it makes the space for that idea to grow if it needs to in the future. I don't know if I have really been disciplined in thinking about like, oh, you know, there should really...every time I kind of am designing my database tables, thinking about, like, there should only be one source of truth. But I think that's a really good rule of thumb to follow. And in fact, I can actually think of an example right now where we are a little bit tempted to break that rule. And you're making me reconsider [laughter] if there's another way of doing so. One thing that I have been kind of appreciative of lately is on my current client project; there's just, like, a lot of data. It's a very data-intensive and sensitive application. And so, when we introduce migrations, those PRs get tagged for review by someone over from the DevOps side, just to kind of provide some guidance around, you know, making sure that we're setting up our models to scale well. One of the things that he's been asking me on my couple of code changes I introduced was, like, when I introduced an index, like, it happened to be, like, a composite index with a couple of different columns, and the particular order of those columns mattered. And he kind of prompted me to, like, share what my use cases for this index were, just to make sure that, like, some thought went into it, right? Like, it's not so much that the way that I had done it was wrong, but just that I had, like, thought about it. And I like that as a way of kind of thinking about things at the abstraction that I need to to do my dev work day to day and then kind of mapping that to, like you were saying, those best practices around keeping things kind of performant at the database level. JOËL: I think there's a bit of a parallel world that people could really benefit from dipping a toe in, and that's sort of the typed programming world, this idea of making impossible states impossible or making illegal states unrepresentable. That in the sort of now it's not schemas of database tables or schemas of types that you're creating but trying to prevent data coming into a state where someone could plausibly construct an instance of your object or your type that would be nonsensical in the context of your app, kind of trying to lock that down. And I think a lot of the ways that people in those communities think about...in a sense, it's kind of like database normalization for developers. So, if you're not wanting to, like, dip your toe in more of the sort of database-centric world and, like, read an article from a DBA, it might be worthwhile to look at some of those worlds as well. And I think a great starting point for that is a talk by Richard Feldman called Making Impossible States Impossible. It's for the Elm language. And there are equivalents, I think, in many others as well. STEPHANIE: That's really cool that you are making that connection. I know we've kind of briefly talked about workshops in the past on the show. But if there were a workshop for, you know, that kind of database normalization for developers, I would be the first to sign up [laughs]. JOËL: Hint, hint, RailsConf idea. There's something from your original question that I think is interesting to circle back to, and that's the fact that it was awkward to work through in Ruby to do the work that you wanted to do because the tables were laid out in a certain way. And sometimes, there's certain ways that you need the tables to be in order to be sort of safe to represent data, but they're not the optimal way that we would like to interact with them at the Ruby level. And I think it's okay for not everything in Ruby to be 100% reflective of the structure of the tables underneath. ActiveRecord gives us a great pattern, but everything is kind of one-to-one. And it's okay to layer on some things on top, add some extra methods to build some, like, connections in Ruby that rely on this normalized data underneath but that make life easier for you, or they better just represent or describe the relationships that you have. STEPHANIE: 100%. I was really compelled by your idea of introducing helpers that use more descriptive adjectives for what that relationship is like. We've talked about how Rails abstracted things from the database level, you know, for our convenience, but that should not stop us from, like, leaning on that further, right? And kind of introducing our own abstractions for those connections that we see in our domain. So, I feel really inspired. I might even kind of reconsider the way I handled the original example and see what I can make of it. JOËL: And I think your original solution of doing the delegation is a great example of this as well. You want the idea that a device belongs to a company or has an association called company, and you just don't want to go through that long chain, or at least you don't want that to be visible as an implementation detail. So, in this case, you delegate it through a chain of methods in Ruby. It could also be that you have a much longer chain of tables, and maybe they don't all have associations in Rails and all that. And I think it would be totally fine as well to define a method on an object where, I don't know, a device, I don't know, has many...let's call it technicians, which is everybody who's ever touched this device or, you know, is on a log somewhere for having done maintenance. And maybe that list of technicians is not a thing you can just get through regular Rails associations. Maybe there's a whole, like, custom query underlying that, and that's okay. STEPHANIE: Yeah, as you were saying that, I was thinking about that's actually kind of, like, active models are the great spot to put those methods and that logic. And I think you've made a really good case for that. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

This interview was recorded at GOTO Copenhagen for GOTO Unscripted.http://gotopia.techRead the full transcription of this interview hereRichard Feldman - Functional Programming Language Expert, Author of "Elm in Action" & Creator for the Roc Programming LanguageJames Lewis - Principal Consultant & Technical Director at ThoughtworksRESOURCESRichardhttps://twitter.com/rtfeldmanhttps://linkedin.com/in/rtfeldmanhttps://github.com/rtfeldmanhttps://www.roc-lang.orghttps://twitter.com/sw_unscriptedJameshttps://twitter.com/boicyhttps://linkedin.com/in/james-lewis-microserviceshttps://www.thoughtworks.com/radarDESCRIPTIONJoin Richard Feldman and James Lewis as they unpack a new programming language and what it brings to the ecosystem. They navigate through the nuances of language selection, exploring the sweet spot between fun and standardization. From Elm's role in front-end development to Scala's adoption patterns and Dart's transformation into Flutter, the discussion takes you on a journey across diverse programming landscapes.Discover the ins and outs of Roc, a fresh face in the coding scene, and the driving force behind its creation. Learn about its architecture, design principles, and standout features, including parsing strategies and a candid comparison with other languages. Explore the excitement around Roc's innovative traits and its knack for performance optimization, unveiling its potential in the dynamic world of functional programming.RECOMMENDED BOOKSRichard Feldman • Elm in ActionTim McNamara • Rust in ActionCristian Salcescu • Functional Programming in JavaScriptYehonathan Sharvit • The Clojure WorkshopTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Among compelling points in this interview is "the politicalization of medicine is a horrible thing," and, in public health "personal responsibility does not work."  Our guest is former Indiana State Health Commissioner Dr. Richard Feldman who also is a frequent columnist in The Indianapolis Business Journal as well as author of books, including his most recent:  "What Our Patients Have Taught Us . . . "    

Erik Person shares how he joined Corvus Insurance as the first engineer building the system from scratch with Elm and Elixir. We talk about onboarding, culture, and growing the team. He exclaims his excitement for the next phase of acquisition by Travelers.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.12.05GuestErik PersonShow notes[00:00:22] Sponsored by Logistically[00:00:52] Introducing ErikElm seedsTravelers to Acquire Corvus Insurance[00:01:20] Getting started[00:07:27] The flight to Elm[00:12:43] Elm seeds[00:17:14] Why Elm at Corvus?"The Python Paradox" by Paul Graham"Make Impossible States Impossible" by Richard Feldman[00:21:57] Hiring & onboarding practices[00:24:09] ScalingAaron VonderHaar's elm-format[00:27:49] Static Elm + dynamic ElixirLuke Westby's elm-http-builder[00:34:32] Programming the plane[00:38:58] Corvus engineering cultureForbes' list of "America's Best Startup Employers"[00:43:59] AcquisitionTravelers to Acquire Corvus InsuranceTravelers Completes Acquisition of Corvus Insurance[00:48:34] PicksErik's picks"Interesting bugs caught by no-constant-binary-expression" by Jordan Eldredge"Training AI to Play Pokemon with Reinforcement Learning" by Peter WhiddenThe Data Warehouse Toolkit by Ralph Kimball and Margy RossJared's pickJeroen Engels' elm-review

For the final episode of Elixir Wizards' Season 11 “Branching Out from Elixir,” we're featuring a recent discussion from the Software Unscripted podcast. In this conversation, José Valim, creator of Elixir, interviews Richard Feldman, creator of Roc. They compare notes on the process and considerations for creating a language. This episode covers the origins of creating a language, its influences, and how goals shape the tradeoffs in programming language design. José and Richard share anecdotes from their experiences guiding the evolution of Elixir and Roc. The discussion provides an insightful look at the experimentation and learning involved in crafting new languages. Topics discussed in this episode What inspires the creation of a new programming language Goals and use cases for a programming language Influences from Elm, Rust, Haskell, Go, OCaml, and more Tradeoffs involved in expressiveness of type systems Opportunistic mutation for performance gains in a functional language Minimum version selection for dependency resolution Build time considerations with type checking and monomorphization Design experiments and rolling back features that don't work out History from the first simple interpreter to today's real programming language Design considerations around package management and versioning Participation in Advent of Code to gain new users and feedback Providing performance optimization tools to users in the future Tradeoffs involved in picking integer types and arithmetic Comparing floats and equality checks on dictionaries Using abilities to customize equality for custom types Ensuring availability of multiple package versions for incremental upgrades Treating major version bumps as separate artifacts Roc's focus on single-threaded performance Links mentioned in this episode Software Unscripted Podcast https://feeds.resonaterecordings.com/software-unscripted Roc Programming Language https://www.roc-lang.org/ Roc Lang on Github https://github.com/roc-lang/roc Elm Programming Language https://elm-lang.org/ Elm in Action by Richard Feldman https://www.manning.com/books/elm-in-action Richard Feldman on Github https://github.com/rtfeldman Lua Programming Language https://www.lua.org/ Vimscript Guide https://google.github.io/styleguide/vimscriptfull.xml OCaml Programming Language https://ocaml.org/ Advent of Code https://adventofcode.com/ Roc Language on Twitter https://twitter.com/roclang Richard Feldman on Twitter https://twitter.com/rtfeldman Roc Zulip Chat https://roc.zulipchat.com Clojure Programming Language https://clojure.org/ Talk: Persistent Data Structures and Managed References by Rich Hickey https://www.youtube.com/watch?v=toD45DtVCFM Koka Programming Language https://koka-lang.github.io/koka/doc/index.html Flix Programming Language https://flix.dev/ Clojure Transients https://clojure.org/reference/transients Haskell Software Transactional Memory https://wiki.haskell.org/Softwaretransactional_memory Rust Traits https://doc.rust-lang.org/book/ch10-02-traits.html CoffeeScript https://coffeescript.org/ Cargo Package Management https://doc.rust-lang.org/book/ch01-03-hello-cargo.html Versioning in Golang https://research.swtch.com/vgo-principles Special Guests: José Valim and Richard Feldman.

Lane chats with Richard Feldman, creator of the Roc programming language, about why he decided to create it. They discuss object oriented programming and whether it did irreparable damage to the industry - or not. Follow along as they talk about all of that and functional programming too!Learn back-end development - https://boot.devListen on your favorite podcast player: https://www.backendbanter.comRichard Feldmans Twitter: twitter.com/rtfeldmanRoc Programming Language: https://www.roc-lang.org/Software Unscripted can be found on any podcast platform!

José Valim hosts this episode, and chats with Roc Programming Language Richard Feldman about the language.

Sometimes, what a programming language makes harder is just as important as what it makes easier. For a simple example, think of GOTO. We've been wisely avoiding it for decades because it makes confusing control flow desperately easy. Types and tests are other examples - they're as much about specifying what shouldn't work as what should. And perspective is what makes this week's topic particularly interesting: Roc is a language that's functional, fast, friendly, and extremely interested in making your life easier by enabling some possibilities and restricting others.So this week we're joined by Richard Feldman, the creator of Roc. He's been an advocate of the Elm programming language for years, for its tight focus on taking the best bits of Functional Programming to the browser. And in recent years he's been inspired to build his own language, taking that philosophy to other places and platforms.But which bits are “the best bits”? And how do they change when the domain you're coding for changes? How is Roc built and how would we build systems in it? Let's find out…--Roc's homepage: https://www.roc-lang.org/Richard's GOTO Copenhagen 2021 talk: https://www.youtube.com/watch?v=3n17wHe5wEwRichard on Twitter: https://twitter.com/rtfeldmanKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Mastodon: https://mastodon.social/@krisajenkinsKris on Twitter: https://twitter.com/krisajenkins

Lindsay Wardell tells how she persevered to write her own story as a programmer and shares her views on JavaScript frameworks & fatigue.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.11.06GuestLindsay WardellShow notes[00:00:20] Sponsored by Logistically[00:00:49] Introducing LindsayHuman Side of DevElm and Vite on Elm Radio, hosted by Dillon Kearns & Jeroen EngelsFunctional programming with Elm on PodRocket, hosted by Paul MikulskisFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman"Functional Programming in Vite" at ViteConf 2023elm-vue-bridgevite-elm-template.[00:01:54] Getting started in computing and programming[00:06:06] A break in Brazil"How to teach programming (and other things)?" by Felienne Hermans[00:09:27] Getting back into programmingFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman...again[00:18:55] Why Elm?JuralenFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman...yet again. Seriously, it's good.[00:28:06] The road to NoRedInkWikifunctionsViews on VueS08E014 Modern Web Podcast - Elm with Richard Feldman[00:33:05] JavaScript fatigue[00:38:04] Standardization around Vite[00:41:13] The challenge of legacy code at NoRedInknoredink-uiElm Landelm-pages[00:46:22] Star CommanderStar Commander (GitHub)Elm Town 63 – Opening the doors of functional programming[00:53:47] What are you excited about?Lamdera"The Economics of Programming Languages" by Evan Czaplicki at Strange Loop 2023[00:55:50] PicksLindsay's picksNuxtNaNoWriMo (National Novel Writing Month)Blood on the ClocktowerBabylon 5Jared's picksBattlestar GalacticaS2E2 - "One Moore", PortlandiaFeel It All Around by Washed Out

In this episode, Conor and Bryce conclude their interview with Richard Feldman about the Roc programming language!Link to Episode 159 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Richard Feldman is the creator of the Roc programming language, the host of the Software Unscripted podcast, and the author of Elm in Action from Manning Publications. He teaches online courses on Frontend Masters: Introduction to Rust, Introduction to Elm, and Advanced Elm. Outside of programming, he's a fan of strategy games, heavy metal, powerlifting, and puns!Show NotesDate Recorded: 2023-11-13Date Released: 2023-12-08Software Unscripted PodcastThe Roc LanguageDenoRust YewThe Roc Language TutorialIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

In this episode, Conor and Bryce continue their interview with Richard Feldman about the Roc programming language!Link to Episode 158 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Richard Feldman is the creator of the Roc programming language, the host of the Software Unscripted podcast, and the author of Elm in Action from Manning Publications. He teaches online courses on Frontend Masters: Introduction to Rust, Introduction to Elm, and Advanced Elm. Outside of programming, he's a fan of strategy games, heavy metal, powerlifting, and puns!Show NotesDate Recorded: 2023-11-13Date Released: 2023-12-01Software Unscripted PodcastThe Roc LanguageHylo Programming LanguageCarbon Programming LanguageElm Programming LanguageBQN Programming LanguageContinuation MonadContinuation Passing Style (CPS)C++ Senders and ReceiversIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Jim Carlson shares his discoveries in software development through the people he's met in the community and the projects he's building. We also discuss how a history in mathematics shapes his work.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.10.13GuestJim CarlsonShow notes[00:00:16] Sponsored By Logistically[00:00:45] Introducing Jim"Making a LaTeX-to-Html parser in Elm" at Elm Europe 2018jxxcarlson/meenylatex"Tarring files with Elm" at Oslo Elm Day 2019jxxcarlson/elm-tarjxxcarlson/elm-markdownjxxcarlson/elm-l0-parserRandom Exchange ModelSchelling's segregation model"Making Elm Talk to Your Personal Supercomputer" at elm-conf 2019Fake Drum Language Apphttps://scripta.ioElm NotebookElm Town 29 - Knode.io with Jim Carlson in 2018 w/Murphy Randle[00:02:10] History in Mathematics[00:04:27] Serious software development[00:06:37] Getting out of the basementMatthew Griffith's elm-uiLamdera[00:09:59] Problem-solving approaches[00:14:43] Scripta.io[00:19:25] Learning Haskell[00:24:40] Elm NotebookBooklib.ioelm-in-elm/compilerMinibill's elm-interpreterElm Land

In this episode, Conor and Bryce interview Richard Feldman about the Roc programming language, what qualifies a language as a functional programming language (and whether Rust makes the cut) and more!Link to Episode 157 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Richard Feldman is the creator of the Roc programming language, the host of the Software Unscripted podcast, and the author of Elm in Action from Manning Publications. He teaches online courses on Frontend Masters: Introduction to Rust, Introduction to Elm, and Advanced Elm. Outside of programming, he's a fan of strategy games, heavy metal, powerlifting, and puns!Show NotesDate Recorded: 2023-11-13Date Released: 2023-11-24Software Unscripted PodcastThe Roc LanguageHaskell LanguageElixir LanguageSoftware Unscripted: Gradual vs Static Typing with Jose ValimInterview with Senior Rust Developer in 2023 (YouTube Video)Rust Iterator::mapRust Iterator::filterZig LanguageThe Essence of Functional Programming by Richard Feldman #FnConf 2022Rank-N Types (Higher Rank Types)Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

In this episode, Conor and Bryce interview Richard Feldman, creator of the Roc programming language, about the last edition of the Strange Loop conference, virtual vs in-person events and more.Link to Episode 156 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Richard Feldman is the creator of the Roc programming language, the host of the Software Unscripted podcast, and the author of Elm in Action from Manning Publications. He teaches online courses on Frontend Masters: Introduction to Rust, Introduction to Elm, and Advanced Elm. Outside of programming, he's a fan of strategy games, heavy metal, powerlifting, and puns!Show NotesDate Recorded: 2023-11-13Date Released: 2023-11-17Software Unscripted PodcastWhy Isn't Functional Programming the Norm? – Richard FeldmanStrange Loop Conference“The Economics of Programming Languages” by Evan Czaplicki (Strange Loop 2023)“Software & The Game of Go” by David Nolen (Strange Loop 2023)“A Long Strange Loop” by Alex Miller (Strange Loop 2023)Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Adriano Ferrari talks about how Elm allows him to solely support Gingko Writer and make progress on new projects while also homeschooling.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.09.08GuestAdriano FerrariShow notes[00:00:25] Sponsored by Logistically[00:01:00] Introducing AdrianoGingko Writer, open-source on GitHub at gingko/client.[00:01:19] Getting started in computing[00:03:55] Physics in Canada[00:07:03] Discovering Elm[00:11:30] Perfectionism"Tools & Perfectionism" by Adriano Ferrari[00:15:07] Little leak in your mind"Make Reliable Web Apps Without JS Fatigue" by Jared at Detroit Tech Watch 2019[00:17:25] Overcoming creative blocks"Reset Expectations to Overcome Creative Blocks" by Adriano Ferrari[00:21:38] Breaking things down with Gingko WriterElm Town 61 – Turning the pages with Dillon Kearns[00:25:19] Challenges building Gingko WriterElm Town 64 – The network effecthttps://ascii-collab.apphttps://town-collab.app[00:31:43] Homeschooling & solely supporting Gingko Writer[00:37:52] "Frequent changes of treatment""A 'Gradual Commitment' Productivity System""Exploring elm-spa-example" by Richard Feldman at Oslo Elm Day with a section about dependencies[00:42:13] New, 100% Elm project[00:44:22] PicksAdriano's picksSimon Lydell's elm-watchSimon Lydell's elm-app-urlONYX BOOX Note Air 2 PlusJared's picksStretchlyYoga

This week we're taking you to the hallway track of the final Strange Loop conference. First up is AnnMarie Thomas — an engineering, business, and education professor. AnnMarie gave one of the opening keynotes titled “Playing with Engineering.” We also caught up with many first-time and multi-time attendees who shared their favorite moments from Strange Loop over the years. You'll hear from Richard Feldman, Colin Dean, and Taylor Troesh. Last up we talk with Pokey Rule. He gave a talk about his project called Cursorless which is a spoken language for structural code editing. Changelog++ subscribers get a super extended version of this episode which includes everything we recorded at Strange Loop. Become a Changelog++ subscriber

This week we're taking you to the hallway track of the final Strange Loop conference. First up is AnnMarie Thomas — an engineering, business, and education professor. AnnMarie gave one of the opening keynotes titled “Playing with Engineering.” We also caught up with many first-time and multi-time attendees who shared their favorite moments from Strange Loop over the years. You'll hear from Richard Feldman, Colin Dean, and Taylor Troesh. Last up we talk with Pokey Rule. He gave a talk about his project called Cursorless which is a spoken language for structural code editing. Changelog++ subscribers get a super extended version of this episode which includes everything we recorded at Strange Loop. Become a Changelog++ subscriber

This week Authentically Detroit welcomed former auto-worker, longtime community and labor activist, and board member at the Boggs Center, Richard Feldman. Together they discussed the historic “Stand Up Strike,” started by the United Auto Workers (UAW). This strike is the culmination of a workers movement that has taken over the United States. As a former auto-worker at one of the striking UAW plants and labor activist, Rich has a wealth of knowledge on the conditions that led to this groundbreaking strike. In the end, the trio expands upon what it will take to achieve true freedom for the working class.For more information on the Boggs Center, click here!FOR HOT TAKES:MEET THE DEMOCRAT BLOCKING MICHIGAN ABORTION BILLS. SHE SAYS SHE'S NOT ALONE TAX REFORM, TENANTS RIGHTS, BUS DISCOUNTS: WHAT'S NEXT FOR SHEFFIELD'S "PEOPLE'S BILL”Support the showFollow us on Instagram, Facebook and Twitter.

We review Jeroen Engels' journey with Elm from ESLint to elm-review. Jeroen even gives tips on how to introduce rules to a team.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.08.01GuestJeroen EngelsShow notes[00:00:21] Sponsored by Logistically[00:00:58] Introducing Jeroen Engelselm-reviewElm RadioElm Town 61 – Turning the pages with Dillon Kearnselm-syntaxjfmengels/elm-review-commonjfmengels/elm-review-documentationjfmengels/elm-review-simplifyjfmengels/elm-review-unused[00:02:37] It all started with a book[00:06:09] Getting a job as a backend developer[00:11:33] Senior: Figuring out what you're passionate about[00:15:24] Using ESLint to solve challenges with JavaScript[00:20:25] The refreshing experience of discovering Elm[00:26:13] A greenfield Elm projectCrowdStrike® Falcon LogScale™[00:33:04] Starting elm-reviewelm-analyze[00:42:06] elm-review v2"Implementing multi-file analysis for linters" on Jeroen Engels' blog[00:43:33] Middle names[00:44:40] Humor, coding, & podcastinghttps://postitontheweb.tumblr.com[00:50:19] Challenges with building elm-reviewElm Radio 84 – Writing Great Docs"Pushing unused exports detection one step further" on Jeroen Engels' blog"A tale of failing to design rule boundaries - Data-last functions" on Jeroen Engels' blog

Ryan Haskell-Glatz talks about making Elm mainstream, learning through iterations of elm-spa, and how experiences at Vendr shaped Elm Land.Note: the quality of Jared's recording is off and there are technical difficulties with the video at the end.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.06.05GuestRyan Haskell-GlatzShow notes[00:00:11] Introducing Ryan@rhg_dev on YouTubeElm Landelm-sparyannhg/date-formatryannhg/graphqlGrowing Programming Communities on Software Unscripted with Richard Feldman[00:00:57] A common computing genesisLet's be mainstream! by Evan Czaplicki at Curry On Prague, 2015Seven Seas Remake[00:12:27] Elm at workelm-spa v3elm-spa v6 on Elm Radio[00:20:15] Solving different problems with Elm Land vs. elm-spaorus-io/elm-spa[00:24:03] Scaling an Elm Land projectelm-pagesDillon's elm-graphql["Incremental Type Driven Development"]](https://youtu.be/mrwn2HuWUiA) by Dillon Kearns at Elm Europe 2019[00:33:54] How the experience at Vendr shaped Elm LandMatthew Griffith's elm-ui[00:39:21] Sponsored by Logistically[00:39:55] Success with Elm at scale at VendrElm Town 60 – Productivity and the culture of moving a little bit slower with Wolfgang Schuster[00:43:12] Exciting stuff with Elm Land 0.19Elm Land: The Sai Update (0.19)The Milkmaid (Vermeer)[00:47:49] PicksRyan's Picks"Let's be mainstream!" by Evan Czaplicki at Curry On Prague, 2015"On Storytelling" by Evan Czaplicki at Deconstruct, 2017Jared's PicksElm RadioSoftware Unscripted

This interview was recorded for the GOTO Book Club.gotopia.tech/bookclubRead the full transcription of the interview hereTim McNamara - Author of “Rust in Action” &  Software Developer at AWSRichard Feldman - Author of Elm in Action & Head of Open Source at NoRedInkRESOURCESGet 35% discount on all Manning products with code: ytGOTO35mng.bz/z5RQrustinaction.comdoc.rust-lang.org/stable/bookDESCRIPTIONRust in Action introduces the Rust programming language by exploring numerous systems programming concepts and techniques. You'll be learning Rust by delving into how computers work under the hood. You'll find yourself playing with persistent storage, memory, networking and even tinkering with CPU instructions. The book takes you through using Rust to extend other applications and teaches you tricks to write blindingly fast code. You'll also discover parallel and concurrent programming. Filled to the brim with real-life use cases and scenarios, you'll go beyond the Rust syntax and see what Rust has to offer in real-world use cases.Richard Feldman, author of Elm in Action, goes over the benefits of this multi-paradigm, high-level, general-purpose language together with Tim McNamara, author of Rust in Action.* Book description: © manning.comThe interview is based on Tim's book "Rust in Action: Systems programming concepts & techniques"RECOMMENDED BOOKSTim McNamara • Rust in ActionRichard Feldman • Elm in ActionBrenden Matthews • Code Like a Pro in RustPrabhu Eshwarla • Rust Servers, Services & AppsBastian Gruber • Rust Web DevelopmentBlandy, Orendorff & Tindall • Programming RustKen Youens-Clark • Command-Line RustKevin Hoffman • Programming WebAssembly with RustTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily

Working on legacy code is never easy, but some programming languages make it more enjoyable.  Today, we talk with Richard Feldman, the creator of the Roc programming language, the author of Elm in Action, and the creator of the Frontend Masters courses Introduction to Elm and Introduction to Rust. Richard tells us about the advantages of the Elm, Rock, and Rust languages and why they are more enjoyable to work with than other languages.  When you finish listening to the episode, connect with Richard on Twitter, check out his book and courses, and take a look at the Roc programming language.  Mentioned in this episode: Richard on Twitter at https://twitter.com/rtfeldman Roc programming language at: https://www.roc-lang.org Elm in Action at https://www.manning.com/books/elm-in-action Richard's Frontend Masters courses at: https://frontendmasters.com/teachers/richard-feldman/

Gun policy continues to be a challenging issue to tackle, even though polling shows Americans of all stripes want something to be done about gun violence and mass shootings. One former gun lobbyist says bridging the divide has much to do with how we talk about gun reform. Richard Feldman, of the Independent Firearm Owners Association and a former NRA lobbyist, joins Geoff Bennett to discuss. PBS NewsHour is supported by - https://www.pbs.org/newshour/about/funders

Gun policy continues to be a challenging issue to tackle, even though polling shows Americans of all stripes want something to be done about gun violence and mass shootings. One former gun lobbyist says bridging the divide has much to do with how we talk about gun reform. Richard Feldman, of the Independent Firearm Owners Association and a former NRA lobbyist, joins Geoff Bennett to discuss. PBS NewsHour is supported by - https://www.pbs.org/newshour/about/funders

Is religious disagreement a special case of epistemological disagreement or is it just like any other case? Dr. Richard Feldman argues that it's just like the rest and that's actually a good thing for theisms! If you like this podcast, then support it on Patreon for $3, $5 or more a month. Any amount helps, and for $5 you get a Parker's Pensées sticker and instant access to all the episode as I record them instead of waiting for their release date. Check it out here: Patreon: https://www.patreon.com/parkers_pensees If you want to give a one-time gift, you can give at my Paypal: https://paypal.me/ParkersPensees?locale.x=en_US Check out my merchandise at my Teespring store: https://teespring.com/stores/parkers-penses-merch Check out my blog posts: https://parkersettecase.com/ Check out my Parker's Pensées YouTube Channel: https://www.youtube.com/channel/UCYbTRurpFP5q4TpDD_P2JDA Check out my other YouTube channel on my frogs and turtles: https://www.youtube.com/c/ParkerSettecase Check me out on Twitter: https://twitter.com/trendsettercase Instagram: https://www.instagram.com/parkers_pensees/ --- Support this podcast: https://anchor.fm/parkers-pensees/support

My guests today are Blake Thomas and Richard Feldman. They both work at NoRedInk. Blake is the VP of Engineering and Richard is the Head of Open Source. They have hired a large number of engineers over the last year and are continuing to scale NoRedInk. Video: https://youtu.be/9vdFSCWHV1M Part Two - Technical: To be posted Part Two Audio only: To be posted Spotify - https://open.spotify.com/show/7zvt9QZWMUGsQ27NM8XuMd?si=272649053fbf4c03 Apple Podcasts - https://podcasts.apple.com/us/podcast/professional-technical-interviewee-with-taylor-dorsett/id1557937961 Guests: Blake Thomas and Richard Feldman of NoRedInk LinkedIn (Blake): https://www.linkedin.com/in/bwthomas/ LinkedIn (Richard): https://www.linkedin.com/in/rtfeldman/ Website: https://www.noredink.com/ If you enjoyed the show please subscribe, thumbs up, and share the show. Episodes released on the first four Thursdays of each month. Host: Taylor Owen Dorsett Email: dorsetttaylordev@gmail.com Twitter: @yodorsett LinkedIn: https://www.linkedin.com/in/taylordorsett/ Github: https://github.com/TaylorOD Youtube: https://www.youtube.com/c/TaylorDorsett Editor: Dustin Bays Email: dustin.bays@baysbrass.com

Richard is one of my fave speakers in software, particular in the Elm and language sphere of things. Check out Why Isn't Functional Programming The Norm? and Roc, the new language he's working on!Listen to Software Unscripted: https://www.listennotes.com/podcasts/software-unscripted/crossing-the-chasm-1-dDJwWER37/

This interview was recorded at GOTO Copenhagen 2021 for GOTO Unscripted.gotopia.techRead the full transcription of this interview hereRichard Feldman - Author of "Elm in Action" & Head of Technology at NoRedInkErik Doernenburg - Head of Technology at Thoughtworks & Passionate TechnologistLars Jensen - Lead Developer at GOTODESCRIPTIONWhat would your ideal programming language look like?Erik Doernenburg, head of technology at Thoughtworks, and Richard Feldman, author of “Elm in Action,” sat together at GOTO Copenhagen 2021 to chat about what theirs would look like. They also had a look into the future of up-and-coming languages.RECOMMENDED BOOKSRichard Feldman • Elm in ActionJeremy Fairbank • Programming ElmWolfgang Loder • Web Applications with ElmCristian Salcescu • Functional Programming in JavaScriptTim McNamara • Rust in ActionSaša Jurić • Elixir in ActionDijkstra, Gøtze & Van Der Ploeg • Right SourcingRichard Monson-Haefel • 97 Things Every Software Architect Should KnowThoughtworks Inc. • The Thoughtworks AnthologyJimmy Nilsson • Applying Domain-Driven Design And PatternsTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Discovery MattersA collection of stories and insights on matters of discovery that advance life...Listen on: Apple Podcasts Spotify

Elm is a functional language that compiles to JavaScript and runs in the browser. Lindsay Wardell from NoRedInk joins the JavaScript Jabber panel this week to discuss his background with Vue and Elm. The discussion ranges into how Lindsay got into Elm and how it differs and solves some of the issues that crop up when people build apps with JavaScript Jabber. Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Links elm-vue-bridge (https://elm-vue-bridge.lindsaykwardell.com/) GitHub - lindsaykwardell/vite-elm-template (https://github.com/lindsaykwardell/vite-elm-template) Utilizing Elm in a Web Worker (https://www.lindsaykwardell.com/blog/utilizing-elm-in-a-web-worker) Setting up an Elm project in 2022 (https://www.lindsaykwardell.com/blog/setting-up-elm-in-2022) Lindsay Wardell (https://www.lindsaykwardell.com/) Picks AJ- GitHub: coolaj86/AJScript (https://github.com/coolaj86/AJScript) AJ- Slonik (https://www.npmjs.com/package/slonik) Follow CoolAJ86 Live Streams: YouTube: https://youtube.com/coolaj86 Twitch: https://twitch.tv/coolaj86 Follow Beyond Code: YouTube: https://www.youtube.com/channel/UC2KJHARTj6KRpKzLU1sVxBA Twitter: https://twitter.com/@_beyondcode Charles- Taco Cat Goat Cheese Pizza (https://amzn.to/3jtcuQ3) Dan- Uprooted (https://amzn.to/3E4U0hY) Dan- Support Ukraine Lindsay- Elm Radio Podcast (https://elm-radio.com/) Lindsay- Why Isn't Functional Programming the Norm? – Richard Feldman (https://www.youtube.com/watch?v=QyJZzq0v7Z4) Lindsay- A Taste of Roc — Richard Feldman (https://www.youtube.com/watch?v=6qzWm_eoUXM) Steve- Twitter: Dad Jokes ( @Dadsaysjokes ) (https://twitter.com/Dadsaysjokes) Special Guest: Lindsay Wardell.

Elm is a functional language that compiles to JavaScript and runs in the browser. Lindsay Wardell from NoRedInk joins the JavaScript Jabber panel this week to discuss her background with Vue and Elm. The discussion ranges into how Lindsay got into Elm and how it differs and solves some of the issues that crop up when people build apps with JavaScript. Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=jsjabber&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links elm-vue-bridge (https://elm-vue-bridge.lindsaykwardell.com/) GitHub - lindsaykwardell/vite-elm-template (https://github.com/lindsaykwardell/vite-elm-template) Utilizing Elm in a Web Worker (https://www.lindsaykwardell.com/blog/utilizing-elm-in-a-web-worker) Setting up an Elm project in 2022 (https://www.lindsaykwardell.com/blog/setting-up-elm-in-2022) Lindsay Wardell (https://www.lindsaykwardell.com/) Picks AJ- GitHub: coolaj86/AJScript (https://github.com/coolaj86/AJScript) AJ- Slonik (https://www.npmjs.com/package/slonik) Follow CoolAJ86 Live Streams: YouTube: https://youtube.com/coolaj86 Twitch: https://twitch.tv/coolaj86 Follow Beyond Code: YouTube: https://www.youtube.com/channel/UC2KJHARTj6KRpKzLU1sVxBA Twitter: https://twitter.com/@_beyondcode Charles- Taco Cat Goat Cheese Pizza (https://amzn.to/3jtcuQ3) Dan- Uprooted (https://amzn.to/3E4U0hY) Dan- Support Ukraine Lindsay- Elm Radio Podcast (https://elm-radio.com/) Lindsay- Why Isn't Functional Programming the Norm? – Richard Feldman (https://www.youtube.com/watch?v=QyJZzq0v7Z4) Lindsay- A Taste of Roc — Richard Feldman (https://www.youtube.com/watch?v=6qzWm_eoUXM) Steve- Twitter: Dad Jokes ( @Dadsaysjokes ) (https://twitter.com/Dadsaysjokes) Special Guest: Lindsay Wardell.

Richard Feldman discusses teaching data storytelling with Shirley Wu. ( Full transcripts available at https://sites.google.com/noredink.com/podcast-transcriptions )

On the heels of our conversation with David Wild regarding Ringo Starr's Time Takes Time album, which turns 30 this year, we went a bit deeper. (As if David's great interview with Don Was in that same episode wasn't impressive enough....)Former Tom Petty and the Heartbreakers drummer Stan Lynch (a talented producer and songwriter himself) had the pleasure of co-writing a song for the Ringo album called "Don't Know a Thing About Love."  He got on the phone to share his memories of writing the track with Richard Feldman, enlisting Sheryl Crow to sing on the demo and lots more.Stan has new music on tap for release this year from The Speaker Wars and also, The Chefs, his band with Dan Baird, is readying a second course (read: second album). He gives us an update on both pending releases.Show Notes:Our conversation with David Wild regarding Ringo Starr's Time Takes Time (with David's bonus interview with Don Was regarding his work on the Ringo album).Thanks to Dan Baird for connecting us with StanGeorgia Satellites - Lightnin' in a Bottle: Live in Cleveland 1988Stan is organized.Stan's parentsThe Speaker Wars, Stan's latest band. The Speaker Wars and Andy TimmonsThe Speaker Wars - "Never Ready to Go"Andy Timmons - Electric Truth albumThe 30th anniversary of Ringo Starr's Time Takes Time albumStan's song on Ringo's album, “Don't Know a Thing About Love”Richard FeldmanEric Clapton - “Promises”June Pointer - “Love Calling”The birth of “Don't Know a Thing About Love”Writing for RingoSheryl CrowStan's history with Don WasWas (Not Was) = awesomeGoing to hear the finished songMeeting RingoAll roads lead to RingoStan sitting in with Ringo and the All-Starr BandRingo Starr, the drummerStan's impression of the Get Back documentaryThe demo of Stan's song vs. what ended up on Time Takes TimeNew music from Stan and Dan Baird - the second album from The ChefsSomeone/Anyone Todd Rundgren tribute Was Stan a Rundgren fan back in the day?Stan and The Speaker Wars have recorded different versions of “No Matter What” for a Badfinger tribute

Epistemology is the field in Philosophy that focuses on what Knowledge is, how we know (or whether we know) what we think we know. Get ready to go a million miles an hour with professional epistemologist Dr. Trent Dougherty, editor of the Oxford University Press book "Evidentialism and Its Discontents" available for purchase here on Nile, Mississippi, or whatever river you get you books from. E.g., https://www.amazon.com/Evidentialism-its-Discontents-Trent-Dougherty-ebook/dp/B00AQH7F8W/ref=sr_1_3?crid=3BM8FK58OQ5DX&keywords=trent+dougherty&qid=1645212085&sprefix=trent+dou%2Caps%2C119&sr=8-3 We ask him how we know things, what counts as good evidence, what the definition of opinion and knowledge is, is "publish or perish" good for Higher Education , how does one make it as a professional philosopher , and whether sense experience is required for having knowledge . He lists some of the great names in his journey, including Edmund Gettier, the three "RF"s --Richard Fumerton, Richard Foley, and his dissertation chair Richard Feldman--who were almost as important as the late, great Roderick Chisholm. Enjoy also the personal anecdotes in the last half where he shares how he became interested in Philosophy after his conversion to Christianity from paganism, and how he got interested in Epistemology in particular. Welcome, Dr. Dougherty ! The Republican Professor Podcast Team

Richard Feldman discusses deployments with Will Keleher (ClassDojo), Juliano Solanho & Alec Munro (NoRedInk). ( Full transcripts available at https://sites.google.com/noredink.com/podcast-transcriptions )

Richard Feldman discusses interactive style guides with Tessa Kelly & Ben Dansby (NoRedInk). ( Full transcripts available at https://sites.google.com/noredink.com/podcast-transcriptions )

Richard Feldman discusses teaching functional programming with Anjana Vakil (Observable). ( Full transcripts available at https://sites.google.com/noredink.com/podcast-transcriptions )

Richard Feldman discusses observability with Jessica Kerr (honeycomb.io) and Juliano Solanho (NoRedInk). ( Full transcripts available at https://sites.google.com/noredink.com/podcast-transcriptions )

Both sides of the statehouse continue their debate over the governor's mandates. First, we'll talk with former state health commissioner Dr. Richard Feldman about the current state of this public health crisis. Then, we'll hear from state senators, from both sides, on their stances on those mandates. Finally, we'll hear from Indiana senator Todd Young and energy secretary Jennifer Gonholm as they'll talk about the Build Back Better bill.

The creator of the new Roc programming language, Richard Feldman, joins us to talk about rocking developers worlds' with better tools & paradigms. Discuss this episode: https://discord.gg/nPa76qF

Richard Feldman (Twitter) (GitHub)Richard's Elm book Elm in ActionRichard's Frontend Masters coursesRichard's talk Teaching Elm to BeginnersFind motivationMloc.js conference (by Prezi)Pairing as a way to teach ElmIntro to Elm Frontend Masters workshop exercises are open sourceSouth Park therefore/but storytelling technique"I like teaching things the wrong way and then showing what's wrong with it."The importance of finding good examplesTraining From the Back of the RoomDillon's Elm JSON Decoder koans repoGradual release of responsibility techniqueBrian's JSON Survival Kit bookNoRedInk jobs (looking for Elm and Haskell engineers)Richard's Frontend Masters advanced Elm course and Elm intro course

Lindsay, Steve, Luke, and Solomon talk with Ariel from Maison Futari about using Vue without building a full single-page application. We talk about using Vue with Wordpress and other backend frameworks to build widgets, as well as using Vue to build web components. We also explore libraries like Livewire Inertia to integrate with a Laravel backend. Panel Lindsay Wardell  Luke Diebold Solomon Eseme Steve Edwards Guest Ariel from Maison Futari Sponsors Dev Influencers Accelerator Links Yes, this is how to use Vue JS with WordPress in 3 unique ways Core API for turning any Vue 3 component into a custom element - Twitter Setup a Micro Frontend Architecture With Vue and single-spa Livewire | Laravel Livewire Inertia.js - The Modern Monolith Using Vue JS in WordPress : The 7 clean ways to do it Zapier Maison Futari Courses @maisonfutari - Medium Twitter: Maison Futari ( @maisonfutari ) Picks Ariel- SEO Tips Lindsay- Modern Web Podcast - Elm with Richard Feldman Lindsay- BooksBank Lindsay- NaNoWriMo Luke- GitHub | vuejs/petite-vue Luke- GitHub | alpinejs/alpine Luke- TALL stack Steve- The Bulwer Lytton Fiction Contest  Contact Lindsay: Twitter: Lindsay Wardell ( @lindsaykwardell ) Contact Luke: QuasarCast Twitter: Luke Diebold ( @LukeDiebold ) Contact Solomon: Profaily Mastering Backend Development Twitter: Solomon Eseme ( @Kaperskyguru ) GitHub: Solomon Eseme ( Kaperskyguru ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRichard Feldman - Author of "Elm in Action"Thomas Anagrius - Lead Developer at HumioDESCRIPTIONElm is a purely functional language that compiles to JavaScript in less than 4 seconds. We sat down with Richard Feldman, author of the book Elm in Action to understand how learning to code in Elm can help software developers whether they work with it on a daily basis or not.The interview is based on Richard Feldman's new book "Elm in Action": https://www.manning.com/books/elm-in-action?a_aid=trifork&a_bid=a11d59e7Read the full transcription of the interview here:https://gotopia.tech/bookclub/episodes/upgrade-your-frontend-game-be-an-elm-wizardRECOMMENDED BOOKhttps://www.manning.com/books/elm-in-action?a_aid=trifork&a_bid=a11d59e7https://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/GotoConferences

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

Summary It's been awhile since we have chatted about Elm Lang. Richard Feldman (@rtfeldman), Developer at No Red Ink, returns to the podcast with Conner Ruhl (@connerruhl), Developer Operations at Carfax, in his podcast debut. The two Elm fanatics chat about their experiences with Elm and how it's made their productivity exponentially better. Resources Elm - http://elm-lang.org/ Richards Github - https://github.com/rtfeldman Elm in Action - https://www.manning.com/books/elm-in-action?a_aid=elm_in_action&a_bid=b15edc5c JSAir: Typed Functional Programming in JS - http://audio.javascriptair.com/e/034-jsair-typed-functional-programming-in-javascript-with-alfonso-garcia-caro-richard-feldman-phil-freeman-and-jordan-walke/ JSJ 175: https://devchat.tv/js-jabber/175-jsj-elm-with-evan-czaplicki-and-richard-feldman JSJ 229: https://devchat.tv/js-jabber/229-jsj-elm-with-richard-feldman

The beauty of the web is being able to write in a language you love that'll compile down into JavaScript. In this episode, Justin Ribeiro sits down with web developer and Elm pro Richard Feldman (@rtfeldman) to talk about Elm, a functional programming language that compiles to JavaScript and offers many feature you just may love. Resources and Links http://elm-lang.org/ http://elm-lang.org/try On This Episode Richard Feldman (@rtfeldman) Justin Ribeiro (@justinribeiro)