diff --git a/podcast/72/transcript.markdown b/podcast/72/transcript.markdown
new file mode 100644
index 00000000..fea5ca45
--- /dev/null
+++ b/podcast/72/transcript.markdown
@@ -0,0 +1,189 @@
+*Mike Sperber (0:00:15)*: Welcome to the Haskell Interlude. 
+
+*Matthías Páll Gissurarson (0:00:17)*: Hi.
+
+*MS (0:00:17)*: Today, Matthi and I talk to Manuel Chakravarty, whose history with Haskell is wide and long. So, this is another one of those episodes that could have gone on forever. We talked about Manuel’s work on the backend, such as data parallel in Haskell and the FFI, and how that work segued into type system design. Manuel also has a wonderful perspective on Haskell from the language design of Swift, as well as some advice for the current set of GHC maintainers and Haskell language designers. We hope they are listening, and you are too. 
+
+So, hi, Manuel. So, what was your first point of contact with Haskell?
+
+*Manuel Chakravarty (0:00:49)*: Hi, everybody. My first point of contact with Haskell. So maybe I should start with my first point of contact with functional programming, and that was, well, not surprisingly, at university. I was always interested in compilers and, as a result, somehow in programming languages. And in Karlsruhe, where I studied, I did some courses on compilers and programming languages. And in the library, in the university library, I stumbled over two books, one of them being Introduction to Functional Programming from Richard Bird and Philip Wadler, and the other one being the Implementation of Functional Programming Languages from Simon Peyton Jones. 
+
+And I mean, I had been programming as a kid already, but of course, Bayes, Pascal, Assembly, whatever, kind of very unstructured. And so seeing in Bird and Wadler that you could treat a program like a mathematical object that I thought, that’s like, how cool is that? And also, as I said, I mean, I was interested in compilers. And then for me, the question was quickly, okay, that’s very cool to express, let’s say, computational algorithmic thought, but how can this ever be executed? And that’s where Simon, of course, was the big inspiration. 
+
+And then, as a result, because I was really interested in this, I did my master's thesis on implementing a functional logic language, and I implemented it in some weird compiler construction system that only existed in GMD, a German research institute for computer science, which doesn’t exist anymore. And the language was something I designed myself, which is kind of a, yeah, function logic. So think ML-like with the ability to have backtracking logic variables. 
+
+And at that time, it was Miranda people were talking about, but early Haskell specs were floating around. And so, because that was like in what I was working on, of course, I was very interested in seeing, and at the time, the big debate was, how can you ever do IO in a lazy functional language in a proper way, other than streams? And that’s, yeah. So it was kind of an indirect contact. I did something on functional programming, and then Haskell was like one of the things which was like references to put into my thesis, I guess. 
+
+But then, after my master's thesis in Karlsruhe, I went to Berlin, the Technical University in Berlin, to start a PhD. And in Germany, I mean, you’re not a student. You’re an employee of the university, wissenschaftlicher Mitarbeiter. And so I had to do teaching, of course, and the group, the professor, my supervisor, he was assigned to first-year teaching. And that was supposed to be in a functional language. So we used Haskell. It was not really Haskell, but Gofer, which is kind of Mark Jones’s Haskell-like interpreter, and yeah. And so for me, the real use of Haskell was actually during using it in the course to teach introductory computing. That’s the first real encounter, if you like.
+
+*MS (0:05:22)*: But then eventually, at some point, you segued into actually working on Haskell itself and on the GHC compiler. So can you trace a path from your PhD to there?
+
+*MC (0:05:34)*: Yeah, so my PhD was on parallel functional programming. And there was still this influence from logic programming. So I used basically two-level languages where a part of the coordination layer was kind of inspired by logic programming and to coordinate concurrency and parallelism, but the actual computations were purely functional. 
+
+And yeah, at that point, also having used Haskell for teaching, for me, Haskell was the natural language to use to implement this. And also already in my master’s thesis, the implementation, the abstract machine I developed for this functional logic language was basically a variation of Simon Peyton Jones’s STGM. So the abstract machine which underlies GHC. So I like the internals for GHC. 
+
+And when I submitted my first journal paper, one of the reviewers was Simon, and he was very gracious. What he sometimes does, he signs his reviews with his name, and he said he’s really interested. He thinks it’s cool what I’m doing, but it could be better. And he offered to help with that. 
+
+And yeah, so through this contact, I was eventually invited. At the time, Simon and Phil were still in Glasgow, and Glasgow had a Glasgow summer workshop each year. And so Simon invited me to that. It’s usually somewhere, some obscure place in Scotland. So I went to that. And so that kind of started getting really in touch with Simon, hence GHC development. 
+
+And I did small things on that, on GHC, but I think the first real contribution was with the foreign function interface, where I mean, I was the editor of that, then addendum to the original Haskell report for the foreign function interface. And there was an implementation of an earlier version, and I kind of made this, let’s say, more reliable, and adapted it to whatever we put into the standard at the end of the day. 
+
+And then, together with also again Simon and Gabriele Keller, when we started to work on associated types and type families and all that, I did the implementation of the first version of type families in GHC. And that, of course, was a rather major change of the type checker. So that’s the point where I really got into the depths of, let’s say, GHC hacking. 
+
+And at the same time, we had a project. We being Gabi and I together with Simon. So Gabi and I had a research group together, and then Simon was the person we collaborated with. We implemented this nested data parallel Haskell project for using Haskell for parallel programming, and that was less about type checking but required to get really deep into the whole code generation and optimize core-to-core optimizations and that kind of messy aspects of the compiler, I would say. 
+
+And also one of our students at the time, so Gabi and my student, David Terei, he implemented the LLVM backend for GHC. And that was also in the hope of improving – parallel programming performance is like the big thing. So it was all about getting as much performance out of GHC as possible.
+
+*MPG (0:10:10)*: Yeah. So, you really touched on both the FFI and the type checker, and so you work with a whole stack a lot, right?
+
+*MC (0:10:17)*: Yeah. Also, with data parallel Haskell that included extensions to the language, kind of to list comprehensions or monad comprehensions, if you like. And so it started from the lexer, some new tokens, the parser, and then you have to put it through the whole pipeline. I think something I never touched personally is really STG to machine code. That part, we had students like David who worked on that, but I don’t think I ever touched that bit, as in changing anything, but probably most of the rest of the compiler one way or another. Yeah.
+
+*MS (0:11:10)*: So I’m really grateful you worked on the FFI. That has to be one of the most thankless tasks in programming language implementation and design. So every year I want to say, “Well, C is now less relevant,” but that year never seems to arrive. So it’s been a long time since you started your work on that. Do you have any thoughts to offer on do we still need FFIs or was what you did – I remember that – I almost forgotten about that, but it was a deeply impressive work for me because I also worked on FFI. So is the way that you did it back then still the way you would do it now? Do you have any perspective on the whole FFI issue?
+
+*MC (0:11:50)*: I think FFI is a really multi-layered issue. I think FFIs are absolutely needed. The reason I got into it is because, well, like most people, I wanted to use existing libraries, which 99% of the time are written in a different language. And in this case, I’m also interested in user interfaces, and I wanted some proper user interface for Haskell user interface library. 
+
+And so I picked the GNOME GTK library to make a Haskell binding for that. And well, GTK is written in C, so you need a good C interface. And that was the motivation for me to start in the FFI and to – I also implemented a tool called C2Haskell, which is still being used, I believe. I mean, I developed the tool, and I passed maintainership to somebody else, but I think it’s still around. And that was expressed for the purpose of writing an interface to GTK and user interfaces. 
+
+Libraries have this disadvantage that they are gigantic. So just manually writing stubs for every function is not a process you want to do as a single person. Maybe there’s a lot of people who could do that. So I wanted to generate things, and that’s where the c2hs came in. And that shows already – it’s a multi-layered issue. So you need the basic interoperability. Haskell function has to be able to call a C function and vice versa. 
+
+But these days, in these large software ecosystems that apps usually live in, usually that you just have a program which uses a few system libraries, and that’s it. It barely ever happens. You’re interacting with the whole ecosystem, and then these ecosystems are huge, and then you need more automation for the API. And the question is how to do this automation. And I’ve been through multiple phases myself, if you like. 
+
+So, of course, you have to have the raw interface, and the goal with the Haskell interface is to have something which is really very basic but super predictable. And then as a basis to put more, better things on top. And so c2hs was what I started with. And at the same time, inspired by that, somebody else wrote hsc2hs, which is bundled with GHC as a kind of pared-down version of c2hs, because c2hs we try to generate as much as possible and was half a C compiler to do that properly. 
+
+And then later, when I started to get interested in developing for Apple interfaces, I wrote a library based on Template Haskell called language-c-inline, where the idea was to be able to embed C code in Haskell code. So you could have a Haskell module, and then using quasi-quoting from Template Haskell, you could embed C, actual C code, in your Haskell code. And Template Haskell would take this apart and generate a C file, which would be compiled separately, and then automatically generate all the interfaces in between the two. 
+
+And the reason I did this, because we, c2hs, I mean, did a lot and did a lot automatically, but having these two totally separate code bases and then a lot of generated code in between always was not very easy to handle, especially with big interfaces where you have to think in two languages at the same time. And so having it intertwined, the code of the two languages, that made it a lot better, I think. I think I had a talk at one Haskell Symposium about that. 
+
+*MS (0:16:34)*: I remember that, yeah. 
+
+*MC (0:16:36)*: And there have been a whole bunch of similar libraries after that. Not only after that. I think Mathieu Boespflug, basically at the same time as I, he kind of experimented with these ideas as well. I still think it’s a multi-layered issue. What I’m really impressed with is how Swift has done it. In Swift, you basically have seamless interoperability with C and Objective-C, and you basically don’t see – as a user, it’s invisible. You just use it. And all this generating stuff and cross-calling and so on, it’s all behind the scenes. But this requires, I mean, of course, a commitment because in the language specification, you don’t have the language and a separate FFI as we’ve got in Haskell. But then the kind of interfacing to that other language or those other languages is really spread a little bit throughout your whole language definition. So that’s the trade-off, basically. Much better developer experience, but the separation between the languages, it becomes more fuzzy.
+
+*MS (0:18:02)*: So, you mentioned Swift. How did you get involved in Swift? Isn’t Haskell the much better language? 
+
+*MC (0:18:09)*: So, the way I got into Swift is, as I said, I started to become interested in writing software for Apple device, Macs, and iPhones. I mean, when the iPhone came, I mean, it was the real first mobile computer. I mean, this was super attractive to write code for that somehow. At the time, you had to do it in Objective-C. So, well, I learned Objective-C because I really wanted to write a program for this thing, whatever language. 
+
+And also, one of our students, Andre Pang, as a professor, I think your students give a lot of impulses coming from your students. They bring all the new stuff. That’s how it works, I guess. So he was very much into – he was professionally developing for Macs. And also, he did his thesis about that. Also, Haskell. So Haskell interfacing with Cocoa. That’s the kind of GUI environment on Macs. And with Haskell, so to do that from Haskell. So I got into that. And that in the beginning was with Objective-C. 
+
+And then it’s now 12 years or so, I guess. Chris Lattner, at the WWDC, the Worldwide Developer Conference from Apple, announced Swift as a new language, which was quite a surprise at the time. And I was like, "New programming language, download specification." I read through that, and I thought, “Okay, somebody designed a language who actually knew what they were doing,” which typically is not the case. I mean, I guess that’s the reason why a lot of people like Haskell, because it’s a well-designed language. Maybe you like it or you don’t like it, but it’s well-designed. That’s objectively true. And Swift is a well-designed language from people who knew what they were doing. So as a programming language researcher, I thought, “Okay, that’s worth a lot. So let’s have a closer look at that.” And I wanted to write – I mean, I was writing code for those platforms anyway. And so replacing Objective-C with Swift seemed very attractive. 
+
+And then I had already started on an application called Haskell for Mac, which is a development environment for Haskell, Macs, surprise, surprise. And I had started this in Objective-C and Haskell, using this language-c-inline to glue it all together. And then the prospect of actually not using Objective-C but a language which adopts, which is very strongly tied, has a lot of inspiration taken from Haskell. I mean, Chris Lattner wrote a short post about where his ideas came from, and Haskell featured prominently in that. And you see there’s something called protocols, which is basically exactly typed as this. And all the training games, we do this with type classes, you do in Swift with protocols in a very similar way. So there are a lot of ideas from Haskell, which you can use in Swift as well. So that was like a very welcome replacement for Objective-C for me. 
+
+And of course, writing an application, which you actually want to publish professionally in a new programming language, is kind of a risky endeavor. But I mean, for me, it wasn’t critical. And I was much more interested to learn about this new ecosystem, this new language, than having the stability of Objective-C. And yeah, there was another component.
+
+The Apple developer ecosystem, what I learned at the time, is actually very open-minded. Apple developers, they are really kind of interested to learn about things which happen. And so I got in the beginning in the local Apple, in Sydney. I lived in Sydney at the time. Local Apple developer community, and they have meetups called CocoaHeads. And so, Sydney CocoaHeads meetup, I kind of started to go there regularly, and I gave several talks about functional programming and how they could use these ideas in Swift. Things like parametricity and how parametric types kind of force certain implementations, like A arrow A can only be identity function or this kind of stuff. 
+
+And that was a very interesting synergy because the Apple developers at the time, they were using just Objective-C, of course, and then this new language came, and Apple was kind of like, “Yeah, you guys have to switch.” I mean, they were kind of nice about it, and you just can mix and match, you can do it at your own pace, and so on. But it was clear in the long run, you will have to switch if you want to develop for these platforms. And you can use any language, but if you want first-class support, that language is going to be Swift, not Objective-C longer. 
+
+So, I also found that – I mean, I did a lot of teaching computer science. So, from a teaching perspective, I found that also very interesting. How can we kind of teach this paradigm of functional programming to not first, second, third year students at university, but to full-blown developers who know what they’re doing and have a lot of experience and very strong opinions about how things are to be done. But that was very nice. So, starting with these CocoaHead meetings and then also at developer conferences, I gave a lot of talks on basically essentially variations on functional programming in Swift, functional programming for user interface programming, and architecture of apps and stuff like that. And yeah, I liked that a lot because it allowed me to take my passion for functional programming and bring it to a broader audience of people who would actually use it for their jobs. I guess, Mike, you can relate to that. 
+
+*MS (0:25:09)*: Yeah, yeah, I can very much relate. As I keep saying, the Haskell community is sometimes very insular, and it’s very good to have some people who actually talk to the outside world, even if it’s just telling them how great the programming language they already have is. So you mentioned Haskell for Mac. For those who don’t know, could you briefly summarize what it is and why you wrote it?
+
+*MC (0:25:33)*: Yeah. So as I said, I did a lot of first-year teaching. I mean, introduction to computing teaching. And I did this a lot in Haskell, also not only in Berlin, but in Sydney. I developed a course together with Gabi. Well, when you teach like beginners, then you see where the friction points are. And Haskell tooling is, yeah, I mean, it is maybe unfriendly. It’s a very polite way of saying it.
+
+*MS (0:26:12)*: Yes.
+
+*MC (0:26:12)*: Some people would call it actively hostile. And you always get the impression there’s this like, in order to enter this sphere of Haskell greatness, you first have to suffer the pain of actually getting anything installed and running and working properly on a computer. And that’s, I mean, for anybody who’s been teaching Haskell. Now it’s like students with lots of different operating systems, this and that, getting everybody even to get Haskell running on their computer and editor, working somehow with it, is the big first struggle and demotivating for the students, of course. So that’s part of it.
+
+And the other part is, as I said, I’m interested in user interfaces, but I’m generally also interested in, yeah, user experience and how to make, like, computers and developer tools actually a pleasure to use instead of something you fight all the time. And one person who’s dedicated his work life, I guess, to a lot of this is Bret Victor, who has a lot of interesting talks about ideas for better developer tooling. And he has this idea of, yeah, playgrounds, which incidentally, when the Xcode is developed environment for Apple platforms, and when that started to integrate Swift, they also started some sort of playgrounds. 
+
+And what do I mean by playground? Playground is like an editor buffer where you type what you would usually type into GHCi, more or less. But when you change your program, it will always be executed in rerun all the time. So you see you change something in your program, and you immediately see for all the tests, which maybe would have typed into GHCi, what the result would be. And it just saves a huge amount of typing and switching back and forth. It’s so much faster than the interaction we have with editor GHCi, editor GHCi. And you can do a lot of other cool things in an environment like that. And if anybody is interested in that, I highly recommend Bret Victor’s website, WorryDream, where he has lots of videos about that. So I wanted to have something like that for Haskell.
+
+So, Haskell for Mac was meant to be really easy to use. You just install it. And after you’ve installed it, which is like one click, you go into the editor and you write Haskell, and it works immediately, and you have nothing, zero, nothing else to do, just like you wish it were as a user. And then have a playground as well. And have a playground where you not only have textual interactions like with GHCi, but you can generate graphics and display, like textual results would be in GHCi, and you could have HTML, and it’s in the browser component. And that’s really the idea behind Haskell for Mac.
+
+*MS (0:29:47)*: Yeah, I like it a lot as well. And there’s a successor product I’ve seen.
+
+*MC (0:29:52)*: Yeah. So Haskell for Mac, when I mentioned the – I used this FFI library, language-c-inline, to link Haskell and Swift together, because Haskell format, the whole frontend is written in Swift, but all the backend stuff in Haskell. In fact, it links GHC as a library. And that’s how it does all its magic for the playground and everything.
+
+*MS (0:30:23)*: So does that via the C FFI?
+
+*MC (0:30:26)*: Ultimately, it goes via C FFI. But as I said, FFI is a layer cake. And I wrote this Haskell with C inline. And the thing generates a lot of stuff, which ultimately is because Swift to Objective-C is via the C FFI, basically. And then bridging that to Haskell is very simple because it’s still the same kind of protocol of putting things on a stack, everything. So this integration of GHC API into the app made it very tightly coupled, of course, which was nice for these interactive features but very bad when GHC gets updated. And as we know, GHC API is not a particularly stable interface.
+
+*MPG (0:31:24)*: No, no. Not at all. 
+
+*MS (0:31:26)*: Yeah.
+
+*MC (0:31:28)*: Yeah. So that made it a hassle. And for advanced users who then wanted to use other versions of GHC, it also wasn’t very convenient. So I kind of, at some point, thought about, like, “How can we improve this?” And when I started Haskell for Mac, there was no Haskell language server or anything. And now we have the same Haskell language server infrastructure. So it seems kind of silly. A lot of Haskell language server features I built into this interface layer between my app and GHC API to maintain all this code, which is basically doing the same. This Haskell language server seemed kind of not very wise. 
+
+So the new app, Applicative Code, which is not just for Haskell but also Agda and Swift, and maybe more languages over time, it uses the LSP, the Language Server Protocol, to do the interfacing with the toolchain. And so there’s no dependency on a particular version of GHC anymore. So it’s really a completely different architecture. But that, of course, means things like the playground feature is more difficult to realize. So you get these trade-offs, but then it’s much easier to support multiple languages. 
+
+And I think Agda is a good example, maybe even less users than Haskell, but also a lot less choice if you want to use it, because basically you have to use Emacs. There’s a VS Code integration, but it’s rough, let’s say. So I mean, they are having a nice interface for that, I think. And there’s a lot, I think, in interface design that can be done for dependently typed language, where you have ways to generate code based on dependent types and so on. 
+
+I think there’s also a lot that could be – there’s a lot of innovation to be done as well, which is also interesting to me. So this is, at the moment, in beta testing. So if anybody is interested in being a beta tester, send me an email.
+
+*MS (0:33:53)*: Okay, that sounds like a good idea. So it seems all we’ve talked about now up to this point is sort of backend issues, right? But you mentioned in the beginning that you also worked on Haskell’s type systems. How did you get there, and why did you do it?
+
+*MC (0:34:06)*: Oh, why did I do it? I mean, I was always interested in type systems, but the reason here was to work on parallelism, actually. So yeah, it was a spinoff of the Data Parallel Haskell project. So Data Parallel Haskell project –
+
+*MS (0:34:22)*: Yeah, maybe you can say a little bit more on what that was exactly. 
+
+*MC (0:34:25)*: Yeah. So there’s this programming language, NESL, which is a Lisp dialect from Guy Blelloch, which is for parallel programming, data parallel programming, where you – and NESL is a purely functional language, but it has something like Lisp comprehensions, the array comprehensions, with the idea that everything that happens in such a comprehension for every element of the array happens at the same time, conceptually. Whether you have the parallel hardware to do everything at the same time or some of the things sequential, well, that’s a problem for the compiler. And we also, in Berlin, we used NESL for teaching a parallel algorithms course. So I knew that – and parallel programming, I mean, is quite a complicated endeavor. If you use something like MPI or these traditional libraries, it’s very complicated, and you get so many errors, which are super hard to debug, race conditions, deadlocks, everything. 
+
+But this is nested data, so we’re having data parallelism, which is restricted in expressiveness, but if you allow nesting, so recursion, you can express a lot more, but you still have the nice sequential execution model of a data parallel programming language. And the idea was to take this idea, this concept of nested data parallelism from this NESL programming language, and implement it in Haskell, and implement it by way of basically having these array comprehensions, which is a variant on Lisp comprehensions, if you like, but with a different execution model.
+
+That was a very ambitious project, because in order to – this nested data parallelism, you can’t execute efficiently. So the way to execute it is that there’s a transformation, I think it’s in Guy Blelloch’s PhD thesis, I mean also Guy Blelloch’s idea, where you can take nested data parallelism and you can flatten it into flat data parallelism. Now Guy Blelloch did this for Lisp. We had to do it for Haskell, meaning for arrays, which might include general algebraic data types. And that’s where a lot of our research in this project, together with Simon, went. So that’s the first kind of like, you really have to think really deeply about types from a programming language design point of view and a program transformation point of view. 
+
+But the second point, where we got kind of dragged into deep-type research, if you like, is in the implementation family because it turns out that if you want to implement this efficiently, and these flattened programs, and you want to do it in a way that your programming model is still reasonably high level, and you want to do this for GPUs, and you want to do it for multicore, so you want to have the right instruction level, then the Haskell type system proved to basically not be sufficient. And what was missing, you can describe that in several ways. 
+
+We actually had a library using function dependencies, if anybody still uses function dependencies and existential types to do this transformation or express those array libraries, parallel array libraries. But the problem with that is if you use combined function dependencies, existentials, even if two existentials – so these are types where we know there exists a type and we have a name for it, but we don’t know which type it’s going to be. But even if from the programming logic you know two existential types, if you unwrap them, if only you would unwrap them, they’re the same type, the compiler can never know that. That’s like inherent in existential types. And that turned out to be something which killed optimizations in core-to-core optimization passes. And so we were looking for ways to improve that. 
+
+And so, at the same time, the work on Boost, so C++ template programming madness, Boost, and the graph libraries, C++ graph libraries around that, they used something called associated types, where the idea is that you’ve got a type like a graph, maybe, and that’s associated with a node type and the edge type. So you have types, but they kind of depend on each other a little bit. And so this kind of brought us to think about, how can we do this in Haskell? And that’s what led to the work on type classes with associated types and then type families.
+
+And that then required to really rethink type inference and type checking and the type system itself, because once this introduces a totally new idea on the type level, namely an explicit equality of types, and yeah, that’s something which wasn’t in Haskell’s type system at all. I mean, there are other languages which explore, of course, these kinds of ideas. But bringing that into the Haskell type system, that was really the challenge for us. 
+
+And yeah, so you see, we went there basically only because we want to implement this array library. But out of that, I think at the end, we don’t have Data Parallel Haskell these days, unfortunately, because it turned out to be a lot harder than we thought to really do this transformation for the whole language and keep performance reliable. So, this predictability of “I know I’ll write this, and then we have that performance” is tricky in Haskell already. But adding this transformation in just made it too unpredictable. But we got a lot of spin-offs out of this project. 
+
+So, all the type family stories, and I think half the packages on Hackage these days use type families or associated types. I mean, that came out of that project, and the motivation was that implementing those data parallel arrays. But also other libraries, which some students of us wrote at the time. So ByteString, the vector library, and yeah, things which built on that. And then also other, when we kind of saw DPH is kind of taking the whole of Haskell and trying to parallelize, this is maybe a bit too much. We kind of went the other way and thought like, what’s the minimal thing which would be useful as a parallel programming language, but we don’t try to transform all of Haskell. And that’s where then the Repa project for parallel arrays and Accelerate, which we also took this time to keep use, came basically out of that desire to kind of like, okay, let’s start from as little expressions as possible, but being really fast and predictable and then add expressiveness until we say stop, because you can’t keep it predictable. 
+
+*MPG (0:42:34)*: So, I mean, I guess it’s the same questions for the FFI. Like, now you have some hindsight. So, how would you have changed how type families work? Because, like you said, they become ubiquitous across all of the Haskell ecosystem.
+
+*MC (0:42:47)*: Yes. So personally, I think, I mean, the main problem with type families is really that they were added retroactively to the language. And the initial design of the language had some, yeah, things baked in, which kind of made this somewhat awkward, but that was, of course, totally not predictable at the time when the language was designed. Like, for example, that we usually say functions are lowercase, but type functions are uppercase. That actually doesn’t make any sense. And if you look at dependently typed languages, they are, of course, uniform across these things. That’s a problem. 
+
+The other then, there has been work on top of our work, like for closed-type families. That’s something we always knew is needed in some cases. But also, I mean, we have it in Haskell now, but these things become awkward. They become syntactically awkward. They become like – because all the existing problems still have to work. You can’t change anything. So it’s just, you’ve tried to find the way to embed it in the language without too much noise and friction, but you always have to make compromises because you can’t go back and just change the whole language design. 
+
+And then when you have languages like Rust, for example, which take this on board right from the start, then you get much more orthogonal design. And that also makes it a lot easier to understand, of course, for people. So I think usability could have been improved a lot if this would have been added right from the start, or we would have been allowed to change the language, if you like.
+
+*MS (0:44:50)*: Yeah. Well, it seems, I mean, the underlying assumption in the original Haskell design was that there would always be this two-level thing of values and types, and they would stay separated forever. And that’s kind of unsustainable in the world of dependent types. And the other one seems to be that, like, the original type class system is essentially a small logic programming language, right? And you mentioned Mark Jones’s idea of having functional dependencies, which kind of extends that idea of doing a little bit more logic programming. And so it’s kind of consonant with sort of the original type class idea. But now you’re doing functional programming, which seems kind of natural in a functional language, but it’s not the idea of Haskell’s type system, which is logic programming-based. 
+
+*MC (0:45:31)*: But for me, it was very logical. And the reason is, as I said, I started with functional programming because I came to functional programming doing something with functional logic programming. 
+
+*MS (0:45:44)*: Yes.
+
+*MC (0:45:45)*: And so for me, it's kind of saying, “Okay, our type system is no longer a logic language. It’s a functional logic language.” I always thought that’s a good use of functional logic programming.
+
+*MS (0:45:58)*: Yeah, absolutely. I agree. I mean, type families are indispensable, I think. But this idea of having actual functional – I mean, so there’s a little bit of functional programming in that place, and there’s logic programming in other places. But for the full vision of functional logic programming at the type system, still maybe it needs another language, right?
+
+*MC (0:46:19)*: Yeah. I mean, then if you stratify it really, then you very quickly come out with a dependently typed language. And you could, of course, have a dependently typed language where you don’t allow value-level things to be used in types, so that it’s a bit more statically checkable than something like Agda. You could do that, and then everything would be a lot more orthogonal. 
+
+But then you get even Agda, where people kind of define structures again, which are basically type classes, because you want the overloading. And that’s the problem. You also want to kill the overloading with the same mechanism, which I think is very elegant. And that’s also interesting to look at what Swift did, because I mean, Swift has a lot of good ideas in strongly typed, like Haskell, as strongly typed, and you can go as crazy with types. Very convenient for a Haskell person. But it’s also very strict about mutability in a different way than Haskell. 
+
+So, Haskell is this kind of like you don’t mutate, full stop. Swift is more like, okay, you mutate, but you tell me. And then you have a lot of mutability control. And you even have something like lenses in Swift. So Swift really goes a long way in kind of doing all this type of nonsense in the similar ways as Haskell but more kind of fully baked into the language. 
+
+So let’s say from a programming language researcher’s point of view, it’s maybe less elegant, but I think for a developer, it’s more accessible. It looks kind of more like you more quickly think, “I know what’s happening.” Then maybe you still don’t know what’s happening. But you already got a little bit of an idea. Whereas in Haskell, it’s kind of like, “I have no idea. This is a new program,” which makes it a bit more approachable. But in Swift, overloading is not coupled to protocols, which are type classes, in the same way as it is in Haskell, because Swift, of course, has this OO (object-oriented) legacy as well. 
+
+But I think one reason why I like Swift in comparison to other languages of the same generation, these hybrid languages like Scala, Kotlin, Swift, and so on, Rust a little bit, is because Swift maps object-oriented features to functional features. It’s basically compiling the object-oriented stuff away to end up with the functional language and then do the rest. Whereas other languages, like Scala, for example, do the opposite. They kind of take the object-oriented paradigm as the core and then put functional stuff on top. Then you get things like case classes for case pattern matching, which makes the functional programming, to me, less elegant than in Swift, where you’ve got algebraic data types of code. 
+
+They have funny names because Apple tries to use names which sound less scary, but it’s exactly the same thing. It’s recursive algebraic data types, and you just have pattern matching with nearly the same syntax, what we would also recognize as pattern matching. So, in that sense, doing functional programming in a kind of mainstream programming language, Swift, really, I think, offers the purest experience, if you like. 
+
+*MS (0:50:17)*: Yeah. I mean, Swift, of course, had the advantage of hindsight, right? Scala had already existed, and I think it took Scala a long time to realize that you really needed to bake in the functional features and couldn’t just compile the functional features to the object-oriented features, right? Finally, Scala 3 takes a very similar route, I think.
+
+*MC (0:50:41)*: Well, I think there’s now this object calculus, which is like the core language. So it’s still like desugaring to object-oriented. But I think the real difficulty with Scala was that it wanted to run on the JVM. And running on the JVM, I mean, we know this from other projects which try to build functional languages on the JVM or even on Microsoft’s CLI, so F#. You just have to make compromises because there are certain things which are difficult to do or where class files don’t load because they are not considered safe, or you explode the stack because you don’t have tail calls. So that’s the kind of limitations which the execution engine imposes on you. 
+
+And I totally get the idea to say, “We want to run on the JVM.” I mean, there’s a huge practical value in that. And I mean, there have been plenty of attempts to compile Haskell to the JVM. There’s a good reason why that’s very difficult. So in that sense, I think Scala’s language design was very much constrained in what it could do due to this hard requirement of being able to run on the JVM. So I don’t criticize the language design as such. Given the requirements, it’s a very good design. But if I just look at how much do I like using language, well, then my conclusion is what I said. 
+
+*MS (0:52:28)*: So, there was some bits now about what other languages did and maybe should do. But maybe for the end, let’s circle back to Haskell one more time. So, do you have any advice for the current set of maintainers of GHC and the Haskell language on where things should go?
+
+*MC (0:52:44)*: Well, my advice, I think, is to finally realize when you have a project, a new language, or a new whatever, a computing thing, you have a certain budget for being weird. Now, Haskell as a language, it probably already exceeds that budget but definitely uses it up. And then the rest has to be not weird. And I think that has been really the reason why now – I mean, I’ve also been using Haskell in industry and so on. So I see a little bit how much adoption we’ve got and so on. 
+
+And now, actually, we see a reduction in Haskell use, whereas something like OCaml is kind of getting more and more popular. And the reason I think is that we – in the time where people still absolutely wanted to use it, we still didn’t make it easier to use it. The Haskell toolchain has always required extra things, hard to link, hard to compile. Cross-compiling never really worked properly, which these days is a really big problem. Compiling to mobile devices is like magic for Haskell. Compiling to WebAssembly is kind of working now because Cheng has put a lot of work into it. But these things, if the language is weird, you’ve used up your weirdness potential. And then these things—cross compilation, compile to a mobile device, compile to WebAssembly, install the thing, link with something else—needs to be just straightforward, like standard tools. No variation whatsoever. You just don’t have any budget for that anymore. 
+
+And that, I think, is – and I find it sad, that I think the adoption of Haskell ultimately has been kind of constrained by that. And you can, of course, say, “Well, it started as a research project, so that was the priority.” True. But I still find it a little bit sad. And to draw a last comparison to Swift, that’s where Swift did the exact opposite. As a language, I think to the Objective-C programmers, it was imposed on. It was at least as weird as Haskell, but integration to toolchain was exactly like everything before. So from that point of view, it was never any different. 
+
+Swift can perfectly do cross compilation and have something like Template Haskell, which is called macros, in the same compiler. But after how many years, we haven’t managed that. So that’s my, well, critique/advice to toolchain maintainer. Even the Haskell language server, you see it. I mean, it does a lot of things, but everything is a little bit weird. And you start it, you have to pass an argument. Okay. It’s totally within the spec, but nobody else requires that. So it’s kind of like these things. You just make it a little harder here, a little harder there, a little harder. Another point with tooling that just grinds people down. 
+
+*MS (0:56:26)*: Yeah. I can very much get on board with that. So I hope the GHC designers and the Haskell language designers are listening, the current set. And with that, thank you very much, Manuel. This was wonderful.
+
+*MPG (0:56:38)*: Yeah, thank you.
+
+*MC (0:56:39)*: Thank you very much for having me. It was great. conversation. Thank you.
+
+*Narrator (0:56:45)*: 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 Gold-level sponsors: Input Output, Juspay, and Mercury.