Foojay Podcast #20: Functional Programming: "The Good, the Bad, and the Ugly"

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:00] Functional programming, it seems you either love it or you hate it. You know, like everything in software engineering, it’s a trade-off. So, for today, let’s focus on the good, the bad, and ugly parts of functional programming. Welcome to the Foojay podcast. All your news about OpenJDK. I’m joined here today by some very smart people, Alejandro and Deepu. Could you introduce yourselves and tell me how you got in contact with functional programming? Alejandro, could you start? I got in contact with functional programming back when I was in college at in college I had some some friends and we were quite interested of kind of exploring everything which was outside of what they were telling us. You know, we had a very traditional education where we started learning Pascal to learn then C to learn in Java and it’s like you know, there are all these weird languages. So, so we got into this so I got in contact with like Prolog, Closure, Erlang, everything like this and somehow I got hooked by by the more functional programming languages, Closure, Haskell, and things like this and that led me

[1:11] To then wanted to study it more. Then I actually moved countries to be able to do a PhD in functional programming languages. So, yeah, I’ll I’ll I’ll be the typical example of you don’t need a PhD to do functional programming, but yeah. Then I’ve been exploring Haskell and functional languages. I spent like 7 years in academia. Most of my time teaching this kind of stuff. And then a few years ago I decided that well, industry was kind of an appealing place because I saw that most of the things that 10 years ago were, you know, in a corner for weird people using a strange languages were now becoming much more mainstream. So, even Haskell was becoming somehow using industry, but you have the Scala. People in Java suddenly knew what the map or a flat map was. So, I had well, that that’s a nice place where I can actually bring what I know.

[2:14] That’s That’s more or less what I’ve been doing in the last few years. So, I’ve been slightly moving from Haskell to support more pure functional languages to JVM. I’m I’m mostly I’m I’m working on Kotlin and you know, figuring out how to apply all these functional programming ideas there. So, applying everything you learned from academia to a language like Kotlin. Yes, it’s been interesting because I first went into a more direct, okay, I know this thing from academia, let’s apply it, but it’s been an interesting journey of also having the feedback of, okay, why there are some things which are done differently in industry. And you know, there’s a reason for this and learning this and kind of coming into a new version of what I think functional programming is from what I thought it was 5-6 years ago.

[3:07] Something we should continue on soon. First, Deepu, could you introduce introduce yourself? Yeah, so I’m Deepu K Seshadri. I work as a developer advocate for Octa. I’m a Java Champion and I co-lead the JHipster project among few other open source stuff. So, a heavy open source enthusiast. I wouldn’t consider myself primarily a Java programmer, I’m more of a polyglot programmer and a generalist. So, I kind of take the same approach for functional programming as well. I’m not like a you know, not a functional programming purist or anything. I use the tools appropriate for the situation. So, functional programming is just another tool in the paradigms available. I first got introduced to it coincidentally at the same time I moved to the Netherlands.

[3:57] So, I moved to a small startup working on release orchestration and you know deployment automation stuff and they were doing a lot of Scala and I have never done any Scala before. I hated by the way. So, that in that company I had a lot of colleagues who were some of them probably functional programming purists who would would have liked everything to be written in Haskell or something but for the time being they were content with Scala maybe but there were a lot of functional programming happening and I had some colleagues who we were doing a little bit of Java as well like it was a mix of Scala and Java and some of my colleagues who were into functional programming wanted to introduce that to the Java code as well. So, you know there were a lot of the friction that comes from trying to do pure functional programming Java and all those things. But that’s how I got introduced to functional programming and in the beginning I was a bit resistant because wasn’t heavy fan of all that added verbosity especially in Java when you try to do functional programming, right?

[5:04] And I wasn’t a huge fan of Scala still but later on I came to appreciate the goodness the good aspects of it. And I think then I realized hey I was actually because I was also doing a lot of Java at that time and I realized actually I’m doing a lot of these in JavaScript. I just didn’t realize that I was doing all this and I just didn’t realize that okay that is functional programming, right? So, yeah then from yeah from that point you know once I started appreciating a bit more of the good aspects of it I did start to use that when the need arises or when there is an opportunity regardless of the language that I was using and I think recently I was doing a lot of rust and I was I found myself doing a lot of functional programming in that.

[5:53] Yeah, so that that’s me and functional programming. That sounds good. I’ll also introduce myself a bit. My name is Steve Van De Ven. I also kind of got introduced to functional programming in a sort of similar way where in the beginning of my career I did a lot of debugging for applications. Like I worked on this big monolithic application, millions of lines of code. And most of my time I just spent debugging. And I noticed that like if I would see a null pointer, I would just add an if condition. But then like a week later I would get another error that the function call in that function would now have a null pointer because of course I returned null. Doing that a few times, I started slowly figuring out that maybe this is not a very sustainable approach.

[6:41] You just keep adding if check if checks. And just starting to see what’s the actual root cause of this problem. And slowly figuring out root causes for more and more problems until I sort of find certain things that worked for me that would solve those things. Yeah, years later I saw a talk from Scott Wlaschin. That’s one of my functional programming heroes. And suddenly like all kinds of stuff that I figured hey that worked for me, then they were those have names within functional programming. So I actually discovered certain things just by accident because I figured I wanted to find root causes. So that’s how I ended up being a bit in functional programming. So like I kind of I have no academic background whatsoever. I just came here through being curious and trying to figure out what root causes are.

[7:36] And I found that functional programming was a very good way to learn those things. In that sense, another good question I have for you two is one thing I’m also struggling a bit with. just a simple question, what actually is functional programming? As my answer has changed quite a bit over the years. There’s I think a bit of an academical side, there’s a bit of a practical side. So, what is functional programming for you people? To me, functional programming is you know, more the paradigm where you structure your code from the point of readability rather than performance or you know, something else. It’s it’s it’s about structuring your program in a more readable way, in a more reusable way, and maybe in depending on the language, of course, in a more reasonable way. So, that’s functional programming to me.

[8:27] That’s more of the thing of saying what you want to happen, not how you want it to happen. How about you, Ole Aasland? Do you have any insights on this because you said you actually changed your way of functional programming from academic to practical? What I often say is that so, functional programming is this, well, this idea of using functions, and that already is quite nice. I think that the latest shift to like everybody knowing what the map function is, for example, shows that this kind of code. and that’s a bit what unites all what all those languages that are called functional from, let’s say, Lisp to Scala. They are There’s a What I like to do and the kind of functional programming I like to do is it’s like strongly typed functional programming, if you would like to spell it out completely. So, for me, the main three things is, well, first of all, you kind of use functions and this idea of passing functions around to structure your code. And as I said, well, that means that things like map and this kind of ways to traverse structures are nicer

[9:36] Expressed. The second thing is that you take a lot of care on defining types for everything in your domain. So, I think a very important thing is you use data classes, you use, you know, you use enumerations, you use case classes, whatever the language gives you to have these as small repositories of data. And then the third thing which I find important in this style I like to do is taking thinking about effects. And with this I mean thinking, “Okay, should this function at this point talk to the database?” If it does, then I think it should be somehow explicit. And there are many ways to do it explicit. Types is the one I like the most, but there are other approaches and I still think this is functional. So, it’s about caring this thing, not just randomly, you know, having dependencies all around and talking to stuff and doing network everywhere. I think this is a another important part. Actually, when you take this to the extreme, and I actually like to do that, things like for example, errors also become part of this effect that your function does. So, if if your function may fail, this should

[10:48] Also be apparent somehow in your types, in whatever way you’re doing. Maybe, you know, just to give another point. So, do you have a Lixir where you don’t have types, but people really take care of doing this in a nice way. So, they document this. And I think this is a still the kind of programming I would consider to be this explicit functional programming, if you want to say it. So, but there’s mostly things like try to make illegal states not representable. Basically, maximizing use of your compiler that it can help you with all your problems. I heard a talk by you once where you said it’s it’s like about have been in love with your compiler or something like this. And I thought that’s a very poetic yet true way to put it. Yeah.

[11:38] Yeah, that’s like I think that’s original to the idea behind Haskell that if it compile if it compiles, it works. Just making sure that move as many errors from runtime towards compilation time. I have a bit of a in that sense controversial against basic counter to what you say that for me functional programming I think that it’s core it’s mostly functions and function compositions. If you have two small functions where one from A to B and one from B to C, you can just compose them to create a new function from A to C. I think that’s the core in functional programming as in starting from really small building blocks and using those building blocks to create bigger and bigger programs. From what you said like I see three core problems.

[12:27] That is state management. Like those are all things related with data. Also things like null pointers come from there. There is effects like side effect management and purity of functions. And there’s error handling. And I just don’t see those as three just major problems in functional programming. But in a way I dare to say they’re not directly functional programming related, more functional well, software engineering fundamentals. As in object-oriented programming has these same problems. Right. We could we can never shy away from the fact that you know, our network somehow is disconnected, right? And people input wrong data. So that’s yeah. I agree with you that that’s that’s a more general problem of you know, we have to handle those.

[13:19] And I have a bit of a theory on that. Like why is this more so much more prevalent in functional programming than in object-oriented programming? Because they have exactly the same problems, but for some reason functional programmers can’t stop talking about these things, and you don’t hear them as much from object-oriented programmers. Nice to hear those terms, huh? Functional programmers than object-oriented programmers. Yeah, but that’s the thing like I in a way I hate those terms because there’s there’s first of all nothing inherently wrong with either approach. but one insight I had is that at least in my education I basically learned programming by here are some if statements, this is how an if statement works, this is how a for loop works, this is how Spring Framework works basically, and hey, you can be productive. What I kind of decided to call that more the physicist approach to software engineering.

[14:13] Where in physics we given our universe, and we’re trying to discover what the laws of the universe are. So, I start at the top. I just got the basics, and now I slowly start to learn what programming actually is. Well, academia usually starts with the actions of programming, the absolute basics, and try to work their way up on how can you actually be productive with this? I don’t know if that was a joke or not, but like how to do a print line in Haskell was like chapter five or something to give a bit of an example of that. I don’t know what probably know that. Yeah, so I kind of see a point there. I think that’s also kind of a stereotypical way to do this to approach this, right? I still think that we don’t often remember how we learn programming, and I mean I was a teacher of programming, so we also start with this, right? I mean it feels weird, but people usually take a month to understand if statements and things like this. So, we also start in that way by composing a small pieces.

[15:22] So, I wouldn’t call this a physicist approach either. We also start with this. It’s true that usually imperative programming is print line or things like this is more more is much more Yeah, it’s at your fingertips and there is this, you know, there is this Haskell joke that it usually takes you a lot of time to print something to the screen, but to me that raises the question, all right, okay, why is it possible to actually spend, for example, four chapters in Haskell without actually printing to the screen? And the reason to do this is, well, one nice thing which comes from functional programming communities are interpreters, right? So, the fact that you can open an interpreter and have a piece of code loaded and then directly test it and see what the results are without having to build a main application with which actually prints the things.

[16:20] It’s what actually allows you to do this, right? You can just open Haskell or Scala has it or I think even Java has it now, that you just open it and you can say three plus two and then you get five, right? So, that means that you can already start testing and I think that that’s a more interesting and valuable way to actually introduce programming that maybe the print ln approaches. The going to talk about would like to talk a bit about in the teaching. It’s It was more that I noticed that a lot of these concepts general problems are more like somewhere in the middle between like the mathematic axioms and the top of the physicist. And yeah, that that’s it’s generally people from academic backgrounds are arrive at that point a bit sooner than people from a physicist point of view.

[17:11] Yeah, I was saying that I call it the dry land aroma because I can relate to this more on that. Because I never studied software engineering or computer science. I was electrical engineer who accidentally got into programming and started tinkering around. And I learned everything by tinkering and I trial and error. It’s also same with functional programming. So I can relate to that more. I never had the academic exposure for functional programming. So I might not even understand some of the concepts from the academia side. it took me a while to understand what monads were and stuff for example. So I had to figure it out by trial and error and tinkering as well. some of my colleagues kept talking about monads and I was like, “What are they talking about?”

[17:50] And then I saw what they were like, “Okay, that is what it is. So you could have just showed me.” So yeah, and I just wanted to ask you. So would you consider yourselves functional programming purists? I did in the beginning, but I think everybody goes in a way through that stage where you try to be to the point of dogmatic as in I want to do this correctly. And I kind of moved on from that now and now I don’t think it’s good to be a dogmatic functional programmer and just try to apply when it’s at its best. And certain things are just not good for functional programming. And the way I see that, and I’m very curious also about Alejandro’s opinion on this, is that most of the things in functional programming are in a way to reduce complexity.

[18:38] But the problem is if you apply those to a relatively trivial application where there’s almost no complexity, ironically it start adding complexity. So if you have a trivial problem where you just want to read a file and output the content on the screen, you don’t want to deal with monads, error handling, side effect management and such. That’s way too overkill for it makes that simple application a lot more complex. If you ever have a really complex application, then you kind of need to have these things to make sense of it in the long time. Yeah, I have experience with exactly what you said. Being the on the other side, I’m I’m not a functional programming purist. I would use it if it makes sense. Otherwise, I’d go with the what makes sense. If imperative makes more sense, I’ll go with that. I have been in teams where there were functional programming purists in the team and we ended up adding way more complexity because of trying to do everything the functional way. So, yeah.

[19:36] I think I think I have a good insight because he also works on the error library, the functional programming library I have got in. So, I think that that’s a quite a different approach to this topic. I don’t know what you think of it. It’s It’s interesting to me because I think that all these these these kind of discussions about functional programming always end up on this pure thing. So, it’s it’s also for me interesting as maybe something somebody coming from, you know, functional programming first into other to see why people want to do this pure thing, right? And even to agree what pure is and maybe the people who are listening to the podcast don’t really know what we are saying when we say pure. And for example, I consider this when people, for example, say, “No, I want to do everything super immutable regardless of whatever. This has to be immutable.”

[20:32] And then I think this to me, what happens there is a bit like with maybe design patterns, things like this. It makes sense if you understand the why you want to do this, right? We want immutability because with the that makes debugging easier, that makes the scaling easier. That doesn’t mean, of course, is the solution to everything. And I mean, you know, sometimes using this is as overkill as as if you would introduce a file factory to read, you know, for a small application with reads a file, right? Why would you introduce a factory pattern if all you are going to do is to instantly a single class? You know, I think in the past, for example, we also have like for example, design pattern theories, right?

[21:17] Who always wanted to apply this kind of thing and I see the same kind of overkill thing. So, you see a solution to a problem and suddenly you want to apply the solution everywhere. But, I would say that in this year what I Maybe I’m a still a purist in that I what I really have become very very I think it’s very important in all of in all the code that I write is explicit nest. I’ve become a pure a purist if you want to say a very dogmatic about explicit nest. I really want my signatures of my code to essentially tell all the function can do and never has a sneak never have a sneaky behavior to do this and I find this is this just helps me helps the teams I work with. So, I thought that of everything that functional programming mean as I said strongly that functional programming has to offer, that’s the only thing what at the end of the years I’ve become convinced that still pays off to be somehow dogmatic, purist, extreme, call it whatever. I think that that’s the main thing that I still want to do.

[22:26] Now, but I think the key part here what you say is that understanding the why. Why do you want to do a certain thing? You know, once you understand that, it becomes a logical to do and it also becomes logical when not to do it. Like I need immutability I’m a big fan of that and favorite it solves a lot of my problems. But, if I have a function that needs to loop over a million elements and do a computation on that, mutable state is way more performing there. But, what I like to try to do is that function should have an immutable object in and an immutable object out and if the state in between is mutable, it doesn’t matter. The rest of the application won’t see that and that would be a for me a practical though I know exactly what I’m trying to do. The application should have immutability in immutability out and an implementation can have safe mutable state. That’s not really an issue.

[23:21] And I think that thing you raised an interesting thing also because that’s what I’ve seen for example in languages like Kotlin which I think it’s a really great idea is to expose the functional API but actually when you see what bytecode is generated is actually doing the looping because whatever inline thing it’s doing which I think it’s also an interesting approach. So we are I think in the history of programming we’ve been very forced to actually have the stupid have the same view in the low level and the high level, right? So for example if Java decided that in the JVM they are not having generics, that means that you don’t have generics in your language and you have to deal with it, right? Whereas you have a Scala and Kotlin would say, “Yeah, sure my platform doesn’t have generics but I still have full-blown generics and I think that’s an interesting idea which is going to become more prevalent, right? So have APIs which are nice and functional yet have implementations which really do the terrible thing you maybe don’t want to do by hand because you want the

[24:32] Performance. That’s that’s I think that’s that’s a given for almost every programmer. I think performance is the I think that the key reason I avoid functional programming is always performance. Especially in Java, I mean okay, in Java I avoid functional programming, a lot of the paradigms. I think the only time I use functional programming in Java is if I have to use if I can do something with the stream APIs or you know the optional monads and those. those are the only things I sprinkle in. Otherwise, I generally tend to go with the imperative or object-oriented with Java. But, I found myself doing a lot more functional programming in Rust because it didn’t matter. The performance aspect didn’t matter there because the compiler in the end was generating imperative code regardless of what I was writing, right? So, I didn’t have to care about that. But, in Java, when it’s quite easy to check, right? You write something in functional and you write something in imperative, you run a performance benchmark and you clearly see that the functional one is like twice as

[25:29] Slow as the imperative one, right? So, I tend to avoid a lot of that in Java, especially if I have to do, you know, process over a lot of things. I tend to avoid using functional programming there. question here is if if it wasn’t, right? If if if the performance was the same, Mhm. would you then prefer the functional Yeah. version? Yeah, that That’s what I said. In Rust, I tend to use functional programming most of the time. So, so I don’t even think about it. I just notice that, hey, I’m I’m just gravitating towards that. Like, I tend to use most of the functional APIs most of the times. I mean, of course, except there are a few scenarios where I don’t, but I know, unconsciously, I tend to gravitate towards that because I’m not thinking about performance there. But, in Java, then I’m I’m thinking about that. So, I tend not to. So, exactly as you said. So, if that was not a problem, then I’m pretty sure most people might have because it is convenient, you know? the functional APIs are convenient. They are more readable and you know, easy to reason about than imperative code, of

[26:32] Course. Yeah, you need to get that confidence that you don’t have to think about that to get there. Also, yeah, I think I tried to write something about how to do every aspect of functional programming in Java. And to be honest, I wouldn’t use half of that myself because it’s it’s not very concise to read in a language which is not meant to support that, you know as as a first class citizen, right? So except for lambdas and you know the stream APIs maybe, it the code becomes very untreatable. You know, it does the opposite of what you want functional programming to do, right? It is not it kind of becomes hard to read for someone who is a regular Java developer, right? Because that’s not how you write normal Java code. It starts to look weird.

[27:14] And to me that goes a bit on the same idea of exposing So again, Java is kind of forcing you to go It’s it’s like with properties, right? Java is forcing you to have your getter and your setter. Why? Why is it forcing me to do this when any other language is able to declare a property? You know, C# had this 20 years ago, right? So I have a problem with doing these kind of things, right? It tries to not hide complexity. I don’t know why, but I think that’s the approach of the language, right? That you also see this with things like project to loom and so on where they provide a very low-level API, which I think oh, that’s a great API to build a library on top of this. But then what you read in blog posts is how to use this API directly. It’s like, why don’t you create something new and beautiful on top of the low-level API?

[28:08] Sounds like a new library idea for you. Deepak did raise an interesting point, the cost of functional programming because indeed there is the performance overhead. For example, with immutability, the only way to change objects is to create a new instance of the object. That causes a lot of extra objects on the heap, which damages performance. Can you elaborate a bit more on the cost of functional programming, Alexander? As in, what problems does it give you? When I think of the cost, I think there are two main costs. One is I think sometimes when you don’t have the performance that you want from your functional code because the kind of languages we use to do functional programming are usually built on top of let’s say a JVM or some other platform which is not functional, then you end up having to figure out what was the translation and figure out where the performance issues come from. And I think that indirection it’s it’s hard and maybe maybe it’s even something which functional programming always have. So if you hear Haskell people, one of the things they usually struggle is when I

[29:20] Have a performance issue, when I have a memory leak, how do I find this? Because yeah, the APIs are very convenient, but they hide away complexity and we sometimes need to unveil the complexity in order to understand where the performance issues are coming from. So I think that’s that’s one thing. The second thing is usually traditionally people don’t learn functional programming when they start learning programming. If you want to introduce functional programming in a team, you need well somebody to kind of push for it, you need people to learn this and this of course has some some friction, right? So I think that’s not a problem with functional mean per se, but if you want to introduce functional programming, that’s something that I think people have to be honest about. This is going to cost you and some people say this will only be one month, some people say that’s going to be three months, but there is one time there is some period of time which people need to familiarize themselves with functional programming.

[30:24] Looking at myself, it took me quite a few years to really get into the why it’s and yeah, there is a cost there where there are a lot of concepts that you kind of need to learn and if you want to do it correctly also but people pointed to that yeah, you really need to understand the why, when to use it, and that takes a lot of practice. So, there is indeed the cost of I wouldn’t say there actually added complexity, but yeah, there are just new concepts you need to learn and understand. And if you’re not used to that, that can be difficult to introduce into a team. People, do you have any other insights on this? I think I would like to touch upon something that Alessandro was mentioning. It’s about when you learn functional programming, right? I believe it helps that you learn functional programming after you learn something like imperative, object-oriented, probably not, but at least once you’re very familiar with imperative programming and you can write something very closer to machine code, and then if you learn functional programming, I think that helps you to kind of appreciate it a bit more.

[31:29] Because I have come across folks who, again, probably similar to me, they didn’t have an academic you know, path to learning programming, learned on their own, and they tend to they kind of started directly with a language maybe like a functional programming language or maybe with Scala or even like a functional programming in JavaScript kind of thing, right? They tend to kind of overuse it in my opinion, and kind of use it as a silver bullet, and not understand as you mentioned, not understand the cost or when and why aspects of it. So, I think it would be So, I agree that it would be nice if when people are learning programming, they learn also functional programming, but it would be nice if they do it after they learn imperative or some other paradigm.

[32:18] I actually want to challenge that because isn’t this just the definition of a junior developer? I mean, whatever a developer is a starting, usually you know, they come with a set of things they learned and they believe are the way, right? And be it functional programming or whatever, they tend to have a very narrow view. So I want to challenge that this is a functional programming thing. I’m much more like a junior developer thing instead. I don’t know what your thoughts are about that. Yeah, yeah, definitely, definitely. It can be that. So my point was regardless of you if you’re a junior or whatever, right? Like my point is that it helps to appreciate functional programming more when you actually learn some of the paradigms.

[33:04] That that’s an interesting point. So you want to learn the bad so that then you see how nicer it can become? That is how I learned it. Basically, I was making mistakes and I figured out solutions for those mistakes and that’s basically how my love for functional programming started to come. because I saw how it fixed things that were going wrong for me. I want to kind of understand why is you both seem to think that this is an important a step or an interesting a step with respect of the other possibility which is if you start blank slate, you let’s say learn both paradigms at the same time. Why do you think that it’s important to make the mistakes to then appreciate it more? That is something that works for me personally. I wouldn’t say that’s the only way, but that that’s how I got in contact with but also didn’t have someone to teach me functional programming.

[34:00] I’m not saying the other paradigms are the bad ones. They all of them have their all of them have their need. All of them have their place and all of them have their strengths and cons. To me at least similar to what Dave said, to me personally, already knowing imperative and object-oriented helped me to appreciate some aspects of functional programming. Also helped me to not appreciate some aspects of functional programming. That’s why I would never use functional programming wherever I go. No, I’m not I’m going to use it when I think it is appropriate. So, as I mentioned, so if I’m writing Rust, then yeah, maybe I’ll just do functional programming everywhere if possible. Again, I’m not going to do pure functional programming there because sometimes it’s not practical.

[34:41] Sometimes it just adds more complexity than it is required. Sometimes I just a simple for loop is less complex in some situations, right? I’m I’m going to do that, but having all these in my tool belt helps me to make the right choice. Helps me to appreciate when to use what. So, it helps me to appreciate, “Hey, okay, functional programming is going to make this part of my code very readable concise.” It helps me to appreciate that. And sometimes it helps me to not make the bad choice and add unwanted complexity because I I’m not familiar with other concepts and I don’t appreciate those, right? So, for me it’s it’s about knowing the different options, having different options so I can make the right choice. So, I that that’s why I mentioned, if someone does that, then yeah, they probably can do the same thing and I see a lot of this in our industry, right? generally there is this push that, “Okay, functional programming is the ultimate way of programming.” And there is a chance that a lot of people who might start with that will get stuck on that and they will never

[35:43] Explore the other options and regardless of they are junior or senior. I mean, I have I have seen very senior folks who would not touch any other paradigm because they are very hardcore on functional programming and they end up adding unwanted complexity. So, I wouldn’t say it’s a it’s 100% a junior thing. It’s more of getting too much tied into one way of doing things. Yeah, there is a bit of a dogmatic elitist thing, but I that is true, although that’s also in object-oriented programming here and there. So, that that’s everywhere. But yeah, I do think that’s a bit of a problem. Same with how it’s explained, which is usually in very academic language, which makes it harder for people like you mentioned at some point, hey, what is a monad? But if you look at the definition on the internet, yeah, you don’t know you just see like 12 new words that you never heard before. So, that’s not going to help.

[36:38] Yeah. So, that’s a bit of a problem with that. I actually want to challenge that, right? I think that the industry has become and I’m a bit afraid that we keep repeating this stereotype and then we help perpetuate it. I mean, we are in a regular podcast talking about functional programming. We all use functional programming in our jobs and there are books being written. In short, I think what you said is what’s true one decade ago. I think it’s no longer true. There is this elitism is really gone. I think that most people nowadays have these concepts and of course there is a there is always a few people who want to feel superior by knowing the mathematical definition of a monad, right? But I think you can now learn what the monad is even with the 10 million blog posts explaining it.

[37:26] Basically going to be my follow-up point. So, so thank you for that. Okay, that’s exactly the thing. That’s also something I tried to do with in all my talks about it. Just make it accessible as in you’re probably using all these things already without maybe knowing the names behind it and it has become a lot more accessible these days. Yeah, exactly. I had a huge issue with this math the academic way of explaining things. That’s how because when I got introduced to functional programming, I was looking at higher order functions, monads, this, that, like referential transparency. I was like I didn’t I was like what are these? Like okay, then I started getting this what do you call this imposter syndrome like got blown up that because I didn’t have an academic background or like I didn’t have a computer science education. I was like oh, I just don’t know a lot of things. I’m just stupid. Like then I started trying these and I was like okay, referential transparency. I’m yeah, I’m already doing that. So, Yeah, can’t you just say that you know why can’t you just say that it is about

[38:25] Immutability? Why do you have to say That’s the approach I tried to show people that you’re already using it, but I do notice by myself notice myself that learning these definitions does help me. Like learning how something is called by the correct name does help me think about it in a different way. So, I learned it by exactly what you say like I’m already doing this and how slowly I’m starting to use the word monad for example more and more because yeah, that it it’s shaping how I think about programming. So, terminology does help in ways of thinking. So, I can encourage it people to learn it over time, but you don’t need to know it right away. I used all these things for years without actually knowing the proper names for it.

[39:13] I think most people do. Most people are do using most of those without knowing those terms, right? So, I agree. It is important to know the terminology at some point, but to make it more accessible I think it helps to kind of you of course use the terminology, but also explain it in simpler terms in more universally used kind of terms, right? So, it hits faster. It registers fast. I want to go a bit in that that’s the leads a bit into the teaching side. I want to make two points of this. So, first of all, one one thing that I think as to be clear is that even if you want to go into functional programming, you will have to learn something, right? It’s a different thing.

[39:53] And I think it’s very even irresponsible from us to say either oh, you need you don’t need the whole to know the whole definitions and all the whole book. That’s right. it’s not true either that you don’t have to learn anything, right? You will have to put some effort. And I think I like with the pass of time with the passing of time, I’ve tried to be more honest about this. I used to tell people, “Oh, no, it’s so easy. No, it’s you know, it will you will have some learning curve. It could be a steeper or shallower depending on how deep you want to go into this concept, but you will have to learn. And you will have to unlearn some things you know. And this goes a bit into the point I wanted to make, which is that’s a bit to me like I don’t know if if you’ve tried, but the difference between teaching kids or even you know teenagers, people something for the first time is different very different from teaching grownups something. And you can see this for example in language, right?

[40:53] When you are a kid, you learn language by doing, by trial and error. And you every everybody around you kind of tells you when you’re doing something wrong, tries to help you. That that’s how a kids learn language. When you are an adult, you have a book which tells you the grammar rules of the language and it’s very hard. It usually you say “Why do I need all of this? I just want to say hello.” And to me this happens a bit with functional programming. We tend to learn functional programming at point in our career when we’ve already learned the other stuff. So, we learn it from a book. We learn it from a more, let’s say, academic, but maybe more book-like perspective. And we want to be very productive very soon. We don’t give us the room for trial and error. We don’t give us the room for experimentation.

[41:42] And that’s why I think where all these questions come from. Okay, but why do I need to know what referential transparency is? Well, it helps you. and if you had learned this from the beginning, you would just have grown with it. That that’s kind of the point where I am. It’s it’s And I see this again with teaching anything, I think, to a grownup, right? Try try to teach somebody why they suddenly need to make their taxes on their computer instead of on a piece of paper, right? And they will say, “Why do I need this?” I think this is a bit of the same kind of thing in that goes when people have to learn functional programming. I think that’s a very good insight, but you know, you have to be kind to ourselves and others that yeah, this is something that you don’t get to be productive instantly.

[42:31] These things just take time. And I do hope that if others probably listen to the podcast that people spend the yeah, accept that and also spend a little time in learning functional programming. Now, how do you see the future of functional programming, Alejandro? The main thing for me is that functional programming is here. I mean, I always tell my friends who are also doing this like we already won, right? Like Java has records, still here case and functions. So, it’s it’s all I want from a functional programming language. So, in that sense, I think it’s it’s just there. It’s it’s inevitable and I think the last missing thing, which was all this kind of concurrency threading idea of having lightweight threads to have many things it’s it’s already there with project loom. So, on some sense, it’s inevitable is now.

[43:23] The future is now. What I would like to see is that people start asking for compiler writers more than they used to. And for example, I think that if you do Kotlin and then you use their nullability analysis where you cannot have null because the compiler keeps track of this. To me, the main question is being an academic and knowing that kind of analysis already existed in the 1980s, why does Java in 2020 doesn’t have that analysis, right? So, I think we are going to see I hope that we see something where people say, “Oh, my compiler can do more. Let’s track more things. Let’s try to make it help me. I think what Ross has done is incredible, right? It’s stuck in your memory. So, you know you cannot leak it. why can other languages have this kind of thing? And I hope this is the future of what we’ve seen the la- in the next decade or so.

[44:22] So, it’s quite cool. People, what do you think of our future? Do you have anything to add to that? Yeah, definitely. I mean, since this is a future podcast, right? I think we have to talk about Java. We have to talk about Java. I love Java. I’m a I’m a Java champion. I’m going out and teaching Java to folks, but I’m also the biggest critic of Java personally, right? I would love to see Java grow more. I would love to see Java compiler becoming smarter. because it’s hard not to notice in other languages, especially if you’re a polyglot, right? It’s hard not to notice things missing, right? I would love to have I would love to see zero cost abstractions in Java. Then you don’t have to worry about some of the performance cost of functional programming, for example, among other things, right? I would love to see tail recursion in Java so that you can write proper recursion without having to worry about stack overflows and stuff like that, right? So, I would love to see a lot more of these underlying compiler features in Java. I would disagree that the functional programming feature is

[45:25] Already here in Java. I don’t think it is already here. We are getting there, maybe, but I personally think we still have a long way to go because I still think you can’t write No, if you really want to do full-blown functional programming in Java, I don’t think you can do that yet, unless you go out of your way and, you know, start using all those functional interfaces everywhere, which kind of, in my opinion, makes the code less readable than object-oriented or imperative in Java. So, I would like to see that improved. I would like to see more native support for maybe first-class functions, and not just lambdas, right? I would love to see the compiler grow more, become in line with like like something like the Rust compiler or something, right? I would love to see that.

[46:13] So yeah, I think we are getting there. So, we are going in the right direction, but maybe it would be nice to speed up a little bit more. Personally, I think I may just can’t add anything to language. I think you covered that really well. I would like to see a bit more like in teaching aspect to the abstract thinking part. what are the underlying problems? Although people also kind of need to figure those out themselves if they really want to stick. but I do think indeed the as in the future is now, I do notice a big difference now and years ago. So, that there is a bit more incline in into this functional features, and I hope that continues because I do like the whole making illegal states not representable, moving errors to compilation time, being explicit in code. I think those are very good things in general, and I like it that they’re coming up more and more.

[47:07] Yeah, definitely. Any last thoughts, Alejandro, Deepu? Yeah, I would like to continue on what you said. So, yeah, I think a lot of things changed from that teaching aspects and the general acceptance aspect because lambdas and you know, the monads of Java like optionals and all these things, right? They are very very normal now, right? So, they have become mainstream and kind of have become the de facto when people write code, which is a good thing. So, I think teaching wise, yeah, as you mentioned, the language features, yeah, we are kind of maybe at a level there probably not a lot to add other than optimizations to the compiler, but maybe from the teaching aspect yeah, I think functional programming can become aspect of teaching Java maybe among along with of course object-oriented and imperative. I do see a decline in pure object-oriented programs written in Java. I don’t know how if you also notice the same but maybe that’s a good thing. Maybe we are seeing a decline of people because Java used to be object-oriented programming’s the downside, right? So I think that is

[48:26] Changing so that probably is a good thing. I think it’s a good thing mostly because there are certain problems object-oriented programming is really strong in and there are certain problems functional programming is really strong in. So in practice the combination is always better like Brian Goetz the Java language architect also said in one of his talks, don’t be a functional programmer, don’t be an object-oriented programmer, be a better programmer. Yes, exactly. I think that was very inspiring for me. And I That’s it. Like you can also mention a few times you should have a toolbox full of tools and apply the correct tool to the correct problem and in practice that’s going to be a combination of all paradigms.

[49:07] Plus one on that. That tends to be my starting line whenever I write about functional programming. Don’t just use that you depending on the language use whatever available to you. If any last thoughts Alejandro? I don’t use Java for most of my day. I write Kotlin so I’m I’m but I’m I’m starting to actually get jealous of what is coming in like Java 21 and all of that. So I consider for example pattern matching to be a very nice tool if you want to write functional code. You don’t have that in Kotlin but you have it in a Scala and it will come in Java 21 for records. So I think this kind of additions will hopefully means that all of these becomes more mainstream. I don’t know. It’s It’s also I think nice to see how some of these ideas are also impacting other parts of the process. So, I don’t know about you, but for example, I Now I even hear about declarative DevOps, which I think is a nice twist that I wasn’t expecting on this whole story like functional programming becoming popular enough that people in ops think, “Oh, maybe we can apply some of these

[50:23] Ideas here, too.” So, that’s I don’t know, a small twist that I see that we can see that more broadly these these ideas are going into our industry. And your statement, the future is now, that’s also happening in other areas. And I think that’s a good thing to close on, too. Thank you both so much. I got some quite some good insights from this. Had a really nice conversation. So, thank you both for coming. And thank you all for listening. Give me a Foojay. Give me a Jay. Give me the friends of OpenJDK.