 Alright, welcome everyone and welcome Richard. This is great to kick off the second day of Functional Con. I think it's a great way to kick start the conference with Richard who has done amazing work in the Elm community to start with. At least that's how I've known Richard first read his book and then used a bunch of the packages that you've built for Elm. So I appreciate that and then of course these days you've been working on the new programming language called rock. And I'm sure you'll talk about more about that in your talk so alright without much delay over to the one and only Richard. Thank you. Alright, thanks so much. This is the essence of functional programming. I'm Richard Feldman. So we're here at Functional Con 2022. This is from the website and as Nourish mentioned there are a lot of different programming languages represented here. These are some of the icons that were on the website is even more than this but just in case you're not familiar with all the logos this is APL closure C++ Alexa F sharp O camel Haskell Elm prologue Scala and Java. And like he said there's there's even more at the conference. Well, you're going to get a different experience doing pro functional programming in each of these languages. Some languages have more or different facilities for functional programming than others. And of course these different experiences are going to lead to different expectations, like for example, if you're used to doing functional programming in Haskell, and you try doing functional programming and C++. That's just going to be a very different experience or just very different languages. Likewise, if you use elixir versus prologue, very different experiences, even programming languages that are sort of dedicated functional programming language they're not multi paradigm at all, they're just functional programming like closure and Elm very different experiences. And these different experiences will lead to different expectations which sometimes doesn't necessarily lead to a good experience. So let me give you an example of this. As Nourish mentioned I've been working on this programming language called rock for the past couple years. It is a purely functional programming language, but because performance is a big focus of the language and not just in terms of like runtime performance but also in terms of compile time performance. We've been building the compiler for rock in rust. The reason for this is that we want to go fast. Rust is a systems level programming language gives you a ton of control over stuff. It's not really known as a functional programming language per se it's definitely like imperative at its core. But there are a ton of articles about how to do functional programming and rust, like tons and tons and tons of lots of people talking about here's like a blog post on how to do functional programming and rust a video and how to do functional programming rust. So there's lots of people talking about how to do this and sort of advocating for it. So, because I was writing this compiler in rust. This is actually my first time using rust for a serious project, and I was much more familiar with functional programming I've been doing it for like 10 years. And so I decided I'm going to write the parser using parser combinators so that's what I'm familiar with. And since I've heard about all this like functional programming and rust stuff. So I have a blog post from Bodal Soka, who is awesome. She wrote a great post about how to do parser combinators and rust which I actually used to make the initial parser for this programming language. And everything was going okay until I hit a problem. And this commit message, actually, and this is exactly September 1 2019 was when I ran into this problem, and the commit message says attempt at making a type annotation parser. At this point I'd gotten to the point where I could parse like expressions and functions and all these different things I was like okay let's get the type annotations because rocks a type check language that has type annotations. And I got this weird error from the rust compiler, which said recursion limit reached. Basically what it said is you're doing too much higher order function stuff and I wasn't built for that so I give up. Just stop doing that. I have never seen this happen in any program language any compiler I've ever used, except for this experience I had in rust. And needless to say I was like well I thought I could do all this functional programming and rust what do you mean recursion limit. So, kind of my my first takeaway here was, this is this is just not a good experience. Clearly rust is not designed for heavy use of higher order functions like this I mean, when you look at these like rust and functional programming and rust posts. A lot of them just kind of talk about really basic examples like we're doing a map over an array or a vector or something like that. But you never really get into like what if you have a ton of higher order functions like parser combinators but it's just built in this giant stack of them. Rust technically can do that to a point but there comes a point apparently where you just reached the compiler's limit it's like no just don't do this anymore. So that was my first takeaway my second takeaway was, honestly, I'm just not having a great experience trying to do what to me feels like a normal functional programming thing in rust. And yet, there's all these other people who have a different experience or promoting a different idea of like yeah you should do functional programming rust that's a good idea you know rust heart lambda. And so this this sort of as an example of us sort of talking past each other, like I have in my head, based on my experience is an idea of what functional programming is. But somebody else who's maybe talking about functional programming rust, they may have a totally different idea of what functional programming is that maybe doesn't involve parser combinators or anything like it. So this is where these sort of different experiences that we have from doing functional programming in different languages can lead to different expectations and maybe talking past each other and miscommunications like this. I kind of wish in retrospect that I didn't have this idea in my head that rust was a functional programming language or was the language where it's a good idea to do functional programming, because based on my idea functional programming. I was like, you know what, I kind of wish that I hadn't had that idea I just embrace the imperative aspect of rust because I think it's quite nice for using doing imperative programming rust. But with my own background, this this did not set me up for success. So in this talk I want to explore though like what is the common ground between all these like we're at functional con these are lots of different languages but we're all talking about similar kinds of ideas. So what I'm going to try and do is explore this idea of like what's the essence of functional programming what's the minimal sort of essential like irremovable part that at that point we are doing functional programming no matter what language we're doing it. And I'm going to explore this in sort of three angles. First I want to talk about what are the minimal language features required to do functional programming. I want to talk about the relationship between functional programming and math, because a common thing that I hear people talk about is that functional programming is about math or has a lot to do with math. So what is that relationship. And third what is the functional programming style, like regardless of what language you're doing it in what is the actual fp style. Okay, so let's start about the start with the minimal language requirements in terms of features. The answer to this question that I hear in terms of like what is the actual minimal thing that you need to do functional programming is lexical closures. Now this is an example of a first class function is a lexical closure but you might not be familiar with exactly what that term means so let me go into sort of an example of what it is. So here we have an inner class and Java. This is an example that comes out of a blog post when they were announcing lambdas being introduced in Java eight. And in this blog post this is on oracle.com and says, although possible functional programming in Java was by any account obtuse and awkward. And what they're talking about is basically code like this, where you're using this inner class in order to define something that with the lambda syntax could be defined like this, much more concisely. Now worth noting that semantically these two actually do the same thing in Java, like the inner class even can do the closure thing where it captures stuff from the outer scope. So basically the difference here is largely syntactic sugar. Like you could, like the quote says it was possible to do functional programming in Java using this style of like instantiating a new runnable and making a method called run inside of it, but it wasn't very pleasant. It would require a lot more code than certainly the lambda syntax sugar ended up required. So FP and Java has always been possible, but it hasn't always been ergonomic and now with the introduction of the lambda syntax, it's more ergonomic. Let me give you another example of of where FP is possible but not necessarily ergonomic this time using a sort of different definition of a lambda a different style of closure. I'm going to use sort of JavaScript syntax for this just for familiarity because I think most people know JavaScript. I say suffix equals exclamation point, and then I write a function called exclaim which takes a string, and all it does is it returns that string plus that suffix of exclamation point. So in JavaScript, this is this function would work the way you expect if you call explain passing a string it'll return it with an exclamation point on the end. But now let's say that when I was calling that this exclaim function, I just happened to also put suffix like ahead of that in the same scope. So we have like a var or a const or something like that or a let in front of both of these suffixes. So this is not about global variables this is let's assume locally scoped. And I call exclaim in the same way. So in a language with lexical scope, lexical closures. This will return hello world with a question mark, even though in the second example we said suffix equals question marks, if that had a letter or const or a bar or something like that in front of it. It would be locally scoped and it would not affect this, you know, exclaim function. But there's another style of closure, where it would not do that, where it would actually use the suffix that's closer to the call site, rather than the one that was closer to the definition site. And the difference between these is that the hello world the exclamation point is lexical scoping where what matters is what was sort of lexically that is to say in the source code around it. The next example is dynamic binding which is basically it's, it's all about what was in scope around the call site. So this exclaim function is actually going to evaluate suffix from the call site or what's near the call site rather than definition site lightning might expect. So both of these work, but one of them is a lot more ergonomic to the other there's a reason that basically every language does lexical binding these days. But you might be surprised to hear about a particular programming language that used to do dynamic binding. And he talks by David Turner, who was the creator of the Miranda programming language which is the basically the immediate presence of the Haskell it's like one of the earliest languages to do lazy functional programming. And he talks all sorts of all sorts of history it's it's a really nice talk I definitely recommend watching the whole thing. But one of the slides that he focuses on is he talks about some myths about lists. This list never existed. It had assignment and go to that is to say mutation and like literally go to like jumping to an arbitrary point in the source code before it had conditional expressions and recursion. As far as I know, this was actually this is from 1958 was the original language that introduced conditional expressions like if then else that actually evaluates to evaluate. And the first language to introduce recursion. And Lisp was not based on the lambda calculus, despite using the word lambda to denote functions, it was instead based on first order recursion equation which is from the mathematician claiming. So basically, he's saying that, you know, although we talk about lambda calculus a lot we're going to talk about it some more later on the talk. Lisp itself was not actually based on it and in fact the creator of Lisp, although he had heard of lambda calculus and knew about the term lambdas from it. He actually had not really studied it and he did not base list on it. The M language which is part of Lisp was was first order but you could pass a function as a parameter by quotation ie is the S expression for its code. What you're seeing right here is that Lisp original list did not have higher order functions in the sense that we typically associate them with today. What you could do if you wanted, because you can basically take the source code of that function like a string and pass it in an eval that which you know if you ever heard of eval language like JavaScript something like that. Probably alarm bells are going off like that's not a good idea that's not a good way to do higher order functions or to simulate them. But that was what you would have to do in original list. And then he goes on to say this gives the wrong binding rules for free variables dynamic instead of lexicographic. So that's where our example previously of dynamic binding comes from if you imagine if you're just basically copy pasting that code in there and then eval it yeah it's going to run using whatever's in scope from wherever you copy pasted it because it doesn't know about what was originally in scope all of those is the string of the source code. That's where dynamic binding comes from. And yet your economics are not as nice as lexical binding. So he goes on to sort of give an example of this and then finally he notes, not until scheme, which is a 1975 did versions of lists with static binding aka lexical binding appear, and today all versions of lists for lambda calculus based. So this is really interesting, because we've been talking about this sort of like, you know, functional programming being possible but not ergonomic. I would argue that dynamic binding is another good example of this like yeah we had lambdas they were even called lambdas in this, but the ergonomics back in 1958 were not great. They were not good to associate with, like functional programming today with higher order functions. If you said, here's a programming language, and the way that you do higher order functions you pass a string of the source code into it and then eval that in the middle of the function. I don't know how many people would say yeah that feels like functional programming to me. Now, here's the question. What's the difference between this on ergonomic way of doing functions in Lisbon 1958 and this other on ergonomic way of doing functional programming in Java in 1995. I mean, both of them. Yeah, you can write the same kind of stuff. I mean, arguably, the Java one Java interclasses did actually have lexical binding. So, in some sense you can even argue that the Java version of this was more ergonomic for functional programming despite being more verbose than the list version because at least I got the binding right. Something to think about. Okay. This is kind of the strangest part to me is to realize that both Java and list got lexical closures 15 plus years after the initial release of the language. Like, people give Java a lot of hash for you know having taken so long to finally get lambdas I mean, let's put that long to get this. I mean not not exactly the same amount of time but like 15 plus years after the initial release before they got it. Before scheme came out in Lisbon before lambdas landed Java eight. Lexical closures are definitely ergonomic for functional programming but they're not required. You can do functional programming without you certainly can do functional programming in original lists. I think a lot of people agree with that some people including Wikipedia as we'll see later, consider lists to maybe be the first functional programming language ever. But they're not essential. They're not required. You can do it without them is just the ergonomics are going to be worse. And honestly the same thing is true of first class functions I mean we saw from the inner class example in Java. That was not a function that was an inner class that had a method inside it was not a function. And yet you could do functional programming in Java before it got lambdas just ergonomics were not as good. And in fact, you can go even further with this you can do functional programming in C. This is an article about and this is not just somebody who is doing like a toy project and was like I want to see if I can do functional programming and see no he was actually talking about. It's a functional problem and I use my experience and functional programming to solve this problem and help make my code better in C. And you can go even further than that. Here's a stack overflow talking about functional code in assembly, like pure functions in assembly language. And that's even more bizarre because if you think about it, assembly doesn't even have the concept of functions. It's just machine instructions. Like how can this possibly be. Well, again, I come back to, do you actually need literal first class functions to do a functional programming style I mean if inner classes are sufficient in Java. What's the difference between that and a raw function pointer. I mean the answer is there's no capture but again, let's didn't really have capture. So do you necessarily need that. I think the answer is no. I think, even if you don't have the most basic thing the word function is the first word in functional programming, but you actually can do that style of trying to write pure quote unquote functions. Even if you don't have that as a primitive all you've got as a raw function point which is just an address to jump to in memory. It still can help you out in the same way that the functional programming style can help you out in Java pre lambdas, and in original list. So yeah, I would say even functions are ergonomic functional programming but still not required they're not essential. Conceptually, yeah, you can certainly have an idea functions but are they required to be in the language for you to do a functional programming style. I think the answer is no. Okay, so what are the minimal language features required to do FP. I think it's done, not even functions, any programming language can do functional programming. I claim. And if that's true, then certainly know these other programming language features are required either to do functional programming like immutability not required pattern matching not required macros, I mean all these things purity laziness. These are all things that are somewhat associated with functional programming languages, and you might say that these sort of feel like functional programming if that's what you're used to. But if you use a programming language that didn't have any of these and not even functions, I claim you could still do functional programming, at least from a stylist perspective and get the same kinds of benefits that the C programmer got when he applied functional programming techniques to his C code. They do certainly improve ergonomics so when you have access to nice language features. I'm making a pure functional programming language because I think that that having a language level support for functional programming is a great idea, but I have to acknowledge that even as someone who's not committed to functional programming languages, who's been using them exclusively my career for the past five plus years. They're not required for functional program. Okay. So, having said that, I would encourage you to explore the different ergonomics of different languages. Like if you've only ever done functional programming and one or maybe two of these languages. Try another one. See what it feels like, you might actually find that you like it more, especially if you've never had the experience of using a language that was designed from the ground up to be a functional programming language. The ergonomics are pretty much across the board going to be better if you're using a language where this was the idea, this was the plan, rather than a language that sort of much later ended up deciding that oh we should actually add some functional programming language features, even though that's not what the language was originally designed to do. Okay. So that brings me to what is the relationship between functional programming and mathematics. So this is another thing that people talk about a lot. I'm kind of learning a lot about this when I was trying to answer the question what's the original definition of functional programming. I wanted to just say like okay surely there was a time when no one use the term functional programming. And then at some point somebody used it for the first time. And then now today it's sort of part of our shared lexicon so what was that first moment like what's the earliest documented example I can find of someone using the words functional programming. And that would be Alonzo church who created the lambda calculus back in the 1930s because a lot of times when people talk about functional programming, they'll sort of hand wave you say, you know function programming originated with the lambda calculus. And if you look on Wikipedia, talking about the lambda calculus says it influenced the design of the list programming language. Not really true. It influenced the design of like later lists and not the original list, and functional programming languages in general, which I certainly think is true. Alonzo church in the 1930s actually use the words functional programming. I cannot find any evidence of this. I looked through some of his early papers. I don't see that in there. I think that came later even if playing the calculus was obviously very influential and functional programming. I don't think it was the where the term originated. Next place I looked was john McCarthy creator of lists in the 1950s so about 20 years later. Wikipedia says list implemented in 1958 was the first dynamically typed functional programming language. I think that's a reasonable claim. I'm not going to try and debate like was it or was it not the first functional programming language some people will say it is some people will say it isn't weird. I think if you want to be consistent though you should say that functional programming does not require lexical closures that you think that or being based on the lambda calculus if you think this is the first functional programming language. But regardless, did john McCarthy use the term functional programming. Again, I can't find any evidence of this. I have not seen in his early like 1950s papers about you know list and symbolic execution and all that stuff. I can't find it. The first example I can find of the words functional programming being used in a paper was by Peter landed, who created lexical closures in the 1960s he wrote a paper that they use this term. He's a British computer scientist one of the first to realize that lambda calculus can be used to model programming language, definitely strongly influenced by lambda calculus as we will see. Until he was the first person to write down the term functional programming in like an academic paper. It was this one was called the next 700 programming languages and it's from 1966. We can already see in this paper like a lot of things that are familiar to us today in terms of functional programming. He's describing a language which we'll get to in a second. He talks about, you know, it's oriented around expressions rather than statements that sound familiar. A non procedural aka purely functional subsystem of this language so he's actually talking about not just functional programming but like pure functional program with no side effects as part of this language. This is where he talks about functional programming. He uses the phrase for the first time functional programming in a sentence in which he's actually talking about syntax which I thought was kind of funny has little to do with functional notation. He goes on to talk about references another paper he talks about a correspondence between X and churches lambda notation, basically talking about like the relationship between lambda calculus and mathematics and similar concepts in computer programming. The name for his language that he's describing here is called I swim which is stored for I see what I mean, which I also thought was kind of funny because here I am trying to find the original authoritative definition of functional programming. So my conclusion is this sentence which doesn't define it it just sort of uses it, and then it's in the context of a programming language called see what I mean, see what I mean, you know. And so, unfortunately, I did not end up finding an authoritative definition here I just found this this usage of it where he just kind of casually drops it in there, as if the reader already knows what it means. So my conclusion is like, what's the original definition of functional programming. Maybe there isn't one. It just kind of seems like this colloquialism that people were talking about at the time that like Peter Landon knew. And at some point he wrote this paper and use this term that people were colloquially using. And you know what, I bet they all probably had different ideas about exactly what it meant. Maybe functional programming has always been this sort of vaguely shared understanding of related ideas between programmers. I think that's the most plausible answer. So, to sum up what I ended up sort of learning in the context in the course of exploring the origins of the term functional programming. Well, it definitely referred to mathematical functions like the functional and functional programming like all these papers from around this time. They're all talking about math, lambda calculus, mathematical properties, and wanting programming to try and sort of like get some of those benefits from mathematics or steal some ideas from there. So definitely that's where the function, the word function comes from as mathematical functions. Secondly, I learned, you know, like Lisp is actually not coming from a lambda calculus background but it is coming from plenty of ideas on functional recursion as a mathematical function recursion. So even more math influence in the whole like list branch of things. And then I swim and which influence ML and Haskell and all these other languages. I'm definitely inspired by lambda calculus and then eventually lambda calculus ended up getting into the list family through scheme and and and on it goes so definitely there's a very, very strong undercurrent of mathematics sort of like that's bound up in the origin story of functional programming. So what about category theory. I mean quite often I've heard people say if you want to get into functional programming you're going to have to learn some category theory. Is that true. So in Python, you have a concept of lists, like, you know, another language is called the rape and Python they're known as lists. And when Python programmers are talking about lists they say lists. Haskell also has lists but it's quite common that you'll hear Haskell programmers talk about the list monad instead. Same idea. They're both talking about lists, you know a data structure called list and their respective languages. You know, colloquially Haskell is referred to it as the list monad. Now in both languages, like Python lists and has lists are both monads. It's like that's just a true fact about them. It's really just there's a cultural difference about how they're talked about. Now part of this granted is that Haskell has monad in as part of its standard library. It's really difficult to use Haskell completely without learning what a monad is very easy to learn Python about what a monad is even though both of them have monads. So is that required? Well, no, I mean in Elm, for example, which is also a pure functional programming language like Haskell. Sadly typed type inference, a lot of similarities between Elm and Haskell, but culturally in Elm, we just call lists. That's totally fine. Similarly in the rock programming language that I'm working on. So just called lists, you know, monads don't appear in the standard library there aren't really any category theory terms. It's just a cultural thing. And actually, like, if you look at the breadth of functional programming whether people are doing like the functional programming style or it's just a functional programming language that's not Haskell or a descendant of Haskell. You really actually don't find that much category theory terminology. It really is just kind of like a niche of functional programming that tends to use that terminology. But again, like, you can find different experiences no matter where you look. There's some overlap between mathematicians and programmers and some overlap between category theory terminology usage and programmers and mathematicians. Some people are two of these three some people are three of these three but plenty of people are just one of these three and they're interested in programming but not math and not category theory. And that's fine. All of those are fine. So I would say based on what I've learned. I don't think that category theory is required for functional programming. But it's something that you can learn if you want to and in fact it's also something you can learn if you have no interest in programming at all. They're just kind of separate and culturally you may find that it's more of a thing, especially in languages where category theory terminology appears in the standard library like in Haskell, but there's plenty of other functional programming languages that don't have it so if it's not something you're interested in learning, you don't really have to. Okay. And finally, this brings us to the functional programming style. So, what's the common ground stylistically between all these languages. Well so far, what from what we've explored it doesn't actually seem that they all have like some particular set of features that they all need to have not even functions that doesn't seem to be requirement. Also, although it seems like math is like an integral part of the origin story of functional programming. I really can't find any evidence that math is sort of like part of the definition of it so it's not like you need to have any particular math background or usage of math in order to do functional programming in any of these languages. So what's the common ground between them like what are what are you going to find this over the common thread, I expect with like the talks you're going to see at this conference, using more pure functions. I think that's really kind of what it comes down to. So pure functions if you're not familiar with the term, basically have two rules, if you give them the same arguments they have to return the same return value, no matter what. And they can't perform any side effects along the way. And my favorite analogy for pure functions is that pure functions are basically they're not exactly but basically look up tables. So for example, let's say we have a function called string length. And if I call it passing the string, hi, it returns to bypass functional returns 10 bypass cough 2022 returns nine. This could be implemented this function could be implemented internally as a lookup table, like whatever string you give it, it's going to just look up the answer the lookup table and return it. And that's it. No side effects, and no matter what arguments you give it is always going to return exactly the same answer. So if you wanted to you could take the body of this function, whatever is actually in there and theoretically you could return replace the entire body of that function with a gigantic lookup table for like all the possible strings that could possibly accept. Now okay, that's like assuming unlimited system resources obviously in practice you would not actually be able to implement it that way. But the idea is that any pure function should in theory given unlimited resources. Be able to replace its entire body its entire implementation with a gigantic lookup table. If you can't do that, you don't have a pure function. That's the rule. And really if you think about it, mathematical functions work the same way, mathematical functions don't have side effects. And it's certainly if you give them the same arguments, they're expected to give the same return value every single time. Okay. So actually, I mean pure functions are in some sense like mathematical functions and certainly based on the history of what it seems like that's what people wanted them to be more like I mean that's what that was sort of the goal is to get more mathematical properties out of programming. But there is one important difference between pure functions mathematical functions which is they can crash system resources as it turns out are finite so you can get for example a stack overflow. They can also hang like they can run indefinitely and not terminate that's also a bummer. So this is a little bit awkward. And there's this sort of natural question that arises from this which is, like, can computers do arbitrary math. I mean, can we ever get to pure functions being equal to mathematical functions. Unfortunately, the answer is no. And to prove this to you just, here's the thought experiment. Let's imagine that you were thinking of the biggest number you can conceive of just digits and digits and digits for ages huge huge number. The number to the power of itself, over and over and over again. As many times as you can imagine, the resulting number will be so big that even if you don't do any operations on it, it can be represented in the universe, not just on your computer, but like in the entire if you repurpose every all the matter in the entire universe, and all you were trying to do with all the matter in the entire universe was represent this one number. You can't do it it's too big. It won't fit in the entire universe. Unfortunately is infinite, even just that one number is not representable, let alone any functions that might involve that number is like a constant inside of it. So, can we ever get to a point where functions running on a computer are as powerful as mathematical functions. In other words, can we ever get to a point where there exists no mathematical functions that cannot be modeled by computers. I mean, computers can never have true mathematical functions in the sense that there will always exist a mathematical function that cannot be represented by a computer, because math is infinite, and the physical universe is finite, and computers live in the physical universe, unfortunately. So we can sort of asymptotically approach this at best but we can never quite get there. So one of the things that pure functions can do is they can crash. This is unfortunate, but there's also some other asterisks in there that we just kind of like hand wave away when we're talking about pure functions versus mathematical functions, like, technically they affect memory when they run like they allocate memory on the stack or on the heap. And we don't really consider that a side effect even though that is observable within the system. I mean if you have another, you know, another function running that's like not a pure function it's going to be able to observe that memory. So we kind of like to say like, okay, but for our purposes we're not going to treat that as a side effect and yes we know they can crash and they can, you know, not terminate they can run out of memory. But all of those, all of those aside, we're just going to, you know, otherwise treat them under the assumption that those things like won't happen, or that the changing of memory won't matter. Also, as we've seen earlier they don't really even have to be functions I mean mathematical functions yes or functions but we can get kind of the same benefits with much worse ergonomics, even if we don't have access to lexical functions or something like interclasses of Java or even functions themselves. Okay, so putting all this together. I'm going to claim that the functional programming style basically boils down to using more pure functions which in practice means avoiding mutation and avoiding side effects. And you can do both of these, even if you don't actually have access to functions. And this I claim is the functional programming style, avoid mutation and avoid side effects. And so what's the common ground between all these different things that you'll see at the conference. I think it's avoiding mutation and avoiding side effects. So, to give an example of this, and so the difference in ergonomics here. Let's talk about like functional programming and JavaScript was actually what I got into first. Okay, it was coffee scripts but I know a lot of not a lot of people know about coffee script anymore so let's just pretend it's job script, close enough, basically the same language that we used to use. And comparing that to functional programming in Haskell. Let me tell you a quick story. Years ago I was working at a different company, and we were basically building a product, and the team that we were on was really bought into functional programming. We were using coffee script, again pretend it's JavaScript. But basically the rules that we tried to follow were like just pretend it's Haskell like don't do any mutation, don't do any side effects except at the very edges of the system. So let's try to follow all the same rules that we would in Haskell, everybody was bought into this idea. I had one coworker who was used to Haskell, I was actually used to coffee script so I had no prior experience in doing like functional programming in an actual functional language. And so to me the ergonomics were like wow, I noticed that it's a lot easier to do my programming. I find that this is less error prone than what I'm used to. But my coworker really had a lot of trouble because he was used to Haskell. He was like, this is so much harder for me like I actually ended up leaving the team because it was just so impossibly difficult for him to give up the ergonomics that he was used to from Haskell and do functional programming in JavaScript where it was just such a much more hostile environment that he was used to for that style. Now in contrast, today I work at a company called NoRidic. We make software for English teachers and we use Elm on the front end and Haskell, not exclusively but we do use it quite a bit on the back end. And basically, now I know what my coworker was talking about at the past. The ergonomics difference is huge if you have access to all this stuff. The functional programming style in a language that wasn't designed for it is very, very different ergonomically and in terms of like what it feels like day to day programming when you actually have access to a full language that was designed to be used in that way. Elm and Haskell are both pure functional programming languages, but again, lots of other languages at this conference are you know like Elixir and Clojure and stuff like that are dedicated functional programming languages that are not pure functional. There are different ways to go with this, but the point being, if you actually have a language that's built on this the ergonomics are very, very different. By the way, if that sounds interesting to you, if you'd like to use a pure functional programming language to work, we're hiring. Okay, so I claim that avoiding mutation inside effects is sort of the common thread between all of these this is the functional programming style, but the ergonomics definitely may vary depending on the language and its level of support for that. So, summarize all the things we talked about. Building this programming language called rock, it's a purely functional language, probably written in rust. I had this expectation based on all these things I'd seen about functional programming and rust that Oh, this is going to match with my idea of functional programming it's going to feel just like Elm. But really it turns out that we were to some extent talking past each other I mean all these articles that we're talking about functional programming and rust. So I had a different mental model of functional programming and especially the corresponding ergonomics around that that I did and I ended up kind of getting burned by that and having an unpleasant experience. When I tried to apply functional programming techniques like parser combinators that I was used to in rust. So these different experiences, you know, can lead to different expectations and you're going to find a lot of different expectations and experiences at the different talks that you hear in the conference and so you should be aware of that, you know what when the speaker is talking about their experience of functional programming it's probably going to be different than your experience and probably different than the other speakers experiences, you should keep that in mind as you're listening to every talk. Talked about so sort of these looking at this from these three different angles so what are the minimal features required to do functional programming, as it turns out, none, not even functions. It's possible to do a functional programming style, even in assembly language with terrible ergonomics. What's the relationship between functional programming math. Definitely there was a very strong historical influence this seems to me to be where the term functional programming came from was people looking into the relationships between mathematics and programming and pure functions themselves are definitely based on mathematical functions, the function and functional programming comes from mathematical functions, as far as I can tell. And finally, what is the functional programming style. It's avoiding mutation and avoiding side effects. Of course, your economics may vary depending on which language you're doing that style. So what is at the end of the day, the essence of functional programming. I think it's avoiding mutation and avoiding side effects. Thanks very much. Thanks Richard that was awesome, as usual. Cool. I did not know about LISP that background specifically so thank you for that. Cool. Let's see if there are any questions folks have if you have any questions please put it in the Q&A section. As of now I don't see any questions but if folks do have some questions please put it in the Q&A section. Alright, we have a first question here from Kim. So we have so far heard about the essence of functional programming. What is the essence of a functional programmer. What is the essence of a functional programmer. I mean, I guess that's probably a subject of an entire other talk right. I don't have a good answer off the top of my head. I don't know if you can paint all functional programmers with such a broad brush is to say that we all boil down to the same essential thing other than maybe we use functional programming. Maybe that's it. Maybe it doesn't need a whole talk. So thanks Kim for that. I think we have one question again now from Connor. You mentioned David Turner. Have you looked into KRC or SASL the language he worked on Mirana. I know about SASL. I don't recognize the other acronym. I think I've seen it like his Wikipedia article but I don't actually know anything about either of those. I'm only really familiar with Miranda in the context of it being a predecessor to Haskell but I'm sure there's some interesting history there too. Okay, cool. Next question is from Manoj. He's saying which platform does Rock work on. Yeah, so Rock compiles to machine code. So you can actually run it on, you know, Windows. Well, actually, it probably doesn't support Windows yet. So it's like work in progress but like Mac Linux. So it also compiles to WebAssembly so you can run it in the browser if you want. On RockLang.org I have some demos of it running in different environments. And I keep an eye out because later this month I'm giving or sorry in about a month I'm giving another talk or I'm going to demo it compiling to like different platforms like Mac and Linux and stuff like that. Cool. Blazing through there are more questions coming in so that's great. We have the next question from Ram. He's saying, can we say we can compare different functional programming languages to get the best. Like, is there a best function programming language. Is there a best functional programming language. I mean I think that that question is similar to the question of is there a best programming language. And I think the answer is it depends on what you're doing. There, there, whatever you're doing there will probably be a best program functional programming language for that task in the same way that there's a best program language for that task. But languages of this conference and other languages have different strengths and weaknesses so I'd say it really is very context dependent on like what your actual project is. Cool. We have next question from Mr. is composition of functions not essential to function programming. I think that's a great question. I mean my conclusion is no. I think you definitely can still get the same kind of benefits, like this C article is a good example of this where phone mentally like by avoiding mutation and being sort of like aware of side effects and trying to isolate them and he got a lot of benefits from that didn't do any functional composition. I don't think that that's essential and in fact, honestly, in terms of especially like point free function function composition, I have used that less and less, the more experience I've gotten with functional programming. So yeah, I don't think it's essential at all. Cool. I think we just doing a quick time check here. I think we could do. Yeah, couple of more questions so. Next one is from the judge. Some FP languages support category theory, like FP languages like Haskell and scholar, but some languages like closure doesn't have much of category theory and still FP language buys it so. I think I think it's just cultural. Like, you know, we talked about like the origins of functional programming and where a lot of these languages come from. All of them, you know, have some sort of mathematical background but different mathematicians and different computer scientists talk about different things and look at the world in different ways. In Haskell, for example, I know that one of the reasons that monads are really big in Haskell is that Philip Wadler discovered a really nice way to do pure functional IO and the way that he discovered that was actually in the context of reading a paper from a different mathematician on on this concept of monads and mathematics that led him to discover a really nice technique for doing IO and a pure functional language namely Haskell. And so that just became a big part of Haskell like because that was like the origin of how he did it. There's other languages that use that same style of IO but just don't talk about it in terms of category theory. Both are totally valid. I mean there's there's there's there's nothing saying that you need to use category theory in order to do functional programming and there's nothing saying that if you use category theory to do functional programming that you shouldn't. It really is just kind of a stylistic choice and different communities have different choices about how they approach it. Next one is from Yogi. Yogi saying given the physical reality of computers that you mentioned, is there any truth to saying list programmers know the value of everything and the cost of nothing. Replace function. I forget where that quote comes from but yeah I mean this was this was like a, I think what they were talking about originally was it was actually about garbage collection if I remember right. They're talking about like the value of everything and the cost of nothing meaning that like, so list was actually also among other first it was the first garbage collected programming language. And back in the day that that Alan Perlis cool. And I think he was talking about the garbage collection the fact that like, list ran pretty slowly back then might have been that otherwise might have been all the con cells. But as I recall it was a dig on the performance of list, you know. And so, today when lots of languages are garbage collected in fact that's like the most common and most popular way to be programming. I don't think that joke makes as much sense anymore. But I actually don't think that was about functional programming as much as it was about garbage collection. I could be wrong. I think I'll take one last question and then we will move to the hangout section so the last question here is from sort of how important are types to FB. Honestly, from my perspective to functional programming, I think they're just totally orthogonal. I mean, there was this debate over like type versus untyped lambda calculus back in the day. But also at the end of the day like you can do avoiding mutation and side effects in any language regardless of type system. And types are much more about ergonomics in a totally separate distinct category from FP versus imperative in the same way that you can have functional programming languages with dynamic type static types or whatever else gradual types, and you can have an imperative language with dynamic type static types, gradual types, whatever else. It's just an orthogonal concern. Obviously you can categorize functional languages into one or the other. But really I mean the question of like which ergonomics do you prefer and like what type system features do you like or dislike about a particular you can do that have that same debate regardless of what you're talking about in the context of functional program. So I'd say they're totally separate. All right, cool. I know there are more questions again I appreciate everyone asking questions. It's great. Thank you everyone for listening in and being such a good audience not making too much noise. And again Richard for the fantastic talk and helping us kind of go back a little bit in time and understand the essence of functional programming and it's a great way to kickstart this conference, kind of trying to set that base definition and maybe as we go through. We will see if our mileage varies in terms of the experience and economics that you mentioned.