Haskell Weekly

>> Hello and welcome to the Haskell Weekly podcast. I am your host today, Cameron Gera. I'm an engineer at ITProTV. And with me today we have a coworker of mine and my boss Taylor. How's it going, man?

>> It's going good. Thanks for having me on the show Cam.

>> Yeah, man, you know, figured you know, we're in a new year. So happy 2021 everyone. And you know, we got to take a time to look back at what we have come from. You know, 2020 was filled with a lot of stuff. You know, we all transitioned to work from home. We all figured out how to communicate still without in face meetings and figured out how to use Zoom, which some of us are still questionable at. Speaking about myself.

>> Lots of programs we got, zoom, we got teams, we got discord. We tried a bunch of others.

>> That we did, but hey, we're making it through, you know, day by day. And thank you, listeners joining us today, but yes. So today we're gonna talk about a little bit about 2020 for us and then also, uh, kind of dive into a post that was written by Adam Wespiser about lessons learned from a year of writing. Haskell, which is a great post, definitely would encourage you. It's in um, edition 241?

>> 245? I've lost track of the issue numbers of Haskell Weekly, which, you know, you think if anybody knew, I would know. But it's 245. It's the most recent one. So I guess this is ... Yeah. This is from 245. I mean, it was easy when I was on issue, like, seven. But when you're up in the two hundreds, it's been a while.

>> Yeah, we've got, got a lot. So yeah, go check it out. Issue 245 of Haskell Weekly. And This is the 33rd episode of Haskell Weekly Podcast. So, you know, we're getting up there. We're gonna start losing count of these as well. But you know, so today we're gonna talk about this post by Adam, and he actually gives a shout out the Haskell weekly so thank you, Adam. We're glad you enjoy the weekly update of what's happening in the world of Haskell. Uh, you know, it's definitely a kind of a sparse field sometimes. And so we have a place like Haskell Weekly to go and, you know, read articles about Haskell and other functional programming languages. It's kind of nice.

>> Funny you mention that because when I started Haskell Weekly, I was afraid that some weeks there just wouldn't be anything or there'd be, like, two links to publish or something like that. And surprisingly, that has never been the case. There's never been a shortage of content. So, uh, just, I guess, thank ... From me, thank you to the whole Haskell community for writing so much good stuff with such regularity. It makes my job collecting all of it a lot easier.

>> Exactly. Yeah, I would also have that fear. I think of starting some sort of weekly news, uh news, grouping of articles and then not have anything to post. But, you know, Haskell weekly ... Haskell community is coming in strong for us at Haskell Weekly. Um but awesome. All right, Taylor. Well, I want to kind of jump in, um and I want you to kind of share maybe some of the highlights of your 2020 and you know something you've learned, you know, work or Haskell related. Um, that, you know, you were like, Oh, this is pretty sweet.

>> Oh man. You think I would have prepped for this? But questions catch me a little off guard. I'm gonna stall and pull one of the quotes that Adam put in this article that I really agreed with. And I'm not sure that it's something that has changed for me in 2020. But he says that an important perspective when writing code is understanding how it will exist through time and what demands will be placed on it and how the fundamental assumptions that code makes will inevitably change. And for me, and my career is a software engineer. That's something that I've just seen come true over and over again where, like sometimes there's a focus on how do I make this code as clever or performant or whatever is possible in isolation. But really, what's important is like, is it easy to change over time? And even as it passes hands, you know, through a team or something like that, at least in my career, that's the thing that has been important because I've worked on long running software with large teams of people or maybe large is a misnomer. I typically work for startups, so, you know, like less than 10 people. But more than one. That's that's large, I think.

>> Yeah, I Think any programmer knows that, you know, code you write 5 minutes ago is now legacy. Something has changed because we experience that everyday. Working through a legacy API that I've been at ITPro for a long time. I literally just today I was looking at code I wrote in JavaScript four years ago and I was like, wow!

>> You were a different person back then.

>> Yeah, yeah, It's like this is gonna be great. It's awesome. Now it's trash. But that's okay. You know, we've learned and well,

>> And now it's in the trash. So it's where it belongs.

>> Yes, delete over 5000 lines of code today. So

>> That's that's a good day.

>> Good day at the office.

>> So that's my non answer to your question. Cam, what's your answer about 2020?

>> I mean, actually, it's funny because this is something Adam kind of mentioned at one point, um, is using stack or not Stack Well, yes, using that, he does mention that he's been using that. But what I meant to say is he's been using servant or you mentioned servant as far as like some type level shenanigans that you can kind of learn that will, you know, really be helpful in the long run. And I think we've really benefited from switching out API over to servant and slowly moving routes over because, you know, we've been getting documentation for free. We've been getting, ah, lot of, you know, benefits out of switching over to servant

>> Testing for free. Certain types of tests.

>> Yeah, we're testing for free. We get a lot of great benefits from over some of the other. You know, our other API that we framework we use Happstack you know, Happstack was good at the time, but now we've kind of understood the fundamentals of Haskell a little bit better, and we can kind of conceptualized type level shenanigans a little bit more as a team. And so I'm really happy that our team's kind of just taking servant by storm and really, you know, just really creating an API That's a joy to work in. um, especially as a web API.

>> And that, you know, touches on something else that Adam talks about in this post of in general, preferring to write junior code but knowing the team you're with and knowing what they can handle and changing what you write to fit that so for me, you know, one of the reasons that we were using Happstack was that it is. I mean, it's got some complicated stuff behind the scenes, but generally when you use it, it's pretty straightforward. It's just like, write stuff in a monad and it'll work. Um, whereas servant has a much higher bar to clear and you get a lot of benefits from it. But I have been pleasantly surprised that our team, which has quite a few junior engineers on it that are not familiar with Haskell, um has been able to pick up servant and run with it. It's been great.

>> Yeah, yeah, I think you know that Helps to have also senior people on the team that have kind of led the way. Um, and kind of you know demystified some of what's happening, eh? So we can all kind of learn from one another. Um, really? Well, and I think, honestly, 2020 was a year that we had to grow together, you know, in a different kind of way. You know, usually we're in the office, and we're sitting next to each other, and, you know, we always We've been pairs for a long time, but I think at this point 2020 kind of push just to be even a tighter knit group where, you know, we're communicating better. We're teaching each other, you know, healthy habits and just really, you know, helping each other, uh, build together as our company slogan currently is, Uh, but you know, that's you know, that's what 2020 really offered us. So, you know, I'm really thankful for that um, but I think you know, for us as a team, we're like, what? Year two, year three of Haskell writing?

>> Three. Little more than three. Because I joined right after y'all had switched to Haskell and I'm coming up on my third year.

>> Mm. Okay. Yeah. So we're in three years of writing Haskell, and, you know, I think last year was really a year that we stopped worrying about JavaScript code or worrying about migrations from various platforms. And we have been just really solely working on the ITProTV product So I think that was really great. Um, yeah.

>> And I'm sure that, you know, the remote members of our team are very glad that we're remote first. Now, everyone's in the same shoes that they've been in the whole time. So we understand their plight a little better.

>> Mhmm oh, yeah. Um, but yeah. So back to the post too is he He talks about type level witnesses, which he tried out. Hey, had a little little difficulty. Um, honestly, I really never heard of, you know, the type level witnesses. So I really should probably follow the blog posts because he linked to a type level witness blog post. So I should definitely check that out. But do you know anything about that?

>> I don't. I pulled up the blog post, so I'm trying to scan it really quick. If I had to guess, I think this would be about the like, um, ghosts of departed proofs paper where you encode information in the at the type level, so that once you prove something via like a smart constructor, you have evidence of that proof that you can carry along. So the canonical example would be like, um, you have proved that a number is odd. So now your type is odd number rather than just number or integer or whatever. Um, and in general, like, you can do that with new type wrappers for any particular type. But in general, if you want to connect like, uh, refinements or constraints to stuff, there's a more principled way to do all of that. And I think that's what this type level witness stuff is. Although maybe I could be grossly misrepresenting it. So I apologize. If I am.

>> Maybe we'll cover that in another weeks of Haskell weekly podcast here, you know, um, but yeah. Okay. So thank you for trying to give me some insight there.

>> Yeah, and so my my reading of his, you know, hesitation about using type level witnesses is that they are nice and they give you some good things. But the interface for using them is too clunky or too complex or too difficult for him, which I think is a fair complaint. Not just about type level witnesses, but many things in type level Haskell. And, you know, for me, that was one of the reasons I push back on Servant for so long is like Well, yeah, I can see all the benefits, but I'm not sure what all the downsides are.

>> Yeah, yeah, it definitely you with high overhead to understand. Something really tends to rub me the wrong way as well, because I'm like, Well, you know, it's not just me at 'sthat writing this code like it's an entire team. We all need to be able to handle this. And if it's clunky and harder to use like it's just not ready, then you know.

>> And it's not only is it hard to write or use but, like, maintain or understand when something goes wrong. We ran into that the other day with Servant, where we had moved an in point from our old service to our new one. And it wasn't behaving the same. And like everything we could look at was the same. It was, oh, something behind the scenes that servant is doing. It's actually more correct and like, it's good that it's doing that thing, but we weren't aware of that. So it was hard for us to debug this problem because we were looking at our application code rather than the, you know, servant code,

>> right? Yeah. But, you know, with time, everybody kinda can work through those clunks and, you know, maybe Adam in 2021 can, you know, master with, you know, type level witnesses, and you look forward to reading his post next January

>> I finally figured out Type level witnesses, Yes!

>> or maybe. Hey, if you want to write it in 2021 I'm all for it. Definitely down to check it out. Ah, yeah. Um so I think this is something we faced, and we've gone through many iterations of build systems and, you know, we've we're using Stack, but we know it's limitations, and we're we rub up against it. We thought about Nix like, and he kind of mentioned this in the blog post, and he's kind of gives his his two cents per se about it, Um, which I thought was was informative. I think you know, for us we want all the caching we could get so if we could do Nix like we're all about it. But like he says, it's a little complicated until we've kind of, you know, we have some team members who use NixOS and they will not be named they're great. Uh, but

>> names have been changed to protect the innocent. Yeah, I mean, Nix has been like a pipe dream for us for years and not so much like nix the technology but the stuff that it brings. Like you mentioned with caching because we have spent a lot of engineering hours trying to get the caching not only on our local machines, but on CI, uh, to get our caching in a good place with stack so that we don't spend, you know, 15 minutes waiting for a really small change to go through our CI process.

>> Yeah. So you're saying if we could get the cache right, we would save a lot of cash?

>> Very true. Yeah.

>> Yeah, You're welcome. I'll be here all year. Maybe outrage from from viewers. Get this kid off of this

>> We Can't handle those Haskell puns anymore. Kick him off the podcast.

>> He's out of here. All right, Well, then you'll get Taylor by himself because

>> my puns are just as Bad

>> Fair. But hey, at least we've got them, right? Dad jokes for days.

>> Yeah. Um, but yeah, I I liked hearing his take on build systems because it kind of matches ours. Like we're using Stack. There are some things about it that annoy us, but not enough to push us on. Anything else and something like Nix would be great. We could probably get away with using Cabal directly, but Stack gives us some niceties that we want to stick with. Although I was surprised to hear that this, like, flat name space error that he mentions. I don't think I've ever seen that. And we have eight people working on stack working with stack all day every day. Um, so I don't know. He says the dreaded like it's some well known thing I have never seen. Knock on wood.

>> Same. Yeah. Tomorrow. Coming to work tomorrow. Saturday. But come in Monday, and it's gonna be just like, uh, nobody can work today. We're all work through this problem together. Uh, but yeah. So then he moves on from build systems to kind off some of the tools which I guess can play into the build system. Uh, but, you know, it sounds like he's a ghcid fan, which we here it ITProTV are also ghcid fans.

>> Yeah, it's surprising how helpful ghcid is, given that it's such a simple tool like it hardly does anything in principle. It's like if you started GHCi and just hit colon reload over and over again every time you saved a file. But that's really helpful. I mean, GHC is a nice compiler, especially once you're familiar with how it reports errors to you, right? Um but yeah, that, like ghcid by itself is great. So thank you, Neil Mitchell, for starting that

>> Whoo! Yeah, And then we've got you know, something? I think we've tried here. It ITPro At least a few of us have is getting Haskell language server up and going. Um, you know, we've caused some crashes from that.

>> I was going to say it's a running joke that when one of our one of the guys on our team runs HLS, it's like, Well, his machine is gonna crash sometime in the next 48 hours. We don't know when, but it will happen.

>> Yeah, but, I mean, that would work if you turn the machine off every night.

>> But yeah. And this was a long time ago that this, you know, internal meme came up, So I'm sure HLS is better. Um, but we haven't tried it in the meantime.

>> Yeah, Yeah, it's been a minute. Um, because HLS and HIE all kind of merged together, right?

>> I have not been able to keep track of all the naming, and merging, but I think that's true or HLS includes HIE or something like that. Mhm. Yeah, Yeah, they fixed a bunch of memory leaks, and supposedly, it's a lot better and faster now, but I haven't given another chance.

>> Yeah, you know, I just use this little Adam, uh, VSCode plug in called purple yolk. That this guy made

>> I didn't wanna plug my own plug in, but yes, I wrote one called Purple Yolk, and it behaves a lot like ghcid where really it just spins up GHCi in the background and reloads it for you a bunch and gives you the little red squiggly underlines which works really well for me.

>> Hey, More to come in 2021 Probably.

>> Yeah. I might make, like three commits to it this year

>> if we could get, like, a quick jump or something working with it. Uh,

>> well, yeah, I was gonna say one of the other tools that he mentions his hasktags and that has been really useful again. It's like a relatively simple tool, and it doesn't do a whole lot, But just being able to say, like, keyboard shortcut jump to where this thing is defined amazingly useful because I do that all the time And what I used to do was select it and search through the whole project for it. And then, like, oh, no, these are your call sites, not definition sites.

>> Yeah,

>> I'm a cave man.

>> I still I'm stuck doing that because I guess I lost my hasktags configuration or something along those lines with VSCode. But so I really haven't been doing that. I've been doing the control shift f with the highlighted word and yeah, then being like, uh, scroll, scroll, scroll! Oh, there it It's OK, Maybe that's one of my 2021 resolutions. Just get that get away. Working again? Yeah, It's like it's one of those things. Like it broke, but it wasn't a huge inconvenience. Yeah, I don't know. I guess I have a high tolerance for inconvenience.

>> Well, you know, it's a little thing where you don't feel the pain that much. It's like, Oh, yeah. It took me five seconds to find this definition instead of one second. And maybe you don't do that operation enough for it to matter, or it's like, just part of your work flow. So you keep

>> your like, uh, yeah, so anything I definitely think the tooling in 2020 was. You know, there's some major improvements that happened there. Um, for sure. So, yeah. Team ghcid always the old reliable at this point, HLS is the cool, new shiny toy that you know, has a squeaky wheel here and there. Mhm So. But yeah. So then he kind of moves on talking about the release of GHC 9. Done done.

>> Yeah, that's a big one. Which maybe we should do a whole episode on that, But I feel like I'm not qualified for it because the big like, you know, headline release or feature for GHC 9 is linear types, which are really exciting, but I don't really know anything about them, so

>> Okay, it will be good. Maybe we'll learn about it and then talk about it will be good practice. Good. Yeah,

>> but yeah. The first release candidate for GHC 9 was released. Um, I think I installed it on one of my machines, but I haven't really played with it yet.

>> Mhm. Yeah, I haven't at all. Didn't even know there is a pre release version So you know, that's how in the know I am here. Uh, just hosting the Haskell weekly podcast. No big deal.

>> Yeah, I'm kind of into Haskell. Wait. There's a GHC 9?

>> What's GHC?

>> I use Hugs

>> Hugs Not drugs any. Uh yeah. And then another great thing that happened in 2020 that was announced near the end. Was the Haskell foundation being formed? I think that was a big win for 2020.

>> Yeah, I'm really looking forward to seeing where that goes. Right now, it's kind of nebulous, like it is a good thing that it's there and they've secured a bunch of funding and all the right people are involved. But what are they going to do? I want to see what happens.

>> Yes, we can all sit there like pet our cats And with a maniacal cackle,

>> Mr Bigglesworth. Yeah, yeah, but, um but yeah, those are definitely things, like maybe at the end of 2021 we'll look back and say, you know, GHC 9 was this watershed moment for the community. Linear types are amazing and change the world. Um, and Haskell Foundation united all these disparate projects and really helped push the ball forward or push the lift the boat up, Whatever the expression is, rather yeah, row the boat. Get everyone rowing in the same direction. There we go. We got there.

>> Lift. Lift the boat. Uh, rising.

>> Rising tide lifts all boats is what I was going for, but

>> oh, gotcha They're all rising. Tides were just pouring water into the ocean.

>> Yeah, there's too many idioms to pick from.

>> Yeah, you mixed them up. That's okay. We like we like, merged stuff here. Yeah. Yeah. So I'm gonna put you back on the spot again since You denied My last time I asked the question, but what was? Yeah, one thing that sticks out in your mind of something you learned in 2020 can be meta. It could be code related. It could be so

>> So I got something. It's kind of code related, and it's actually my, um, my resolution for this year, and it is to write less code at work. So for those listeners that aren't employees of ITPro um, I I manage the team of engineers here, but I also in the past year and my whole time here, have done a lot of engineering myself, and I've found that, um, it can often I often use that as like a short cut of like, I know how I want this done, so I'll just do it. But that kind of robs everyone else on the team of that opportunity of poking around and trying it out and seeing what works and what doesn't work. So one of my goals for the new year is, to Let my team explore the space of how to solve problems, and I'll be happy to give direction and coach. But I want to write less code at work.

>> Can I have that resolution too?

>> the whole team. Can't write less code. Or maybe we can. Maybe that's what we should go for

>> it. Yeah, just minimalistic. I mean, no just kidding. No, I think there's a lot to learn in 2021. Looking forward. To writing more code? Yeah. Solving more problems.

>> Yeah. Oh, that reminds me. Um, I gave up on the advent of code on, like, day 22 or 23. We were talking about that. on I think the last time we recorded How did you do on it Cam?

>> Chuckles just chuckles. I mean, if you count getting through day four. Part one is a win, then, Yeah, I think it's further than I made it in any other years of advent of code. I think I totally skipped it in 2019 and 2018. I did like, a couple of days. It's just hard to like, Yeah, I didn't have a ton of, like, you know, here at the house. We've got a new puppy. We were doing home renovations. So, like, doing stuff outside of work is generally not coding So

>> it takes a surprising amount of time. Even if you're good at those types of puzzles You still have to, like, read it and understand what it's asking and try it out and debug it. And, you know, then you want to write, you know, make your own code better and all that. So, yeah, it's it's a big time commitment.

>> Yeah, it wasn't Wasn't ready for it. Yeah, So maybe I'll prep everything next year and just be like, all right. From December 1st to December 25th, I code.

>> I got an hour a day blocked out on my calendar. Don't interrupt me.

>> Yeah, just take off time of work. It's like, take my sick, sick days like an hour every day

>> spread one sick day over a whole week.

>> Yeah. Can I make that work?

>> We'll see. HR has to weigh in on that.

>> Fair enough, But yeah, so you know that's 2020. Now we're heading into 2021. And, you know, we've got a new slew of opportunities for Haskell weekly podcast, and we actually also would love to invite any of our listeners or blog post authors who are interested in maybe sharing what they have to say on Haskell podcast we love for you to reach out. Um, Taylor, where can they find us?

>> Yeah, I was gonna say, uh, we have mentioned that before, kind of in passing. But really, if you want to be a guest on the podcast, if you got something to say or if we have grossly misrepresented one of your own blog posts, please come on and correct the record. Uh, and you can find us at Haskell weekly dot news or you can email us at info at Haskell weekly dot news or Twitter. Our handle is Haskell Weekly. Those are all the best ways to get us or on GitHub. Our user name is Haskell Weekly, and you could make an issue on the repo or pull request or whatever. Um, any of those places I will hopefully notice and get back to you.

>> Yeah. Or you can look up Taylor Fausak on Google. Find this phone number and call them.

>> Please don't. Hopefully my number is not online, but screen all my calls.

>> At this point. I feel like everything's online. Want. Want

>> somebody will try to call me on key base or something,

>> but shell phone just you know anything? Let's not get into song here. Uh, yeah. No. So thank you. All listeners who joined us today. We really enjoyed having Taylor on the show. Thank you again, man.

>> Yeah, thanks for hosting. And, uh, you know, hopefully my another one of my resolutions here in 2021 is to actually record one of these podcasts every week. We did pretty good toward the end of the year last year on, we did pretty good when we started, but there have been some big sabbaticals in between. So this year, hopefully we'll do better.

>> Hopefully, this year will be consistent because, um, you know, our sponsor ITProTV is allowing us to do this. And so we wanna thank them. Um, they also want to thank you for listening. So if you're interested in ITProTV the learning platform for IT professionals, I encourage you to goto itpro.tv and see what we have to offer. And if you're interested in a subscription, uh, there is a promo code available to you. It is Haskell Weekly 30 that you can put in at check out, and that will apply 30% off the lifetime of your subscription, so we would definitely encourage you to check it out. And we really appreciate you being on today. I think that's all I've got anything else to add? Taylor?

>> Uh, that is it. Happy hacking, Have a good year and adios

>> Peace.