Haskell Weekly

>> Hello. Welcome to the Haskell weekly podcast. I'm your host, Cameron Gera, an engineer at ITProTV. And with me today is Taylor Fausak, lead engineer. As well as a guest. How you doing, Taylor?

>> I'm doing well, Cam. Thanks for having me on the show this week.

>> So we have a guest. I would love to have you introduce him.

>> Yeah. I'm very excited to introduce our first ever guest on the Haskell weekly podcast. We're thrilled to have him on. Thank you for joining us today. Matt Parsons, author of Production Haskell. Thanks for joining us

>> Hi Yeah. Thanks for having me on. Excited to talk.

>> So welcome. You're calling us from Sunny Denver and we're talking to you from Florida. So we got, like, most of the United States covered here feels good.

>> The important parts anyway,

>> Very true.

>> I don't know. West Coast listeners disregard that

>> We love all people.

>> Yeah,

>> we're inclusive here.

>> Um, but yeah, we are really excited to have our first guest on and particularly talking about this book. But before we launch into that Matt, I feel like you and I share kind of a common history or maybe I'm mistaken and just projecting a little bit. But, um, you have some ruby in your background too, right?

>> Yeah, that's right.

>> The programming language, not the gem.

>> My first real internship was with a startup in Athens, Georgia, doing ruby on rails. And that's kind of where I got my experience building things out with. I learned how to build Web apps from the Michael Hartl's Rails tutorial, and that is kind of poisoned How I look at all Web programming ever since then. So now whenever I look at evaluating something, it's like, All right, I'm gonna build a Twitter clone. We'll see how easy this is.

>> And that's something that rails make super easy and you say poisoned. But I feel like it's probably like Ruby and Rails puts such an emphasis on the developer experience making that as nice as possible. And I feel like that's something that Haskell has some room to improve. Perhaps so pulling some of that is a good thing

>> for sure, I think I picked up the phrase poisoned actually from went to rails conf, 2015, with the company, and we got to see Sandi Metz talk Sandi Metz, said that she was poisoned by small talk and was trying to poison Ruby with it, too. And as far as I can tell, that's like a universally good thing to do is introduce more small talk idioms into your programming language.

>> Yeah, I think Ruby was pretty strongly, um, inspired or maybe stole from small talk quite a bit. So it's seems to work out.

>> From what I can tell, Ruby is this weird combination of Perl and PHP and small talk and all of the rubyists that really care about programming languages really want you to forget that it's not just small talk.

>> They say Don't look under the covers, you know, PHP. You know, that kind of stuff. Leave it alone. Let's just focus on small talk. Well, my background's in javascript, So you know, web app programming?

>> sweet.

>> But now we're in Haskell. So that's that's the good thing.

>> Yes. So, uh, since we had this kind of shared background, I'm curious. What drew you to Haskell in the first place?

>> So when I first started learning how to program, I was doing java at the university and I decided that there were Well, I didn't decide. I found out that there were no java internships in Athens, Georgia, where I was going to school at. So it was like, Okay, well, like if I want to get an internship, I need to use a language that other people use. And I asked people in the startup community the developer meetups what do people actually use. And it came back that the community in Athens had settled on Ruby and JavaScript with JavaScript being more common more available easier to get roles with. So I decided. All right, well, I gotta learn. JavaScript and I picked up a book called Eloquent JavaScript. And that book has right next to each other. Two chapters, one on functional programming and one on object oriented programming. So I read the functional programming chapter, and it was mind blowing and confusing, but seemed pretty cool. And I kind of understood it. And then I read the object oriented chapter and it was mind blowing and confusing, and I didn't really feel like I understood it all. I'm sure most of that it comes down to javascript, not at the time having a good oriented story. So The prototypes were very weird for me to understand. Um, but I decided. Okay, well, it seems like they're these paradigms. I gotta learn the most object oriented programming language. And I gotta learn the most functional, functional programming language. And I looked around and I saw Haskell, and everyone kind of decided that Haskell was the functional programming language. I was like, All right, well, I'm gonna learn that it's gonna expand my brain. It'll be cool.

>> Yeah. And then, I guess for the most object oriented you went ruby slash small talk.

>> Yeah. Ruby, I haven't actually ever worked with small talk. I've read about it. I read the spec. I tried implementing it in rust, but it turns out that's really hard. And so I never actually got that far with, but yeah, I decided to do Ruby. Ruby was kind of an easy one to pick, because, like everyone in the community that was doing startups wanted to program in Ruby.

>> Yeah, I had a similar experience. Uh, not in Athens, but in Dallas, Texas. Um, although I'm surprised there weren't any Java jobs that seems like kind of the safe bet. But there were definitely a lot of ruby jobs very popular with the startup community. Ruby and rails made that type of work. Like you said, write A Twitter clone. You know, it's just tutorial stuff.

>> Yeah, I think I think the main reason there weren't Java jobs is that Athens is just like a tiny community, only about 100,000 people in the city. And so there just was not a tech scene. I think they were, like, maybe for companies Total. And there's, like, one or two. There's I think two tech companies based out of Athens right now that are, like, modestly successful.

>> Yeah, And they're not the big ones like Oracle or Cisco. Something like that?

>> No, they might have 100 employees.

>> Yeah,

>> So, Matt, are you telling me you're a bulldog? Is that what you're telling me here? If you're going to college in Athens, then

>> I never went to a football game. People tell me that I'm going to really regret that for the rest of my life. And I still haven't ever felt any desire to go to a football game.

>> I'm with you. There Matt. I went to UT I was a longhorn. I went to one football game just to say that I had gone and it was okay.

>> I'm a diehard gator. So, you know, for me Bulldogs, you know, they're just somebody to beat every year. But, you know, you ever Matt if you ever find yourself in Florida in October, you know, maybe we can go to the Florida Georgia game in Jacksonville is pretty sweet. That that would be one game that would be cool to go to just because you're in a Pro Stadium. They literally split the field half and half like as fans. So it's kind of neat to see uh, but it's also

>> I wouldn't wanna be right on that dividing line.

>> Yeah, it's very vicious on that line, but any who its back on the you know, it's almost like the divide of, like functional programming and object oriented programming, you know,

>> We need to fill up a stadium

>> Which one is functional programming? Which one is object oriented programming?

>> Obviously, the Gators are the functional programmers just kidding well, I think we take the teams out of that one we Let that be more of the the paradigms that we're really comparing there no, no football teams needed.

>> Of course

>> Yeah, but awesome. Thanks for, uh, kind of sharing that experience. So going you went to the two extremes, which is, you know, pretty cool. I got I got started in the middle with, you know, javascript. So it was like, which one do you pick? Because you can pick either and good luck

>> or both. Same time.

>> You can just Sprinkle them in

>> Matt. Clearly the functional side kind of won out. Um, I know it's a really complicated question, but do you have a feeling of why you gravitated toward functional rather than object oriented?

>> Well, yeah. So when I was working in that in the Ruby internship, I ended up finding that it was easier for me to, like, sketch out a design for a problem in Haskell. And I'd come up with ADTs and come with the basic data transformations. I'd write that out in Haskell, and then I port it all to Ruby, and the code that I wrote that was based on, like, functional programming paradigms in Ruby ended up being like, easy to test, really easy to work with. It was very easy to write. You know, TDD approaches to this highly functional code and by thinking more along the lines of data structures and less along the lines of classes and objects and messages, it was a lot easier to like model problems such that the solutions just kind of fell out naturally. One of the things that we built at that company was a message tree so that, like you could have a text message conversation, and based on the answers, you gave back different actions. would happened on the back end? Uh, the first draft of this was to have an object with mutable state that would update its internal state based on what text messages were received back this ended up being really complicated and difficult to work with. So I replaced it with kind of a trie or a tree of possible messages. And each level in the tree had a choice of messages that it could respond to. And this is extremely easy to express as a nested, sum type and you port that over to Ruby and then the whole thing just works really simply and nicely. Um and so I just kept finding that I was more and more interested in functional programming. I never, ever modeled a problem in Ruby and then tried to solve it in Haskell. And that's partially because I wasn't solving problems in Haskell. I didn't have a Haskell job, but then I got a Haskell internship. My last year I was working with Layer three communications out of Atlanta, and I was getting to use Haskell to solve actual problems. And I never once tried to model a problem in Ruby and then put it into Haskell.

>> Yeah, that's telling.

>> Yeah, it's funny.

>> I just got more and more interested and excited about it. I started giving talks at the Athens developer meet Up Group about it and eventually one of the local startups in Athens actually started building out some services in Haskell is an experiment, and it came time for me to graduate. I talked with the company. I had a few folks that knew me from the community and they were gonna vouch for me. And we're like, All right, let's try this out Let's try to replace more and more of our PHP code with Haskell.

>> Nice

>> kind of been doing it ever since.

>> Cool. Yeah, That's, uh, that's really interesting to me because I feel I have some of the same, um, like I programmed in scripting languages. I would say PHP, Pearl, Ruby, that type of stuff for quite a while. And when I found Haskell, I was really excited because it felt like the kind of natural extension of my brain. Like the way that I model problems matches how Haskell wants me to model them anyway. So perfect match and then. You get all these other auxiliary benefits like you mentioned, they're easier to test. Easier to inspect, Easier to think about. So yeah, Curious to have that parallel track going on?

>> Yeah, I think with I think with Haskell. The thing that's really incredible is that it has sum types and then you're able to say or because in every other programming language, except until very recently, you could only say and and I don't know, like, I have never, ever tried to limit myself to only saying, and in like my personal life ot the communications that I use, But it would be so annoying. I can only imagine how annoying it would be and then That's kind of how we restrict ourselves in our programming environments we're saying All right, well, you're only allowed to say, and you can't say or unless you're literally saying true or false

>> right only for this one data type, can you say or Yeah, Cam and I were talking about this either last week or a couple weeks ago. Where once you have those tools of sum types in general being able to say this or that, you start to wonder like, how did I accomplish anything before I was able to do this? Just seems crazy,

>> right? Unless I'm doing some

>> I have kind of the advantage of, like having learned Haskell within, like having started to learn Haskell within about, like, six months of learning to program at all. And so I literally don't know how anyone uses that I know that there are things like the visitor pattern that you can do to kind of emulate them. But having never had to actually write that code, it blows my mind. It blows my mind that software anywhere works for a huge amount of reasons, and that's only one of them.

>> Yes, agreed.

>> and I think for me like my experience. I started coding in college like that was my first ever experience, even thinking about programming. And at that point, you know, you're learning Java or C plus plus and like it's very object oriented like there's not a ton of functional programming concepts at least taught at the program I was in, Uh, and, like you know, once I had learned I got a JavaScript internship, actually hear it ITProTV like that's where I started. Um, you know, it offered me, like, a little more flexibility than all the, you know, object oriented programming languages. I was used to like C plus plus and Java. Um, but then, thankfully, a couple years later, I was introduced a Haskell Well, Elm and then Haskell and like, yeah, like Taylor said, it's just like you said. It's awesome to be able to really model things in such an inclusive way. Like there's so many ways and things things you can express with Haskell that you just can't clearly express in JavaScript or any of those other object oriented programming languages.

>> So Elm was the gateway drug for you.

>> Oh, yeah, Matt Have you ever used Elm.

>> I have not.

>> Okay, well, if you're interested in front end languages, you should try it.

>> It's a good one. It's funny. I feel like the Haskell community has kind of a complicated relationship with Elm because on the one hand, for many people it is a gateway like it's a simple version of Haskell that can introduce you to the concepts. But the other side of that double edged sword is that it doesn't have all the fancy stuff that Haskell has that people that use Haskell really like like effect systems and monads and all this stuff.

>> Mhm, yeah, the type class system. Not having that. does really trip me up a lot. And then they have one type class. It's called comparable. And you're like, What? What is this

>> Magic!

>> Yeah, I'm familiar with Elm. It seems like a really like it has the most important features for doing functional programming correctly. Like I wouldn't want it. I wouldn't want to take away sum types I wouldn't want to take away, like pure functions on. I wouldn't want to take away like generics or type variables or whatever they have, because I feel like they have like the most important things for it. Um, yeah,

>> it's kind of like the simplest possible.

>> Yes, yes, My take on the front end is that I don't want to do it. And so whatever technology will allow me to push that on to someone else. That's the best technology for me on the front end. If I had to write my own like interactive, single page app, I would want to use probably pure script. My experiences with that have always just been extremely positive. Great community, great language. Libraries are pretty high quality when they exist. And

>> the editor tooling

>> Yes, the editor tooling. It just works. It's amazing.

>> Yeah, Haskell is getting there, but it's a slow process.

>> Yeah, you know, I dedicate about eight hours a year to trying to figure out if the editor tooling situation has gotten any better, and it has not every single year that I've tried to do it.

>> Well, this year might be the one that it changes the year of the Linux desktop and the Haskell tooling coincide.

>> I would love it.

>> Mhm. That's awesome.

>> my problem Is that it always. It always works fine on small projects. It does seem like the size of a project is increasing before the tooling kind of falls over. But I have received I've tried to get it working with the work project at Lumi and it does not work. What happens is it will get through, like, kind of the beginning of the module hierarchy. alright so the stuff that doesn't have any dependencies, you'll get pretty good feedback. But once we start getting into like, oh, I don't know, like the we have about 700 modules in the project. And once you start getting into about module 300 400 the feedback just takes way too long for it to be useful.

>> So what we need is the, uh size that the tooling is okay with to grow faster than the average size of a Haskell project.

>> That's correct.

>> It'll tip over eventually.

>> I can write Haskell code faster than people can release. Fast tooling. Unfortunately.

>> Just slow down Matt. The problem will take care of itself. Write less code. Um, well, cool. I appreciate you, You know, giving us some insight in to How you got to where you are. Um, I wanna turn our attention a little bit now. toward the book that you're in the process of writing. I know that you've been working on it for at least several months now, and you have several hundred pages to show for yourself. But can you, uh, tell us about it?

>> Yeah, absolutely. Um, the book actually started out as a joint project between me and Sandy Maguire. He was going to write all the advanced type level system stuff, and I was going to write another section on other advanced Haskell techniques. And I was, uh, unable to work on the book fast enough. And so he ended up taking his half of it and releasing thinking with types. So I've actually I've had this project on the back burner for a really long time, but I've had a hard time getting started with it until really Until about August of last year, I was diagnosed with ADHD And started receiving treatment for it. And in the intervening time, I'm up to about 400 I think 418 pages.

>> Wow.

>> Yeah, yeah, it's amazing what executive dysfunction can do or not,

>> So the treatment is working

>> Yeah, but the idea initially I wanted to write kind of a book on intermediate to Advanced Haskell that would be useful for someone that had completed something like Haskell Book or Haskell from First Principles or Graham Hutton's book or some other introductory text, and was stuck knowing the language but not knowing how to actually build something useful with Haskell. Because once you understand monads and maybe monad Transformers, you're able to, like, write, code and understand code. But then you're kind of plopped into this ecosystem. That's mystifying. That is just very difficult to discover, despite the presence of tools like Hoogle, which, given a type signature, could give or, you know, some things that will implement that type signature. And so this book. I'm really I'm wanting to say you can use Haskell in industry. You could make a lot of money with it, and it's really cool. But it's tricky. It's different than other systems. It's different than other ecosystems. So what I want to do here is say, I don't know like what the best way is, but I have watched projects work and I've watched projects fail, and this is kind of the advice that I have to have your project work.

>> I mean, I think, honestly, the community needs that Yeah, think from as a programmer myself who you know works in Haskell day to day. And it's maintaining, you know, a relatively large project that continues to grow. You know, it helps to be able to kind of say Okay, what can we improve and why are we going to make these improvements? So I think that would be really beneficial.

>> Yeah, And the Haskell community has a lot of beginner. Resources like you mentioned, you know, Haskell programming from First Principles, Hutton's book and the other one, um, learn you a Haskell for great good and there's Also, a lot of like very expert things like real world Haskell or like you mentioned Sandy's book and many, many others, Um and So I feel like you're feeling an important gap here. where like, Yeah, I can do Haskell in the small But how do I leverage those skills to produce a system?

>> Yeah, absolutely. And I think one of the one of the difficult things about Haskell is that its attributes as a language. It's so much more productive when it comes to just the act of writing software. That part of being a Haskell developer is so much better. And I am obviously biased, uh, in part because I use Haskell all the time and also in part because I don't actually know what it's really like to be a professional engineer with any other kind of language. But I do think that Haskell is a superpower in terms of software engineering, but that's only one part of the system. And so when one part of a system becomes super optimized and super fast, you have to let the rest of the system kind of optimize around this new set point. It's kind of like, you know, when you're writing concurrency code, if you have a queue and that queue doesn't have a limit in its size or it doesn't have any back pressure, that queue can overflow and blow everything up.

>> Yeah,

>> um, at the at the first job, we actually witnessed this kind of in the actual performance of the Haskell code and also in how the team was working. I think I was able to mostly on my own, develop a code base that was around 35 to 40,000 lines of Haskell.

>> Wow, What kind of time frame?

>> Um, I think that was within my first like year of working there. Yeah, it was pretty early, but you know, Haskell, it's just so easy to write code that works, that it was just for the most part. Also, it helps that I was to some extent taking existing PHP projects and transpiling or porting, transcribing them porting them, making them better. But we had one system that I wrote, and it was so much faster than the equivalent PHP system that when we dropped the new system in it revealed a lot of performance problems in every other component that touched it. We had servers that were falling over because they weren't used to having a, you know, back in server that was responding so fast. So we ended up having to actually artificially slow down the Haskell service in order to deal with that problem. Now, eventually, a lot more of those services got folded over into Haskell and that made everything like a lot faster. But you can't just make one part of a system better and expect the whole system to improve. And I think that's something that's, like not, uh, intuitive. It's not something that I think people are. It's It is weird, right? Like you expect. Okay, well, I'm gonna make one part faster. Everything else should get better.

>> Well, or at the very least. Everything else should not get worse. But like you, you know, like you lay out in this example, things kind of depend on a particular level of performance. So if you just completely blow out of the water, they don't know what to do anymore, or they fall over, or who knows?

>> Yeah. And on the productivity side of things, you know, you might you might be a 10x developer if you're using Haskell. But that only applies to the actual code that you write. You have to write documentation you have to care about, like, observability of a feature you have to care about, You know, a continuous integration and testing and all this stuff. And those aren't any faster with Haskell. In fact, I think in a lot of cases they're slower, Um, integrating with like, an error reporting service is something that I've had to do recently and in every other language you just like import error reporting service into your package file. Crazy java metadata Hacking happens after that. Or like, Ruby scripts get rewritten behind the scenes and you just get error reporting. Haskell.

>> None of it is pretty, but it just works.

>> Yeah, exactly. And, you know, in Haskell that's not the case. Um, nothing is off the shelf. Nothing just works. You have to thread in everything that you want to care about. Um I think that that does over the long run give you, like, a better signal to noise ratio. But, you know, it's still annoying that we have to put together our own stack traces for exceptions.

>> Oh, my gosh, you're striking a nerve here because we've been struggling with this at our job as well as, well, where we want to just plug in exception reporting. But we have to remember like, Oh, we forked a thread here, but we forgot to install the exception handler. So those have just been throwing into the ether in the meantime.

>> Mhm.

>> Yeah, I I've It's a problem that I keep coming back to. I want to have, a exception wrapper type that carries just a list of like I don't know, Aeson values. Just some random metadata. You can attach an exception, but it is so tricky to figure out how to deal with that information. Because if you want to do this and you want to attach that information directly to the exceptions, well, now you have to write a special catch function that looks at the exception and tries to determine. Okay, Well, are you what I'm trying to catch? Or are you a version that's annotated with metadata? And I need to preserve that metadata if the exception gets rethrown?

>> We've been struggling. You're hitting all the nerves here because we have this exact problem, not with arbitrary metadata, but just with the call stack. And it's, you know, we have to provide the wrapping and unwrapping and catching and throwing and all this. It's painful and, you know, bringing it back to the larger point. Earlier, we were talking about tooling being bad, and I think one of the reasons that Haskell tooling can kind of get away with being subpar is that it is such a productive language that you can kind of get away without it until you start getting little glimpses of it. You know, like we've been trying out Haskell Language server. And for the few minutes that it manages to work for, some of us we're like, Oh, my gosh, this is game changing. I want to do this every day, but then it crashes it. Sorry, I don't want to besmirch HLS. It's a fantastic project. We haven't had good luck getting it to work at work.

>> Yeah, like you said, smaller projects, it looks works pretty well. It's fantastic. And then we try to bring it into our larger project, and we just have trouble. But, you know, we have hope we're going to continue to try it and do anything we can to help it.

>> Mhm.

>> Yeah. I do think that you're right and that the additional productivity of the language means that we can get away with less. IDE support I actually have ah kind of tongue in cheek law of the universe. It's the law of conservation, of engineering, suffering where if you make one thing nicer, something else will get worse in order to make sure that you're always as unhappy as you can be.

>> Well, yeah, you always gotta aspire to better, right? You know, it's gonna always have something to work for.

>> This sounds like a glass half full glass, half empty type of way.

>> Always a glass half full kind of person.

>> Well, awesome. Yeah, you said so much that I agree with. And I feel like we could spend 30 minutes just talking about each and every little bit of minutia here. But bringing it back to your book it sounds like a fascinating resource and super valuable for the community. Um, I managed to snag a pre release version by advertising in Haskell Weekly. Not everyone can do that. If other people want to get their hands on this, how can they do it?

>> Well, the book is currently available for sale on Leanpub. And so, if you, I think to leanpub.com/production-haskell that will bring up the book sale page and you'll be able to acquire it. If you get it now, you will receive updates. You'll receive email updates. I'm doing a release about once a month, and I'm including a change log and everything. I do You can follow the Twitter account @ProdHaskell and that will also keep you up to date on the status of the book and how things were going with it.

>> Excellent. I'll be sure to include those links in the show notes. So if people are lazy and looking for something to click on, I'll give them just that. Yeah. Um and yeah. Is there anything else you want people to know about? You like your twitter handle or where to find you what you're doing?

>> Oh, yeah. My twitter handle is @MattOfLambda. Um and yeah, I'm on the FP chat slack a lot. So if you have any questions or want help with programming Haskell, hop on there, we'll be able to get you sorted, make sure everything is good and happy.

>> Excellent.

>> Yeah, mostly, though, I'm doing a lot of bike riding.

>> Oh, yeah, Let's talk about that because I'm also a bike rider. Um,

>> This is nowp a cycling podcast.

>> Yeah, maybe we need to spin off podcast, um, It's funny I was listening to another podcast today called the bike shed. But it's not about bikes, it's about programming. Um, but yeah, it's funny. I think that cycling is one of the more popular, like the Venn diagram of cyclists and programmers I think is almost a circle.

>> Yeah, it's interesting. I like it because it's so It's so deterministic. I just got an indoor trainer. Um, that has, like a power meter built in and training with a power meter is about as objective is like lifting weights at the gym and that you know exactly how much work you're doing, man. Like you add the time dimension to power. And it's like the analysis you can do on it is nuts. It's fun. Like I've been trying out all these different apps and checking out all these different ways of analyzing your fitness and your freshness and how much you should train. There's so much there. It's so cool. I spend more time looking at charts than I do actually riding my bike. Maybe

>> you gotta look at the charts while you're on the bike, you know, multi task.

>> That's a valid option

>> that sounds awesome. Mhm. All right, well, I think that'll about do it for us. Like I said, there's so much more that we could dig into here. But I get the feeling reading the book will be a good opportunity to dig into some of those topics. Um, so thank you for joining us today, Matt. I hope you had a good time. I've had a great time.

>> Yeah.

>> Awesome having you on the show

>> this was fun. Thank you so much.

>> And, Cam, you wanna walk us out with the usual

>> where they can find us? Uh, here at Haskell weekly. You can find us on the Web at HaskellWeekly.News. You can also find us on pretty much any social media platform @HaskellWeekly. Um, and obviously sign up for the newsletter if you already have it. If you haven't already that way you can see, um, all the great content that the community is creating and you know we've We've done covered quite a few topics that Matt's even talked about. So, you know, if you're ever interested in what's going on the community, please check out our and subscribe to the weekly news letter.

>> That's the important part. And we are brought to you by our employer ITProTV the e learning platform for IT professionals. On if you go to itpro.tv you can apply the promo code HaskellWeekly30 at check out to get 30% off the lifetime of your subscription.

>> Oh, yeah? Well, thank you guys both for being on the show today. It has been a blast. Thank you all for listening. And I'm signing us out. Haskell Weekly.

>> See you

>> Peace.