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. And I'm very excited because today we have a special guest: Andrew Boardman, the Executive Director of the Haskell Foundation. Thanks for joining me today, Andrew.

>> I'm really glad to be here.

>> We're really glad have you, so, uh, let's get right into it. And, uh, could you tell me a little about yourself? Let's start with that.

>> Yeah! I've been in the industry for a very long time at this point. Um, I have a background, mostly in C, C++ kind of lower level programming. And, uh, a lot of emphasis on communication technologies. So I do a lot of work on instant messaging technologies. And I did some on desktop publishing, desktop publishing some on, Oh boy, let's see. Um, Vector graphics programs. Uh, for a while, I was a tech lead in the Windows build lab. So the lab that actually builds the daily builds and the golden masters for the Windows operating system.

>> That's cool.

>> Yeah. Worked at, uh, Quark software, which did the desktop publishing software. Uh, I did, uh, a little over six years at Microsoft. Working in a variety of different divisions on a variety of different projects, mostly instant messaging. And, uh, I came to functional programming, sort of by accident. So, uh, I'm also a serial entrepreneur and in one of the, uh, one of my companies, I helped hire a guy out of the University of Washington PhD program. And he came and he did some amazing work for us, and he knew a lot about functional programming and tried to incorporate that into one of the startups that I worked on. And I said, great use whatever tools you want. That's not as important to me as what you produce. And a little bit later I tried using it. And for the first time I was able to do a nested loop without bugs on the first attempt. And that was kind of an eye-opener for me. Uh, and then after that, uh, I, I was curious about the state of research in computer science. So I've been very focused on how you do things like how you build a software processes, how you manage people and less about the technical underpinnings and some of the theory. And honestly, at that time, I didn't think the theory was all that important. But what I tried to do was figure out how are we going to solve the really big problems in computer science? How are we going to solve problems like concurrency, fault tolerance, realtime systems. Uh, the, the things that have kind of stymied the industry for a long time and particularly as CPUs become multi-core instead of faster on the Silicon. And Moore's law seems to be kind of getting to, to its end. Uh, we don't have really great stories in most programming about how we're going to take advantage of those multi-cores in a way that isn't just running multiple programs on the same computer at the same time, having that work better. Having worked on operating systems and build systems. Threading and parallelism and concurrency are critical to solving some of the harder problems. And they're really tough. Like if you've ever done a lot of mutex and semaphore kind of coding, you know, how brittle that can be and how difficult it is to actually debug it. Especially when you have to have something like a kernel debugger to figure out what's going on at the very lowest levels of the operating system. So looking into that, I found functional programming as one of the approaches in research that was the most likely to tackle these problems in a serious way. And being me, I went for the functional-est of the functional programming languages and thus found Haskell. Uh, I, you know, I, in my career, I've learned maybe three dozen different programming languages. Um, some of them are industrial like C, C++ I did. I learned Turbo Pascal, and that's where I did some of my first serious programming a long, long time ago, but I also have friends who made little toy programming languages for various reasons. Uh, one friend of mine, uh, created MOO the MUD Object Oriented programming language. Yeah. Turned into LambdaMOO, which was a PARC project. Uh, and it, you know, all of these different languages were imperative in different forms. Sometimes they kind of touched on little bit of functionalism here and there, but it was basically imperative and Haskell was the first one that really kicked my butt. I had a hard time from that imperative to functional, uh, mindset change that you have to do. And between different syntax that I've really used before, and that mind shift, it took me a long time to really dig in and figure out what was going on. And it kind of renewed my interest in programming in a way. Uh, because it'd been a little stale, like if I learned a new programming language, okay, this is another one. It's just different syntax over the same concepts. I'm not sure why they made this new programming language, but fine. I'll go ahead and tackle this. Haskell was fundamentally different and, and functional programming was a fundamentally different approach. And, uh, that difficulty was also one of the things that hooked me and, and made me really want to dig in more. And then in addition to that, um, it was actually solving problems in really interesting ways. And, uh, the lazy evaluation, uh, and the, the ways that you can avoid recalculating the same value over and over by storing things, in thunks. Like th this, this was an approach that was actually addressing the problems that I had identified.

>> Right.

>> And then, so I tried to do a startup based on that. Uh, it didn't work out, but not necessarily for Haskell reasons. Although I do have to say trying to learn Haskell by yourself. From first principles, uh, with just books and stuff. Is a very difficult thing, like getting into the community, getting on IRC or the FP Slack or, or any of these where you can ask questions of people who've been there and done that before and, and enjoy mentoring new people. It makes it so much easier and highly recommended. But I tried to do it by myself and it didn't really work out. And then I did some other consulting for awhile in embedded systems of C++. Then when that contract started winding down, because the company started winding down, I looked for a job in, in Haskell. Like I figured if I'm going to have to get a new job, why don't I try to learn how to do Haskell and production? Why don't I try to do something for real. And, uh, took a couple of stabs at it and SimSpace bit, and, uh, had a wonderful two and a half years at some SimSpace. And, uh, when the, when the job opening was announced for the Executive Director of the new Haskell Foundation, my first reaction was, this is my dream job. This is absolutely my dream job. I won't ever get it, but if I don't apply, I certainly won't get it. So I'll give it a shot. And to my amazement, I got shortlisted. And worked on my presentation and my, my, uh, my vision statement and put, put my heart and soul into that and then gave the presentation to the interim board. And then to my absolute amazement, I was offered the job. And, uh, haven't looked back since.

>> Congratulations! Always a good thing to land your dream job.

>> I think so.

>> Um, so yeah. Thank you for sharing a little about yourself and your story and how you got here. Uh, there were a couple of things you mentioned that I wanted to dig into a little bit before we move on. Uh, the first is that coming from a Windows background, I feel like Haskell itself is kind of a strange choice. And, you know, maybe for a while, it had not the best story on Windows. And I could see, I don't know what the timeline was. I don't know when F# came into being, but. That could, that could be, you know, a appropriate windows choice. Um, but that being said, one of the things that you mentioned about Haskell that was appealing was that it's like the most functional of the functional languages. So languages like F# or Scala, you know, they make a lot of concessions to other paradigms. Um, so I guess, it is that pure functionality what drew you to Haskell or was there, was there anything else going on in that consideration?

>> I think that the pure functionality is a big consideration because when you have that purity, it is not the pejorative purity. It is purity in the sense of how the runtime system evaluates things and the assumptions that that runtime system can make. And so, uh, for example, uh, one of the things that I keep hearing about is how STM is this game changer. You know, the killer app for Haskell and the more I dig into it, the more I believe that to be the case, STM was tried in other languages. It's, it's not unique to Haskell, but the implementation in Haskell is unique. Because the choices that have been made in both the structure of the language and the runtime mean that you can get a real implementation of STM that doesn't have a bunch of warts. And, uh, as, as the, the folks at TypeClasses.com say like, it just works. Like you don't ha it just works. You don't have to think about it. You don't, it's not, in some ways, it's not a sufficient problem to garnish a lot of attention because you just, it's just the thing that you use and then it works and then you move on with your life. And I think this is kind of true with Haskell in many ways. We take for granted so many things in Haskell that just work and they work great and you don't have to think about them. And then we get to focus on the problem areas that we do have. And I think people over-focus on those problem areas in some sense, when they're evaluating the language, because they're not, you know, you don't see the things that just work.

>> Right. Yeah. I, I, I'm familiar with the Type Classes article that you're referencing, where they're, you know, writing about software transactional memory and what it means and how Haskell does it and why it works so well in Haskell. And I like that, it's kind of the, um, Yeah, it works so well that you just take it for granted. And so many things in Haskell are like that. And like you said, uh, that can cause people to, over-focus not even people new to the language, but people that are really familiar with it, you know, you get these little paper cuts and you spend all your time complaining about them because everything else works so well. Uh, which in a way is kind of good, but also kind of gives the wrong impression to people that may be new.

>> And what we want to do with the Foundation is actually address those paper cuts. Uh, and it's not so much. I see the, the, the purpose of the foundation isn't to solve all the problems. The purpose of the foundation is to bring the community together and focus the efforts to make sure that we make significant progress on some of these areas. So in, you know, we have issues with CI, we have issues with our builds and, and the reproducibility and increment ability of those. So what we need to do as a community is focus on those problem areas. Stop having wars between different points of view and communicate, and really come up with what is the right solution for the overall community. And I think that the Foundation has been exceptionally, uh, I think that we've been very successful at that already. So we we've brought together a number of groups that have been at odds in the past. And getting them to talk constructively together and actually figure out what the right solution is. And I think we'll continue to do that. And I give a lot of credit to that, to our CTO, Emily Pillmore, who is doing a fantastic job of taking the technical approach of, okay, here's our big problem. And here are the right people to get into the room to talk about it and figure out the solution. Hash out the solution and then try to figure out how to make the technical changes to get it done.

>> Yeah, it seems to me like she has done an excellent job of that so far. And the Foundation itself has only really been together for a few months, right?

>> Yeah, we started full time, uh, two months ago almost to the day. So, you know, overall we have not been in existence very long, but I think that we already have a lot to show for, for what we've done. And, uh, you know, one of the things you can get into very niche, nerdy areas with, with Haskell in general, but with programmers in particular and, uh, you know, our, our text UT-8 proposal is one of those cases, right? So the idea is that we take our internal text representation from UTF-16, turned it into UTF-8. Most of the time, UTF-8 is the correct solution. It's not only smaller because it encodes in a more compressed format. But, in most use cases, it's going to be more performant. And when you think about data locality, you don't want a giant chunks of memory, when you can have it in much smaller chunks of memory. You still need the UTF-16 representations, and we're not talking about getting rid of them. But those are more for special cases where you're taking something from maybe an older encoding. Uh, especially like an East Asian encoding and trying to turn it into a UTF kind of encoding. And in those cases, maybe the, uh, the default performance will degrade very slightly, but on the other hand, almost all the other performance will get significantly better. So this is just something that, that has needed to happen. We needed to get the right people into the room to make it happen. And at this point we have a plan on what we're going to do.

>> That's excellent to hear. And I know that's one of those paper cuts where I have heard about it a lot. And based on the volume of complaints, you might assume that it's some huge problem that like text performance in Haskell is abysmal because of UTF-16. But that's not the case in like, as I understand it, Windows uses UTF-16 behind the scenes or something like it. So it's not a completely unheard of. Um, but yeah. Thanks for giving an overview of that. Uh, what other kind of irons in the fire does the Haskell Foundation have going on right now?

>> Well, you talked about, uh, Windows support. And, uh, we are really, this, this is an area that has been interesting. So Windows has been something that has been supported by, by GHC and the Haskell community more or less for a long time. But clearly the compiler was built on Unix and it's kind of a Unix first situation. So getting this tool set onto Windows, which is these days, what I run. I, I come to, I did work at Microsoft for a long time, but I was also an extremely early Linux, adopter and Mac programmer before I was a Windows programmer. And, uh, uh.

>> Got all your bases covered.

>> Yeah, I got, I've done basically all of them. I like the Windows platform and having worked on Windows itself, I understand the technical excellence that's going on inside the kernel. It's just different enough from Unix that trying to do something Unix-y on windows is difficult. There's, there's a lot of friction there. And right now, that was interesting, right now. Um, we sort of have this, this almost emulation layer between the way GHC wants to talk to the operating system, which it assumes has Unix style to figure out how to make that work on Windows. Uh, we would like to fix that, but that's a longer term thing. That's a, that's a pretty massive change. In the shorter term, we want to make it easier to just install GHC and get it up and running on Windows. Uh, and so, Emily again, has gotten a bunch of experts in this area together to figure out what the right choice is. And I think we have a plan on that as well. It's not the slickest thing. Like it's not, it's not just simple, unfortunately, because of the ways that that GHC has been developed. And not just GHC, but the libraries. So there's a lot of libraries out there that are very fundamental to the way that people build Haskell applications. That assume Unix as well. So we've got a lot of work to try to make uh GHC a Windows, uh, native, if you will kind of, uh, program. I think we'll get there eventually, but that's going to require a lot of work. Uh, probably a lot of money, uh, because there's, there's just going to be going out and finding the right experts and, and trying to get them to do it. I don't think that there has been historically enough volunteer effort to, to make that viable as a 100% volunteer project.

>> Right. It, it sounds promising. And, uh, it does seem like a lot of the volunteer effort, people that are interested in Haskell as a hobby typically are on Unix or these days maybe even Nix, uh, or macOS so you don't get a lot of that non POSIX representation. Um, that being said, similar to you, I have, you know, right now on my desk, a Windows PC, Linux PC, and a Mac laptop. And I use Haskell on all of them. And most of the time, almost all the time, in fact, it just works. So again, like this is one of those paper cuts that maybe gets talked about a little too much. So, um, but I'm happy to hear that the situation will be improving.

>> Yeah. If you can, if you can figure out how to install it, it generally works really well. I think the, the, the group that, that has built Stack, uh, Michael Snoyman and company have done an excellent job. They've got one approach to how they do the installations that, that makes it work, uh, quite well. And it may be that we adopt most of their approach, uh, in general. But it could get better. And, you know, it's, it's that once you get it onto the machine, then it works. But I wonder if there is some selection bias there. So if it is difficult to put it onto a Windows machine, Therefore people who are very Windows centric, try it out. They get very frustrated. They don't do it. We don't get a lot of them in the community.

>> Right, they bounce off.

>> My, my hope, you know, w as, as the, the Haskell Foundation, we are trying to drive more adoption of Haskell. One of the ways that we can do that is by making it easier for more people to bring it up and install it and try it out. So one of the big reasons that we're making this effort in the Windows installer is to try to make it easier for people on Windows to use Haskell so that they can get involved. And then maybe if we get that, if we can get that snowball kind of started, then we'll get more and then we'll get some people that are very passionate about Windows. And having Haskell on Windows and then they'll volunteer and it'll just get easier and easier after that. That that is definitely our goal.

>> Sounds like a virtuous cycle.

>> Yes.

>> Yeah. Um, so that, that sounds again, very promising, very exciting. And, uh, it sounds like one of the ways that people could help with this, and other things in general, is to, you know, be more active in the community, and try to onboard, you know, evangelize a little bit, I guess. Um, but what are some other ways that individuals could help out? Uh, both the Haskell Foundation and the broader Haskell community.

>> Well, there, there's a few different ways. So volunteering is clearly the biggest way. If you can put your time and energy into it, you're going to make the biggest, uh, biggest change. Uh, but it doesn't necessarily just mean coding. And so one of the ways that you could help is by finding an open source project that you are particularly passionate about or interested in, or curious about and volunteering to help. Make changes to that. Submit some PRs. That's one way to do it, but there's also a big need for documentation improvements and updating. So, uh, we have, uh, one of our board members who is doing a fantastic job of rallying the community around updating, improving, fixing the documentation. You know, if you go to Haskell.org, there have been historically a lot of dead links and, uh, dated material. And so they've been going through and fixing the links and updating material and making it much more friendly for people to come into the community and find the resources that they need. Uh, one of the things that we're trying to, to spearhead is a sense of community. And in particular, we would like people to volunteer, to become community moderators. So that when there are conflicts, when there are people that are, uh, either arguing or not treating each other well, that we have some way of resolving those conflicts in a way that is consistent with the Guidelines for Respectful Communication that Simon Peyton Jones, and the GHC steering committee came up with, uh, and are foundational to the Haskell Foundation. So one of the things that I would like to do, one of my goals is to get volunteers. Both in the core Haskell Foundation community, as well as affiliated communities to have training on conflict resolution, situational deescalation, uh, active listening, and a lot of these techniques that are well-known throughout the industry and other industries. Uh, but having those skills is something that's great for you personally. Uh, and it means that our community is better off overall. So we're exploring ways of providing that training. Uh, I know some materials that people can look at today to start acquiring those skills, but I think training with a mentor also makes a big difference.

>> That sounds very, uh, exciting. I am a moderator of the Haskell subreddit, which is not, you know, an official community and not associated with Foundation in any way. But, um, that's one of the things that I have struggled with in that role as well of, seeing a thread develop in a direction where you kind of know where it's going to end up and it isn't going to be productive. But maybe lacking some of the tools. You know, in my own repertoire to deescalate that in a way where people don't feel like they're just getting shut down, but that, you know, w we all know where this is going. Let's not, you know, snipe at each other. Let's be productive.

>> Yeah, I think we, we want to assume good intent most of the time. And oftentimes, it's not bad intent that causes these issues. It's the communication styles that rub the wrong way. Or it's somebody who makes assumptions and those assumptions are not warranted. But how do you help them realize that they're making assumptions about this other person or that person's intent? We see this on a regular basis, sadly, where, uh, somebody will step up. They'll say, I want to help make a difference. They start trying to, to take action in the community to, to make things better, and then somebody will get defensive about it and make assumptions about their intent, make assumptions about what they're intending to do, and then react negatively. Uh, ideally, you know, it's one of those classic, like if you have nothing good to say, don't say anything at all. But, once somebody starts down that road, if you have the skill sets, you can deescalate the situation. You can say, Hey, think about it from the other person's point of view. What do you think that they're trying to accomplish? How do you think that the way that you reacted comes off to that? What were you trying to do? What, what, what are you worried about? What is the thing that is causing you stress? When you get these techniques, it becomes much easier. Um, but you need those techniques. And in tech in general, I think we, we don't give enough value to the soft skills, the interpersonal skills, and they are a set of skill sets. If you're not good at them, you can't do well at those skills. So the, the classic example is the exceptional engineer who was promoted to lead or manager who has no leader manager skills and not enough of the interpersonal skills. And then they flail for a few years while they try to acquire them, but they don't necessarily get the support and the training that they need to acquire them in a reasonable speed. Uh, I think that's a mistake that the industry makes in general. I think we're addressing that in, in many cases. But, within the Haskell community. I think we need to get very proactive. I think we need to not only do the moderation, but we also need to empower the moderators with the skills that they need to do the job well. And then the payoff for that is going to be a bigger, happier community that is cooperating more and fighting less.

>> Absolutely. I agree with everything you said. And the only additional thing I have to throw in the mix is that Haskell, as a community, is very geographically distributed, almost surprisingly so. I often, you know, see posts or get up profiles from people all over the world. And there's an assumption, I think, that if you're communicating online in, in majority English speaking forum, that everyone is a native English speaker. And I think a lot of disagreements, strife or whatever can come from that translation layer. And, you know, not being familiar with idioms or not catching things that a native speaker may catch. So um having a third party moderator or arbitrator come in and say, I don't, I don't think you two are actually disagreeing here. There's just an impedance mismatch going on. That that can be hugely helpful.

>> Yeah, we've seen a number of violent agreements in the community over time. And I w you know, I love the community. One of the reasons that this is my dream job is because of the community around the language. The language is great. Don't get me wrong. The runtime is great, but the thing that makes Haskell what it is, is actually the community around it. The people that are absolutely passionate and creating all of the foundational libraries that we build upon. We need to support those people. And. Uh, we've had a big problem with, for instance, open source project moderator burnout. And one of the reasons I think that is, is because we don't give them, we don't proactively give them the skills that they need to be able to manage a group of people, a group of volunteers. Uh, help them with their communication skills so that they are not constantly feeling like they're fighting defensive actions against a bunch of people that don't get their vision or, or are trying to do something different with their project than what they want. Where they want it to go or where they think it should go. One of the reasons that we want to do this affiliation with different communities and projects is so that we can help those projects get the same skills, the same people skills, the same training. So that they're not struggling with the same problems over and over. Um, and you know, if you, if you are in a project where everybody is on the same page. Everybody has a shared vision of where they want that project to go. And they're supporting each other and ideas are bouncing around and you know, you, you put up a PR and instead of nasty comments about how bad your code is. Instead it's have you, have you tried this? Have you tried this? Have you tried this? Then it becomes exciting and energetic, and everybody wants to spend more time doing it. And you know, you make friends for life and you have this close knit community. And that's what we want out of Haskell. So when a project affiliates with the Haskell Foundation, part of that is adopting the Guidelines for Respectful Communication so that we know we're all on the same page about how everybody should be treated. And that does not mean that everybody thinks the same. What that means is that we are respectful even when we disagree.

>> I love it. That's the world that I want to live in. Um, so we've talked a lot about what individuals can do to support the Foundation and support the community. Uh, for those of us that are lucky enough to be working with Haskell professionally, um, what can we do as companies or as individuals in a company to support the Foundation and the community?

>> Yeah, we have a sponsorship program. So we have a number of wonderful companies who have stepped up to support the Foundation financially. Uh, and there's a few different ways to do that. Writing a check is, is obviously one of the best ways to do it. It gives us the opportunity to prioritize and figure out where that money is best used. Uh, we have a list of prioritized projects. Like if we get enough money, we are going to help the GHC devs with their CI infrastructure. This would make them substantially more, uh, more productive because they would spend less time worrying about the dev ops related side of what they're doing. And more time working on fixing bugs, tracking down issues, enhancing things, working on performance. We want a budget so that we can train these moderators. You know, there, there's a lot of things that if we have money, we can, we can make a big difference. So, get ahold of us and sponsor the Foundation, write a check, uh, encourage your company to support the Haskell Foundation. So the way to think about this is like any open source project. You're getting it for free and you can build your company based on Haskell without having to pay a dime. And that's fantastic. That's actually what we want. We want you to be able to try out the language to build your company to gain a huge amount of success. And then after that, we want you to look at supporting your community. And that's not necessarily just the Haskell Foundation. There are other open source projects out there. There are other organizations like, like Haskell.org that that could use support. But fundamentally, you know, if you make a lot of money using Haskell as your technology stack, You need to give back, you need to support those tools. And it's, it's what I call enlightened self-interest. You're also going to get better tools. You're also going to, uh, get your name out there as one of the companies that uses Haskell and then. In our materials, we have our list of sponsors and people that are actively looking for Haskell jobs, know that they can go to that list of sponsors and say, Hey, what are your open positions? Can I apply? So it's not pure philanthropy, but, uh, I think that if you. Particularly, if you have pet peeves about the state of the tool set. About, uh, the, the speed of the compiler, you know, whatever it is. You need to support the people that are trying to make the difference. You need to support the, the groups and, uh, the technical agenda that allows us to address those issues in a big way. We have plenty of ambition. Ambition is not a problem. What we need is resources to make it happen. And we know that if we had a, you know, In a fantasy world, millions and millions or tens of millions of dollars. I know like the projects that I would write checks for, and I w I feel like I would find the right contractors, the right consultants, have them write up the plans, maybe go through a re refresh request for proposals process. We know what we want to do. And one of the interesting things about Haskell is, that there really are no full time developers of GHC. It's all a volunteer effort. There are a few people that are paid like a Ben Gamari. For instance, we do support him through the Foundation today through a very generous grant from GitHub. But the amount that we're talking about is not sufficient for someone of his skillset. So, what I would ideally like to do is I would like to have full-time people that work on the compiler and that is their full-time job. I think we need a release manager. I think we need a professional dev ops person for GHC. Uh, I would like to have a speak, you know, calling back to our community efforts in the moderation, I would like to have a full-time community manager at Haskell Foundation that helps all of the moderators for all of the other groups. And, you know, schedules the training and make sure, and is the escalation path, if something goes particularly wrong in one of those groups. So I think if you are out in the community, if you think that Haskell is a, an amazing language and should be adopted more, talk to your companies and say, this is, this is important. This is how we give back to that community and write a big check. The other option is if, if the big checks are not the, the, the right choice for a particular company, is there are other resources that are in kind donations that if, if a company wants to support, but you know, is, is maybe still in that bootstrapping phase. Maybe they can encourage their developers, uh, in a soft way to volunteer on various, uh, projects in the community. Help make a difference, like be, be one of those companies that is there and making the community better. Don't be a company that is using all of our tools and the work of all of these volunteers and then not giving back.

>> Yeah. So those are all excellent suggestions. And you touched on a lot of things in there that I want to dig into a little bit more. Uh, so I guess starting from the back there with in kind contributions. Um, so ITProTV uses Haskell. And one of the most valuable things that I've found from being a lead there is that when my team struggles with something, that's not a, you know, that's not the fault of my team. That's usually the fault of some documentation or some process or just something has gone wrong. And so it's really easy to unblock that person or unblock the team and say, okay, look, I know the answer here. Let me tell you the answer, but it's a lot more valuable to say. Oh, I know the answer. I should give this back to the community so that the next person doesn't run into this problem.

>> Absolutely. And there's a few different levels of that. So I think if you, if you find a problem in Haskell and you do a Google search, you will often find results. And you'll go to a blog post or something that will say, okay, here, here's how you solve this particular problem. One of the issues is that sometimes those are like seven, 10 years old and they don't really relate to what's going on anymore. Uh, and one approach is to make a new blog post that says, okay, this whole blog post had this information and I'm updating it with this other information. And that is valuable. That is absolutely valuable to do. The next level is to try to make that more official, to try to get something onto Haskell.org or a related website where you can say, okay. I ran into this problem. I'm sure other people are going to run into this problem. Here is the correct solution. Or maybe you get onto like the functional programming Slack or the IRC, and say, I need to talk to people who really understand this area and we need to hash out what is the right solution to this? Uh, absolutely get ahold of the Haskell Foundation if you see one of these issues. Because part of what we do is connect to the right people to each other so that these problems can be solved once and for all. And that gets to my next level, which is. If this is a problem that is more fundamental to a technology. Or maybe one of the open source libraries that, that we build all of our Haskell, uh, programs on. Let's solve the problem for real, let's actually dig in and come up with what is the correct solution. And sometimes those are very non-trivial solutions. Uh, I remember something going on with, uh, uh, Postgres. And, and I'm, I'm unfortunately forgetting off the top of my head, what it was, but, you know, it's, it's one of those really subtle issues that can happen at the margins. And I think it was Matt Parsons that was saying, yeah, we ran into this and I think we're solving it in like persist, but I'm not sure. I I'm I'm I am absolutely not saying that Matt Parsons said any of that stuff. I'm trying to paraphrase. But, the point is that people were following up with some of these library authors and saying, I ran into this problem. Let's figure out what the right solution is across the board. And that is the most, the most, uh, valuable thing that you can do. And I think for, for a company, that runs into any of these problems. One of the most valuable things you can do is allow your developers to really track down these problems and, uh, you know, run them to ground, as I think it said in the military. And determine what the correct fundamental solution is and let them help make that change, help them fix it for real.

>> Yeah, it's funny that you.

>> Then it's done.

>> Right. No one else has to worry about it. Um, it's funny that you bring up that Postgres issue because that, I think we kind of spurred that me, uh, ITProTV.

>> Uh, previous, uh, Haskell Weekly. That's exactly what it was. Async exceptions, right?

>> There you go. Yeah. And we ran into this problem and we kind of tilted our head and looked at it and said that that's weird. That shouldn't happen. And, uh, yeah, so we spent some time kind of running that to ground, as you said. And fortunately Matt was able to pick it up and really get to the bottom of it. Um, But, yeah, that was a great example of, we could have fixed it in our application and said, Huh, that was weird. I hope that doesn't happen again. But, uh, we decided to, you know, try to help the overall community.

>> Yeah, and I think. That that is an incredible way of giving back to the community. Another way is to, uh, have like an internal library that fixes a problem, or maybe just some internal code that fixes a particular problem. Take the time to turn that into an open source library, put it out there as an open source solution. Accept contributions from people outside of the company. Uh, I I've seen this, uh, both in companies that I've worked at before, you know, SimSpaces has, uh, for instance, open source some of their libraries and given back to the community that way. But, but that's another great way of doing it. And I think this is a popular way of doing it. But, you also then have to take on the responsibility of properly maintaining those libraries. If you just kind of throw something out there and then leave it, uh, it's not as valuable.

>> Right, that's like the blog post you were talking about where, okay. Seven years ago, this was how we'd solve this problem. But maybe things have changed in the meantime. Um, and then you said one thing earlier that I wanted to follow up on, which was startling to me, which is that GHC, there are no full-time maintainers or developers working on GHC. And I know that I see Ben Gamari, his name pop up very frequently. He seems to be a release manager and a core developer. He, he basically does everything. It's it's phenomenal. Um, but yeah, th th that was startling for me to hear, because we get so many improvements to GHC and it's such a good compiler. It produces good code. You know, I, I enjoy working with it. Um, so I'm just thinking of this hypothetical future where we can have somebody working on it, or many somebodies is working on it full time. That would be incredible.

>> W, and we have, you know, to, to be clear, we have people like Ben that are essentially full-time working on it. Although they, they do other work, which is why I'm saying that they're not full-time on the compiler. They, they do have other responsibilities as well, but they don't, like it is not, it is not their entire full-time day job. And, uh, I, when I worked at, at Microsoft, I worked in the developer division for a while and you know, the Visual C++ team at that time was a big team. It was tens of hardcore developers. Uh, who they would, you know, and program managers and a big test team and the requirements would come in and they would think about ways that they wanted to change the compiler or the language. And they would, uh, spend a bunch of times speccing out that and figuring out test plans and then, you know, writing code and then doing big releases with golden masters. And, the, the work that the GHC team does is incredible given the size of the team and the constraints that they're under. And I think we benefit hugely from the work of, for instance, graduate students who are working on their thesis and their thesis happens to be programming language related. And so they implement some cool new thing. Um, I, yeah, Haskell and GHC are kind of a miracle under the circumstances. And, uh, there there's that image that is circulated every now and then of what, what would happen if GHC blah, blah, blah. And it's this futuristic city, futuristic, uh, image. I think that if we can get enough resources to really, we don't need, like, we don't need the same kind of team has maybe a Visual C++, right? We don't need that. But I think there are a few key roles, like I've mentioned, release manager and dev ops and a few other things where if we could get somebody doing that full time, then that allows people like ben or Moritz Angermann to leverage their time. Even more. They can concentrate more on the things that they are uniquely qualified to do, rather than the stuff that has to be done, because things aren't working today.

>> Right. So if that sounds like a future that you want to be a part of listeners, then convince somebody to write a big check.

>> Big, big check.

>> Um, so yeah, Andrew, we've been covering a lot of topics here. We've touched on everything that I, that I wanted to bring up about the Foundation. Uh, so as we're closing up here, is there anything that you would like to talk about that I have not asked you about?

>> Oh, let's see. Um, I think one of the things that we're very interested in is areas where Haskell is uniquely qualified. Has a unique value for an industry or a particular, uh, application. So, as an example, uh, we recently, uh, uh, announced that we have affiliated with the Clash language. And Clash is a programming language, which is in Haskell, that allows you to create hardware designs by writing Haskell code, using their libraries and their compilers. Uh, functional language functional programming seems to uniquely qualified to do hardware, because it's the same kind of thought the same kind of, uh, of approach. I think that there's some others, you know, we have inroads in financial software. Uh, if somebody is going to write a compiler, I think Haskell is clearly the right language to write a compiler. But there's, there's gotta be others. And I think. If you, you know, calling back to the STM conversation, anything doing parallel, concurrent programming. Uh, and I think that we, we have the opportunity to showcase Haskell as the premier language in different areas. And, uh, and I encourage your listeners to think about that. Like, what is the thing that the combinations of the Haskell programming language and the runtime. Make essentially trivial, which is actually very difficult in other languages. Let us know because we are looking for those. Uh, and I, I am incredibly excited about some of the projects that I'm seeing, that I had no idea existed in the community.

>> And are you looking for something along the lines of like a case study, like Clash? You know, this is a good example of how Haskell can be leveraged to do something that it's uniquely, uh, You know, it, it can accomplish. Or are you looking for something like Haskell could be used in this vertical or this industry, but it's not and why not? Let's dig into that. Or maybe both?

>> Both of those. Absolutely. And, uh, if. If you are very excited about some emerging market, some emerging technology, that really isn't on anybody's radar yet, but you think would be uniquely, uh, applicable for Haskell. Uh, let me know. Those are what we're looking for, because if we can get in early, we can be, you can, we can have the language be synonymous with a particular market. And then the more of those that we get to, the easier it is to sell into existing markets and say, look at this, this and this. They're using Haskell almost exclusively. And they're kicking butt. You should use Haskell too, for what you're doing.

>> I like it. So you mentioned that people should let you know when they find things like this. Uh, how should people contact you and/or the Foundation at large?

>> My, my email address is andrew@haskell.foundation. Or, uh, if you want a sort of more generic, uh, contact, then contact@haskell.foundation. I'm also often on uh FP Slack, the Zulip, uh, IRC, uh, Discourse. I I'm all over the place. Uh, often as MyShoggoth..

>> Yeah, I was curious about that handle. Could you explain what that means?

>> So a shoggoth is a horror from the elder gods of HP Lovecraft, uh, fame. And, where it comes from. So like, like a lot of online handles, they come from when I was much younger. Uh, and they kind of just stick around for a long time. But, uh, a friend of mine, I think still owns shoggoths.com. And so I couldn't get that one anymore, I couldn't talk him out of it. And this was early two thousands. So this was when like Windows XP came out and it had my documents, my pictures, my, this, my, this, my, this. And I thought it was really funny to have my shoggoth. Like this very friendly version of this, this thing that is supposed to be like insanity, creating horrible. And it just stuck with me. And one of the nice things is that, uh, obviously nobody else uses this handle. So it's very easy for me to get. But that's where that's my handle on Twitter and basically any social media that I use. And, uh, I, yeah, that's, that's where that comes from. And that's also my personal website.

>> Uh, well, I will do my best to include as many links as I can in the show notes for this episode to get to those various places. But there were a lot. Um, so yeah, Andrew, thank you so much for being on the show today. This has been excellent. And, uh, it's just been great talking with you.

>> Thank you. I appreciate this opportunity and this has been a lot of fun.

>> That does it for us this week. Thank you for listening to the Haskell Weekly podcast. I've been your host, taylor Fausak. And with me today was Andrew Boardman. If you want to find out more about us, please check out our website, which is HaskellWeekly.News. This week, we are brought to you by our employer, ITProTV, the e-learning platform for IT professionals. Use the promo code HaskellWeekly30 at checkout to get 30% off the lifetime of your subscription. Head over to ITPro.TV to get started today. Thanks for joining us and we'll see you next week.