Welcome to the GOTO podcast. Each episode covers the brightest and boldest ideas from the world's leading experts in software development.

Tune in for practical lessons, compelling theories, and plenty of inspiration.

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow, and create a better future.

Stay up to date with the latest in tech through GOTO's top-rated events held online and in person in cities like Amsterdam, London, Copenhagen, and Chicago and by subscribing to the GOTO Conferences YouTube channel where you can find thousands more high-quality dev talks.

Hello Russ. Hello James. Yeah, how are you doing? I'm doing well. We were talking last night in the little speakers event that we hadn't actually seen each other since before COVID, I guess.

Yeah. And we seem to be sort of conference buddies. I think you had a memory of me leading you around London late at night after QCon or something like that, which is probably So I I don't really remember but I do remember the the alcohol that followed to a certain degree.

So that's that's not something that I would recommend obviously.

So I think the first thing we're going to talk about if that's all right with you is functional programming and your, well, love of functional programming, really.

So I wonder, like, maybe you could talk about how you sort of started with functional programming.

>> Sure. >> And yeah, we'll go from there.

>> Okay. Well, I think, I think my experience with functional programming is similar to a lot of people's experience where you start reading or seeing very smart people talking about this is a better way of doing it, and you know, lots of reasoned arguments about why it is a better way that you can reason about the code a little bit better, it's easier to test and all that kind of stuff.

And then my experience was running into an absolute brick wall of trying to figure out how could I possibly write practical programs with you know, functional programming is essentially a set of more or less arbitrary rules for how to how to write programs.

And it's exactly, I was thinking about this coming into the conference today.

It's exactly like back in the 60s or 70s or whatever, somebody saying, no, no, don't use gotos in your program anymore.

And the reaction to that which was, how the heck do I write programs without gotos?

And of course, >> And slowly kind of unraveling the, the secret of how you do functional programming and discovering that much of what people write and say about functional programming is well-meaning and correct and not helpful at all.

Uh, so it's not helpful because it gets tangled up in terminology. It's not helpful because it's kind of describing the end result of a long thought process.

And what's more helpful, what what managed to help me sort of break through is to start at the beginning and go through the the thought process that leads to functional programming.

Things like these are an arbitrary set of rules that we're imposing on our program because we think it will make the code easier to understand, easier to reason about.

Okay, if that's the starting point, then okay, I will follow you along to the point where maybe I will understand functional programming.

You know, maybe not, but maybe. And that's certainly more helpful than saying, oh, we have these things called monads, right?

You know, and that kind of thing. What do you mean you don't understand category theory?

Come on. Right. Exactly. Yeah. And I also think one of the problems, just kind of a silly thing with functional programming is since it comes out that many of the ideas come out of like the world of math, right?

It's functions as in the functions you learned in school about about mathematics is so many of the examples that people give and the easy examples to give are all about numbers.

And while, you know, practical programs, yes, deal in numbers, we're much more likely to deal in text and structures and big conglomerates.

It's all equally true. But it's just, you know, if all you're talking about numbers, it's sort of hard to hard to map that.

Every sufficiently complicated enterprise piece of enterprise software starts with doing the Fibonacci sequence.

It's a bit like it's a bit like spherical spherical resource in a vacuum from physics, you know, spherical chicken in a vacuum.

But that's one of the so my background is that I've been an engineer and then a manager of engineers and then I'm engineer again and back and forth.

And so I spent a lot of my career teaching people, you know, new things, new ways to program and that sort of thing. And just the choice of examples in when you're trying to teach somebody like how to how to program in a different way makes a huge difference.

And the reason I know that sort of in my core is that and this is going to sound shocking to a room full of programmers.

I hate games in most forms most of the time. And so many programming examples are, "Oh, let's do this game.

Let's do who plays the Tower of Hanoi? Has anybody ever actually done that?" Right. And you know, and I think examples should be like when you're trying to teach somebody something, an example should start with something that the person knows already, you know?

So, like if I get up every morning and make breakfast, then start with the how to make breakfast example.

Don't start me with how to run a five-star restaurant 'cause not a lot of us know how to do that.

I was reading them 'cause you you have a new book. Is it just out or is it It's I'm still working on it.

>> Still working on it. It's early access maybe.

Is it? >> No, I'm still, yeah. Yeah. So, it was going to be I was going to have early access for this conference, but you know how authors are, right?

>> Did you know that about deadlines? I love, I love deadlines. Love the sound they make as they swoosh by which is a wonderful line.

>> Well, there's a, there's a publishing thing which is like a year late to 6 months early or something.

>> So, back to the book because I did want to talk about it because it sounds absolutely fascinating and I think it talks specifically to what you're you've been explaining there.

Um which is it's called Getting Closure, right? And it's >> So that's my, that's the book that's out.

>> That's out. >> Yeah. So, and you should all buy many copies. So, so Getting Closure is a book about, well, it's about the Clojure programming language, but it's really about how do I figure out functional programming given given that I'm learning Clojure because you can't really, Clojure is such a functional language that if you're Clojure, if you really can program in Clojure, you are a functional programmer, you get it.

It's not like, you know, Scala or something, nothing wrong with Scala, but you could be a Scala programmer and ignore the functional aspects of closure or of Scala.

If you're a Closure programmer and you ignore the functional aspects of Closure, I think you could print hello world and you'd be done.

So, so yeah, so getting Closure has been out for a while and it's a book.

So, Closure is a Lisp programming language and it's a book that's trying to explain a Lisp programming language and I wrote it a few years ago and I started thinking about how I actually, so Lisp is another one of those things like functional programming which people find hard.

I found difficult to really get my arms around.

Again, it was something that smart people that I respected. I remember one of my early mentors said that there were more ideas per byte in Lisp than any other piece of software ever.

Right? And so, you know, how can you turn that down? And again, it was like completely impenetrable.

How I eventually figured out Lisp was I wrote my own, right? And which is not terribly difficult.

It was a lot more difficult because I did it in Fortran. Um I mean it was the language we had, but once I had built one built it myself, I understood everything about it.

It was like that was the easiest path to to Lisp.

And so the book I'm writing on right now is or working on right now is called The Lisp Adventure.

And that is a book about implementing Lisp. Like you want to learn Lisp, let's build one together, and we'll build it in Python because everybody sort of half knows Python now.

I guarantee you if you go through this exercise, in the end, you will understand Lisp. This all sort of reflects what I feel really strongly, which is there is not one way to teach things.

There is not one way to understand things. But we have this go-to thing, which is if I want to explain something to you, I want you to understand something.

Here are the big ideas, and here are the more refined ideas, and here's how we practically put them together.

That works some of the time. That's fine. But it's not the only tool you have.

You know, if you're trying to understand, if you're trying to teach some software, maybe a good way to do that is to have the person implement a toy version of it or something else.

You know, it's like I think explaining technical concepts is one of the few places where engineers tend to do a thing, see it fail, do it exactly the same way a second time, see it fail, and just repeat until, you know, there's no one left in the room.

I don't know. >> I think there's the opposite of that as well because if you do something once and it works, then you do that everywhere there is that, and you don't learn stuff.

as well. There's the kind of second second system syndrome thing as well, like as opposed to the fail fail system syndrome, I think.

Yeah. Yeah. Yeah. Yeah. Well, I think I think second system syndrome is also a good one because I've seen people, another common explanation failure mode is I explained the basics to you and it worked.

So the next person who comes along, I'm going to explain it in excruciating detail and they're going to lose the big picture for all the details.

That is a really common failure mode in explanations.

So going back to Clojure. So I I want to caveat this with I've never written production Clojure code.

Sorry. Sorry, everyone. However, I did have a go on a course with Stu Halloway. Oh, sure. Some years ago in London, we we we brought Stu over to do a course for us.

It was it was remarkable for a number of reasons.

One of which I was smoking at the time. I'd go and have a cigarette and Stu would do 20, 30, 40, 50 press-ups. I thought that was like this there's a difference between someone in the US and the UK.

But it was, I mean, it blew blew my mind and I ended up getting a lot more into the concept in functional programming.

I read Structure and Interpretation of Computer Programs. I did went down that sort of route and we've had lots of pleasure projects in in in in in Thorwex over the years.

One of the things that keeps coming back and I noticed it when I was writing, solving toy problems in Clojure, was that I found like the terseness, the elegance of it was amazing when I was writing it, and I had to think about it a lot before writing.

But I found it often when I went back to it, harder for me to understand than some other languages I've written software.

>> I I I I think there's some of that. I I I think of Clojure as, you know, we took a tour of a distillery last night and I I was thinking about that in terms of Clojure.

Somehow Clojure is like 80 proof programming language, you know, it's it's you can get a lot of So my talk on Thursday, I think I'm going to talk a little bit about Pedestal, which is this Clojure library.

And it's hard for me to talk about Pedestal, well, one of my slides says, Pedestal, it's 10,000 lines of Clojure.

And in many programming languages, you'd be thinking, ah, 10,000 lines.

But it's like I want to jump up and down on the stage and say, "No, no, this is 10,000 lines of Clojure, right?

This is like all the Clojure has ever been written." There there is certainly some of that, that it's a very terse language.

One one of the things I I think so one of the other things that I find wonderful about programming and software engineering is it's as much cultural as it is technical.

you know, and one of the things that Clojure programmers do to fight the write-only aspect of the code, where you can write it but you can't read it again, is they adopt certain patterns so that you can look at the code and you can say, "Ah yes, this is a chain of functions because I always write them the same way and therefore I can make sense." But that, you know, and so you can chunk up the code in your mind, except that culturally, and you know, I'm probably going to have people with torches and pitchforks at my doors tomorrow for saying this, the word "pattern" in the Clojure community, you cannot say that word, right?

Because it's, you know, the sort of holdover from people abusing design patterns and stuff like that.

So in the Clojure world, we're against patterns.

We will tell you this is how we do it in Clojure, but that is not a pattern, right? And it's just this wonderful sort of cultural quirk, you know, use a different word and you're fine.

So, um, so at this point, does anyone in the room have any questions?

Stay with us. We'll be right back. Now in its fifth season, Inspiring Tech Leaders is the podcast that talks about technology strategies, challenges, and breakthroughs shaping today's digital world.

Each week, Inspiring Tech Leaders brings you technology reviews and interviews with visionary CIOs, CTOs, and industry pioneers.

Whether you're leading a tech team or just love innovation, Inspiring Tech Leaders is your go-to source for inspiration and real-world advice.

Subscribe now on your favorite podcast platform.

Hi. So, I'm a, you know, a big fan of functional programming too.

How to Get People Excited about Functional Programming • Russ Olsen & James Lewis

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow and create a better future.

Learn from thought leaders and innovators with top-rated videos released daily, and at our year-round conferences, masterclasses and meetups.

Get started: https://gotopia.tech

GOTO is produced by Trifork, a leading full-service supplier of high-quality, custom-built applications and end-to-end solutions.

GOTO YouTube Channel Code of Conduct: https://blog.gotocon.com/yt-coc


How to Get People Excited about Functional Programming • Russ Olsen & James Lewis

Scripts