What are the benefits of picking up a new language? In today's episode, we're talking to Richard Feldman about Elm and some of the benefits of using Elm both in your career development and beyond. In this part 1 of the two part interview with Richard we discuss his journey into programming and in becoming an author.
Â
Thanks to DeepSource for supporting the show!
DeepSource continuously analyzes source code changes using static analysis to find and fix issues categorized as security, performance, anti-patterns and bug-risks. It integrates with GitHub/GitLab/Bitbucket and runs analysis on every commit and pull request, discovers and fixes potential issues before they make it to production.
Generally available analyzers: Python, Go and Ruby
Plus it's Free to use for open-source repositories and small teams. Check it out and let them know we sent you: deepsource.io/devtea
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.Â
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
What are the benefits of picking up a new language, even if you're not going to use that language directly in your work? In today's episode, I talk with Richard Feldman about Elm and some of the benefits of using Elm, both actually in your job and beyond. My name is Jonathan Cottrell. You're listening to Developer Tea, and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Let's get straight into the interview with Richard Feldman. Richard, welcome to the show. Hey, thanks for having me. So let's say that I am a front-end engineer and 98% of my time is spent messing around with, I don't know, a React app or something. Been there? Somebody tells me, hey, you should check out Elm. I'm like, oh, yeah, I'm going to check it out. And, you know, of course, I'm thinking, oh, this is probably just another JavaScript package. Just another thing to add to my tool set. Why would I be wrong? I don't like to tell people they're wrong so much as, you know, maybe if they're missing some information, I like to try and give them the information. So I'd say what's missing from that analysis is the main thing is that Elm is a programming language. So it's not a JavaScript package. It is a different language than JavaScript altogether. And it compiles the JavaScript so you can use it, you know, in places where you would otherwise use JavaScript. But for my money and for a lot of people in the substantially sized Elm community, it's a much more delightful experience than using JavaScript. So if JavaScript is the only language you've used for front-end development, I think Elm is definitely worth learning because you might find that you enjoy it a lot more. Very good answer. Concise answer. I like that. That's I think that's that's probably going to. Convince me to to dive in. But first, I want to kind of take a step back and ask you about you. I guess we we totally blew right past that because I think a lot of people who are coming to this are interested in Elm, but they're also probably wanting to hear more from you as an author and as an authority in the Elm community. Can you tell us just a little bit of how you ended up becoming a programmer in the first place? Oh, interesting question. So I like a lot of people, I think originally wanted to make games. This is when I was very young and I was always, I don't know, like elementary school. I was pestering my dad and say, like, hey, when can I, I don't know, take a course or something on learning how to make games? I just really wanted to make games. And he didn't want to. Well, first of all, I don't think they're worth such things. This is in the 90s. I don't know if you could just take a class on making games may not have existed, but yeah. He said, look, I'll buy you this book on programming. It was called Learn Basic Now, which I think he picked up at the local bookstore. And I totally ignored it for a long time. And then eventually I got in trouble and was sort of like kicked off the computer for a while. And I was like, well, what if I use the computer to just read this book that you gave me and learn how to program? And he's like, OK, fine, you can do that. So I was like, ha ha. I pulled one over. I found a way to. To get, you know, get out of my restriction on computer time. And then I actually started reading the book and started writing some code and totally fell in love with it. And, you know, now more than two decades later, it's still the thing that I spend most of my free time on. So I really pulled one over on him. Yeah, basic was where it started. That's good. And that's so it seems to be a common pattern for, like you said, for engineers that they somehow. Experience something that they love on a computer. Yeah. For many of us very young. It's games. For me, a lot of it was actually music, music recording. Oh, nice. And so there's there's this moment where you say, hey, wait a second. Like there's there's more underneath this thing that I'm using and I really like to know more about it or I'd like to kind of get closer to the process or something like that. And that seems to be a common thing. Yeah. That's a common pattern. So thank you for sharing that. I'd love to know, you know, in the course of your journey as a programmer, what are some of the high points that led you to Elm? Hmm. Wow. That's an interesting question. I, I'd say, I mean, there was definitely definitely a high point very early on the first time that I used Visual Basic. And Visual Basic is a language that I think people have a pretty polarized view of because some people have really fond memories, maybe with, you know, sort of rose tinted glasses, looking back in hindsight and remembering only the good parts. And then some people who have used it professionally have very bad memories. Fortunately, I was in the first group where I only ever used it as a hobbyist. And I just remember being really delighted that I could actually make a user interface. And, you know, I was in the first group where I only ever used it as a hobbyist. And, you know, at the time, it was a game, but I made some other things that weren't games. But just the feeling of power, I guess, of, of control over the environment and being able to, you know, drag this thing over here. And now it actually looks like that in the running program. And then being able to add logic and code was really cool. And getting to actually see, you know, the results on the screen. I remember making a science fair project. And there were only two people in the room. And I was like, Oh, I'm going to do this. At the time, they were bringing me evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution point, I would say, um, my first internship I had, uh, was actually working on a satellite project. And in that case, it felt pretty good because I guess, um, they weren't expecting much from me as an intern. And I ended up kind of exceeding their expectations. I think because like to give you a sense, like the first job that I had there was, um, refiling CDs. Like they had several hundred CDs that they wanted to move from CD jewel cases, which were kind of thick to CD sleeves, which were a lot thinner. And then they also wanted to redo the label. So that was my job. I would just take the CD out of the case and put it into the, uh, into the sleeve and print out a new label for it, you know, hundreds of times. And at some point I was like, you know, I was like, you know, I could also write code. Maybe you could give me, you know, a program to work on. And, um, it turned out that the CD jewel cases were kind of thick, but they were kind of thin. And then they also had been on, um, sick leave basically, uh, for a long period of time. And I'm there like, well, this person wrote some code and there's a bug in it and nobody really knows how it works. So maybe you can, you know, figure out what the bug is. Like, here's the bug report and maybe you can fix it. And, you know, just, just take as much time as you need to get acclimated to the code base. And you can have like, you know, two days to work on this and we'll see what you come up with. Um, and I, I found the bug in like two hours and it fixed it. And, uh, and they were like, oh, you, you can like really code. I was like, I guess, I don't know. This is my first time doing this like a professional setting. So I didn't really have any benchmark to compare it to, but they kept giving me more and more responsibilities until, you know, by the end of the summer, I was already like in charge of my own project, you know, to go like build new UIs for stuff. And that felt really good just to have sort of validation that, uh, you know, the, the, the time that I've been spending building my little games and stuff, um, actually it's sort of translated to a, like a bigger and more professional setting. That was really, uh, a warm feeling. And I guess the third moment that comes to mind is like a high point before Elm was, uh, jQuery. So I'd done some JavaScript before jQuery and a lot of the, so back then the, the web browser APIs, um, like the, what you could do in JavaScript was very, very limited. It was, there was just not a lot compared to visual basic. Uh, it was quite hard to build anything non-trivial in the browser. Um, with JavaScript in terms of interactivity, the primitives are really not nice to work with. Um, and jQuery was the first example I can remember of getting a really serious API upgrade. Like the tools that I was working with suddenly felt, it felt like I had a lot more ability to make the types of things that were in my head. Like I wanted to, you know, make a UI that worked a certain way and now I could. So I I've often said that to me, the, the three major milestones like front end web development for my money are jQuery react and Elm. And that's it. Like the other, everything else, um, sort of pales in comparison to how much of a leap those were including TypeScript. Uh, but I'm sure others would, there are TypeScript fans who I'm sure would disagree with that, but, uh, for my money, that's what they are. Yeah. Wow. So those, all of those are probably, um, they make a lot of sense. Yeah. For other people who have experienced similar milestones, uh, or, or I guess high points on their way. You know, what was that, what was it like the first time that you picked up Elm and we're focusing in on Elm so much because this is really, uh, kind of your, uh, a heavy domain for you. But, um, what is, what is that initial feeling that you had when you first tried it out was, and it's okay. It's, uh, you know, I can imagine at least initially, you know, I can imagine at least initially, you know, I can imagine at least initially, it could feel very unnatural, uh, coming from something like jQuery or even react, but then talk us through how, how you kind of became acclimated and then ultimately felt like, and this is definitely the next milestone in my, in my development. So, uh, back in the day, so I got into Elm in 2014 and back then it was, I mean, this was like, uh, um, I think, I think it was like six or seven releases of the, uh, of the, uh, of the, uh, of the, uh, of the, uh, of the, uh, of the, uh, of the, uh, of the, uh, you know, a lot of stuff has changed. A lot of the ergonomics are better than documentations better and so forth. Um, but back then the way that I got into it was just, I read this blog post about it and it was called blazing fast HTML and Elm. And it was basically about this new, um, uh, virtual Dom experience for Elm that was similar to react in terms of, um, like how you think about rendering and it had benchmarks about how it was faster than react and faster than angular and faster than everything else. that was popular at the time, including things that are still popular today. And basically, that blog post came with a to-do MVC. So if you're not familiar with to-do MVC, it's basically an app that's designed to have a really, really simple, small specification for building a little to-do checklist application. And the whole point of to-do MVC is that it's been implemented in lots of different languages and frameworks and libraries. So you can kind of compare sort of apples to apples, like, oh, here's the same app, but implemented in these different technologies. So maybe you can look at it in a familiar technology and look at it, you know, the same app implemented in an unfamiliar technology and then be like, okay, I see what the differences are and, you know, where this maps to that and how to do these things in these different situations. So I was familiar with to-do MVC and I saw the Elm one and I just sort of dove in there. I downloaded the to-do MVC app and I just started making modifications to it to try and turn it into a to-do MVC. And I just started making modifications to it. Turn it into something else. And that was how I learned Elm. It was just doing that. And Elm's compiler is very, very helpful. Actually, back in those days, it wasn't nearly as helpful as it is today. But still, there was enough sort of feedback from the compiler that I don't really remember reading much in the way of documentation or like introduction to the language. I think partially because I already had some familiarity with some similar languages to Elm. But yeah, I just, you know, looked at the code and to-do MVC and saw like, okay, this maps to this that I'm familiar with, this maps to that that I'm familiar with. The syntax is a little bit different. And whenever I'd mess something up, the compiler would give me an error. And yeah, one thing led to another. And eventually I had a working application. And I mean, honestly, I think I fell in love with it pretty much the same day that I tried it. It was really immediate. Just like, oh, wow. Oh, wow. I mean, I think I was like, oh, wow, this is a really, really amazing, like moment was I remember after I'd gotten it working, and I'd gotten this like initial, you know, thing off the ground that I'd wanted to build, having just realized that, oh, well, now that I know a little bit about the language, I don't like any of the decisions I made, you know, three hours ago. So I'm going to go back and make a bunch of changes to this. And the wild thing was that after I went back and re-architected everything and just, you know, replaced so much stuff that, you know, it was like most of the code was gone. And I was like, oh, wow, this is a really, really amazing moment. And I was like, oh, wow, this is a really, really amazing moment. And I was like, oh, wow, this is a really, really code base was different when I was done. I was like, ah, okay, I'm happy with how this looks. And now let's bring it up on the screen and see how it runs. And, you know, my experience with JavaScript had been at that point, and still is today. Yeah, right. Like, I'll bring it up. And then I'll see when there's a crash. And then I'll, you know, pull up in the console and look where the crash happened, follow the stack trace, make, okay, that crash there. I see what the problem was, then go fix it, and then go back to the browser and then rerun it and get back to the next crash. And then look at that stack trace and so forth. And then I'll see when there's a crash. But, I mean, the very first time I did this major refactor in Elm, I pulled it back up and everything worked. And I hadn't run, I hadn't written a single test. I hadn't, you know, I was a complete beginner. And just the fact, I mean, once it compiled, it worked. And that's like the most consistent thing when I talk to Elm people is everybody has this experience. Everybody does. I mean, the like, it compiles and it just works. It's not 100% of the time, but it is, it is way more than a majority of the time. I mean, it's shockingly often that like your program compiles again. And even if you haven't written a single test, it just works like no matter how invasive the change was. And that is so hard to go back from. I mean, at this point, I, yeah, I mean, I spent many years being a professional JavaScript developer, but I'm just done. Like, I cannot go back to being a JavaScript developer. So I guess that's a bit of a warning. Like, you know, you might become so spoiled by Elm that you might become a career Elm programmer instead of a career JavaScript programmer. But I mean, no regrets. I love it. It's still my favorite programming language, you know, six years later. Yeah, I think I can trace a lot of that, that love back to that first day. It wasn't something that took a long time to, I don't know, acquire. Yeah. So I'm gonna put on my skeptic hat here and say, wow, that sounds wonderful. What am I missing? Why is it that this thing can't be done? Why is it that I can't do it? Why is it that I can't do it? Why is it that I can't do it? Why is it that I can't do it? Why is it that I can't do it? Why is it that I can't compile and just work? What is different? What's happening here? It's not like the computer is smarter suddenly, right? So what exactly is going on that makes this code? You know, I won't say bulletproof, but that makes it easier to refactor without having a bunch of potholes. Yeah, I mean, it's not magic. It's just design. So Elm is designed based on, number of programming languages that have sort of a long history of having these characteristics of reliability. So it's, it's got a type system, which is like sound and also doesn't give you like null errors, like it doesn't have null, it doesn't have undefined. So you don't have to worry about those. And perhaps more importantly, the entire ecosystem is built around that. So a big difference between TypeScript and Elm, I mean, there are several big differences, but two of the main ones are number one, TypeScript has any, which means that any anywhere in your code base, you could potentially have an any type, which means that it's sort of sneaking around the type checker, which means you can potentially get a crash from that. You can get something where it says it compiles, but then it doesn't work. Elm doesn't have that feature, there is no any in Elm. So that that is not that sort of vector is just entirely closed off. It's not possible to have that happen in Elm. And then the second one is that TypeScript, I mean, the history of TypeScript is that you have all these JavaScript APIs out there, and then you add optional TypeScript typings on top of them. And you know, there's more and more coverage all the time. But it's still somewhat of a patchwork. And in a lot of cases, there are some of these any like workarounds for older design decisions that maybe are hard to type check or, or sort of can't be made to properly or fully type check. But Elm has the luxury of having been designed from scratch around having complete type checking over everything. And so putting all these factors together, what you get is a language where everything is sort of coherent, and it's designed to work together. And it turns out that if you start off with, okay, we're going to have a sound type system, in contrast to TypeScript intentionally unsound type system. And we're going to have no null and no undefined. And we're going to have it be that every API in the whole language going from the standard library to everything that's built on top of it is built in the context of the system. So if you've been able to do that, then you can achieve that, you know, you can have this experience where once it compiles, it almost always just works. And it's kind of surprising that that would be the result and that it wouldn't take, you know, something really magical, some extreme wizardry to achieve that. But it turns out that just having that design coherence, you know, from day one, where you aim for that is enough to get you there. And the ecosystem that's been built on top of that over the years, still preserves that. Yeah. Yeah. Like now, you can you can get way more off the shelf than you could in those days, you know, there's a whole Elm package ecosystem where every single package in it is 100% Elm code. And so it sort of preserves this, this experience, even though the ecosystem is now a lot bigger than it was before. Now, granted, NPM, you know, as an ecosystem is way, way bigger than I mean, the biggest package ecosystem in the world. So there's really no, you know, comparing to that in terms of size. But the the quality level in the Elm ecosystem is just so much higher, because because, I mean, the experience I've had with NPM stuff is like, I install it, and then if it works right off the bat, I'm pleasantly surprised. And if I come back to it, and update it, six to 12 months later, and it still works, I am shocked, because that, I mean, that, but an Elm attached or something, I don't right. But an Elm is the exact opposite experience. Like if I install it, and it doesn't work on the first try, I am shocked. And if I upgrade it six to 12 months later, and it doesn't work again, on the first try, I am shocked. everything just works by default and that's the norm and that's what I've come to expect so whenever I dip my toe back into the JavaScript ecosystem for some older project that I'm maintaining it's always just like a cold bucket of water over my head like oh yeah this is what this is like I mean this used to be my life day in and day out and then I'm like okay alright let me get through this and I'll get back to Elm where things are nice but yeah that's sort of how far I've come now, gotten very used to it So that's so interesting because there's a lot to deconstruct here and to understand what is going on I think there's a few things that you mentioned one is just kind of borrowing from these long standing very reliable kind of design patterns but something stands out to me that I think is really critical to understand and this is something that I believe you've talked about maybe in blog posts or something the idea that most of your code is some kind of typing and I don't mean typing on a keyboard but the vast majority is object types if you want to call them objects just data types really and I think that's a really good idea being passed around and a lot of our pain comes from when we're trying to pass a given data type but it's not the right one and we don't know it for whatever reason we're trying to call a method on a thing and it doesn't have that method as an example and so what I hear in Elm is that, and this is true for some other strongly typed languages that that's just not possible right? It's not possible to have the wrong type in hand you're basically verifying the type at every step or I guess Elm is so can we talk a little bit about how most or I guess talk a little bit about data types and how constructing code with that kind of paradigm in mind how that can change the way you think about code so this is something that I honestly prior to my experience with Elm hadn't thought a lot about I remember much earlier in my career I was a Java programmer and Java is categorically it is a type checked language so you have a compile step where the compiler goes through and every language has a compiler that checks your syntax because it has to so it'll tell you if you've got a syntax error like you're missing a you know, close paren or something like that and it'll give you an error but then some languages additionally have a type checking step so Java is one of those languages JavaScript is not TypeScript is Ruby is not although in a lot of languages that don't have a type checking step there's increasingly it's increasingly common for them to have a sort of add-on after the fact that introduces one so like in Ruby there's Sorbet in Python there's I think it's called MyPy is the popular one not really a Python programmer but and of course JavaScript and TypeScript and there's a lot of sort of historical debate as to I don't know what the value is or is not of that step which I've personally thought is kind of a silly debate to be honest I think a lot of it is people talking past each other and sort of missing the mark and so a lot of the traditional debate goes something like and I actually felt this personally when I was a Java programmer it's like well you know type checking is just a lot of ceremony and it's a lot of slowing you down and it's a lot of spending a lot of time up front verifying things that you know may not actually matter that where you're just sort of trying to appease the compiler and making your code a lot more verbose and you're not really getting that much benefit out of it especially if you're writing tests anyway and then the counter argument goes well tests don't verify everything tests just tell you where bugs aren't but they don't provide any guarantees of you know places that you might have missed with your test cases and so I think that's a lot of time and I think that's a lot of time and you need both you need tests and you need types and I don't think either of those arguments are they don't really resonate with me and a large part of that is because I think you know getting back to what you were saying about like a lot of programming I mean pretty much all programming is passing data from one place to another and sometimes you pass data to a place that causes some interesting effect to happen but a whole lot of the time you don't I mean a whole lot of the time you're just saying like give this piece of data to this function and it's going to return you back to where you were some other piece of data that's you know transformed in some interesting way or represents it in something in a different way so my thinking back when I had just sort of gotten finished with Java I remember having a conversation with someone who was not a programmer and they were asking me I think it was about like a what's one of the big debates in programming or something and I brought up static versus dynamic typing and my feeling at the time the way that I explained it was I said well static type checking is a lot like training wheels and I said well you basically it helps you kind of understand the structure of how things fit together but then once you become a good programmer you don't need that anymore you don't need the training wheels and it's actually you can be a lot faster with the dynamic language which was genuinely how I felt at the time I mean this is like more than a decade ago now but it was an honest expression of you know what I felt was true but subsequently I've sort of come to believe that actually it's actually way more context dependent than that and that the sort of black and white context dependent static dynamic sort of bright line divide is kind of misguided in that it really misses the nuanced importance of API design and of type system design so if I were to rank the programming languages I would most like to use like you know start to finish it's not like among all the languages I've used which is somewhere in the neighborhood of 16 at this point I would not rank them like you know okay first of all first are all the statically typed languages and then followed by that are all the dynamically typed languages last I wouldn't say that I would say I mean Elma's number one which is a statically typed language but honestly Java's pretty far down the list and it's below multiple dynamic languages and a lot of that is because the feelings of like oh typing is so verbose and it's a lot of ceremony that doesn't give me a lot of those you know a lot of it's like stated benefits comes from my experience with Java and turns out yeah I do think Java is very verbose and its type checker doesn't do a very good job of sort of pulling its weight relative to how much ceremony it asks of me and how much time I spend sort of appeasing the type checker but it turns out that's not universal that's not just a property of static type checking that's a property of Java and I think C++ has similar problems where I mean you can even get you know segmentation faults and like memory corruption from C++ programs where the type checker's like oh yeah everything looks good to me so whereas you can't get any of those things in Elm and the type checker doesn't ask nearly as much of you in fact Elm has 100% type inference meaning if you don't want to you can write your entire Elm program without writing a single type annotation anywhere you can just write it as if it were a dynamically typed language and in fact actually the first two chapters of Elm in action like the book I wrote don't mention types at all it's just like chapter one is about basic syntax and you know language constructs like if and stuff like that functions and then chapter two is you build an entire working Elm application without writing a single type annotation the book doesn't even mention the word type at that point I don't think and then chapter three introduces types for the first time after you've already built a complete working application and that is so completely different from my experience with Java that it makes me sort of reevaluate the the usefulness of the entire debate itself there are still languages that are dynamic that I would rather use than Java and then but there are no languages that I would rather use than Elm you know at least if I'm building a browser-based UI since that's what Elm focuses on today's episode is sponsored by DeepSource with DeepSource you can find and fix issues during code reviews using static analysis DeepSource integrates natively with pull request code review workflows on all supported providers like GitHub GitLab and Bitbucket no more digging through linter logs from CI builds it brings it right in to your version control where your PR is and where you're already doing a review each issue has a detailed description of what the issue is and most importantly how to fix it DeepSource helps you auto-fix some of the most commonly occurring issues and DeepSource can also run code formatters like black prettier etc. on autopilot and of course it's configurable so let's say that your team doesn't care about style issues well you can disable this directly from the dashboard DeepSource is free to use for open source repositories and small teams so it's built for you to learn and grow without having to spend a bunch of cash up front to do it head over to deepsource.io slash devt to get started today that's deepsource.io slash d-e-v-t-e-a thanks again to DeepSource for sponsoring today's episode of Developer Tea so I'd like to talk about you know why Elm is focused on browser UIs more from a technical perspective you know is it is it focused on that because it's it's the most succinct kind of in point and then I'd like to know you know how can I take this same kind of philosophy and use it in a back-end language do you have a way that I let's say I'm not a front-end developer at all and I don't plan on being one it's not part of my job you know how can I take some learning from this and apply it to my work but let's say I'm working in totally different language is there something that I can do or is there maybe a plan that Elm you know in the future is going to be ported to some other kind of more general use programming language environment is that a possibility yeah so great question that's actually been one of the sort of one of the most common questions that has been asked of about Elm over the years is like hey when is Elm on the server coming and there's an official like answer in the FAQ but I can summarize it as it's not like something that can be done overnight because a large part of the reason that Elm feels as nice as it does for building browser-based UIs is that a lot of care was put into the design of that so there's a lot of design work involved in trying to figure out like what should server-side APIs look like that sort of feel true to the experience that people have come to expect from Elm and I think the API design piece there is pretty easy to underestimate but also extremely important like I was saying earlier I think API design really is really an underrated thing as far as like how much it contributes to user experience as a programmer but to answer the question of like why does Elm focus on browser-based UIs the short answer is simply that that was the problem that Evan originally set out to solve the history of Elm is that Evan was doing an internship at Google working on Gmail he was actually at the time he was doing back-end work on it as a C++ programmer but he had a friend who was working on the front-end side I forget if it was Gmail or some other thing and Evan had kind of finished his project early and was going over to his friend and talking to him about his project and his friend said hey maybe you can help me out with this thing that I'm working on and what they were trying to do was to add some piece of UI some UI element to the page and this must have been like 2011 2012 something like that and he was trying to vertically and horizontally center it on the screen which prior to the days of Flexbox was an extremely difficult task and Evan had sort of two big memories from that one was wow this is really hard to do this because they ended up concluding you know what maybe we're not going to vertically and horizontally center this after all we're just going to change the design somehow because this is too hard and! experience of what was out there from a historical perspective and he said man there's a lot of stuff that's been around for decades that would make this so much nicer but here I am at Google if anyone has an incentive to make the experience of building websites or browser based UI is really good surely it's Google they have the incentive and they have the resources but they're not doing it the only explanation for that I can come up with is maybe they just don't know that these things are out here that these techniques have been around for so long so he decided to when he finished his summer internship he went back to his undergrad college education he decided to do a senior thesis to try building a language that could implement these ideas for browser based UIs and long story short one thing led to another and he ended up creating Elm and actually he ended up getting hired right out of college his first job was at Prezi and they hired him to because basically they saw Elm and were impressed by it and said wow this actually seems like what we want to move towards because they had this huge legacy Flash code base and Flash was sort of on the way out and they were like uh oh we need to switch to something but we've had like a million lines of code of Flash and if we have a million lines of JavaScript we think that's going to be really hard to maintain so we don't want to move to that we want to try and move towards something that will be better and so they basically hired Evan to sort of productionalize Elm so that they could use it as their Flash replacement but I mean there's a lot of history between then and now but that's sort of the reason that Elm focused on browser-based UIs at first was simply that that was the problem Evan set out to solve yeah it's kind of trial by fire if you're building something that large you know to essentially develop the language it in some ways kind of incubates that language rather than trying to build it in a vacuum and then maybe it'll work it seems like the design or at least like you said the productionalizing of Elm was probably done with very practical problems on the table being solved that's very it's a really interesting kind of progression for a language a lot of the people who are listening to this podcast are probably not going to design a language but it's useful to think about right it's useful to think about that etymology because it certainly changes you know the I guess the ergonomics of that language when you start facing those problems because the language has been more or less exposed to that level of problem and of course since then I'm sure much larger or I guess maybe not larger but certainly many many more very large production projects Elm has been a part of oh yeah I'm actually personally very interested in history of programming and where things come from and C++ as it turns out has a very similar origin story in that Bjarnas Stroustrup who created C++ was earlier on in his career he was working with this language called Simula which was the first language that had objects as a thing in it and he remembered liking Simula quite a bit but Simula was not a particularly fast language and later on in his career he was working on a project where it made sense to use C for various reasons and he decided that what C is missing is a lot of the ergonomics that I remember from Simula and I really liked this concept of objects and I thought having a stronger type checker was actually quite helpful and so he set out to essentially augment C by introducing classes and objects and also a stronger type checker and one thing led to another and he ended up at C++ and the rest is history but it was a similar story where he found himself in this environment where he had a language that felt like it wasn't really meeting his needs but he had experience with other languages from earlier on in his time as a programmer and he decided I want to try and bring some of those ideas to this new environment and see what the result is and C++ has also been quite a successful language yeah that was definitely one of the books that I saw when I was at the bookstore with my dad I would see visual basic books and then next to them was the C++ books back in those days those books were 3,000 pages I really struggled to learn C++ back in the day I remember that it was very hard to this day I don't consider myself a very I am not qualified to be a professional C++ programmer I'll tell you that I never call it luck or missed opportunity I never picked up those books so I ended up learning programming through roundabout way through JavaScript which is a lot of! Today's programming crowd a lot of them entered through something like JavaScript is very accessible language and that kind of thing way more common for sure thank you so much for listening to today's episode of developer team the first part of my discussion with Richard Feldman we will pick up where we left off in the second part of this interview on the next episode of developer team thank you again to deep source for sponsoring today's episode you can get started for free by heading over to deep source dot IO slash dev T that's deep source dot IO slash D E V T E A today's episode was produced by Sarah Jackson you can find all the show notes and relevant links for this episode at spec.fm thanks so much for listening and until next time enjoy your tea