diff --git a/podcast/65/transcript.markdown b/podcast/65/transcript.markdown
new file mode 100644
index 00000000..1683ec5d
--- /dev/null
+++ b/podcast/65/transcript.markdown
@@ -0,0 +1,171 @@
+*Samantha Frohlich (0:00:15)*: Hello and welcome to this episode of the Haskell Interlude. Today, Matti and I –
+
+*Matthías Páll Gissurarson (0:00:21)*: Hi.
+
+*SF (0:00:21)*: – are joined by Andy Gordon from Cogna. We discover the origins of the bind symbol, hear about Andy’s involvement in the introduction of lambdas into Excel, and discuss using AI to allow non-programmers to write apps using natural language.
+
+All right. So today we’re joined by Andy Gordon from Cogna. Welcome to the podcast.
+
+*Andy Gordon (0:00:43)*: Very glad to be here.
+
+*SF (0:00:44)*: Yeah, thank you. So, how did you get into Haskell?
+
+*AG (0:00:48)*: I fell in love with functional programming when I was an undergrad at Edinburgh Uni doing computer science, and we learned ML in second year. And then in my final year project, I adapted a compiler for Standard ML. I graduated in ‘87, so this is really early on. And Edinburgh had a compiler for an early version of ML, and it had been adapted to Standard ML, which was sort of in the process of happening in the mid-’80s. And so my final year project was to adapt this compiler so that it generated native code, which is actually six to eight thousand native code. It was actually a bytecode compiler. That was the original machine or the original code I was working from. I think it actually was based on code, or at least ideas that Luca Cardelli had done a few years earlier. He’d been a PhD student in Edinburgh earlier, and he became a big hero of mine. And later on, I wound up working with him at Microsoft. 
+
+Anyway, to stick to the point of how I got into Haskell, that final year project got me really stoked about functional programming. And I went down to Cambridge to do a PhD, and I wanted to work on functional programming. And I asked around, and various people said that input/output was rather underdeveloped for pure functional languages. And at the same time, I arrived, and then people were very excited because I think that summer there’d been the first meeting of the Haskell Committee at a – I think it was in Oregon. I think the predecessor of ICFP, at that meeting, there had been a follow-on committee discussion about doing a standard lazy functional language that I think originally we're going to call it Curry, but then later on it became known as Haskell. And a guy called Jan Fairbairn, who was a pioneering lazy functional programmer, was a research fellow at Cambridge, and he told me about all this and encouraged me to look at input/output. There were discussions in the Haskell Committee about how to do input/output, but apparently, they were sworn to secrecy. So there was a mailing list, and he was on it, and he set up a sort of black arts dark net kind of router. And so we forwarded the mails of the discussions onto me. And so that was interesting information. 
+
+Anyway, let me see. So it was a long period, my PhD, but that was the start of it, how to do input/output. And I wound up studying input/output in detail in the thesis. Afterwards, I published the thesis, and I got to know folks up in Glasgow, like Simon PJ and Phil Wadler. They invited me to come up and talk about the thesis. It was a little bit of a grilling. Phil was super impressive, actually. I turned up and I had a bound copy of my thesis with me, and he more or less examined it. He just took me into his office and said, “Andy, tell me about your thesis.” And we wound up going through page by page, a bit like a viva. So that was great, actually, to get all that sort of feedback. 
+
+Anyway, they said, “Okay, we like what you’ve done on doing.” I’d done a formal semantics for monadic IO, and they said, “Why don’t you join the Haskell committee to define monadic IO for Haskell?” And so that’s how I ended up joining the committee.
+
+*MPG (0:04:54)*: Yeah, that’s where you – but you entered the bind operator, or at least the symbols for that, right?
+
+*AG (0:05:00)*: I did, yes. Yes. The “>>=”.
+
+*MPG (0:05:03)*: Right.
+
+*AG (0:05:04)*: So I think the history of that is that during that period when I was doing my PhD, I actually wanted to do – my original draft title was Functional Programming and Concurrency. And I’d come from Edinburgh, and my first ever lecturer at Edinburgh University was Robin Milner, and he taught us Pascal when I started there. And later on, we did a CCS course within the calculus of communicating systems, which was a precursor of the pi calculus, which is now maybe best known through all the amazing work on session types over the last 10, 15 years. 
+
+Anyway, I was kind of aware of this style of concurrent programming, and I realized during my PhD that if you could find a way to add side-effecting operations like an input and output to a pure functional language without disturbing, if you like, the purity of expression evaluation, then you could also add concurrent operations as well, you know, arbitrary sort of imperative behavior or communication on channels. And so I did various experimental implementations of parallel functional programming inside various precursors of Haskell. I mean, I think I had my own implementation of a Haskell-like language. I did it with Nick Benton. And then a bit later on, Mark Jones at Oxford was a PhD student there, and he had a system called Gofer, which was an early implementation of Haskell, or a superset of Haskell at the time, and I did experiments with that. 
+
+But anyway, what I did was I did a data type of – it was usually called behavior, where the data type basically describes the different kinds of actions you might have to do input/output. So the data type would have a constructor for input, and it would take a lambda as its argument, and the lambda is a continuation. It would accept whatever being input from the keyboard or whatever, and then pass it to the – and then the lambda would produce another behavior, or another constructor of a behavior might be output, and it would have two parameters. One would be the thing to output, and the second argument would be the continuation or the next behavior to run. And then to represent parallelism, you can have a par constructor that would take two behaviors, and it would run them in parallel. And then you could have channel-based communication rather than just simple input/output. And the output constructor on a channel in this type of behaviors would have three arguments. One would be the argument of type alpha, and then there would be an alphaChan on which that first argument would be sent, and then there would be another behavior that would be the continuation, and so on. You could have choice and so forth. 
+
+So you could take languages like CCS or pi calculus, like communication, and encode it in this data type, but it was a single-type behavior. And so, as I say, I did all these experiments, writing programs using this type, and almost immediately realized this is really irritating, having to thread the next behavior through. And I realized that if you had a type, sort of alpha behavior—basically it was a monad that would be a behavior that returned an alpha—then that was a lot easier to actually program with. So I found this from doing experiments. You could then have a monadic-style collection of operators that behind the scenes would construct values of the original behavior type. And in order to do that, you naturally had a sequential composition operator that would take – what would you do? It would take a alpha behavior. So I’m giving away that I was – I must have been writing in a more ML style, where you set alpha behavior rather than behavior alpha. But anyway, I’m just telling you how it evolved. So we’d have an alpha behavior would be the first argument, and then you’d have an alpha arrow beta behavior would be the second argument. And then the result would be a beta behavior. And that would be coded up in terms of continuation passing and returning the original, you know, on top of the original behavior data type. 
+
+Oh, and really, to complete my story, I’ve told you these data types, and of course the idea was that you could just write these down as types in the purely functional language. Because you hadn’t added anything to the underlying implementation, you hadn’t changed the evaluation semantics of the language. It was still evaluating expressions of values in a side-effect-free style. And then you would have a kind of execution loop that was implemented at the top level, and it would execute these behaviors. It would do the concurrency or would do the input/output or whatever. So, that was a kind of thinking I had during the PhD.
+
+And then I find when writing these, then – I can’t remember. I must have a keyword like bind or next or something. I really can’t remember. So when I say a keyword, I mean an identifier for doing what became bind. And I soon realized having an infix operator was just a lot easier to write. And I think in the original thing I did in ‘89, it was something called PFL+. It was never published, but it was a parallel functional language done in this style. There was some other ASCII art I had apart from the “>>=”. But I’m pretty sure by the time I did a re-implementation in Gopher when I was finalizing the PhD, I kind of switched to the “>>=” style. And I picked that notation, since you asked, because the idea was the greater than, greater than was the idea of one thing after another. It’s an arrow, obviously. And then the equals was meant to note that there was a kind of binding taking place, that there was a value being assigned to the lambda that came immediately after the equals sign. And so naturally, there was a variant that was just greater than, greater than, which kind of threw away the argument, because I found quite often what you were doing was you were having an action that had nothing to return. So it was returning unit or void or whatever. And so it was just useful to have a sort of synthetic sugar that just always threw that away. So that’s where that notation came from, and it wound up in the last chapter in my PhD, which I did in ‘92. 
+
+And then, as I say, a few years later, myself and Kevin Hammond were asked to do the def or the bindings for Haskell 1.3. I was happy with that notation, so we just stuck with it. And I think that was before all the sort of type class mechanisms had been introduced into Haskell. So I think at that point, you couldn’t sort of have a class of monads and et cetera, and all that. It’s become much more elaborate since then. So we didn’t define a class of monads. We just used those, that particular concrete syntax for the particular IO monad. But then later on, other people did the richer type systems that could parameterize over things like monads, and they, happily for me, kept the ASCII art. So I’m very proud that there’s a sort of trace of my PhD work that has stayed in Haskell.
+
+*MPG (0:13:05)*: Yeah, and I mean, it’s even in the Haskell logo now, right? It’s become like this iconic. This is what Haskell is all about. This is “>>=”, and it was very – because I remember when I saw your keynote and I’m like, “Wow, I didn’t –” because you realize that someone must have picked that ASCII art, but then you see it and you’re like, “Wow, I didn’t know.” No, that was cool. So what did you do after Edinburgh and after the report? 
+
+*AG (0:13:29)*: So I did my undergrad in Edinburgh, and then I did my PhD in Cambridge, and I had a fantastic year in Gothenburg. And Mary Sheeran was my employer, my advisor in Gothenburg. And as a postdoc, she was a great boss. She roughly said, “Do what you like, Andy.” So I had a lot of autonomy to do different things. Actually, one thing I did was I was into theorem proving, and I wanted to use interactive theorem provers to reason about functional programs. Maybe I should go back a little bit. Well, okay, let me answer the question. I could go into more detail, but maybe it’ll be too much detail. But I wanted to build up infrastructure, and it was in the HOL, H-O-L, theorem prover to reason about operational semantics of functional programs and do proofs about functional programs. And one of the things, one of the claims or hypotheses in my PhD thesis, I kind of looked it up before this conversation. So my first point wasn’t about input/output at all. It was—I’m reading it out—an operational theory of functional programming is suitable for precisely specifying a functional language and proving properties of functional programs. I hadn’t really thought about this for years. I haven’t read this. In the first chapter of my dissertation, I had explicit hypotheses, and the other two were about input/output and monads and all that. But the first one was just about operational semantics or operational theory. And I was reading that last night and thinking, “Wow, this is like blindingly obvious.” Of course, I mean, almost all papers at, I don’t know, popular ICFP, if they develop formal semantics of functional language, you’ve got a core language and you maybe added something to it, or you’ve got some fancy type system and you want to prove something about it. You have an operational semantics, and then you prove progress and preservation theorems or whatever. This is just absolutely standard. So I was thinking, “Why was I bothering stating this as a hypothesis in 1992?” And I just reminded at that point, at that time, I think operational semantics wasn’t very respectable. I’d gone through all these courses, and there was a big emphasis on domain theory and category theory. And it seemed to me as a grad student that operational semantics seemed sort of less respectable than things like domain theory. And I personally found domain theory and category theory a bit harder than operational semantics. I find operational semantics are more intuitive. I mean, they correspond really directly. A big step semantics is really directly saying in a few symbols what it means to evaluate each of the constructs of the language. So I think it’s just directly stating in the language’s own terms what the program is doing, and I found that fairly straightforward. And I think I felt a bit dissatisfied that you had to go to these, rely on these other, sometimes quite sophisticated and maybe hard to convey theories. 
+
+There was a academic, or Doug Howe. Actually, he was at Bell Labs at the time, but he had a great paper at LIX in 1989 where he showed how you could – let’s see. He started with an operational semantics of a programming language, and then he defined a notion of equivalence between programs, between expressions in terms of their operational behavior. It’s a kind of bi-simulation, if you like. But if you do that, it’s not completely clear that it’s a congruence in the sense that if you’ve got a larger program and you look at a sub-expression, and you replace that sub-expression with an equivalent second expression, that the whole program or the two programs you obtain in that way are equivalent. That’s what congruence means, or being a congruence means. I think that was one of the problems with why operational semantics had a bit of a bad reputation. That it was quite hard to show that these equivalences were actually congruences, which is essential for doing equational reasoning. So Doug Howe came up with a great technique for showing that bi-simulation equivalence on any program is in fact a congruence. And this has been really important in my dissertation. That was a technique I applied to a bunch of settings and used it, in fact, to show that, well, maybe later on. But anyway, I used that technique to show that functional programs with side effects still had had an equivalence that was a congruence.
+
+So I’d done all that on paper in my PhD. And so when I was in Gothenburg, I’d learned the interactive theorem prover Cambridge HOL, actually, when I’d been in Cambridge. And when I was in Gothenburg, I gave a grad course about it and also said about building up the infrastructure so you could do proofs like that inside the theorem prover and hopefully hence avoid errors. Turned out to be, as often in my career, just really unrealistically ambitious to do all of that. And in fact, the initial problem was simply, how do you represent the syntax of a functional language inside the theorem prover, particularly when it’s got binders? You can’t just easily write down a data type that has alpha conversion on it. So I developed this theory of – I developed the infrastructure inside HOL to represent syntax up to alpha conversion. And behind the scenes, I did it using De Bruijn terms. And so you end up with nice De Bruijn terms just out of the box, gave you a theory of syntax up to alpha conversion. But I felt strongly that if you are writing, if you’re doing proofs about a functional language, you shouldn’t have to use De Bruijn notation. You should be able to use the ordinary notation. And so I kind of lifted the underlying theory that worked for De Bruijn terms, or the equivalent you got that way, to a surface syntax that had conventional syntax. So I think I was one of the first to do a theory of syntax up to alpha conversion inside a theorem prover. And that was the locally nameless representation that I implemented there, that later on became sort of more famous in the POPLmark Challenge, for example. 
+
+So that was the thing I did when I was in Gothenburg, and then I returned to Cambridge and had a few years as a Royal Society University Research Fellow there, which are great roles to have. You have five-plus years of research funding to really pursue the things that you want to. And yeah, I had a great period where I’d collaborated with Luca Cardelli, who’d been a hero of mine, as I said, when I was a student. And we did something called the Ambient Calculus. That was in the era when the internet was kicking off and people were starting to think about agents roaming around the internet buying stuff for you or whatever, or the ideas of mobile code. I mean, Java had made mobile code popular, but we were thinking about mobile computations of various sorts and thinking about how they might pass through different security domains. And so that led to the Ambient Calculus, which was something I worked on for several years. And Luca joined Microsoft when Microsoft set up their lab in Cambridge in ‘97. And so I asked for a job and ended up as one of the first employees there and then did a bunch of things at Microsoft.
+
+*SF (0:22:29)*: What did you do at Microsoft? 
+
+*AG (0:22:31)*: Sam, it’s a long story.
+
+*SF (0:22:33)*: I hear you did something quite cool in Excel that might be interesting for our listeners.
+
+*AG (0:22:39)*: Absolutely. So Simon Peyton Jones also joined Microsoft, like about a year after me. He was the one who made connections with the Excel team, which is really cool. He just went out to Redmond, and he realized that spreadsheets are – spreadsheeting is functional programming. The Excel formula language is a purely functional language, pretty much. And he made some connections out there. And sadly, nothing happened at that point in the late ‘90s. But then one of the people he made friends with in the Excel team wound up becoming, about, I don’t know, 15 years later, very senior and was appointed as the product manager, the chief product manager for Microsoft Excel back in – I think it was in 2013 or so. He asked one of their product – well, they were called program managers at the time, or PM. Let’s say PM. A PM in Microsoft would be someone who would be in charge of making the product successful, and part of that would be designing features that would, I guess, help customer pain points and make the product more attractive to customers.
+
+And so this guy, David Gainer, who was the person Simon had reached out to, when he became the head of PM, he wanted to consider what are the radical changes we could make to Excel to make it attractive, make it fit for purpose for the next 10, 20 years. It was already a super successful spreadsheet product. I mean, it was, and still is, the most successful, most popular spreadsheet product. But he wasn’t complacent. And he assigned someone to go and talk to customers, find out what their pains are with the product, and figure out some solutions. So it’s a long story, but this guy went and talked to customers and found that very often they were sort of simulating functional programming structures by other means. So in those days, the only thing you could have in a cell in Excel, I mean, roughly, was either a string, a text string, or a number, and things like a Boolean or a date were actually just special cases of numbers. So you could only have a scaler. Well, either a scaler or a string, but nothing else. And very often people wanted to represent objects or records. And so they would be hacked up as strings. And some big banks or other firms that were using Excel had built elaborate libraries that simulated proper programming structures. 
+
+And also another problem was that customers very often had what they called mega formulas—a formula that would capture a particular repeated computation that they wanted to, well, repeat. They’d figure out the way they calculated – I don’t know. Well, mortgage interest is built in, but some sort of calculation. Maybe a tax calculation. It’s quite elaborate to figure out how you calculate income tax. And so you’d like to get it right once and then be able to reuse that formula. And so they’d have these massive formulas that sometimes they would actually store elsewhere, like in a text editor or something, and then paste them back in. So obviously, to you and me, you realize, “Oh, you want a lambda,” or some sort of way to define a function and give it a name and reuse it rather than keep it outside the product. So they discovered all these snags. 
+
+And then David Gainer remembered that Simon had been talking about some of these ideas way back. And so he got us involved in Microsoft Research, and Simon asked me to join the team, which is great. Simon had asked me years before to join Haskell 1.3, so I don’t mind saying I have a big debt to Simon PJ. He’s a great guy. So I joined the team, and I was a manager by this time, and I thought we had several people on the team, and we did some prototypes of adding records or actually arbitrary data types to Excel. The project was internally called Project Yellow, and it took many years. The Haskell code base goes back to the mid-’80s. So remember I said when I was in Edinburgh, I’d worked on this bytecode interpreter for ML and added native code options to it. Well, that code I’ve been working on in Edinburgh, I mean, in a parallel universe in the Pacific Northwest, the guys at Microsoft had built a bytecode interpreter for Excel, which is a weird parallel. Apparently, Bill Gates was directly involved. They had a weekend in a hotel in Bellevue, in I think 1984, and kind of sketched out the first version of Excel, which eventually came to market, I think, in ‘87. So, that happened in parallel. 
+
+So, the code went back to then, and by the time we were working on it, I mean, we actually built Excel, and it was quite a heroic effort. We would get the source code and compile it, but it’s not a simple matter of doing a checkout and hitting compile. It’s really quite elaborate. And so we did some prototypes about Andrew Kennedy, who I think is known in the Haskell community. He’s a great researcher. He’s done many different things, but he was the guy who first, in MSR Cambridge, added lambdas and actually implemented lambdas and entities and various other extensions, units. He’d done his PhD on adding units to functional programming languages, and he showed how you could have values with units as a sort of basic data type in Excel. 
+
+So we had this running, I think, in about late 2014, 2015. So 10 years ago, we had – actually, where I sit in Cambridge, it’s not very far from the Microsoft Lab. So just around the corner, we had like PCs with Excel with some custom extensions that we’d added that showed the viability of higher-order functional programming implemented on this old bytecode interpreter from way back. And then there was a long campaign to actually get this into the product that took many years. But eventually it came out. So, I mean, I forget exactly. I think about 2020 lambdas came out in Excel, and they’re there, and they’re really powerful for customers, perhaps, especially because they can be used as arguments to other functions. So the higher-order nature is really useful. So Excel always had arrays, but it was quite tricky to have operations that acted on arrays. But we added all the typical combinators you might imagine for programming with arrays, and many of them take lambdas as arguments. So these are called dynamic arrays, and they’re great. So they’re like variable-size arrays. They’re actually two-dimensional matrices, and you can write a formula in a single cell. And if it returns one of these matrices, it sort of spills out into adjacent cells. So it means you can – there’s now a style of writing spreadsheets where you write fewer formulas. You don’t drag fill so much, and you copy a formula, but instead you write a sort of formula that returns a whole array. And that way you end up making fewer errors in spreadsheets. That’s a team I was very happy to be part of. 
+
+*SF (0:30:38)*: So what took it so long to get it into the actual product? Was it just a lot of implementation to do?
+
+*AG (0:30:43)*: Roughly, yes. The underlying code base, as I say, goes back to the ‘80s. It’s in C++, the core of the code, and it was written in – I mean, they really obsessed with efficiency. So it’s old code that was optimized for efficiency rather than sort of clarity. It’s the standard software engineering problem. So it meant that to actually make changes in the code base and do it reliably was very time-consuming. So each particular bit of functionality had to be very carefully thought through so that it could be done on time. 
+
+I must have say it was – so I was at Microsoft for 26 years, and the early phases, I did a lot of research, and it was kind of like being on a research fellowship, a bit like when I’d been a Royal Society Research fellow, and you can kind of just autonomously pursue what you think is interesting research. I mean, of course, I was also trying to find ways to make an impact in product, but also, we were really publishing a lot. 
+
+On the other hand, the last period, which was, I don’t know, six, seven years, I was working continuously with the Excel team, and I learned such a lot about how to build a product and how to coordinate multiple people to do a demanding software engineering task in an efficient way. They would think very carefully about what they were going to release and what would be the minimal, useful feature to release. And for Project Yellow, I mean, we had all these things implemented, and we were gung-ho about releasing it all, but they realized that we take ages to do all that. 
+
+So I think the first thing they did was just records. And there was a great use case for that, which was stock prices. And they knew lots of customers were using spreadsheets to track finance of various sorts, whether personal life or in your professional life. And so they wanted to be able to have, say, the Microsoft stock price or some other stock quote, or a currency, the euro-to-dollar conversion rate, or whatever. You like to have that sitting in a cell so that you can get the price and then use it in other calculations and have that update as the day goes by. And they realized that was a great use case. 
+
+So the product managers who wanted to produce something that customers could actually use and that they could promote at the annual marketing events that the company has to push a new feature, they said, “Okay, of all this stuff that the guys in Cambridge have implemented, let’s take just the entities, and also let’s add the ability to link to external sources so they can be updated.” And so the other stuff was put on hold, and they said, “Let’s just focus on that.” And then they would think very, very carefully, “Well, what’s the minimum we need to do in the code base so that we can implement that feature?” But they would also be thinking, “Let’s look to the future and make sure we leave the code in a way that it could easily be extended so we could have lambdas as well, and we could have these dynamic arrays as well. We could have values and units as well.” But they wouldn’t implement those things. At least they would do a minimum that – so, they could see that there’d be a path to doing that. They didn’t want to foreclose the future, but then they would focus just on that one feature. 
+
+So, what happened was that the first feature that came out, if I remember right, was these entities or these linked entities that would bring stock quotes. And then the dynamic arrays came a bit later. And eventually lambdas came out in 2020. So, for me as a researcher, it was really mind-opening, just seeing how a really well-run product team thinks about making good use of engineering.
+
+*SF (0:34:47)*: I’d imagine as well that they did a lot of user testing if it’s actually going to a product. Did you learn anything about the usability of higher-order functions and sort of functional programming style from that? Did you get any feedback?
+
+*AG (0:35:02)*: Well, that’s a great question. I can’t remember what the product team did, but Simon and I did a paper. It was called Elastic Sheet Defined Functions. That was like higher-order programming, and we did user studies with that. During this period, I collaborated with HCI (Human Computer Interaction) researchers. And that was a real delight because I learned a ton from them as well. So I worked with them to design user studies. So we could see in a nuanced way how people were able to write functions, reusable functions that acted on arrays inside Excel. What we found in that paper was that the techniques we discovered actually did make people more productive. We would do things like defining certain tasks to write a spreadsheet or modify a spreadsheet so that it turned into a function. So the idea was you would have an existing spreadsheet, a spreadsheet maybe with multiple rows in it that repeated a calculation, and you’d like to turn that into a reusable function that could be applied in other settings. And we had a particular way of doing that that I think behind the scenes generated a lambda, but it kind of hid that from the user, because I guess we kind of worried that – a lot of people worried that most spreadsheet users might be intimidated by lambda. So we were trying to kind of hide that. And we found in this study that this technique did do better than not using it. I’m afraid, although we researched this in great depth, that hasn’t really made it into the product ultimately. That’s life. 
+
+*MPG (0:36:52)*: But then you, yeah, I mean, you recently quit Microsoft Research, right, as we introduce you as Andy Gordon from Cogna. So what are you doing now?
+
+*AG (0:37:05)*: So I’m now a science advisor at Cogna, and Cogna is an AI company in London. We were founded in 2023. The two founders are Ben Peters and Lars Mennen. And they’d heard of me because one of the things, towards the end of my time at Microsoft, was to look at using natural language to generate Excel formulas. So I was going from natural language to functional programs, and that ended up as part of Excel Copilot. And I’d been giving – had I been giving talk? That’d certainly be writing papers about natural language as a programming language, I suppose, as a functional programming language where you’d use natural language to say the kind of computation you’d like to have applied to a table, table of data. Maybe if it’s a bunch of dates, maybe you want to return a column, which is the number of days between now and that date. And so we had a system that could generate those formulas that would do that. 
+
+So these guys came to me middle of last year and said, “Andy, so what if natural language really is the next programming language? What are you going to do about it? We’ve got a proposition.” They were wanting to go much beyond generating formulas for spreadsheets, but to use natural language to generate applications that could make businesses more productive. So there’s a ton of situations in business where people have got their data in a digital form inside a spreadsheet, but they’re trying to perform some task with multiple spreadsheets, and they’re doing it in some inefficient way. I mean, the classic is that people are trying to procure some kind of service, and they want to ask a bunch of firms to bid to do the work. Like we work with customers that are digging up roads, and they’ve got multiple roads that need to be dug up to change the pipes. Our customers, Cadent, which owns a whole lot of gas pipes in England, they’re often doing this. They know certain work needs to be done, so they send out spreadsheets to a bunch of their potential contractors. The contractors send them back filled in, saying how much they’re going to charge for doing each of the roads and how long it’ll take them, and so forth.
+
+So yeah, the folks from Cadent have all these pipes in the roads that they need to have serviced. They send out these spreadsheets, get the bids back from the contractors, and then they have to make sense of all these spreadsheets. So it’s not one spreadsheet. It’s like multiple spreadsheets, and you can’t really write a formula that can collate multiple spreadsheets. So they’re kind of stuck. So they have to do quite a bit of this process manually, even though they’ve attempted to use spreadsheets to gather the information. So they’ve got a particular business process like that with a pain point because there’s quite a lot of manual effort. And this is typical of lots and lots of companies.
+
+And so the Cogna proposition that the founders put to me is, let’s build some technology that allows us to elicit a description of this business process from a customer. Let them tell us what their pain point is, like in this case, that it’s very manual, they make mistakes, and it’s hard for them to get a sensible overview of all the bids. And then from that description, generate a software app that will help automate the process for them. And I spoke to these guys, and they had some early demos, and it’s using the latest large language model technology, and I thought, this sounds fun, and this might actually work. It’s a bit risky, but still, let’s go for it. 
+
+And I did a long stint at Microsoft, 26 years. I had a great time. It was a long period, but every few years I did something different, that there’d been a whole lot of different things I’d done before the work with Excel. And I’d seen lots of different parts of the company but always been inside a really mega company. So I thought it’d be nice to be early at Cogna. So I think I’m about the seventh person in the team, including the founders. So it’s been a lot of fun.
+
+*SF (0:41:59)*: Now I have to ask on the topic of natural language for programming. So there’s this Dijkstra piece called On the Foolishness of “Natural Language Programming,” and sort of his point is that natural language is really ambiguous, so it shouldn’t be used for programming. What do you think about that?
+
+*AG (0:42:20)*: It certainly can be ambiguous. I think this is one of the big, I guess, technical challenges in being able to go from the words you get from customers to code that is really reliable. Dijkstra was very negative about natural language.
+
+*SF (0:42:41)*: He does use the word ‘foolishness.’
+
+*AG (0:42:46)*: Yeah, I read that essay. I mean, he’s really advocating for using algebraic notations, programming notations rather than natural language. And I guess he was writing in the ‘70s, and he was probably thinking about what is good for professional programmers. And that’s fine. There’s lots of great programming languages with algebraic notations, like Haskell is maybe a preeminent example, and they’re great programming languages for professionals. And obviously, Haskell programmers are really super productive, and you’ve got your type systems and everything. And so I think there’s quite a lot of evidence that a professional programmer using something like Haskell is going to make maybe fewer bugs than writing code in languages, say, without types or with a more side-effecting style. The functional nature of Haskell and also the fact that it has types really help reduce bugs. And of course, the notation itself is completely unambiguous. 
+
+So Dijkstra was complaining that natural language was ambiguous, even though I guess he maybe would admit that it maybe is easier for end users to express what they want in words. It’s certainly what we find with our customers. I mean, we all met at – when I was giving my talk at ICFP in Milan, and when I’ve been preparing for that talk, I’ve been looking back at the early history of English as a programming language, and I found these amazing words from – I’m a little emotional, actually. These amazing words from Grace Hopper in the ‘50s. She was really addressing the same issue between algebraic notation and a natural language. And she had a programming language called FLOW-MATIC that I think she first did in 1955. The key innovation in it was that the lines were sort of stylized English, and it was a precursor to COBOL, which of course was amazingly successful in the ‘70s, but I think condemned by people like Dijkstra. And in the ‘50s, Grace Hopper was saying that she tried to use algebraic notations, mathematical notations, to explain what the pioneering software that she’d built was doing to people like generals and admirals and captains of industry, but they didn’t understand it. But if she used words to describe what was going on, it was much easier. And so I think she had this vision that if we want to have programming, want to make programming sort of accountable and available to end users, we really need to use words. 
+
+So there is still this concern about – so I’m a real advocate for using natural language, and particularly now that we have the various GPT-class models that can interpret those words. But of course, we need to do stuff to disambiguate, and we can do that. So we can generate tests, and the tests become examples that we can give back to the end users so that we can ask them to confirm whether they meant one thing or the other. There’s been some research. There was a paper about a system called ClarifyGPT. It takes natural language prompts to write, say, Python functions. And then it deliberately tries to get the GPT to find multiple interpretations of the same words to try and address those potential ambiguities. And then, if need be, you can take those tests, those examples, back to the user. 
+
+So, okay. Maybe I’ve given you quite a lot of context there, but I’ve tried to give some reasons why I think it’s really important that we use words. I think that’s going to empower many more people. And it’s a different group of people from professional programmers, and I’m not knocking professional programmers. It’s maybe a different situation there. But despite the potential for lack of clarity, I think there’s steps we can do to help the end user describe what they want correctly. 
+
+*MPG (0:47:30)*: This might be a trade secret, right? Because I feel like in the AI world, the solution to any problem with an LLM is just to put another LLM in there and make that fix it. But are you allowed to tell us? How do you deal with these at Cogna?
+
+*AG (0:47:48)*: Yeah, I can – I mean, something we’re actively doing – I mean, stuff that’s very top of mind is that we have an intern at the moment who’s a PhD student, and we’re getting her to generate tests. The key question is that we start from some prompts that are going to generate some code, do some sort of updates, say to a database. And we generate the code, but we also generate tests. If the tests fail, we need to answer, is the code right, or is the test wrong? Where’s the mistake? It’s either in the code or the test. And at the moment, we’re measuring how often these kind of problems come up because we anticipated, oh, these tests are often going to be wrong. What we’re finding – this is really top of mind, right? This is what has been happening this week, is we’re finding, at least for the kind of examples we’re currently working with, it’s the tests that are usually right. And if there’s errors, it’s down to the code. And that’s perhaps because you’re generating more code at once, and the tests are kind of smaller. 
+
+So, to answer your question, what we’re doing about this at Cogna, we are trying to measure how well things are going at the moment and get a sense of where the problems really arise, and then we will try and address them. So, that’s where we’re at.
+
+*SF (0:49:13)*: Speaking of LLMs, with the dawn of so much AI that surrounds us, it’s become quite a big discussion, especially around ethics. I think mainly in AI art. Is it plagiarizing someone’s art? Is it putting artists out of work? I wonder how you think that would translate to the software development industry, because I love the idea of empowering people to write programs. But do you think a similar issue might occur in putting software developers potentially out of jobs with AI? What do you think about the ethics?
+
+*AG (0:49:48)*: Okay, yeah. The impact of AI on jobs is a very topical question. I think we could use a ton more software than we have at the moment. So, in a nutshell, I think AI makes professional software developers more productive. The folks who did GitHub Copilot have a comms to the ACM paper showing that their productivity on a bunch of different measures was up a sizable amount. I don’t remember the numbers, but 20, 30% more productive, let’s say. They’re definitely faster. So I think this is also good. It means that professional programmers can get more work done, and I guess the work is going to be maybe a little cheaper. So it means that more customers who need software developed can get the software done.
+
+I mean, Cogna is playing into this, that we see a whole lot of customers who don’t have access to internal development teams have inefficiencies in their business processes. They’re less productive than they ought to be. And without using AI, say at Cogna, to develop their software, they don’t really have an alternative, at least not an economically viable one. I suppose our competition would be consultancy firms that would come in, but they are much more expensive than us, and they take much longer to get the work done. So because we can lean on AI, we can get the work done more cheaply. And that’s Cogna, but that’s not – you’re asking a general question. I think lots of software developers can use AI themselves if they’re in small companies or big companies, and they’re going to find there’s just lots more that could be done. I mean, we all love when we get more features in the software that we’re using, and we wish we’d had them earlier. Well, AI is going to mean those bits of code can be rolled out faster. Or think about our project at Microsoft. Adding lambdas to Excel, as I said, that was a really arduous effort that took six years or longer, and they’re probably still at it. And that’s because it was a really old code base. 
+
+There’s recent forms of AI for professional developers that do multiple edits at once. They get a sense of how a code base works and its style by sort of reading it. And then instead of doing small edits, you ask for an edit to be performed across a whole code base. So Cursor is an example of that. And I was at an AI meetup in London yesterday, and I was chatting with someone from a company called Igent that’s just got some funding, and they have got apparently a much more efficient version of what something like Cursor can do. So we could automate a lot of work of a professional developer, and it’s able to look at a whole code base. So if we had something like that, I’m sure we could have added lambdas and entities to Excel, and we could have had sheet-defined functions, and we could have had values with units. So there’s a few things there that never kind of made the light of day. That all could be done a lot more quickly if we’d had those features. It would be the same developers. They would just have been much more productive. They wouldn’t have been put out of work, and customers would’ve been happier. Some features are maybe relatively niche. Not all customers are going to benefit from them, and if you’re in that kind of area, you kind of maybe don’t get the love. But if software development was cheaper, then, say, more niche features could be better served in mass market products like Excel. So, does that answer your question? 
+
+*SF (0:53:54)*: Yeah, yeah. It was really good. I have another silly, maybe fun question. With the prevalence of AI, it’s kind of fun to think about which sort of sci-fi AI ending the world is sort of most likely. So I kind of like the idea of Wall-E. I kind of think as technology gets easier and easier to use, there might be an increased skill gap between, say, the people managing the AI and just normal people who can just chat to technology and get it to do things, until we become – I don’t know if you’ve seen Wall-E.
+
+*AG (0:54:30)*: Sorry, I haven’t seen Wall-E.
+
+*SF (0:54:32)*: Oh, Wall-E is great. But the people in Wally just become really fat and reliant on their sort of AI helper. 
+
+*AG (0:54:40)*: Okay.
+
+*SF (0:54:40)*: And they’re so happy that they don’t realize that they sort of lack these freedoms, and Wall-E is all about that breaking. But what potentially was your most likely AI apocalypse from a movie with your increased knowledge? I thought it was a silly question. 
+
+*AG (0:55:01)*: I don’t know. I don’t find myself worrying too much about an AI apocalypse. Maybe I’m too much of an optimist. Do you think I’m too optimistic?
+
+*SF (0:55:11)*: I don’t – I mean, Wall-E is a nice film. So I suppose I’m quite optimistic as well.
+
+*AG (0:55:21)*: But I think a lot of life satisfaction comes from solving problems or overcoming problems. So I think lying around being spoonfed by AIs and watching movies, I think people would – I think that actually is an apocalypse in a sense. I think that people would be super unhappy. It’s very unfulfilling if people do your every whim, in my opinion. A bit of fiction is good.
+
+*MPG (0:55:49)*: Right. I think the other direction is more likely because now with these LLMs, you have to know all these techniques. You have to promise them a tip for a job well done. So I think we’ll end up with, like, a tech priest, someone who knows the incantations to make the LLM do the work, right? But yeah. So there’s lots of different directions. So it’s a fun time to live in, I think. 
+
+*SF (0:56:14)*: Yeah. I was at an interesting talk yesterday where they were talking about different prompt selections, and some of the prompts said they give the AI the roles. Like, “Oh, you’re a super-duper developer. Please write this for me.” Or another one was using sort of emotional support, like, “Oh, I really need this. It’d be really amazing if you could do this for me,” and whether it had an effect. So I kind of like that idea.
+
+*AG (0:56:38)*: Yeah, that’s nice. I think there’s some negative examples as well. I think I saw some study where the instructions were much more aggressive, like, “Do this or you’ll be fired.” And that, I’m afraid, was as effective as being nice.
+
+*MPG (0:56:54)*: Yeah. So, as maybe like a last question, I guess. So you were involved in Haskell a lot in the early days, right? And now you’ve seen 26 years of real research in big companies. So, what would you change about Haskell as it is today? What would you change about the language, basically? 
+
+*AG (0:57:18)*: I mean, that’s quite a difficult question for me. I must admit I’m not an active Haskell programmer anymore. I mean, is there – I’m curious, how well does Haskell play with A? Like, have you used GitHub Copilot with it, for example?
+
+*SF (0:57:39)*: Not very well. So we have to warn our first years who are learning Haskell to not use LLMs because it’s sort of gobbled the internet, but there’s not as much Haskell code. And it was quite funny. One of my fellow lecturers put a bunch of examples on the slides to convince them. “Don’t use it for Haskell because it’ll come up with all these silly things,” and there’s a bunch of examples. So maybe it just needs to eat more Haskell code.
+
+*MPG (0:58:07)*: Yeah. Because it’s quite a dense language, right? Each token contains a lot of information in Haskell, so you have to get them right. You can’t just do a bunch of stuff, right? So I think, yeah, it’s a challenge. 
+
+*AG (0:58:22)*: Okay.
+
+*SF (0:58:23)*: It’s quite easily filled by naming as well. So it was like, “Please, can you write this function called filter?” That does and then describes something that isn’t filter. Because it sees that name, it’s like, “Whoa, I know the filter function. Here you go.”
+
+*MPG (0:58:39)*: I think we covered most of it. Is there anything you want to add?
+
+*AG (0:58:45)*: I always like to be grateful. Okay, I’m really happy to be invited on this podcast. I appreciate the attention. And I feel functional programming was my first love back when I was an undergrad and choosing where to go to do my PhD, and it turned out to be a good choice. It was a radical choice, I think, back then. I remember during the time of my PhD that some people were scoffed about functional programming. It was kind of the era when C++ was really taking off object-oriented programming in the late ‘80s, early ‘90s. And functional programming wasn’t nearly as cool in a way. But I stuck with it, and it led me to, I guess, success doing theories of operational theories of functional programming. And then that led to the work I did at Microsoft on various things and then the work with Excel.
+
+So I think functional programming is a great idea and I guess I’ve taken a bet on it in my career, and it’s a great community to be part of. Like I’ve mentioned, some people have helped my career within that community. So I’m glad to be part of the functional programming community and grateful for the opportunities that I’ve given it. So thanks for having me. I really appreciate it.
+
+*SF (1:00:27)*: Thanks for joining us.
+
+*MPG (1:00:29)*: Yeah, thanks for coming on.
+
+*Narrator (1:00:31)*: The Haskell Interlude Podcast is a project of the Haskell Foundation. It is made possible by the generous support of our sponsors, especially the Monad-level sponsors: GitHub, Input Output, Juspay, and Meta.