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


GOTO Conferences

함수형 프로그래밍은 '더 나은 방법'이라는 논리적 주장에도 불구하고, 용어에 얽매이거나 추상적인 개념으로 설명되면 실용적인 적용이 어렵고 이해를 방해할 수 있습니다.

함수형 프로그래밍의 핵심은 부작용을 없애는 것이 아니라, 프로그램의 핵심 로직을 부작용 없이 구축하고 부작용(데이터베이스 업데이트, UI 등)은 외부에서 관리하여 안정적이고 테스트하기 쉬운 시스템을 만드는 것입니다.

새로운 프로그래밍 방식을 가르치거나 이해시킬 때는 점진적인 개선을 강조하고, 학습자가 이미 알고 있는 구체적이고 실용적인 예시(예: '아침 식사 만들기')에서 시작하는 것이 효과적입니다.

함수형 프로그래밍을 처음 접하는 사람들이 겪는 어려움은 무엇이며, Russ Olsen은 이러한 어려움을 어떻게 극복했다고 설명하나요?

함수형 프로그래밍에 대한 흔한 오해 중 하나는 무엇이며, Russ Olsen은 이를 어떻게 설명하며 실제 프로덕션 환경에서의 적용 가능성을 이야기하나요?

Russ Olsen이 현재 집필 중인 'Lisp Adventures' 책의 목표는 무엇이며, 그가 생각하는 기술 학습 및 교육 방식에 대한 철학은 무엇인가요?

강연 'To The Moon'에서 Russ Olsen이 말하는 '달 착륙 경험'이란 무엇이며, 이것이 사람들에게 영감을 주는 순간들에 대해 어떤 시사점을 제공하나요?

아폴로 달 착륙 프로젝트와 같은 거대한 문제 해결 방식에서 발견할 수 있는 흥미로운 엔지니어링 전략은 무엇이며, 현재 소프트웨어 개발에 어떤 교훈을 줄 수 있을까요?

GOTO 팟캐스트에 오신 것을 환영합니다. 각 에피소드에서는 소프트웨어 개발 분야의 세계적인 전문가들의 가장 밝고 대담한 아이디어를 다룹니다.

실용적인 교훈, 설득력 있는 이론, 그리고 풍부한 영감을 얻으십시오.

GOTO는 소프트웨어 커뮤니티의 가장 뛰어난 인재들을 모아 개발자들이 오늘날의 프로젝트를 해결하고, 내일을 계획하며, 더 나은 미래를 만들 수 있도록 돕습니다.

암스테르담, 런던, 코펜하겐, 시카고와 같은 도시에서 온라인과 오프라인으로 개최되는 GOTO의 최고 평점 행사와 수천 개의 고품질 개발 강연을 찾을 수 있는 GOTO Conferences YouTube 채널을 구독하여 최신 기술 정보를 받아보세요.

자세한 내용은 gotopia.tech에서 확인하세요.

안녕하세요, Russ. 안녕하세요, James. 네, 잘 지내시죠? 잘 지냅니다. 어젯밤 작은 연사 행사에서 COVID 이전 이후로 실제로 서로를 본 적이 없었던 것 같다고 이야기했었습니다.

네, 아마 2018년쯤에요. 네, 맞아요.

네, 우리는 컨퍼런스 친구 같아요. QCon 이후 늦은 밤에 제가 런던을 안내했던 기억이 있다고 하시던데, 아마도... 사실 잘 기억은 안 나지만 그 후의 술은 어느 정도 기억합니다.

그건 당연히 추천하지 않습니다.

그럼 괜찮으시다면 먼저 함수형 프로그래밍과 함수형 프로그래밍에 대한 당신의 애정에 대해 이야기해 볼까 합니다.

함수형 프로그래밍을 어떻게 시작하게 되셨는지 이야기해 주실 수 있을까요?

네, 좋습니다. 그럼 거기서부터 시작하죠.

좋아요. 함수형 프로그래밍에 대한 제 경험은 많은 사람들의 경험과 비슷하다고 생각합니다. 매우 똑똑한 사람들이 이것이 더 나은 방법이라고 이야기하는 것을 읽거나 보게 되고, 코드를 더 잘 이해할 수 있고, 테스트하기 쉽고, 등등 왜 더 나은 방법인지에 대한 논리적인 주장을 많이 듣게 되죠.

그리고 제 경험은 함수형 프로그래밍으로 실용적인 프로그램을 어떻게 작성할 수 있을지 알아내려고 하다가 완전히 벽에 부딪히는 것이었습니다. 함수형 프로그래밍은 프로그램을 작성하는 방법에 대한 다소 임의적인 규칙 집합과 같습니다.

오늘 컨퍼런스에 오면서 바로 그 생각을 하고 있었습니다.

마치 6, 70년대에 누군가가 더 이상 프로그램에서 고투를 사용하지 말라고 말하는 것과 같습니다.

그리고 그에 대한 반응은 '고투 없이 어떻게 프로그램을 작성해야 하지?'였죠.

그리고 천천히 기능적 프로그래밍의 비밀을 풀고 기능적 프로그래밍에 대해 사람들이 쓰고 말하는 많은 것들이 좋은 의도이고 옳지만 전혀 도움이 되지 않는다는 것을 발견하게 됩니다.

도움이 안 되는 이유는 용어에 얽매여 있기 때문입니다. 긴 사고 과정의 최종 결과를 설명하는 것 같기 때문에 도움이 안 됩니다.

더 도움이 되는 것은, 제가 돌파구를 찾도록 도와준 것은 처음부터 시작해서 기능적 프로그래밍으로 이어지는 사고 과정을 거치는 것입니다.

이러한 것들은 우리가 코드를 더 이해하기 쉽고 추론하기 쉽게 만들 것이라고 생각하기 때문에 프로그램에 부과하는 임의적인 규칙 집합입니다.

좋아요, 그것이 출발점이라면 기능적 프로그래밍을 이해할 수 있는 지점까지 따라갈게요.

아마 아닐 수도 있지만, 그럴 수도 있죠. 그리고 그것은 '모나드라는 것이 있어요'라고 말하는 것보다 훨씬 더 도움이 됩니다.

아니면 '카테고리 이론을 이해하지 못한다니?'와 같은 거죠.

어서요. 맞아요. 네. 그리고 기능적 프로그래밍의 문제점 중 하나는 아이디어의 많은 부분이 수학 세계에서 나온다는 것입니다.

학교에서 배운 수학에서의 함수처럼 사람들이 제시하는 예시와 제시하기 쉬운 예시의 대부분이 숫자에 관한 것입니다.

실용적인 프로그램은 숫자를 다루지만 텍스트, 구조, 큰 복합체를 다룰 가능성이 훨씬 더 높습니다.

모두 똑같이 사실입니다. 하지만 숫자에 대해서만 이야기한다면 매핑하기가 어렵습니다.

충분히 복잡한 엔터프라이즈 소프트웨어는 모두 피보나치 수열을 수행하는 것으로 시작합니다.

물리학에서 진공 상태의 구형 자원, 진공 상태의 구형 닭과 같습니다.

하지만 그게 제가 엔지니어였다가 엔지니어 매니저였다가 다시 엔지니어가 되는 과정을 반복한 배경 중 하나입니다.

그래서 저는 제 경력의 많은 부분을 사람들에게 새로운 것, 새로운 프로그래밍 방식 등을 가르치는 데 썼습니다. 그리고 누군가에게 다른 방식으로 프로그래밍하는 방법을 가르치려고 할 때 예제를 선택하는 것이 큰 차이를 만듭니다.

제가 그걸 뼛속 깊이 알고 있는 이유는, 프로그래머로 가득 찬 이 방에서 충격적으로 들릴 수도 있겠지만요.

저는 대부분의 형태로 대부분의 경우 게임을 싫어합니다. 그런데 프로그래밍 예제는 왜 그렇게 많은 게, "이 게임을 해 봅시다.

하노이 탑 해 본 사람 있어요? 실제로 해 본 사람 있어요?" 그렇죠. 아시다시피, 저는 누군가에게 무언가를 가르치려고 할 때는 그 사람이 이미 알고 있는 것에서 시작해야 한다고 생각합니다.

예를 들어 제가 매일 아침 일어나서 아침을 만든다면 아침 식사 만드는 방법 예제부터 시작해야죠.

우리 대부분이 할 줄 모르는 고급 레스토랑 운영 방법부터 시작하면 안 됩니다.

당신이 새 책을 냈다고 해서 읽고 있었어요. 막 나왔나요? 아니면 아직 작업 중인가요?

>> 아직 작업 중입니다. 얼리 액세스 정도 될까요?

그런가요? >> 아니요, 아직 작업 중입니다. 네. 그래서 이번 컨퍼런스에 맞춰서 얼리 액세스를 하려고 했는데, 작가들이 다 그렇죠?

>> 더글러스 애덤스 명언이 뭐였죠?

>> 마감일에 대해 그런 말을 했었죠? 저는 마감일을 정말 좋아합니다. 마감일이 휙 지나가는 소리를 좋아하죠. 정말 멋진 대사입니다.

>> 음, 출판계에는 1년 늦거나 6개월 빠르거나 하는 그런 게 있죠.

>> 자, 다시 책 얘기로 돌아가서, 책에 대해 꼭 얘기하고 싶었던 이유는 그 책이 정말 흥미롭고 특히 당신이 설명했던 내용과 관련이 있다고 생각하기 때문입니다.

음, 제목이 Getting Closure죠? 맞죠? >> 그게 제 책입니다.

>> 그건 그렇고, 여러분 모두 여러 권 사셔야 합니다. 그러니까, Getting Closure는 책인데, 클로저 프로그래밍 언어에 관한 책이지만, 사실은 제가 클로저를 배우면서 함수형 프로그래밍을 어떻게 이해해야 할지에 대한 책입니다. 왜냐하면 클로저는 매우 함수적인 언어라서 클로저로 프로그래밍할 수 있다면 함수형 프로그래머이고 이해한 것입니다.

스칼라나 그런 것과는 다르죠. 스칼라에 문제가 있는 건 아니지만, 스칼라 프로그래머가 되어서 클로저나 스칼라의 함수적인 면을 무시할 수도 있습니다.

클로저 프로그래머가 클로저의 함수적인 면을 무시한다면, 'Hello World'를 출력하고 끝낼 수 있을 겁니다.

네, Getting Closure는 나온 지 꽤 되었고 책입니다.

클로저는 리스프 프로그래밍 언어이고, 이 책은 리스프 프로그래밍 언어를 설명하려고 합니다. 몇 년 전에 썼는데, 제가 실제로 어떻게 했는지 생각하기 시작했습니다. 리스프는 함수형 프로그래밍처럼 사람들이 어려워하는 것 중 하나입니다.

저는 정말 이해하기 어렵다는 것을 알았습니다.

다시 말하지만, 제가 존경하는 똑똑한 사람들이 그렇게 말했습니다. 제 초기 멘토 중 한 분이 리스프에는 다른 어떤 소프트웨어보다 바이트당 아이디어가 더 많다고 말했던 것이 기억납니다.

그렇죠? 그래서 어떻게 거절할 수 있겠어요? 그리고 다시 말하지만, 완전히 이해할 수 없었습니다.

제가 결국 리스프를 이해하게 된 방법은 제가 직접 작성한 것이었습니다. 그다지 어렵지는 않습니다.

포트란으로 했기 때문에 훨씬 더 어려웠습니다. 음, 그게 저희가 가진 언어였지만, 일단 직접 만들고 나니 모든 것을 이해했습니다.

그것이 리스프로 가는 가장 쉬운 길이었습니다.

그래서 제가 지금 쓰고 있는 책은 '리스프 어드벤처'라고 합니다.

그것은 리스프를 구현하는 책입니다. 리스프를 배우고 싶다면 함께 만들어 봅시다. 파이썬으로 만들 거예요. 왜냐하면 지금은 누구나 파이썬을 반쯤은 알고 있으니까요.

파이썬으로 리스프를 만드세요.

이 연습을 마치면 결국 리스프를 이해하게 될 거라고 장담합니다. 이 모든 것은 제가 정말 강하게 느끼는 것을 반영합니다. 즉, 사물을 가르치는 방법은 하나가 아니라는 것입니다.

사물을 이해하는 방법은 한 가지가 아닙니다. 하지만 우리에겐 늘 하던 방식이 있죠. 제가 여러분에게 무언가를 설명하고, 여러분이 무언가를 이해하길 바란다면요.

저는 이런 식으로 하향식 설명을 합니다.

여기 큰 아이디어가 있고, 더 세련된 아이디어가 있고, 실제로 어떻게 결합하는지 보여주는 거죠.

그 방법이 통할 때도 있지만, 그게 전부는 아닙니다.

만약 여러분이 어떤 소프트웨어를 이해하거나 가르치려고 한다면, 장난감 버전을 구현하게 하거나 다른 방법을 쓰는 게 좋을 수도 있습니다.

기술적인 개념을 설명할 때 엔지니어들은 어떤 것을 시도해서 실패하면 똑같은 방식으로 두 번째 시도하고, 또 실패하고, 방에 아무도 남지 않을 때까지 반복하는 경향이 있는 것 같아요.

글쎄요. >> 반대도 있는 것 같아요. 한 번 성공하면 어디든 그렇게 하고, 배우는 게 없죠.

두 번째 시스템 증후군 같은 것도 있죠. 실패, 실패 시스템 증후군과는 반대되는 개념이죠.

네, 맞아요. 두 번째 시스템 증후군도 좋은 예시인 것 같아요. 왜냐하면 제가 사람들에게 기본적인 것을 설명했을 때 잘 됐거든요.

그래서 다음에 오는 사람에게는 엄청나게 자세하게 설명할 거예요. 그러면 그 사람은 세부 사항에 파묻혀서 큰 그림을 놓치게 되겠죠.

그건 설명에서 정말 흔한 실패 패턴이에요.

클로저로 돌아가서, 먼저 밝혀둘 게 있어요. 저는 클로저 코드를 실제 제품에 적용해 본 적이 없어요.

죄송합니다. 모두 죄송해요. 하지만 스튜 할로웨이와 함께 강좌에 참여한 적은 있어요. 몇 년 전 런던에서 스튜를 초청해서 강좌를 열었죠.

그중 하나는 제가 그때 담배를 피웠다는 거예요. 담배를 피우러 가면 스튜는 팔굽혀펴기를 20개, 30개, 40개, 50개씩 했어요. 미국과 영국 사람의 차이점을 보여주는 것 같았죠.

하지만 그건 제게 정말 큰 충격이었고, 그 개념에 대해 더 깊이 파고들어 함수형 프로그래밍을 공부하게 되었어요.

저는 '컴퓨터 프로그램의 구조와 해석'을 읽었고, 그 길을 따라갔습니다. 그리고 Thorwex에서 여러 해 동안 즐거운 프로젝트들을 많이 진행했죠.

계속해서 떠오르는 것 중 하나는, 클로저로 장난감 문제를 풀면서 알게 된 건데, 코드를 작성할 때 간결함과 우아함이 정말 놀라웠다는 거예요. 코드를 작성하기 전에 많은 생각을 해야 했죠.

하지만 나중에 다시 코드를 보았을 때, 다른 언어로 작성한 소프트웨어보다 이해하기 더 어렵다는 것을 알게 되었어요.

>> 저도 그렇게 생각해요. 클로저를 생각할 때, 어젯밤에 양조장 투어를 갔었는데, 클로저가 마치 그런 것 같아요.

클로저는 마치 도수가 80도인 술과 같은 프로그래밍 언어 같아요. 제 생각에 목요일 강연에서 클로저 라이브러리인 Pedestal에 대해 조금 이야기할 것 같아요.

Pedestal에 대해 이야기하기가 어려운데, 제 슬라이드 중 하나에 'Pedestal은 10,000줄의 클로저 코드다'라고 적혀 있어요.

많은 프로그래밍 언어에서는 '아, 10,000줄이나 되네'라고 생각할 거예요.

하지만 저는 무대에서 뛰면서 '아니에요, 이건 10,000줄의 클로저 코드예요!'라고 외치고 싶어요.

이것은 클로저로 작성된 코드의 정수와 같아요. 확실히 간결한 언어라는 점이 있습니다.

제가 프로그래밍과 소프트웨어 엔지니어링에 대해 훌륭하다고 생각하는 것 중 하나는 기술적인 측면만큼 문화적인 측면도 중요하다는 것입니다.

아시다시피, Clojure 프로그래머들이 코드를 쓰기만 하고 다시 읽을 수 없는 문제에 대처하기 위해 사용하는 방법 중 하나는 특정 패턴을 채택하는 것입니다. 코드를 보고 "아, 이건 함수 체인이구나. 항상 똑같은 방식으로 작성하니까 이해할 수 있겠어."라고 말할 수 있도록요. 하지만 아시다시피, 문화적으로는 좀 그렇습니다. 내일 당장 횃불과 쇠스랑을 든 사람들이 제 문 앞에 몰려올지도 모르겠지만, Clojure 커뮤니티에서는 "패턴"이라는 단어를 입에 담을 수 없습니다.

사람들이 디자인 패턴을 남용하던 시절의 잔재 같은 것이기 때문이죠.

그래서 Clojure 세계에서는 패턴에 반대합니다.

Clojure에서는 이렇게 한다고 말하겠지만, 그건 패턴이 아닙니다. 그냥 문화적인 기벽 같은 거죠. 다른 단어를 사용하면 괜찮습니다.

음, 그럼 이 시점에서 질문 있으신 분 계신가요?

계속 시청해 주세요. 곧 다시 돌아오겠습니다. 현재 시즌 5를 맞이한 Inspiring Tech Leaders는 오늘날의 디지털 세계를 만들어가는 기술 전략, 과제, 혁신에 대해 이야기하는 팟캐스트입니다.

매주 Inspiring Tech Leaders는 선구적인 CIO, CTO, 업계 개척자들과의 기술 리뷰 및 인터뷰를 제공합니다.

기술 팀을 이끌고 있든 혁신을 좋아하든, Inspiring Tech Leaders는 영감과 실제 조언을 얻을 수 있는 최고의 소스입니다.

지금 바로 즐겨찾는 팟캐스트 플랫폼에서 구독하세요.

안녕하세요. 저도 함수형 프로그래밍의 열렬한 팬입니다.

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

스크립트