Haskell Weekly

>> Hello and welcome to the Haskell Weekly podcast. I'm your host, taylor Fausak. I'm the Director of Software Engineering at ACI Learning. With me today is Cameron Gera, one of the engineers on my team. Thanks for joining me today, Cam.

>> Thanks for having me, Taylor. I'm excited to get back to some podcasting. Uh, today we've got a fun topic. I think it's, uh, A little bit on the void side of Haskell. Um, actually the, the article was called the voids of Haskell by Alexander Granin, uh, who is the author of functional design and architecture. Um, and generally to kind of start out this article is very much like Haskell is great and it's getting better, but there's still something missing. And there's this void in Haskell and that's, you know, the big idea of what we're going to talk about today.

>> Yeah. So, uh, he says the voids and implying there's more than one, but what are the voids that he's talking about?

>> Um, the voids that he's talking about mostly are the voids in the book world related to Haskell and the various design patterns, the various thought processes, the various design choices you can make. And, uh, I think. He actually lays out a really good list of books that would be really nice to have. And so I think we're going to cover a couple of those today, uh, and, you know, give somebody more of a practical resource instead of, you know, a blog post, which blog posts can help you with stuff, but it doesn't give you the big picture of the language and how it relates to the larger, you know, intricacy of the language, because there's things in Haskell that. A lot of languages don't necessarily have, and there's a strong type system that allows you to do and program in a way that doesn't allow mistakes to happen and stuff. So, um, I think pretty excited about the books we're going to talk about today as far as possible books. So for any of our listeners find any of these really interesting. Or you guys read the article yourself, you know, to try to tackle it, see what you see if you can make that book. Because for me personally, I'm not sure what would, what would it take to make a book? Um, what would it make? What would it take for you, Taylor? You think? Yeah.

>> uh, for me to write a book, I would need. No job, I guess it would take a lot of time. Um, but beyond that, I don't know. I've never tried to write a book either. I've written blog posts. And as you mentioned, blog posts, can't go into the same amount of detail as a book. And sometimes that's fine. You know, you can have a really. Precise point you're trying to make or an example. Um, but sometimes it's more useful to have the full worked end to end example, that good gets into all the little caveats and the things you actually have to worry about when you're doing something that's not just a demo or something you're showing off for a blog post. And, um, one of the things I like about what Alexander did here with his posts, It is, he gave a lot of options, right? There's like 20 something blog or sorry, book topics. So he's casting a wide net and there's lots of different people in the Haskell community. And I think there is a lot of potential for good stuff to come out of this.

>> Yeah. And I, and I, as you kind of pointed to blog posts being pretty limited in scope. When you have a textbook, you can generally reference the previous chapters where you said, remember in chapter five, when we talked about this, well, here's. Why that was important, um, because it impacts chapter seven. So the relationships between concepts are much easier to represent in a textbook rather, or a more verbose book than a blog post, because it doesn't necessarily have to be a textbook, but you know, a handbook, you know, we have learned you a Haskell, which is just kind of a step-by-step guide basic. Principals of high school. Um, and they do a lot of like referencing to previous chapters of the book and stuff like that. So, um, that's another great benefit of books.

>> That's a really good point. And you can pull that off with blog posts, you know, like, oh, this is part of a series. Go read the previous posts if you want to find out more. But more generally I think blog posts are intended to be like a drive by resource either. It's something that is approachable enough where you can have the whole thing self-contained, or it's a deep dive on some really niche topic. So. Only people that are already interested in that are going to seek it out and they'll already have all the requisite knowledge.

>> right. Yeah. And you know, back to the point of why he. Was kind of saying there's a void here or there's voids here in Haskell is a lot of the other mainstream languages have a lot of textbooks and a lot of books that reference various concepts, design patterns, and, you know, architecture choices that people can use and pick up. And, you know, there's some for the functional languages, but a lot of them are for the object oriented languages. So when Haskell can create these books, it creates an open door for the functional paradigm to. Kind of move in. Um, you know, I know overall the funk programming world is moving more functional, you know, there's functional, JavaScript, whatever that is. And, you know, there's all kinds of different stuff. That's moving, you know, different object oriented programming languages that are implementing functional design choices, uh, because it's intuitive. It's, you know, Easy for people who have been learning math and it's kindergarten, you know, where you learn, you pick up some algebra. Oh, okay. Here's how these things relate. Here's how, you know, I pass my function. I'm going to pass to another function. Well, it's going to evaluate and give you a result. That's great. Um, and you, and you'll know more or less what's happening.

>> Yeah. And, uh, you know, another, uh, another angle of this, I think that would be interesting to explore is how many papers have been written in or about Haskell? Cause you know, it has kind of academic roots and a lot of the things that people do with GHC to add new stuff to it are part of their PhD thesis. So they ended up writing a paper for it. I would, I would bet that Haskell has more papers. Than most other languages, maybe any other language. Um, but clearly those are not as valuable of a resource for what Alexander points out in here of like a day to day, you know, practitioner more so than a researcher. And that's what he seems to have focused on with these topics.

>> Right. And I think to the, some of the people who may have interest in Haskell kind of shy away from using it in production, because it's got such a research heavy background and, you know, People may feel like, oh, this is only good for compiling results and, you know, enhancing minor speed changes or whatever. Cause as you get know, as hassle gets more and more contributed to there's more of, uh, you know, I guess, or in the academic sense, there's less like major changes happening. On the academic side, it's just like one little thing or one. And so I'm curious if commercial Haskell's really kind of shut conventional Haskell uses shied away from because of that.

>> Would be, um, and you know, major changes I think are still happening, like linear Haskell, or even dependent types making its way in. Um, and I just want to point out that like, for us at it pro slash ACI, um, we are, we shy away from the research heavy stuff, but we still use Haskell and it's been a boon for our engineering organization. So even if you're just doing normal, you know, HTTP, API stuff, Haskell works great for that.

>> Yeah, it really does. And I think, you know, he points to that in his kind of introduction to this post of, you know, Haskell is a really good tool. Yes. It may have higher overhead to learn in the beginning, but the velocity you gain at the end of the day is much greater than the time lost in learning it.

>> So I think we've set the table pretty well here. Uh, do you want to dig into some of these book topics?

>> Yeah. I mean, we've got a whole entire, a feast hero of topics to choose from as well. You know, I think it's, I mean, we have more options and Thanksgiving day, you

>> Yeah. So where should we start? What's our appetizer.

>> um, well, I I'd like to touch on one that. I think it's a very interesting one and something that's a little more hidden. We've actually talked about it on the Haskell weekly podcast before. Um, but it's a book called gain development in Haskell. Wouldn't that be a nice thing to have? You know, you can take it, you can see, oh, Hey, I can make a, you know, a 2d game. This is how this works. Okay. Well, you know, cause. I mean, those are kind of fun. They're, they're an easy way to get in. Right. So like, you know, it's a perfect way for a teenage person to be like, oh yeah, I want to make a game for myself that I can play. Well, okay. Hey, here's this game development Haskell. Everybody loves games. So why not?

>> Yeah, I agree. I think this would be a great kind of starter topic. And one of the reasons I think that is that. For a library like gloss or, um, even SDL, but more so gloss, uh, you can start with nothing and pretty quickly have something interactive up on your screen, like visually interactive, where you can click on stuff with your mouse and see it react. And that to me, I think is a lot more, um, motivating then like writing a command line program that. I don't know, does something, but a game with it's instant feedback is really rewarding to see the progress you made were like, oh, I want to change how that thing looks. I'll make the change over here and then bring it up and, oh, look, it's different now. I made that change happen. That feels good.

>> Yeah, that's what I liked to do. And with Alan, cause it's that front end language that allows you to see the result of your change quickly. Um, it interacts with the code you wrote rather than be like, it's doing something back there, um, in the back end, but I'm not really sure.

>> Yeah. Um, so unfortunately neither of us are game developers. Uh, last time on the podcast when this was a topic, Dustin and Cody were talking about it, and Dustin has some experience with game development. So I'd be curious, uh, you know, he may be a good candidate for writing a book about game development. Haskell we'll have to bug him about that.

>> yeah, I'll make it part of his, uh, annual review process. Hey man, I got this great goal for you, man. I think you should write a book called game day. Well in Haskell, you'll make hundreds,

>> You'll make hundreds of dollars.

>> I can't guarantee thousands or millions, but you know, hundreds,

>> Yeah.

>> you know,

>> but yeah, I don't have much else to say about game development. I think it would be great. And I would love to see it. And I've tried to write some tiny games in high school. So, I mean, maybe I should write the book, but I think I wrote blog posts about them at the time. So I'm doing my part.

>> Yeah. It's not enough to tell her we need more. Yeah. I mean, we don't want you to quit, so you, you're not allowed to write a book. You already said you have to quit your job and that's not okay. We'd be.

>> I protected myself there. So, so the ne the next potential book topic we could talk about, uh, it's a little closer to home for us is test-driven development in Haskell. And I think we probably talked about testing before. I don't think we've had an entire episode devoted to it, but it comes up a lot as a topic here on the podcast.

>> Yeah. Yeah. I mean, test driven development is a big. Big thing around the software industry. Right. You know, anytime you go for a coding interview or you read a job posting it's oh, are you familiar with TDD? Um, and generally they're meaning test driven development. There's other TBDs that we'll get to later actually. Um, but they're talking about this concept of, you know, red, green refactoring and, and you know, the big names in Haskell or in the programming world, you know, Martin Fowler, all those guys have. Written and talked about why test driven fellow it's important. And, you know, with Haskell being, you know, quote unquote academic, I think people tend to not really worry about test driven development. They're more worried about the results. And so we haven't seen that from the academic side. Maybe I could be wrong, but. You know, when you're writing a day-to-day application and something that you're supposed to maintain longterm, um, you know, having a book for test different development Haskell would be really helpful to, you know, understand first of all, like the semantics of testing and at school, uh, really kind of understanding and clarifying the types of tests within Haswell, right. Property unit. Uh, integration, all those kinds of things. You know, you want to kind of expand upon those and how they relate. Um, and also it'd be nice to kind of know how, you know, test driven development works for various like frameworks or, you know, um, things we'll just say libraries.

>> Yeah. I think there's a huge breadth of topics that could be addressed in a book like this. Like you mentioned, just the different types of testing. Would be interesting to cover. And then from there you can springboard into, these are the libraries that can provide, you know, frameworks to write tests of this type in, or that type. And here's why you may prefer this library over that library. Um, I think most people reach for like H spec, but as a beginner, you may not know that. And as an intermediate person, you may not know. What alternatives are there and why may you want to use one of them? Um, and similarly touching on like integration testing in particular, um, you know, if you follow the reader, Tio or Rio, um, kind of framework, how do you test that? And that could also, you know, touch on maybe some of the benefits of effects systems and how that impacts testing. Um, but also focus on, okay, if you're doing IO, how do you actually test that effectively? Um, and that's just scratching the surface of the topics that could be covered here. And there's so much, but yeah, I would love to see,

>> yeah, this could easily turn it into a 500 page book.

>> yeah.

>> maybe we should start with a couple hundred page books to get people. Yeah. A little bit more prepared and geared up for

>> Like some magazines.

>> yeah, yeah. Yeah. I was going to say like, uh, catalogs, you know, like, you know, how like series back in the day would just mail you a catalog with all the things you could buy, you know, maybe we do that for testing Haskell.

>> I like it.

>> Yeah. Well, I was mentioning earlier at the other TDD, um, and this is type driven development with Haskell, which. Is one of the strengths of Haskell is its type system and, uh, really kind of understanding and, and yeah, I guess understanding and grokking are the same thing, but, uh, really getting a deeper knowledge base of how the type system works, how, you know, the type there's tight families there's type, uh, Applications there's type all kinds of type.

>> Pretty much type. It can be a prefix on anything.

>> Right, right. And so why don't we, why don't we take some time and create a verbose book on the type type system and type driven development in a Haskell.

>> Yeah. and not only covering the. Different things you can do with the type system. Like what is the type family, what does it allow you to do? And then also, why might you want to do that? So like I touched on earlier with like affect systems and how they affect, pardon the pun, how they influenced testing, um, you know, for type different development. Like I know about type families, but why might I want to use them? What problems do they solve? What things you know, which states are then. On representable because I've chosen to use type families or J DTS or, you know, uh, functional dependencies or any number of the type based, um, language extensions in GHC and it could be shenanigans yeah. Type based shenanigans. Um, he doesn't list. So in these kind of, uh, hypothetical books that we've been talking about, he lists. Some other books from other programming languages that touch on these topics. And one that I think could be brought up here is not a printed book, but the servant, um, both their like documentation for the servant library and the kind of rationale for why they built it and how they built it and how you might build your own kind of minimal servant style library. Um, because that is some very advanced. Type level stuff, and they do a very good job of motivating why you need each step along the way, like, oh, wouldn't it be nice if you could write something like this, it turns out you can't, unless you turn on this extension, what does that extension do? It does this and here's how it changes the code.

>> all right. So we're just pawning this book off the serpents in the law library, maintainers of that library. Okay, cool. I'm down. Yeah. And I like that he makes a good point too, here in his little, kind of a synopsis of what this book would be about where, you know, there's a lot of languages that have kind of taken bits and pieces of. Haskell's type system and implement engine at their own language. And so it could be nice to kind of show, Hey, this has been in Haskell all along. Here's all the things that Haskell's allows you to do that. Yes, you may be able to do now in other languages, but Haskell's been doing it longer and they're trying to make it better every step of the way. Um, you know, and as we start to come out with newer iterations of the Haskell language, um, right, we've got GA she. 2020, which is a group of language extensions that probably help a lot with the type level of stuff. Um, and getting more examples of how that affects, you know, the day-to-day code, writing of Haskell and what it allows you to do. Cause I think we're missing that and you know, sure. You can read blog post, or you could read the specs for every language extension and how this works, but unless you can see like, uh, end to end example, And something that's walking you through and motivating you, like, like the servant library does and the documentation around it. You know, people aren't going to really dive in and take that direction unless you have a desire to know that, which is if you do that's awesome. Like explore it, take the time, learn it. It's awesome. It's great. We'd ha have you servant here? And we. You know, yes, it was a little bit of a headache at first, but now that we have that type safety, we are grateful and we've really become accustomed to it. And we've kind of forced our hand at learning the type system a little bit deeper. Um, so if we had books like this would be helpful.

>> it would. And, uh, you know, you mentioned like, These, some of these things are already available as blog posts and for the people that are interested in pushing the boundaries of the type system, that material is already out there, they can go read the papers they came from. They can read the GFC documentation, but that motivating example to bring you from why should I care about this at all? All the way to. Man, this is awesome. I'm so glad that Haskell does it. We don't have a resource or even a path of resources that can do that for somebody that isn't already steeped in this stuff. Um, so at this point we've talked about test driven development type driven development. I think there's a third one in this list of domain driven design. So we got TDD, TDD and DDD. So what's DDD.

>> um, So domain-driven design is really the concept that your code and what you write, describe like the complex domains that you're applying it to. Um, so, you know, when you're writing functional programming in functional programming, it tends to be easier to do this. And so, yeah. Yeah. People try to use domain driven design in object oriented languages. It is possible, but they also have a crap ton of resources for it. And there's a lot more examples of things going on out there. And so. We could show improve to the outside world and those other mainstream languages, that high school is the best. Is it one of the best languages to be able to use domain driven design? Um, I keep wanting to say development, but I know it's not. So I somehow keep correcting myself, but you know, those are, you know, because there's no real book out there right now. Not everybody. You know, Nasser's blog posts, and we've talked about those a lot, but it'd be nice to have the full picture. And I feel like a book on it would help.

>> Yeah, I would really like to read a book like this. I have a passing familiarity with domain-driven design. I'm kind of aware of the concept, but I don't think I could explain it that well, um, that being said, I feel like Haskell is an exceptionally good language for modeling domains. So if that's what domain-driven design is about, then I think Haskell excels at it and having a book that kind of lays out. Why that's the case and how to use Haskell's features to effectively model domains would be amazing. Um, but to kind of bolster my own point here, one of the reasons why I think Haskell is so good at modeling domains is that the combination of product and some types along with pattern matching, which other languages have these days swift and rest are, are getting that or have that, um, Those relatively simple tools, make it so easy to exclude impossible states from your program or push them all the way to the boundary. So like when you talk to the database, something could go wrong and you'll handle the error there. But then once it gets into the system, you know that you have a bonafide user or, you know, episode or whatever your domain object is. You actually have one of those things on hand and you don't have to worry about it becoming invalid.

>> Right. Yeah. It's provides a lot of safety.

>> Yeah. And that means peace of mind for people like me, who, uh, came from, you know, I used to program in Ruby doing a lot of object oriented stuff and you Taishan, and it was always, uh, a challenge to know, okay, I have one of these things on hand that says it's a user, but it doesn't have this field set. And this, you know, other fields is supposed to mean this thing, but it means this other thing. And it's like, okay, well, What am I supposed to do with this? I don't know.

>> Yup. Yup. That's the world of JavaScript as well. Yeah. It makes me cry every night. When I think about the past. Sorry, I'm coming back. Let me come back. Oh, okay.

>> it. Yeah. Uh, so should we move on to the next, uh, hypothetical book topic?

>> Yeah. I think, I think this will be the last one. We'll probably cover and we're getting there on time, but, uh, what's the next one there to

>> So the next one is one that I'm excited about, which is event sourcing CQRS and reliable systems in Haskell. And for those that don't know, C, Q, R S stands for a command query responsibility, segregation, and effectively, what that means is you segregate or separate. Your commands, things that change your system and your queries, things that ask the system for information. Um, and this is, uh, well and backing up even further in the title two event sourcing, what does that, uh, event sourcing is like instead of having a database that you update in place, you have a stream of events and as new events come in your view of the current state of your database changes. But your actual source of truth is that stream of events. So a good example of this I think is like instead of a user changing their name and you say, okay, update table users, set name, equal new name, where ID equals one, two, three. Um, that's kind of the traditional way of doing it with event sourcing. Uh, you would say we have a new event that came in that says user one, two, three, changed their name to new name. And that's it. And it's up to you to kind of, uh, collapse all of your events down into one thing that you can look at and deal with like a normal database. So this is kind of an advanced topic, but I think it would be a really fun one to explore and Haskell.

>> Yeah. I think it would mean just from your explanation. It's something that I haven't really heard of or dealt with. So I think. Having a book, maybe I'll, um, I may look into some blog post after this conversation, but, um, you know, trying to have a book that explains this and helps relate it to, you know, really how to implement this in Haskell and how that would work, uh, seemed super interesting. Um, I know we have some, I know they have like ones for some Azure stuff and stuff like that. So they have something along those lines, but it's not, you know, Exactly what we'd like, like it to be, um, especially for Haskell, which.

>> to give a couple more kind of footholds into this area to explore for you. And for other listeners that may be interested event sourcing is also often called Kappa architecture. I think. Um, and that's kind of where the stream of events is your source of truth. Um, and in Haskell, there is a library called acid state that actually implements things like this behind the scenes where you can kind of interact with it like a normal database, if you want to. But the way that it works is by storing. Events. And then checkpointing every so often so that it doesn't have to roll up all the events every time. And it's kind of a crazy way to think about things. Um, but it's actually used in production hacking the official package repository for Haskell actually uses acid state as its primary.

>> you're going to say, ask this date was a song by disturbed, you know, cause I've got down with the sickness and the other guy. State. So,

>> Yeah, it could be.

>> I don't know. Anyways, that's cool. I'll have to check out acid state and stay away from actual acid

>> Yeah. Don't take that as an endorsement. Um, I'm not a huge fan of acid state, but it is a mind-bending concept. So check it out for that reason.

>> so if you want to have your mind bend, go to ass state. Hmm. Now I see why it's named that.

>> Exactly.

>> right. There. It is. Awesome. Well, uh, yeah, I think that does it, I mean, this is a great post by Alexander. Go check it out. There's going to be a link in the show notes. So check that out. Uh, and you know, if you find any interest in any of these or have experience with these, you'll start writing a book. Well, thank you. Just go on. Leanpub charge 50 bucks for it. You know, you'll make 40 bucks a pop. It'll be good.

>> Yeah, I was going to say, it seems like Haskell books have a pretty good track record on Leanpub. So we've talked on this show with Marco, Sam Pellegrini, author of the simple Ascal handbook, which was recently number one on Leanpub and also, uh, Matt Parsons. Uh, and his book I think was at number one as well. So it seems like a good way to distribute Haskell books.

>> go Haskell, go lean pub. I think the Haskell foundation may partner with lean pub to help create more content.

>> Yeah, that sounds like a good idea to me.

>> Yeah.

>> All right. Gamble. You got anything else?

>> Uh, I think That's about it for me.

>> That's all I got to. Well, listeners, thank you so much for listening to the Haskell weekly podcast. I've been your host Taylor Fausak. And with me today, as usual was Cameron Gera. If you'd like to find out more about us, you can visit our website, which is HaskellWeekly.News.

>> Yeah. Yeah, I know you say as usual, but I feel like it's been like every other time nowadays, cause you've been doing all these cool interviews, but anyways, Haskell weekly is brought to you by it pro TV, the e-learning platform for it professionals and also our employer. They would love to extend an offer of 30% off the lifetime of your subscription using the promo code Haskell weekly 30 at checkout, all one word. I'm pretty sure. All lowercase, if not,

>> do.

>> did we ever fix that bug anyways?