The reality of functional programming

I was happy to be a guest on Developer Melange where I talked about the principles of functional programming.

Transcript

[Music] Welcome to Episode 40 of Developer Millarge, the podcast about developing software in the 21st century directly from Vienna, Austria. Developer Millarge brings you regular discussions about everything software development. You can find us online on developermillarge.com and you can follow us on Twitter via @devmillarge, that's dev-m-e-l-a-n-g-e. We are very keen on learning what you think about this show or the podcast itself. So please reach out for us on Twitter or leave your comments on our website. We appreciate all your feedback. And now, here are your hosts. Hi, my name is David Leiden, I'm a co-founder of School of Solutions and we need software company. And describe myself as an enthusiastic software professional who is working on various projects using a punch of different stacks and environments. I'm Peter Kovaler, the CodeCorp. Obviously, I'm fanatic about clean code. My name is Christian Haas, I'm a developer who embraces extreme programming. And in this episode, we are joined by Eric Normand. How about Eric? Hello. Eric Normand has been developing functionality since the year 2000. On his web page, Eric makes functional programming accessible with a podcast on his own, as well as essays. Providing training and consulting as well, he's taking complex academic ideas and makes them useful for the software industry. And with his newest book, "Grocking Simplicity", he provides a friendly, practical guide towards a mindset of functional programming. Great to have you on the show. Oh, it's so great to be here. In your book, you have the inner showcase for a developer trying to pitch functional programming to their manager. And through that, the manager rejects this approach because they then looked up the technical definition of functional programming on the Internet. To which degree is this a stylized story? And what was your most extreme case of rejection to bring this story up? Yeah, well, it's definitely a stylized story. You know, it's like a one-page comic strip or something. So it is meant to be sort of representative of something that happens all the time. But I think it does happen all the time. I think that when people are interested in functional programming, they look up on Wikipedia what it is because that's where you go when you're interested in something. And the definition does not sell the idea. It doesn't talk about how great it is and the benefits of it. It just talks about what you can't do when you're doing functional programming. You can't do side effects and you can't have any mutable variables or mutable data structures. And I think that's unfortunate because there's a lot of functional programmers out there who do have side effects in their software. I mean, it would be weird to have software that didn't have side effects, like some reason to run the program. And they do use mutable state. And so my goal with the book was to kind of address this. Now, I do have a story. When I was, oh, this must have been 10 years ago, maybe maybe 12 years ago. I was working at a job and I was into closure and everyone knew it. All the programmers knew it. And I was talking about Lisp and what I liked about it. My manager, he was also a programmer. So, to be fair, you know, he knew what he was, he had experience. He said, well, I could never use a programming language that doesn't have loops. And I thought to myself, that does not describe the Lisp. I know, you know, I use loops all the time. And I was also into common Lisp. So I went back to my desk and I looked up. We were using Java on the job. So I looked up how many loops are there in Java. There's the for loop. There's the while loop and there's the do while loop. So that's three. And then I counted in common Lisp, how many loops there are. And there was something like seven or eight different kinds of loops. And so I thought, what is going on? And what I asked him and I realized that he had learned Lisp in college in a class where they were learning functional programming. And the teacher had not taught the loops so that they would have to use recursion. And so he had the idea that there were no loops in the language. And so it was totally impractical. And it's that kind of academic take on programming and functional programming specifically that I think has done a lot of disservice to the industry. You know, common Lisp is an incredibly practical language. Now it's dated. You know, it gets older every year. But it has so many features in it that a functional programmer, like, let's say a Haskell programmer would say, I would never use that. It's too mutable. It's too, you know, too much side effects. And it's an incredibly practical system and was used in the industry for a long time. So I always remembered that story and wanted to bring something like that into the book. You know, that this isn't, this isn't, you know, your professors attempt at teaching functional programming to you so that you would, you know, be forced through immersion in a very strict language to learn it. I wanted people to learn it in the language that they already understood. Right, right, which is I guess also why you took JavaScript as the language in the book. Yeah, I see it's like when it seems like for if you want to do functional programming, you have to do, you have to use a function program with language and then you're suddenly stripped away from all your toys, like, well, where are my groups or not knowing about this or want to try something and then the compiler screams at you for doing. That's right. That's right. So it's immersion. It's like, you know, you want to learn French, you go to France and, you know, you speak badly for a long time and you don't get the things you need. And you eventually learn how to say this stuff correctly. And then you speak French. If you try to learn at home from a book, if you get hungry, you can always just speak English. And, you know, if you're hungry in France, you have to learn to speak. And it's just a lot more motivation and your brain kicks in and starts learning it. I think that I have to be clear on something that I it's not a functional programming in JavaScript book. I don't think I can say that enough times I'm not recommending you use functional programming. Or you use JavaScript to learn functional programming. I actually think it's not that great of a language for it. It's okay. It's mediocre for doing functional programming. And it's kind of bad at learning it for all those reasons I said, because you're not immersed. You can always just use a for loop if you get stuck somewhere. So it's more about the mindset. You're going is about the mindset. Yeah, it's good. It's just to be happy. Yeah, it's good for teaching job functional programming because it doesn't have all the features you'd expect. And so we have to build them in the book, right? We have to build immutability. We have to build first class functions, you know, like, plus isn't a first class function in JavaScript. So we have to show how to do it. So, yeah, I think I felt like it was a pretty good language for teaching it because otherwise you get, you get tied up on like functional programming. It's all about these certain set of features that the language gives you. Right. So are you implementing a list in JavaScript? No, no, I'm just making fun of you. Sorry. So what would you recommend as a learning language for function programming then? Oh, that's a good question. So it depends on what side of the type debate you fall. Like if you like static types, something like Haskell, although that might be a big first jump. There's Elm, which I think is really good for learning the types. It has a simpler type system, but still, you know, robust. And it still has the immutability and everything. And so it's a good step into functional programming on the type side. On the on type side, I think closure is a really good language to learn for that. It has it's untyped, but it has immutable data structures by default and runs on the JVM and compiles to JavaScript. So you can you can choose the platform. You want to run it on. I tried my luck with Haskell. I'm still curious about it, though. My time doesn't permit it, or at least I'm not taking the time for that. And for that, I found the Haskell book. For me, it wasn't a curious idea because it was simply starting from zero, both the language and function programming, because the author used the partner proofreading the book and that partner did not have any idea about programming. So this was a curious idea about that, though it's well, specifically to Haskell, whereas you, Eric, your book, more about the mindset for function programming and then taking in in whichever language you are, then to think more in that manner. That's right. And maybe it's a little bit of a provoke. It always happens between us Peter, right? Please go ahead. Maybe it's a little bit of a provoking question, but I mean, why, why should I take the effort to develop something with Haskell. For example, could say, hey, I could use Charles, I could use C sharp in that night, or I could use Charles script, which all come with a basic set to also execute functional programming there. And I still have to forward to say, hey, for some use cases, maybe I want to go there object or end to wait because it fits the problem space better. So what is really the primer, especially for languages, like not closer, which would also run on the JVM, but languages which have a very specific own ecosystem and are hard to integrate and into other kind of. Yeah, so I mean, you're, you're asking me to sell Haskell and like, I don't know if I can. I don't think I'm the right person for that, but I'll give it a shot. Haskell, I have worked in Haskell and Haskell gives you really great modeling tools for modeling your domain. And it's the type system is because it's sound as opposed to say Java's type system, which has, you know, a lot, you know, you could cast it any time, that kind of thing. And it does a lot of inference. It's like having a logician on your shoulder who can catch errors like, Oh, you didn't think of this. You didn't think of that. And that actually, when you do get over the hump and you understand the type system that Haskell provides you, it actually starts feeling good that like, Oh, thanks for catching that error. Before you're on the other side of the hump when you're still learning, it's much more like, Oh, but why? Oh, man, I got to start over or try something else. Why are you? Why do you hate me? Sometimes it feels like the compiler is just your enemy, but you get over the hump and it's your friend. It does have a smaller ecosystem, I have to say, than like Java, for instance. But there's a lot of, there's a lot, there's enough. Like, you know, I worked at a company, it was all Haskell, and we did just fine with the libraries that were available. There are companies based on it. So there's, you know, the practical stuff has been worked out. Well, there are companies based on JavaScript, right? So. Well, that's a big community. They can, they can brute force any problems. No. But let's, let's get back to your book. It's named Crocking Simplicity, right? And so, and then it's a functional programming book. It's like an introduction function programming, right? So how is simplicity, like is it a simplicity? You make the concepts from sick B and like so everybody can understand them or where is simplicity coming in? That is a really good question. The title actually comes from an earlier draft of the book. So the, an early, one draft. All right. And I also have to explain it's, I did not choose the title, the title. Yes, the publisher chose the title after reading this earlier draft. And the earlier draft was, it wasn't very, it wasn't a very good book to read. It wasn't very interesting. But the idea was to motivate functional programming by talking about complexity and kind of talking about different ways that complexity enters into your software. And one of those ways was the different kinds of the different orderings that you get when you're running multiple threads that there's this explosion, this factorial explosion of interleavings between the different threads. And so that's a source of complexity. And so we want to, we want to tame that, we want to reduce that complexity. And the other source of complexity was, I guess you call it corner cases, conditionals. Like every time you add a conditional, you have at least two branches. And so now you have this possibility of this, you know, if you nest them, you have this exponential growth, doubling every time you add of every time you nest deeper of possible states you're in. And the idea was, this was in the early draft, the idea was to address those two with functional programming. And it turns out that I do address the first one, because I do talk about timelines and different threads and ways that functional programming has to deal with timing issues, ordering issues between different threads. But I don't deal with the other one, which I was going to approach it from a data modeling perspective. Like the problem, the reason you have too many conditionals is you have not adequately modeled the problem. And you're having these corner cases, because you used for, you know, just as an example, you use two booleans to model a situation that only has three cases. So now you have this fourth case that what, you know, what if you get it, what if it's in your data. Now you have to make a conditional like to deal with that. And you should never happen so that they recommend this should never happen. Should never reach that code. No, but do you think, do you think that function programming, like on a personal personal question, do you think that function programming paradigms or parts of it lead to more simple code. With that definition of complexity, that the tools that functional programming gives you can address them. Not saying like all functional code is simple, but those two sources, I feel like are not well served by other paradigms. So the whole idea of concurrency and how do you deal with it. I think that when, like, for instance, object oriented programmers talk about it, they always start borrowing ideas from functional programming and then they'll even they'll say that they're like, Oh, yeah, we'll use a mutability like the functional folks do. Then with the data modeling, I feel like the way that object oriented modeling and design is taught. You get into this to Boolean problem all the time. And I wanted to approach it from a more functional side, which is let's use product types and some types and build up the model more systematically to avoid corner cases and use some algebraic properties to define. You know, I actually didn't didn't get into that in the book, but I had a plan for where to go with that. I worked at a company and we had a system where you could sign a document. So it would record when you open the webpage to view the document, and then you click sign and it records that you signed it, right? And it would record, you know, you sign in a Boolean. Yes, view the document. Boolean. Yes, signed it. But what happens if you sign it if you have a true in the signed, but you have a false in the in the view. That shouldn't be possible. But we could represent it. And so the problem is you are trying to model this flow with that actually has three states, which is not viewed viewed and signed. But you have a two booleans, which can be in four different states. And so you have this corner case of not viewed, but signed. And, you know, if it's a legal document, you might get into trouble, like, wait, they signed it without viewing it? Like, why did they do that? And you've got that in your database that they never viewed it. And, you know, it's just technically impossible. They couldn't get to the button without viewing it. But you can represent it in your code. And so you have to have a NIF statement and, you know, you're starting to talk about this complexity we're talking about with this corner case. So the idea is functional programming has tools for modeling that state and knowing when your model has a tight fit on the actual, you know, knowing whether your code has a tight fit on the situation you're trying to model. Yeah, I think, and we just totally sense this example. And it's definitely one of the things where, yeah, we just actually, I think, one of the main advantages, we are often discussing all the recent teams, and when we discuss exactly about this topic and this decision. I think I interrupted you, Peter, but otherwise I would like to understand a little bit more because what we see quite as a trend going on these days is the whole idea of reactive programming, which is kind of as a professional programming I was kind of translated. Do you think that this is something which could change the whole game in a way that people will move more than functional concepts because there we have that what you mentioned before concurrency. I guess need a lot of immutability out of the box. So if all systems coming more into this reactive aspect and maybe this is a good driver to to we have to enable functional programming again as a first class or as a first choice. In the course of writing the book, I decide, and all these drafts, some of that, you know, had all these consequences, but I didn't anticipate like having the title chosen based on one of them. I started to look at functional programming as a rich body of practice, where there were just all these good ideas that are applicable in software in general, regardless of the language you use. And so then the book is just well let's just pick the common ones, the most important ones that you can build on, and I put those into the book. And one of those things is reactive programming. So I would hate for someone to listen to this podcast and think reactive programming is the next big thing I have to change all my code to reactive programming because it's better. It's actually very good for a specific situation of a specific job. Normally in code, you sequence steps, right, this happens and this happens and that happens. And sometimes what happens is you have a lot of things have to happen like when event A happens when something happens in the code, like let's say a variable changes. You run 10 things, boom, boom, boom, boom, boom, right. And then there's 10 places that can change the code. Sorry, not change the code. Change that variable. There's 10 things that might change that variable and 10 things that have to happen every time it changes. So now you have to keep these in sync and you notice there's actually it's an N by M problem. Every time you add a thing that has to run, you have to go add it in all the 10 places. And every time you add a new way to change it, you have to make sure it runs all those 10 things. So this is the kind of complexity that I'm talking about where it's an N by M thing and it explodes the amount of work you have to do. So there are things you can get wrong. What reactive programming does is it reverses it. Instead of saying do A then B, you say whenever A happens do B, right. And so now if you make a construct that can detect, oh, this variable has changed, right, maybe wrap it up in an object and the setter on it now will have some callbacks or something that it can go, you know, it's like the observer pattern. Right. And so you, you decouple the sources of change from the things that have to happen when it changes. Now the problem with it is you can't just look at the code and see, oh, these 10 steps are going to happen because those are all registered in other places. You can't see that statically in the code. And so there's this trade off of the flexibility of adding these things easily from other places in the code versus the readability, the legibility of knowing what's going to happen. Full, full agree. You know, I'm just asking this direction because I always wonder, you know, I think functional programming made it step into the wide maturity of programmers. If you think of it like the stream API in Java, right. But that's mainly used within still an object oriented paradigm you build your classes and within the methods of those classes you start to use functional concepts I would say, right. So that the overall software design is still object oriented and you start to introduce a little bit of functional programming in the methods, for example, right. And we see the same thing a little bit in a way that people say, no, we don't want to do object oriented program at all we go full state functional program, right. And I see it easier that we can mix object or in the program functional program, but I see it, for example, very hard to mix reactive software design is existing object oriented software design on a way how we did it is functional programming. So, I mean, my channel question I was asking this one I was trying to ask is the first question, do you think that it makes sense to mix those concepts. So, so, so heavily rights who have languages which support. I don't know, Charles, I'm starving you can do active programming with the stream API, you can kind of function programming, you have an object oriented program and program language with your hand. I think it's good if we, if we really mix and match those in one kind of software design code base, or would you rather go in one direction say okay, maybe we split up the programs and say, okay, but this for this problem domain we go with object oriented, and here we go is functional but we mix this all together so that you never know is it now in synchronous state, this is nice synchronous state to have a mutant list here to have information hiding of the object oriented side, you know what I mean so it's getting faster to really make understandable what is the code is about, and what are kind of the unspoken rules on people should understand if the work is good. Wow, that's a really good question. So, I was hoping that you can answer it for me. Yeah, well, my answer is I don't think the mixing is a problem, you know, per se as you know by itself, but I think it does take a very clever language designer to make it work well. You know, you talked about not knowing like what's mutable and what's not mutable what's safe concurrently and that kind of thing. That is a hard design choice that you know languages like Java took on by allowing you know mutable variables everywhere, and now it takes a book to learn how to do concurrency. Whereas a lot of languages on the functional side have taken the opposite approach, it's immutable by default if you want a mutable thing you have to jump through a couple hoops. And so you it's very clear that everything is safe except for those hoops the parts where you jump through the hoops that's the unsafe part. So, I think that that the mixing isn't the problem. It's the, you know, the other design choices that that caused the issue. And I actually think that object oriented programming has a lot of great stuff in it. And I would, you know, as a functional programmer, I would probably use a lot of object oriented design to like build nice interfaces around, say, a, what is it called an executor service. Right, so that I could not worry, you know, this code is worrying about the threads and the concurrency and my code doesn't have to do it because it's got this nice interface around it. If I had to, if I had to critique object oriented design for anything, it's thinking it's modeling too big. Right, it's modeling the high level concepts in your domain, like, let's say user, or, you know, document as a, using low level constructs. Right, so you have all these methods on user. And what are they doing in there? They're doing for loops. And they're doing, you know, banging on mutable variables and objects are in the design. It's really good for building small abstractions, small things that need to maintain a tiny bit of state and have a consistent API around them. And I don't see enough of that. I see a little bit, but of course it's in the functional parts, like in the Java, the new Java streams API, they are the Lambda stuff. It's not actually the streams. They have all these, what they call the functional interfaces. And those are really well designed. You notice how, how general they are. And I think that's where the object oriented stuff really shines is, is being able to define these general interfaces, like function from type A to type B. You can define these things and the type system can take care of it. And you can, you can rely on that interface throughout your code. There, it's not as good at like Java doesn't provide as much help with like modeling a person or the data that has to do with a person. Or at least you have, you have to create everything yourself. So I'm like proposing or like when I doing workshop, I always want people to model smaller things. So let's have a name class, let's have a birth date. Maybe the birth date contains a general time, which is again a wrap around existing type. So, but I agree, but usually it's not done. Usually it's just a big entity. And we could have it this small fine grained, but maybe it's too, like, maybe it's too much work compared to just having a union type. Maybe that's serious, right? Because I need to create classes and I need to compose classes, but when you do like a union type or some, some mixture of types, it's just one line. So it's, it's very easy to create. Yeah, that's true. That's the thing that string is the most used domain model in object-oriented programming language. String string, probably. And yet Java projects have so many classes. Like, what are, what are these all doing? Oh, that's, it's the services implementations. Yeah, you have the person and the person manager, like, what is the manager doing? What is, why did this person object need to be manual? Yeah, then you have to close and help, but the static, static class needs to actually start going to object anymore. No, let's stop bashing that. Thank you Peter. One in the book, Eric, you're not just only about the mindset on, on a low level. It's even done in the later chapters is also about the architecture. Here the, I, I saw a graphic and came upon it that, well, opened or made me realize what I thought was wrong with the code basis I was working so far. So to give more context for about a year now, I'm working in the, I would say, typically industry. Previously I was in specialized cases where all those fancy regular architectures that you now see and then setups don't happen so often. So I'm pretty much new and I'm finally doing all the stuff that we're discussing on this podcast. And then again, and coming back to this on an architecture where you have this comparison between, okay, you have somewhere this controller terminating HTTP request and have some service layer and then it's downward to the repository database layer. And the idea now with this functional mindset is to draw the line with the main abstraction and the actual side effects a little bit different. It's a little slanted. So, which would then allow the controller to have the access to the persistence layer and only call the services to modify the data that is being requested and then the control again stores it or at least access is the repository again. And for me, this was sort of eye-opening because the code basis, not a closely circular I came across, I was always wondering, okay, why does the controller first ask the service, please give me that entity by that ID and then takes this entity and then gives it back to the service and says, okay, do something with that entity, which was confusing for me and why, what's the, why did I take it and give it right back. Right, so this is, but Christian, I think that's a very interesting point you're touching here and for me, I always say this to links on discussing about this for me, this is the first decision which was ever made in the field of software engineering to move all these patterns and paradigms and mindset, which was actually initially made for Fed client applications like we did in small talk, right, and move it to the web, which is a fully request response model, which doesn't have to do anything with stateful applications usually, right, and I think there's this great book from Scott Walshing, right, who does a lot in F# if I remember correctly, who often says, and it makes full sense if you read it, he says, actually, a request response web server is the best use case for functional program or language because all it does is gets a request and a response that's functional by nature and what we're doing is we're having a stateful job enterprise means and stuff like this because we took it from building Fed clients before the web was there and just took the same paradigms and shifted it into a total different application model, right, and I think this is why we have so many problems as a object to write the programings or programs these days and why they are modeled so kind of strange because they don't fit in many situations, at least from my perspective, and their actual style, which is given by the application platform Yeah, totally agree there on everything, it's a great book, I think it's called Domain Modeling Made Functional, something like that and it's a really good book, it's actually teaching domain-driven design and it's the clearest book on domain-driven design I've read, but also with the mistake The typical web stack, the layered architecture is you have a web server and then you have some business logic underneath that and then underneath that you have the database and the web server kind of goes through your business logic and then that modifies the database and the problem with it from a functional programming perspective is that your whole business logic is now it's not pure because it has to access this impure database, it's a changing thing and what the diagram that Christian was talking about is where I put the database on the side and say the web server can access the database and the domain model and it has to coordinate the two domain model can be pure, no side effects, no mutation or anything and then the database is on the outside and you would query the database like say get the user that's relevant to that request, pass it to the domain model and make some kind of decision like cancel this user's account or something and it would return that and then the service would take some action, maybe setting a field in a database or something and that separation lets you draw a line, it's diagonal in the diagram that shows that under this line it's all pure, it's all functional and above this line that's where all your services and your mutation happen and that's like the sandwiches, right Eric, so you're doing a sandwich so you have something impured and you have to compute and the nice, the cheese or whatever and then you have something like this Right, some people say it's what is it, immutable core and an object or an inch shell something like that The funniest thing is that you arrive at the same architecture if you do test driven development without using test numbers because if I can't double the database, I can't call it, so I'm calling it later and this gives me a similar, I can only call the database in the integration test then but then it's on the highest level So it's what you say, you know, it's like imperative core, imperative shell and functional core, something like that I think that's also like the dominant thing in Haskell, right? Because in order to do any I/O you need to pass it back to the system or kind of like that's right, yeah so in just to expand on that a little Haskell, a Haskell program on its own does not have any side effects it won't even send an email or launch a missile or put anything on the screen by itself What it has is a data representation of that action that you are calculating with your code Now it looks to, you know, as a programmer it looks like imperative code because of the syntax of the language but it's all in this type called I/O and you're building up this big action complex thing that's going to get executed by the run time So the Haskell language has pushed all the burden of the side effects to the run time to execute So that's how the entire Haskell program that you write, even if you want to send an email or put something on the screen or write to a file It has no side effects by itself and in fact if you, I mean if you could figure out how to do it, you can actually test your program Like I want to test that this program will write to the file correctly even without writing to the file You could test that it has to be... You're relying on the libraries And it's only the run time that will do that for you So maybe to conclude to the book, I understand you correctly, you're building the concepts in order to teach them or like to explain them Kind of using JavaScript, you're building the infrastructure you need to do function programming That's right, and it's... Are you building IO also, as the cherry on top or at least the file reader or something? No, that is one branch of functional programming It is this branch of totally pure functional programming So that's just the Haskell branch Even ML has side effects in the code So it's this one branch of approach to functional programming And I don't think that that one branch should dominate how people view functional programming So there's the whole this side of the tree, there's ML which has side effects, and ML includes F#, what else? Reason is a new one And so, yeah, I'm trying to look for the stuff that's kind of common, you know, across all of this So what we start, though, with something that is very common Which is that functional programmers distinguish actions, calculations, and data You know, I say it's like the defining distinction of functional programming But I think a lot of people would disagree with that But if you ask, is it important, every functional programmer would say it's important To be able to distinguish pure code from the impure code Essentially, you start also the book pretty much with it Apart from this story with the manager, it's right off the gate, the first thing that you bring to the reader Right, I think it's vitally important You know, I've read a lot of books on functional programming to prepare for this, for writing this book And I think that those books lose a lot of people Because they talk about pure functions in a sentence or two And then, you know, kind of jump straight to what they think is the more interesting stuff Which is, I just consider, like, lambda calculus gymnastics It's just like, oh, look at this, what I can do, I can curry, I can, you know, call this and do, like, mutual recursion And, you know, fun stuff, it's fun, not going to say it's not fun But I don't think that's the important practical stuff I think the important practical thing, like, if you couldn't tell me that this code has a side effect Like, you know, all the gymnastics in the world aren't going to help you if you can't do that So, I spend the first, what, nine chapters, maybe less, maybe seven chapters Talking about how to work with this code Once you make this realization that side effects are maybe bad, they're hard, they're hard to work with You need them, but they have all these problems And so, what do you do? Oh, well, you start extracting out calculations and you start building in layers of abstraction And you start using immutability and stuff And I think that that's really the approach I'm taking It's like, try to get the people who are interested in functional programming Who, like, don't want to get to the lambda calculus yet You just want to know, like, why is this even useful to me? And that distinction there is the useful thing And I would say you have collected it in quite a comprehensive book So, if we made you the listener now quite interested in this book, so it's published by Manning It's currently a time of recording in the Early Access Program And, well, it says it's publication, estimated April 2021 Eric, is this going to hold, or is it the way Oh, goodness, I am out of, I have no control over when it gets published It is done, everything's written, and it is in, like, revising and copy editing And, you know, layout and stuff like that So, it's already out of your hands, it's not all about the publishing I just get pinged every couple of weeks, like, oh, we need you to, you know, review this And, like, you know, I'm doing that, it's moving along It's still kind of waterfall-ish, right? I mean, I do wish that I could press a button and see the book But, it is very much, you know, this old style of You all remember, back in the day, like, when they had, like, workflows Like, human workflows, like, okay, you edit something in this software And then you import it into this next software, and you export it to this format And you import it, and so, you, like, you don't ever get to see the results Of what you made, because it's, you don't have that whole tool chain That's what I don't remember, maybe because I never did it, or never worked for such an environment Or maybe because I just was drinking so much to forget it, yeah? But I cannot remember it anymore, I was just peaking it That sounds terrible, yeah? Enough of books Thank you, Eric, for over your book As for the next segment For any local events, so, Eric, in your area, what would be interesting, I would say, meetups Or online meetups, either way, that you can recommend Goodness, so, before the lockdown, we had a really nice event That was weekly, it was called Hack Night, and it was just social But it was a very nice, tight-knit group of programmers and designers And other technical, you know, software people And it was great, like, we would go for hours, just sitting in a hotel lobby And then, some of the weeks, there would be a talk So, like, for instance, I had a meetup that was functional programming talks So, the first Tuesday of the month would be functional programming And then, there was one that was more front-end And there was one that was more general Did you just skip it down to Covid, or did you try to move it to the cloud or online? No, we just cancelled Hack Night And sometimes I hear about one of the other groups still doing their presentations But I find that really boring, I want people I don't want to watch a screen for more hours of the day So, if you like it, yeah, you can find it One of them is called front-end party The functional programming one, which isn't going on, it's called No Fun No fun is great, I love it So, pretty much, shut down in your area, from community sign Yeah, but I think it's everywhere the same, right? In the beginning, you had a kind of a peek that people said, "Yeah, cool, let's move everything" So, we went, everybody can join everywhere Maybe it's for the talking things Because for the coding events, like the coding dojo is still around I don't know of the date for the April one, but surely there will be one And we'll have a coded treat on 15th of April That's already like 6th, that's during the week So, maybe it's easier if you do peer programming remotely than it's still some kind of meeting someone doing something together It's not the same as in person, I would say the coded treat is losing big on not being social But it still has a... still works out, right? Do you see any crease of people, even? Is it just stable and common enough? For the small ones that we run like every two or three months, I would say we are growing So, we used to be on site, sometimes we were only 4 or 6 people, it's really a small group Now, I think last time there was like 12 of a person, do you remember? It was definitely much, 10, right? Yeah, we were 12 people, so quite a bump and I said, "Peter, you have to hire charisma to motivate people to come to your institute start." So, it's... but you never know, right? Maybe next time, it's only two people showing up, that's with the smaller community events So, 15th of April coded treat for free during the week I will put the link then in the notes, of course But then, like of what's going on in JavaScript in Vienna, React community to have it Not too much in general, well, in none of the communities, I mean, I don't know all of them, but I at least know that there's none of those meetups Which we had back then, React, I don't know if you just... which is taking place on a regular basis anymore Sometimes we have kind of a special meetup, where I don't know, few people find together and say, "Hey, let's do something again" But yeah, I mean, if you ever joined this meetup and I was at a conference today at an online conference I was great organized, French conference, basically now they moved it online to do COVID And everybody is giving its best, but still here, you miss the social index, you miss especially I mean, if you are more and more, or if you have already been at a couple of conferences in the beginning, you're very eager You're taking as much topics and as much talks and you try to sit everywhere in the first row But if you're getting a little bit older, what you really enjoy is having lunch and discussing stuff with people And just getting a little bit into an area where you can get creative about new ideas And that's totally missing, and I didn't see any format which kind of came to this kind of same drive In a real world kind of event, but maybe I just didn't see it, or maybe it's just not missing Because honestly speaking, if I talk to this, if I listen to talks, I always think to myself Because I'm a very impatient person, you know, right? And I always think, "Okay, I could watch this now, I'll watch it on YouTube then with, I don't know, more than 0.5 speed", right? And I say it a lot of times, I'm doing something, and that's totally unfair to speak it But honestly, it's how I kind of start It's not about who watched the most talks when he dies What about that? I know, I know, I don't know It's about the most notes when he dies, like it's not about seeing, it's about like taking it in, right? Yeah, yeah, yeah, you're right, but you know, if you've already seen so many talks, I've seen them Of course, you know, it's kind of hard to really spot that gold market, so to say, which we... Yeah, that's true In general, I think that the motivation goes as a bit down, it's at least my feeling in the COVID period Now, where the beginning people are very motivated to try out those new formats We had to come to get us on the real boards, and everything was great, and cool, and now we are SSA, come on Let's close these pandemic stuff, and let's meet for as soon as possible I was going to say, I think there's another aspect to traveling to a conference, it's the focus You know, I'm here for this conference, whereas if it's at your house, and your kids are running around And, you know, like, I'm not going to stand here and watch four talks today I might sit through them at the conference, but, you know, someone is maybe catering and making coffee And, you know, it's a totally different thing That's true So, well, finally, Eric, do you have anything that you would like to advertise, apart from your book? So, it's pretty much the one minute of free advertisement space that we can give you Wow, thank you So, if you want to learn closure, I'll advertise, you know, I teach closure online I record videos and show people how to make stuff with closure And you can go to purelyfunctional.tv to find the courses that I've got Cool, we'll put it to a show now, so And the list costs are more like community-based, or what are you doing there? So, that is like a branding mess up between purelyfunctional.tv and listcast So, I am in the process of consolidating all of this, so it's kind of moot But, listcast was supposed to be me, my brand, and purelyfunctional.tv My idea was to have multiple people teaching stuff on there But, I couldn't find anybody I guess no one wants to teach in video form Or at least on my platform And so, this division of like, I'm listcast, and I'm on purelyfunctional.tv It's just confusing to people So, I'm consolidating it all down to one But that hasn't happened yet It's a slow process Alright So, in summary If you, the listener, want to get Eric's book So, first of all, it's published by Manning It's called "Grocking Simplicity" It will be released quite soon, though you can get it in early access program already And if you also use our special promo code, that you can read on our Twitter messages For Manning, you can get some discount on your first order And with that then, I say thank you to everyone, thank you Eric for being with us Thank you, this is great fun And see you here next time for a delicious cup of developer Minaj See you guys