39 – Rebecca Skinner

• Rebecca’s Webpage
• Rebecca’s X
• Rebecca’s Github
• Effective Haskell
• Mercury
• Haskell Org

Matthias Pall Gissurarson (0:00:15): Welcome to the next episode of the Haskell Interlude. My name is Matthias Pall Gissurarson, and my co-host is Niki Vazou. We are joined today by Rebecca Skinner, who will tell us about her new book, Effective Haskell, and how to use Haskell to build abstractions that make sense. She’ll also tell us about Haskell large-scale industrial applications and how the architecture of industrial software reflects the organization of the engineering teams. 

Okay. Welcome, Rebecca.

Rebecca Skinner (0:00:46): Thank you so much.

MPG (0:00:47): So tell us a little about, how did you get into Haskell?

RS (0:00:52): Yeah. So I started learning Haskell around 2008. I was interested in functional programming. At the time, my background was – I’d been working in C, mostly doing very low-level stuff. And I was really interested in this very other end of the power curve. I looked at OCaml, I looked at Common Lisp, and I started looking at Haskell a little bit. And around that same time, actually, Xmonad was pretty new right then, and I picked it up. And it’s funny, I really just wanted to configure my window manager and was interested in functional programming, and it grew from there.

Niki Vazou (0:01:41): So why you wanted to start functional programming from C? Because there are not so many people that make this switch. So, I’m curious about the reasoning.

RS (0:01:51): I think I’ve always been interested in extremes, I suppose. I think one of the things for me that I enjoy when I’m programming is really feeling like I understand something or I understand some true thing. And very low-level programming is like that, in this very mechanical sense that you’re truly working with the machine in some way. And I’m sure somebody will say, “Well, actually, C isn’t very much like a computer works these days.” But it feels like that in a lot of ways. And I think Haskell, in particular in functional programming, is also true in this very different way. But it hit the same part of my brain.

NV (0:02:42): And so you started learning, configuring Xmonad, then you started using it in your work too?

RS (0:02:48): Yeah. So, I started configuring Xmonad. I got really into Haskell. I’m like, “Okay, this is really giving me a lot of dopamine. I love this.” I want to say maybe later that year, the next year, I was working on a research project where we were implementing Shamir’s secret sharing and just doing some really interesting simulations. And it was really just me, and I needed to write this paper. It was research grants. And nobody really cared what I did. And I said, “Okay, I’m going to write this in Haskell.” And then there you go. Professional Haskell experience. So, I can put that on my resume. And for the longest time, I was just following that pattern of using a little Haskell alongside other languages because I thought this is a really good language. And I worked with a lot of people that were very interested in trying things. And so, I just had a lot of opportunities to work it in alongside other languages that I was working with.

NV (0:03:54): And then you started becoming very active in the Haskell community, right? How did they start?

RS (0:04:01): I think it was actually quite a few years that I was just quietly using Haskell and not participating very much in the community. But really, I would say it was maybe around 2014, 2015, something like that. I started going to some conferences and some meetups locally. I live in St. Louis, Missouri, and the Strange Loop conference is here. And it’s funny, you don’t really think of St. Louis, Missouri as being a tech city, but we had this really great conference with all of these functional programming people. And by that time, I was really interested in getting involved in the community, mostly because I wanted to work with Haskell more. I wanted to use Haskell at work more. And I felt like if that was going to happen, I needed more people to be comfortable using Haskell at work. And so, I really wanted to get involved with the community and say like, “Hey, let’s try to open this up to more people, to the sort of people in the industry.” Not out of any altruistic sense. Just like, “I want to use Haskell more, and so I’m going to just come in and see how I can help make that happen.”

MPG (0:05:19): So that was what prompted you to write a book eventually, right?

RS (0:05:25): Yeah. So, that actually came out of a lightning talk that I gave at Strange Loop a few years ago. It was on the subject of how I thought that we could be mindful about the ways that we talk about Haskell if we’re aiming for people that are getting into the language. And Brian MacDonald, who at the time was a development editor at Pragmatic Bookshelf, happened to be in the audience, and he approached me afterwards and was like, “Hey, have you ever thought about writing a book?” And me, at the time, being extremely naive, thought, “Yes, this is something I want to do. How bad can it be?” And so I took his card and just went from there. 

NV (0:06:05): So this is the key to start writing a book—being naive?

MPG (0:06:09): Yeah. So, can you tell us a bit about the book? 

RS (0:06:12): Yeah. So I guess for folks who aren’t familiar, the book is called Effective Haskell: Solving Real-World Problems with Strongly Typed Functional Programming. And it’s published by Pragmatic Programmers. And my goal for the book was really following with that same goal that it got me more involved with the Haskell community. I wanted to write a resource that was appropriate for people who wanted to use Haskell at work and maybe didn’t have a background with functional programming. Maybe had never even used statically typed languages because most of my career using Haskell was working in teams that weren’t already using Haskell. I had a lot of experience selling Haskell to other people that were using other languages. And I’d seen where a lot of the struggles came from. And I knew from my own experience that there weren’t good resources really that I could point people at and use as a text. 

And so, I just really sat down and said, “I want to write something for the people that I’ve been working with. I want to write something for myself that would help me get people onboarded onto the language.” So, I really aimed for something that targets people that have experience programming, but they don’t maybe have the formal background that leads people into Haskell, and they’re maybe not even convinced by all the features at first. And so, really, something that helps them learn how to think and see where the value is in these Haskell features and get into industrial code.

MPG (0:07:56): And the book, it always builds things up. You have a use case before you introduce the solution, right?

RS (0:08:05): Yeah. And that came from what I see as a really common struggle that people have when they’re learning. I think Haskell is a particularly good example of this, but I don’t think it’s unique to Haskell. People see an abstraction, and they don’t quite understand that it’s solving a specific problem. And so, what happens is you either go one of two directions. You either say, “Well, that’s a bad idea. It’s too complicated. I don’t like it.” Or you say, “Oh, this must be like some grand truth of the universe, and I should try to use this as much as I can.” And so, I think that I see that a lot with monads. People learn type classes, they learn monads, and then they sit down and they say, “How can I make everything have like this monad instance?” Because they don’t really understand when to apply that. So they have a shiny new hammer, and they go looking for nails. And so one of the things that I wanted to help people get out of the book was an intuition for when to start looking to reach for different features of the language by showing them like, okay, you’re going to do this, and now you have a problem, and this is the sort of problem that should make you think, “Oh, I should reach for this or that.”

NV (0:09:19): So in the monad example, can you explain this? When you should use them and when you should not?

RS (0:09:26): Yeah. So, I think that there are few different examples because monad is very general, but the one that I really started with was IO. And I think that IO is actually a really good example of why you might want a monad instance. Because the first couple of chapters introducing IO, we don’t even talk about like there’s a monad instance. And instead, we say like, okay, we have this lazily evaluated language. How do we know what happens? How do we know when it happens? Well, what if we just actually implement all of this by hand? Well, it’s really annoying because you have all of these case statements. And then you go to the same thing with like maybe and either, and you’re like, “Why is my code just completely running off to the right-hand side of the screen? I just have case statement after case statement.” And then you show like, “Well, look, I can write this abstraction to make this easy for me, but now I’ve written the same abstraction for IO and for either and for maybe.” And then you say like, “Oh, well, it turns out that if I find myself writing the same case, like nested case after case after case abstraction, maybe that’s a good sign that I should look at monad.” And then you take it one step further and you’re like, “Oh, actually though, once you build this abstraction –” look at these other things that maybe didn’t fit your intuition at first, but that takes it that one step further to help internalize that this is a little bigger than just something that you pattern match with cases. But it’s a good starting point.

MPG (0:11:05): Because you build up this parser example where you end up with a monad in the end. It’s very nice, and it feels like – so did you do research into how monad came to be? Because I feel like monadic parsers are the prototypical original thing. They just very nicely use all the applicative and monads and functor stuff, right? 

RS (0:11:31): Yeah. What’s really funny is I didn’t actually do research on how monads came to be, or even really start out thinking that I was going to write a chapter for writing a monodic parser. When that chapter came about, it actually happened because I wanted to talk about optimization, and I wanted to introduce ST. And one of the things that I was really careful about in the book was structuring things so that you never have to take my word that you’ll learn something later. I really wanted to be able to start at the beginning of the book and really minimize how many things you had to not understand and hold in your head. And with ST, we have to learn about things like type parameters and higher rank types, and you’re going to run into some skolemization errors as soon as you start working with ST. And so, I thought, okay, well, how can I introduce existential types in a way that is gradual and I can get people used to them before they get to this chapter on optimization? So then I thought, well, an encoder. I can show this encoding process. So I had an encoder written, and then I’m thinking about monad transformers. And I’m like, “Well, I’d really like to show people how to compose effects like failure and parsing,” and like, “Oh, well, a parser, that’s a great example there. And I already have this encoder.” And that’s how that set of chapters came to be.

NV (0:13:02): So, talking about monad transformer, in your book, you also mentioned this mathematic jargon that appears a lot in Haskell, and it’s also my experience that people get a lot discouraged by it. So, I think in your book, you’re very carefully trying to avoid that. So, what is your experience? Do you think you made it or have you faced it when you’re teaching Haskell?

RS (0:13:31): Yeah. What I find are there, I think, a couple of failure cases that I’ve seen. And so, for myself, I didn’t come into Haskell being somebody – I never thought of myself as a math person. I’m fine at math, but most of the math experience that I had coming in was around signal processing. I’d never really done any category theory or anything like that. And what I found for myself was that I was just like, my brain would just stack overflow. I try to learn a definition, and that would lead to four more definitions. 

And what I eventually realized was Haskell ended up teaching me a lot of math rather than the other way around. Because eventually, you have some really concrete thing to hold onto when you’re trying to understand a lot of math concepts, but for – and I think a lot of people can go that way, and I think the math helps in the long run. But people are not as stubborn as I am. And a lot of people, when they run into that one definition, leads to another, leads to another, I think some people give up. And I think other people, like when I think of math people, people that come in with a lot of the math background, they tend to think of the terms in the math sense, when often what we’re using in Haskell is like this much more limited definition of something. And so, they also get the wrong intuition. And now they’re going the same route of learning one way that this is different after another.

And so I wanted to just give people an intuition for what the things are without the burden of the terminology. At the same time, we do use this terminology a lot in Haskell. And so, I didn’t want to completely avoid it either. So, I really tried to just tell people like, this is what we call it in Haskell, and don’t worry too much about what you or other people think this means outside of Haskell. You can get there eventually, but don’t worry about it for now. Just like, this is a word, and we’re going to use it, but don’t put too much stock in it.

NV (0:15:49): But it’s actually discouraging people, no?

RS (0:15:51): Yeah, I think it can. And I think that there’s maybe an argument for us to try to move away from that language if we want to get more people in Haskell. But I also think that today if we’re going to teach somebody Haskell, we have to teach them to be comfortable with it because it is the state of the ecosystem right now.

MPG (0:16:13): Was there anything that you learned while writing the book? Was there anything that you had to dig down into deeper or you were just writing down things you already knew?

RS (0:16:23): I think I learned a lot about teaching and about pedagogy, just really learning how to empathize with a reader. In terms of Haskell, I think I wrote about what I knew. But by writing a book, I really cemented my understanding in a way that maybe I hadn’t before. Because when you have to explain something, you really have to know it in a way that before you could just hand-wave know it. 

Probably the thing that I actually did the most research on didn’t actually make it into the book, which was really digging into the runtime system. And there’s a little bit of talking about like how we evaluate things and how thunks are represented in the book when we’re talking about like space leaks and stuff. But I really did a lot of research because I wanted to be able to really tell people like, this is how things work. And there wasn’t space for that in the book. I have a couple of chapters that I cut, and I’m hoping to clean them up and release them eventually.

NV (0:17:31): Oh, so you hope to have a next version of the book too, or in a different book?

RS (0:17:36): Oh, we’ll see. But I do have a couple of chapters. I do want to just publish for free online because I wrote them and I want people to have access to them. So, I have about 50 pages just on unsafePerformIO. And that was really interesting learning.

NV (0:17:54): And is it intended to be used as teaching material for a course also?

RS (0:17:58): Yeah. I’ve talked to a couple of people who were interested. I don’t know that anybody is teaching it as a course. Like I said, I think my primary target audience for people in industry, and I think it would be really well suited for teaching people if you wanted to do onboarding training at a company. I think in an academic setting, it could work, although I think that my goal of not making things too theoretical might run against what you would be looking for in an academic setting.

MPG (0:18:33): Right. No, because you do this thing where you show the error message. And then tell people, don’t worry about it. Because that’s one of the issues people have, right? They get scared away by a huge block of unexplainable terms. 

RS (0:18:50): Mm-hmm.

MPG (0:18:52): So, when you are structuring the book, because you go into – you build it up parts by parts. And I think all the way at the end, you’re introducing GADTs. But you’ve already introduced type level programming before that. And I feel like this is often reversed. We don’t talk about open type families before GADT. So, how did you come up with the path through the book that ended up being there?

RS (0:19:23): Yeah, a lot of it was – it’s funny, I guess, in a lot of ways. My writing style was like lazy evaluation. I start writing something and it demands particular knowledge. And so then I would just stop and go back to an earlier point in the book and look for a place that it fit pedagogically, and I’d start writing there. And then I’d realize like, “Oh, actually, somebody needs to know this.” And so, I go a little bit further back. And occasionally, I would just have to throw a chapter away and start over because I realized it just wasn’t working, or completely rewrite some things to fit together a little better.

With the GADT part of it, it really did come down to – I thought about teaching it the way that I always see it being taught, but realized when I actually sat down to write, that it just didn’t quite work with what I felt like somebody needed to know if they were going to get into the right head space. And so, I just let the text structure itself, and it seems to have worked out pretty well.

NV (0:20:31): What is the usual way that somebody is teaching GADTs?

RS (0:20:34): I think a lot of times, people start with showing those and using them as a motivation for type level programming. Whereas in the last chapter of the book, we cover type level programming, but they’re actually one of the last things that we show after getting into some of the other things like associated type families or just like type families in general and recursive type class instances. And I think that often goes the other way.

NV (0:21:04): But do you really believe that—maybe not believe—that in industrial setting, people can use all this type level programming?

RS (0:21:15): I mean, I have. I do. So, I know that it’s true. So, in my time using Haskell, I think that I see a few different sorts of engineering cultures that crop up in Haskell shops. You see what I call the type of astronaut places. And those places don’t use Haskell for very long. They almost always end up switching to some other language because they have trouble really shipping things because they have a lot of people that are really there just to write Haskell and not actually to do their jobs. And you have other places that react very strongly against that and say, “We’re going to write very simple Haskell, and we’re going to use Haskell 98, or we’re going to prohibit a bunch of things.” And I think that those places tend to also suffer a little bit because why are you paying the cost of Haskell if you’re not going to get all of the benefits? 

And I think really, like at Mercury, the way that we approach this is to encourage people to think about simple code as a default. And if you need to reach for something more expressive, try to wrap it behind a really nice interface, keep it encapsulated so that people don’t have to be faced with that if they’re not ready to dig into that. But also, don’t shy away from something that can really make your product better, because that’s why we’re using the language.

MPG (0:22:51): What would you change? So now you’ve written a book about how it is. And sometimes you mention like, “Oh, this could be dangerous, but we trust the users not to do the wrong thing.” And I mean, you try and keep them safe. But if we take Haskell further, how would you mix it up? 

RS (0:23:12): Yeah. In a lot of ways, it’s funny. I think a lot of the warts and things that we might change are part of what got us to Haskell as it is today. And so, I may be kinder to some of those warts than a lot of people in the community because I think that everything that we have got us here. 

There are features that I would love to see. I personally really enjoy type level programming. I’d love to see more work done in that area. I think that in an industrial setting, people really want more and more sophisticated tooling. And so, I think work on GHC that can enable more of that is going to be really useful. 

If there were one thing I could wave my hands and make it happen, even though I have no idea how to make it happen, it would be some sort of a tuneable knob that lets us both tune maybe a set of imports by default, as well as a set of ways that we write error messages and things that let you dial in your Haskell knowledge. Like, maybe I want to turn Haskell up to 11 and get the really advanced features and really sophisticated error messages. But somebody else doesn’t want even to see, say, type class constraints in their error message yet because they don’t know about those. And I think that could be really interesting for getting people onboarded onto the language.

NV (0:24:47): To me, it was surprising that you saw all the error messages. Even when I program, my mind doesn’t read all the error messages. I mean, do you think it was helpful explaining everything instead of trying to hide all these classes, and what was your experience?

RS (0:25:06): Yeah, I think it is helpful because I’m the same way. When I see an error message, I just reflexively go to the one part of it that means something. And it doesn’t even matter what it says. You can read it and you just build that intuition. But people that haven’t been looking at those error messages for a long time, they don’t have any reflexive understanding. They are reading it line by line by line, and it can be really intimidating. 

And so, the tone I try to take in the book is this friendly guide. Like, I want to be there with you, and you as the reader, you’re going through, you’re learning this language. And I’m just there to help. And one of the ways that I want to be there to help is like, okay, I’m just going to stand here by you and give you some support. Take a deep breath, read this error message. It’s going to be scary, and that’s all right. It should be. And we’ll get there. And I think people appreciate it. 

The feedback I’ve gotten in general has been places where I took a chance on really long error messages or really long examples and walking through them. I was worried about the page count. My original estimate was that this was going to be a 250-page book, and it’s not. I took a gamble on some long examples, some long error messages, and the feedback has been very positive. I think people have appreciated it.

MPG (0:26:35): I feel like one of the things with error messages in Haskell is that they’re written by GHC developers. So, they’re thinking about, “Oh, the skolem that I created here is not in scope anymore.” And then as a user of Haskell, you don’t know what’s going on underneath. So you don’t know. It took me many years until I finally learned what a skolem was. And I don’t think it helped, even though I knew what it was.

NV (0:27:04): I just hope that at the end, there is this suggestion to import the language pragma, and I just add it. That’s all I want.

MPG (0:27:10): Right. So, you do go a little bit into cabal and runtime system flags and stuff like that, but you don’t go so much into the tooling around it. Was it a conscious choice to avoid talking about the tooling because it’s going to change anyway?

RS (0:27:32): It was partly because it’s going to change anyway and it was partly just a matter of saving space in the book. I had originally started writing the book with the idea that I would be neutral about cabal and stack. And even that just ended up taking too many pages. And so, I said, I don’t want this to be an even longer book. I just want to focus on what people are going to need to get through, the examples people do need to know about cabal. And I think learning how to organize modules that’s very tied to cabal, optimizing things, and being able to profile is important because people are going to make space leaks. They’re going to run into some problems. And so, those are necessary. But everything else I just had to cut.

NV (0:28:27): Okay. So, other than writing your book, what else are you doing these days?

RS (0:28:34): Yeah. So, writing the book was the first step to writing the book because there’s still a lot of side work. I’m talking to people on podcasts like this and slowly working through publishing exercise solutions and other material. And aside from that, I’m continuing to work with the Haskell.org committee and working on Haskell at work every day. 

NV (0:29:09): So, what exactly is happening in Haskell.org these days?

RS (0:29:15): Yeah. I think the Haskell.org committee, we are like the slow study committee that is always trying to help Haskell’s image just a little bit. Recently, we’re talking about just trying to broadly unify the look and feel of the site in order to make some of the pages match the homepage. We have a nice-looking homepage on Haskell.org, and then not a whole lot of interesting visuals on the other pages. So, we’re hoping to make some progress there to get some more learning resources up, as well as looking at ways that we can understand how people are using the site. And we really want to figure out how to make Haskell really pop for somebody that is actually going out to Haskell.org and saying, “Hey, I want to learn a little bit more about this language.”

NV (0:30:13): And then Haskell org is also doing the Summer of Code, right?

RS (0:30:17): Yeah. We’ve just been doing the Haskell Summer of Code. I should know more about the projects that are happening right now, but I will admit, I’m just not really having them at top of mind right now. But it’s been a really great program. 

NV (0:30:33): Yeah. I think it’s a very good way for students to get introduced to Haskell and get a very nice mentor, and do a nice project.

MPG (0:30:41): Right. And so, what are you doing with Haskell at Mercury itself? What does Mercury do for those that don’t know?

RS (0:30:50): Yeah. So, Mercury is a fintech company. We’re not a bank. We offer banking services through a number of our different partners and provide a uniform interface into all those different services. We’re built entirely on Haskell in the backend of our application. So, I think we have—oh, I don’t even know how many lines of code we have—something like five or 6,000 modules in our code base and over a hundred engineers. I think about two-thirds of the engineers are working on Haskell. 

MPG (0:31:34): So how does it work with Haskell at scale? How do you organize that?

RS (0:31:41): Yeah. So I think that right now we are really at a point where we’re feeling the scale that we have. And I think we’ve historically had our application just be a single – I don’t want to quite say monorepo because we have a separate repo for our front end, but a single large backend application. And we have an engineering culture that really values teams taking ownership over certain parts of our product. And so, I think our – it’s Conway’s law. The architecture of your software often ends up reflecting the organization of your engineering teams. And so, I think that our code base, we have some teams that own some shared software infrastructure, and then a lot of teams that own individual parts of our products. But it’s all essentially one Haskell library. A big one. And we put a lot of effort into making the tooling and the ecosystem work well with such large products. 

NV (0:32:50): Is it open source?

RS (0:32:52): Our core application is not open source. We do have some open source code that we’ve released. And I think more stuff over time that we’re releasing.

MPG (0:33:05): Do you feel like – was Haskell a good choice for this scale? Or if you knew that it would’ve been like this, would you have done something differently before? What are the pitfalls that people should avoid if they’re going to have 6,000 modules of Haskell?

RS (0:33:25): I think it’s worth it. One of the funny things is, I’m very enthusiastic about Haskell, but I would be the first person to say that there are actually no right answers when it comes to building a product of the scale. I think that Haskell is a really good fit for Mercury’s engineering culture because, I think as an engineering team, we value quality, we value thoughtful approaches to building things. And I think that we really take a first-principles reasoning approach to doing things. If we do something, even if it’s the way that everybody else does it, we’re going to think like, is this the right thing for us to do, or are there ways that we should do it differently? And I think Haskell gives you a lot of capability to approach that. So, I think it’s worked out well for us.

Definitely, at the scale that we have, we invest in GHC. We have both folks internally that have worked on GHC. We also contract to help improvements. And a lot of that comes to compile times, support for the M series max. We ran into some issues there. I think tooling in general, just often we see the sharp edges crop up just when you have so much code. 

So, I think really what I would say to people that are thinking about it is, if you’re going to build a really large Haskell application like this, I would maybe suggest starting with more individual components. I’m actually a big fan of writing many smaller libraries. And I think the sharp edges and Haskell’s tooling don’t crop up so much there. But I would also say, realize that what you get from Haskell’s is a great language with a lot of power hiring. We actually have had people on our recruiting team say that hiring Haskell backend engineers is the easiest recruiting job that they’ve ever had because so many people are so enthusiastic about working with Haskell. And so, you get a lot of benefits, but you do have to pay the costs of working with your tooling and accepting that you’re going to have some slow compile times. You’re going to have a big memory footprint when you compile and things like that.

NV (0:36:03): But is this compiler time something that is feasible to change anytime soon?

RS (0:36:11): We have a team that works on developer UX, and they often manage to say like, “Oh, hey, we improved times by 40%,” or something like that. And so, there are definitely things that can be done. And I appreciate them because I don’t work on that part of our system directly. So it’s always nice when things get faster. So, I think we’ve managed to keep it under control for now.

NV (0:36:41): No, I believe both the tooling and the compile time, that is very slow. And the error messages, as Matti said, is like, when they are written by Haskell people that all of us love Haskell and we are happy with whatever, and how much fun it is, then we don’t really see that this is difficult for people who use it at work and for people who are not like the Haskell enthusiastic. So, as the error messages, like Matti said, they’re written from GHC developers, and yes, for me, after so many years, I see them, I understand them. Okay, I have to explain them at some point. Yeah. But if you have external engineers, maybe this would be possible. So, I guess my question is, is it that these things cannot improve or that the current Haskell developers do not put effort into that because we don’t think it’s a big problem?

RS (0:37:37): Well, I’m never going to be one to say like the Haskell developers don’t put effort into things because I’m certainly not going to criticize anybody for the work that they are volunteering to our language. I do think that we culturally in Haskell do tend to prioritize new features more. And I think that not a lot of people have access to big code bases to really see where the problem is. If I think about large Haskell code base, you have GHC itself and what? Pandoc is pretty big. I struggle to think of many other open source code bases that are just large enough to really exercise the edge cases of the tooling. And so, I think it’s hard to fault people for not optimizing a use case that they don’t really run into. 

MPG (0:38:32): But I think that’s why it’s important to work with a community because complaints crop up. And then, “What are you doing?” “I’m compiling 6,000 modules.” And then the developers were like, “Why are you doing that?” And it’s like, “Oh, we have a huge application that we didn’t know about.” But it’s true. I think we would benefit a lot from more big applications being available just to run stats on and gather data. And like you said, it’s hard to optimize those things if you don’t run into them, or you don’t even have data except for a complaint every now and then that they slow down our build by two hours or whatever. But it’s gotten a lot better, I think, in the last – because I started Haskell as well around 2012, something like that. And then it was so slow. You would see profunctors scroll by. And then you knew it’s going to compile lens at some point. And then you’re like, “Oh no, it’s going to take a while.” But now, you don’t even notice it anymore. So, it’s been –

NV (0:39:39): Yeah. And my point was not to blame; my point was also that I liked Haskell so much. That’s for me spending one day building GHC because this is what I have to do. It’s like, yeah, I have to do it. I don’t mind, I’m going to do it. But if I try to sell Haskell in an industrial setting, they will say, “No, we don’t have the capacity to do that.”

MPG (0:40:01): Right. So, that was something you touched on before because you have the book just a resource to point to now. But what is your elevator pitch to someone who is not enthusiastic about Haskell? How do you get them to – how do you onboard them before you introduce the book?

RS (0:40:18): So, I think that it varies a lot depending on the person you’re talking to. One of the things that I think we have to be mindful of when we’re talking to somebody about Haskell is, what are the problems that they have? Because it’s really easy to say like, “Well, we have this great type system.” But if you’re talking to somebody who doesn’t know that they could benefit from a great type system, you’re not actually going to sell them on anything. 

And so, for people who are, say, just an average everyday developer that maybe doesn’t have a particularly strong pro or anti-Haskell stance, where I really go to is that I think Haskell gives you really great tools for describing your problems, for building abstractions that make sense to you in ways that don’t require babysitting the language. 

And it’s funny, one of the metrics that I use when I’m thinking about a language and how much I enjoy using it is how much of the day-to-day process of writing code is dealing with my own bullshit versus dealing with somebody else’s bullshit. And I think that one of the reasons I really like Haskell is not that I never run into problems, but they’re mostly problems of my own making. Haskell lets me build my playground, and then anything I run into is entirely my own fault. 

And I think that a lot of languages that are less expressive, especially less expressive at a type level, but also that just have a more rigid syntax, they make it difficult to express yourself. And I don’t want to quite go so far as to say like, write a DSL for everything, because I think people get a very specific idea in mind.

But it’s funny, I think one of the languages that reminds me the most of Pascal is Ruby because I think that people in the Ruby community really have this very implicit understanding too of the power of building expressions. And maybe it’s not quite as far as the DSL, but the power of expression. I often have thought we need some version of Why’s (Poignant) Guide to Ruby to Haskell or something. Just really to lean on that power of expression. 

NV (0:42:48): So, in your book, you start by saying that if Haskell is not the big thing, then the next big thing is going to be very Haskell-inspired. And now you mentioned Ruby, and I was imagining that the next big thing would be something between Haskell and Ruby, or do you have a more concrete wish?

RS (0:43:12): I’ll say that I think what I said was a safe statement largely because all languages that I’ve seen are borrowing from Haskell. It doesn’t matter what the next big language is. You can point to a dozen things and say, “Look at how Python got its list comprehension syntax from Haskell,” or “Look at how Rust got traits.” And maybe all these things weren’t directly inspired entirely by Haskell. But I look at Java getting pattern matching. I look at Go’s approach to generics. And a lot of these things, even if they are not as expressive as what Haskell offers, they’re clearly inspired by things that I think came out of Haskell. And I think that we’re – it’s been true. It was true in 2008 when I first started learning Haskell, and I think it’s still true today that working in Haskell often feels like using another programming language 10 years in the future. 

It’s really a shame to me that we used to see – I used to see a lot of people outside of the Haskell community pointing to Haskell as this example of a language that will teach you these things that are going to be used in the future, or we’ll teach you to think about things in a better way. And it used to be really common to hear people say like, “You may never write another line of Haskell again, but you should learn it because it’ll make you a better programmer.” And I don’t see people saying that as much these days, even though I think it’s at least as true, if not more true, than it used to be.

And so I think that it’s less that I have this wishlist of what the next language will look like and more reminding people that Haskell’s still here and still leading and influencing the things that they’re using.

MPG (0:45:04): Yeah. No, I think that’s a great way to look at it. It’s a language of the future, but it’s already here.

NV (0:45:11): For the last 10 years. Okay. Yeah. That was very nice. Thank you very much for coming, Rebecca. It was a very interesting discussion.

MPG (0:45:18): Yeah. Thank you. 

RS (0:45:19): All right, thanks.

Narrator (0:45:21): The Haskell Interlude Podcast is a project of the Haskell Foundation, and it is made possible by the generous support of our sponsors, especially the Monad-level sponsors: GitHub, Input Output, Juspay, and Meta.