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 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.

Learn more at gotopia.tech. So, welcome to another GOTO book club.

I'm Andrew Harmel-Law, and this week we've got the three authors of Effect-Oriented Programming with us. So just a little bit about me, because it kind of maybe introduces how I know Bill, James, and Bruce.

So there is an open space conference up in Crested Butte in Colorado, where I think actually I think all three of you live, right?

I'm guessing you all live there now, 'cause some of you were all saying.

>> So it's this is how it's an open space conference, which so and everyone should definitely attend it, because it's the the best open space conference I've ever been to.

But I first met Bill and James and Bruce at this open space conference.

And one of the cool things is is that at that conference, I was introduced to effect-oriented programming.

And I'm kind of interested to find out—this might be one of my questions—how lots of those conversations and those sessions led to this thing.

But first, I should let you introduce yourselves. So, do you want to go, do you want to go first, Bill?

Just tell everybody who you are and, uh, how you ended up here.

I am Bill Frasure. I have known these guys for about 10 years now. Mainly just as friends, but eventually we found our way into finding a project we were all interested in.

I worked at Ziverge for a few years, which is the company behind ZIO, which is the effect system of choice for our book, which we'll get more into later.

I, yeah, I've just slowly become more and more interested in functional programming via Scala or whatever language might come in the future.

And yeah, I'm definitely the most junior of the authors here. I've got the most experience in ZIO, definitely the one small pond that maybe I have the deeper experience in.

Cool. Cool. Cheers, Bill. Uh, Bruce, do you want to go next?

Sure. Um, Bruce Eckel. I've mostly written books. Uh, sometimes I do consulting.

Yeah, there's some of the books back here. Been doing this for a long time. Have mostly focused on languages in the past.

Trying to broaden my perspective now. And also conference organization is something I've been involved with for a long time. The upcoming Winter Tech Forum is the first week of March here in Crested Butte, which is a ski town.

>> Yes. Which, hopefully, we've been wanting to get Andrew to come back here for every, every year. He's going, maybe I can come and then something happens and he can't.

Yeah, that's me. Nice. >> Yeah. Thanks, James. >> Sorry, Bill.

I should stop reading the names at the bottom. The names are in the wrong order on the screen. And James, sorry. Do you , want to introduce yourself quickly though?

>> We'll align the names on the screen. >> No, the names should be aligned with who like it's confusing.

>> Yes. Right. >> Yes. I'm James Ward. I work on agentic AI stuff at AWS. And Rich and I have a podcast together called Happy Path Programming.

So that's a fun little hobby. And >> we wrote a book together.

>> We wrote a book long ago together. >> Long ago that immediately >> It's up here on the shelf. We hid it behind this.

Yeah. >> Yeah. >> That was on dead technology. >> Yeah. Well, it was dead as soon as the book got published.

Yeah. >> Yeah. >> Yeah. So, yeah. So, I think one of the things Andrew, you'd said that you started exploring effects up here at uh, one of the conferences we did up here and that was my first experience with effects and and it's called ZIO.

Actually, that's where I first started getting into effects was was here at one of our conferences. And so, it was early days for ZIO.

I think it had just been announced as, you know, the first, you know, pre-release of it. And so we spent a couple days during the conference just diving in, trying to learn it, and it took us a little while to kind of wrap our heads around what in the world is this and why do we need it and why is it better?

And so, um, so yeah, I think our journey's >> taken me all of those years to try and figure out that we're still working on it.

>> So that, that actually, that's, that really that leads perfectly on into my first question.

So, 'cause the book is, and this is a thing I've noticed kind of like in more and more books recently, the, the book is not very thick, but it's obviously taken you like a number of years to figure out, right?

And having been someone who's written a book which is far too long and is could potentially be a lot thinner.

Do you maybe want to just quickly explain to us a little bit about that journey because it's, it's very, and I mean this in the best way, it's super terse.

It's very focused, right? >> Yeah. Well, I think there's a few motivating factors.

One of which is just how much knowledge and background seem to be required to get into functional programming and effects in particular.

And it was always these very intimidating texts with all sorts of assumed knowledge about, you know, you must be this smart to read this book.

And our goal was to really just lower that as much as we could and really aim for if you've written any amount of code in a language, hopefully this book is approachable.

You know, it's, it's not going to be perfectly understood by anyone who picks it up, but we just tried more and more.

What can we strip out of this? And I think at the high water mark, the book was about two and a half times as long as it ended up being in the final published version.

And once we realized like, oh, we can remove this.

Oh, we can remove this. And that became its own kind of addicting feeling of just like, oh wow, we just removed 10 pages and the quality of the book did not drop at all.

Like we didn't leave anything behind by doing that. And I think this was a really good exercise because it helped us kind of strip down to, you know, what is really the essence of this thing.

And because there's so much like when you wade into the documentation, you get all kinds of it's this, it's that.

And this process of saying, "Well, what can we take out and still have it be what it is really helped and and I mean for me, I was just kind of hanging on by my fingernails the entire process.

It wasn't until a year and a half or two years ago where lights started to come on and I started to maybe see, oh, maybe this is what we're doing.

Maybe that is what we're doing." It was definitely a mental exercise and challenge. Yeah. And it took us a while to get to the mission that we ultimately got to.

Like we went through a number of iterations. At one point we were going to write a Scala 3 book and then we were going to write a Scholo book and then we came to Effect Oriented Programming and we're like the the mission that we have is to teach people the value of effects, why they should use them, why they're better than what you're currently doing, how they help you create more reliable, testable software, more composable software.

And so then that became the driving mission of the book was let's teach people effects, and ZIO, you know, just became a vehicle to do that.

And then it became very easy to kind of decide what goes in the book. Is this helping people understand effects and the concepts of effects, not ZIO, like we're not going to teach you how to use ZIO.

Like, you can go learn that, read the documentation, read other books, but we want to teach you the concepts of effects and how they're going to benefit you and your code.

>> Yeah. Nice. I mean, and this is just to give props to my editor.

So, I like what you've just said. My editor used to summarize by saying, it's important, Andrew, but is it essential?

And I obviously didn't spend enough time trying to find the essential. But I like to anyone who's listening to this who thinks, is this book worth reading?

Like in my, like the fact that you've like super succeeded in distilling it down to that kind of thing.

You don't it's not suspended on its own that it doesn't kind of apply to the real world, but it's it's very, you know, you could find the stuff that's underpinning it if you wanted to, but you don't need to.

It's very it's very pure. And so that's leads some evidence of of this working.

So there's a new AI framework that the Kotlin JetBrains folks came up with, and they actually just I ran into them last week at DevOps, and they told me that their design for how they designed the like workflow definition system within this Kook AI thing was actually inspired by factoring, and that they wanted to isolate the the the side-effecting pieces from the workflow definition.

And and so I was like, cool, like that's like a totally different realm from what we kind of were in when we wrote the book.

But it inspired somebody to like take an effect-oriented approach to designing this this library, which was really cool to hear. I'm going have to ask you more about that later.

Yeah, that's that's like, so my next question is just because I we've teased this enough.

So what are effects? This is the thing, right? So I I thought I knew what they were, but I didn't. But now I do because I've read the book.

For people who are interested in this, what are effects really? Kind of what are the if you can if you can distill your your very thorough book into an even shorter quick explanation.

Yes. Um, okay, my current way of thinking about it is that effects are operations that can be composed.

So rather, I mean, we we talk about composition with uh object-oriented programming, we stick objects together, but this these rather than objects, these are operations and you can compose them.

And when you do, you get a new operation that can be composed.

So it's kind of a holy grail sort of thing that we've been chasing throughout computer science from the beginning.

How do we make bigger pieces out of smaller pieces? And the challenge here has been predominantly how side effects mess things up when you try and do composition.

Eventually, you know, it's a little easier, but then eventually side effects come in and make it harder and require the programmer to do lots of repetitive custom work every time they want to make these changes.

And I want to jump in and make sure we emphasize that it has an effect on the real world. It is something that operates outside of the realm of your processor because if you're adding two numbers, sure that's an operation that composes.

But if you are adding two numbers and then sending a message about that to another system, okay, well now the situation has fundamentally changed.

You had an effect on the outside world and that just brings new types of risk and consequences to these things of, you know, I think one important part is an effect can't be just universally undone.

You know, once you have sent a message out into the world, you have kicked off, the butterfly has flapped its wings, you don't know what is going to come out of that.

So that's why you need to treat these things with special care is because it can just cascade out into all these unexpected places.

And so effects you want to be very deliberate about when and how you execute them, right?

You can't with when the way Bill described it, oh, you've got all this stuff going on the outside.

That's what makes it hard to compose these operations. So, the effect has to encapsulate its own side effects so that it keeps track of everything, and that's what makes the composition possible.

And I think it's just the difference in, okay, this code puts something in a database or this code, when it is executed, will put something in the database.

And just that slight shift of, okay, well now we have something that we can execute or we can manipulate it further.

We can clamp it down more. We can add some new behavior to it. Just the fact that it is not executed in an unprincipled way.

You always have to be very deliberate about when is this going to be acted upon. And that deferred execution is pretty fundamental to empowering you to compose and alter the behavior in all sorts of arbitrary ways.

Yeah, because that was something that struck me was when I, as all three of you definitely know, I spent many years struggling trying to understand and wrap my head around functional programming.

And because lots of my world was the kind of the side effects bit, which when you do FP, like core FP, they're like, don't worry about that.

That's like, you know, they're bad. We don't think about these. And I was like, but everything I do is side effects.

But then, like you said, kind of Bill, right, then then this is extending kind of types and some kind of determinism into the world, the nondeterministic world of all of this unpredictable stuff, right?

Like you said, when the butterfly flaps its wings, but I really like giving you the right handles to manage the unpredictability of what happens once you talk to the outside world.

So it doesn't like, it doesn't turn the unpredictable into predictable, but it gives you the tools to manage the unpredictable pieces.

So you can easily put on like a timeout or a retry or these different things that you're like, okay, this thing may go wrong.

I may get an error, which is unlikely to happen if I have a pure function.

Um, but I'm now now things can can go a different way than I expect them to. How do I deal with that?

And and then how do I deal with that at a single level or at the composed level of things? Because how do you you know, every time you've got one unpredictable piece, you put them all together now you seem to have something very large and unpredictable, you know, more unpredictableness.

And so like, how do you deal with that at at the small and at the big and use the same foundational pieces to do that?

>> And this was the thing because this is what kept striking me again after having spent, you know, time sitting in open space sessions with with all three of you, like the whole you kept saying the compiler can check this and I was like, this is this is a big, like, this is a big deal, right?

Like suddenly a lot more, like you said, it's not you're not making the nondeterministic deterministic, but you can check that you've thought about these things and that they compose together and I think that's, I mean, is that maybe the aha, sorry, Bill, is that is that feels to me like one of the big things, right?

That you that you want to get >> Yeah, just all the things the compiler can do for you of in ZIO the particular effect system we're using for this book as you execute a series of operations, if they have different failure modes, those all are tracked and assembled at the end.

Effect Oriented Programming • Bill Frasure, Bruce Eckel, James Ward & Andrew Harmel-Law

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

이펙트 중심 프로그래밍은 부작용을 캡슐화하고 구성 가능한 연산을 통해 안정적이고 테스트 및 구성 가능한 소프트웨어 개발을 가능하게 합니다.

이펙트는 컴파일러를 통해 오류 및 리소스 관리를 명시적으로 처리하도록 강제하여, 프로그래머가 복잡한 인프라 대신 핵심 비즈니스 로직에 집중할 수 있도록 돕습니다.

이 책은 모나드와 같은 복잡한 함수형 프로그래밍 용어를 피하고 간결한 설명을 통해, 수학적 배경 지식 없이도 이펙트 개념을 이해하고 다양한 프로그래밍 언어에서 적용할 수 있도록 돕는 것을 목표로 합니다.

이펙트 중심 프로그래밍 책의 저자들이 책을 간결하게 유지하기 위해 사용한 주요 전략은 무엇이며, 이러한 접근 방식이 독자에게 어떤 이점을 제공한다고 설명하나요?

저자들은 '이펙트'를 어떻게 정의하며, 왜 이것이 전통적인 프로그래밍 방식보다 소프트웨어 구성을 더 안정적이고 테스트 가능하게 만든다고 설명하나요?

ZIO와 같은 이펙트 시스템에서 타입 시스템이 오류 처리와 리소스 관리에 어떤 중요한 역할을 하며, 기존 프로그래밍 방식과 비교했을 때 어떤 이점을 제공하는지 설명해 주세요.

효과 중심 프로그래밍 개념이 Scala 외의 다른 언어 생태계, 예를 들어 Kotlin이나 TypeScript에서 어떻게 채택되고 있으며, 미래에는 Python과 같은 언어에도 적용될 가능성에 대해 저자들은 어떻게 전망하고 있나요?

저자들은 이펙트 중심 프로그래밍이 '마법'처럼 느껴지는 Spring과 같은 프레임워크와 어떻게 대조되며, 왜 효과를 명시적으로 다루는 것이 프로그래머에게 더 이점을 가져다준다고 설명하고 있나요?

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

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

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

암스테르담, 런던, 코펜하겐, 시카고와 같은 도시에서 열리는 GOTO의 최고 수준의 이벤트와 수천 개의 고품질 개발 강연을 찾을 수 있는 GOTO 컨퍼런스 YouTube 채널을 구독하여 최신 기술 정보를 받아보세요.

gotopia.tech에서 자세히 알아보세요. 자, 또 다른 GOTO 북클럽에 오신 것을 환영합니다.

저는 앤드루 하멜-로이고, 이번 주에는 이펙트 중심 프로그래밍의 세 저자를 모셨습니다. 제 소개를 간단히 드리자면, 빌, 제임스, 브루스를 어떻게 알게 되었는지 알 수 있을 겁니다.

콜로라도주 크레스티드 뷰트에는 오픈 스페이스 컨퍼런스가 있는데, 제 생각에는 세 분 모두 그곳에 살고 계신 것 같아요, 그렇죠?

이제 모두 그곳에 살고 계신 것 같아요. 왜냐하면 몇몇 분들이 그렇게 말씀하셨으니까요.

>> 이것은 오픈 스페이스 컨퍼런스인데, 모든 분들이 꼭 참석해야 합니다. 왜냐하면 제가 가본 오픈 스페이스 컨퍼런스 중에서 최고이기 때문입니다.

하지만 저는 이 오픈 스페이스 컨퍼런스에서 빌과 제임스, 브루스를 처음 만났습니다.

그리고 멋진 점 중 하나는 그 컨퍼런스에서 이펙트 중심 프로그래밍을 소개받았다는 것입니다.

그리고 저는 많은 대화와 세션들이 어떻게 이 책으로 이어졌는지 알고 싶습니다. 이것은 제 질문 중 하나가 될 수도 있습니다.

하지만 먼저 여러분이 자기소개를 하도록 해야겠습니다. 빌, 먼저 하시겠어요?

자신이 누구인지, 어떻게 여기에 오게 되었는지 말씀해 주세요.

저는 빌 프레이저입니다. 이 친구들을 10년 정도 알고 지냈습니다. 주로 친구로 지냈지만, 결국 우리 모두가 관심을 갖는 프로젝트를 찾게 되었습니다.

저는 몇 년 동안 Ziverge에서 일했는데, Ziverge는 ZIO의 배후 회사입니다. ZIO는 우리 책에서 선택한 이펙트 시스템이며, 나중에 더 자세히 설명하겠습니다.

네, 저는 스칼라 또는 미래에 나올 수 있는 모든 언어를 통해 함수형 프로그래밍에 점점 더 많은 관심을 갖게 되었습니다.

네, 저는 여기서 작가진 중에 가장 경력이 짧을 거예요. 저는 ZIO 경험이 가장 많고, 작은 분야에서는 제가 더 깊은 경험을 가지고 있을지도 모르겠네요.

좋아요. 좋아요. 빌, 감사합니다. 브루스, 다음으로 하시겠어요?

네. 저는 브루스 에켈입니다. 주로 책을 썼고, 가끔 컨설팅도 합니다.

네, 책 몇 권이 뒤에 있습니다. 오랫동안 이 일을 해왔고, 과거에는 주로 언어에 집중했습니다.

이제 시야를 넓히려고 노력하고 있습니다. 그리고 컨퍼런스 조직에도 오랫동안 참여해 왔습니다. 다가오는 Winter Tech Forum은 3월 첫째 주에 크레스티드 뷰라는 스키 마을에서 열립니다.

그리고 앤드류를 다시 모셔야겠어요.

네. 매년 앤드류를 다시 모시고 싶어 했어요. 올 수 있을 것 같다가도 무슨 일이 생겨서 못 오더라고요.

네, 저입니다. 좋아요. 네, 감사합니다, 제임스. 죄송해요, 빌.

이름을 아래에서 읽는 것을 그만해야겠어요. 화면에 이름 순서가 틀렸어요. 제임스, 죄송합니다. 간단하게 자기소개 해주시겠어요?

화면의 이름을 맞추겠습니다. 아니요, 이름은 헷갈리지 않게 맞춰야 해요.

네, 맞아요. 네. 저는 제임스 워드입니다. AWS에서 에이전트 AI 관련 일을 합니다. 리치와 저는 'Happy Path Programming'이라는 팟캐스트를 함께 진행하고 있습니다.

재미있는 취미죠. 그리고 책을 함께 썼습니다.

오래전에 함께 책을 썼죠. 오래전 바로 저기 선반 위에 있어요. 저희가 이걸로 가렸어요.

네. 네. 네. 사장된 기술에 대한 책이었죠. 네. 책이 출판되자마자 사장됐어요.

네. 네. 네. 앤드류, 여기서 효과에 대해 탐구하기 시작했다고 말씀하셨는데, 여기서 했던 컨퍼런스 중 하나에서였고, 그게 제 첫 효과 경험이었고, ZIO라고 불립니다.

사실, 효과에 처음 관심을 갖게 된 곳이 바로 저희 컨퍼런스 중 한 곳이었어요. ZIO 초기였죠.

제 생각에는 그게 막 발표됐을 거예요. 아시다시피, 최초의 프리 릴리스 버전으로요. 그래서 저희는 컨퍼런스 동안 며칠 동안 몰두해서 배우려고 노력했고, 그게 뭔지, 왜 필요한지, 왜 더 나은지 파악하는 데 시간이 좀 걸렸어요.

그래서, 음, 네, 제 생각에는 저희 여정이 지난 몇 년 동안 우리가 여전히 노력하고 있다는 것을 알아내는 데 걸린 것 같아요.

>> 그거, 그게 사실, 그게 정말 제 첫 번째 질문으로 완벽하게 이어지네요.

왜냐하면 책이, 그리고 이건 제가 최근에 점점 더 많은 책에서 발견한 건데, 책이 그다지 두껍지 않지만, 분명히 여러분이 그걸 알아내는 데 몇 년이 걸렸잖아요, 그렇죠?

그리고 너무 길고 훨씬 더 얇아질 수 있는 책을 쓴 사람이었기 때문에.

그 여정에 대해 간단히 설명해 주시겠어요? 왜냐하면 그게 매우, 그리고 제 말은 좋은 의미로, 매우 간결하거든요.

매우 집중되어 있죠? >> 네. 음, 동기 부여 요인이 몇 가지 있는 것 같아요.

그중 하나는 함수형 프로그래밍, 특히 이펙트에 입문하는 데 얼마나 많은 지식과 배경이 필요한가 하는 점이죠.

그리고 항상 이런 종류의 지식이 있다고 가정하는 매우 위협적인 텍스트들이 있었어요. 아시다시피, 이 책을 읽으려면 이 정도는 똑똑해야 한다고요.

그리고 저희의 목표는 그걸 최대한 낮추고, 언어로 코드를 조금이라도 작성해 본 적이 있다면 이 책에 접근할 수 있기를 바라는 것이었어요.

아시다시피, 그걸 집어든 사람이 완벽하게 이해하지는 못하겠지만, 점점 더 노력했어요.

여기서 뭘 없앨 수 있을까? 그리고 제가 생각하기에 최고점에서는 책이 최종 출판본보다 약 2.5배 더 길었어요.

그리고 일단 '아, 이걸 제거할 수 있구나'라고 깨달았죠.

오, 이걸 제거할 수 있네. 그리고 그게 일종의 중독적인 느낌이 되었어요. '와, 10페이지를 제거했는데 책의 질이 전혀 떨어지지 않았어'라는 느낌이었죠.

마치 그렇게 함으로써 우리가 아무것도 남겨두지 않은 것처럼요. 그리고 이것은 정말 좋은 연습이었다고 생각합니다. 왜냐하면 그것은 우리가 이 문제의 본질이 무엇인지 파악하는 데 도움이 되었기 때문입니다.

문서를 자세히 살펴보면 온갖 종류의 것들이 나오는데, 이건 이렇고 저건 저렇다고 하잖아요.

그래서 "무엇을 빼도 여전히 그 본질을 유지할 수 있을까?"라고 묻는 과정이 정말 도움이 되었습니다. 제 경우에는 그 과정을 따라가는 것조차 벅찼습니다.

1년 반이나 2년 전쯤에야 비로소 깨달음이 오기 시작했고, '아, 어쩌면 우리가 이걸 하고 있는 걸지도 몰라'라는 생각이 들기 시작했습니다.

어쩌면 우리가 그걸 하고 있는지도 몰라'라는 생각이 들었습니다. 그것은 분명 정신적인 훈련이자 도전이었습니다. 네. 그리고 우리가 궁극적으로 도달한 미션에 도달하는 데 시간이 좀 걸렸습니다.

여러 번의 반복을 거쳤죠. 한때는 Scala 3 책을 쓰려고 했고, 그 다음에는 Scholo 책을 쓰려고 했지만, 결국 효과 중심 프로그래밍에 도달했고, 우리가 가진 미션은 사람들에게 효과의 가치, 왜 효과를 사용해야 하는지, 왜 현재 하고 있는 것보다 더 나은지, 효과가 어떻게 더 안정적이고 테스트 가능하며 구성 가능한 소프트웨어를 만드는 데 도움이 되는지를 가르치는 것이라고 생각했습니다.

그래서 그것이 책의 핵심 미션이 되었습니다. 사람들에게 효과를 가르치고, ZIO는 단지 그것을 위한 도구가 된 것이죠.

그러자 무엇을 책에 넣을지 결정하기가 매우 쉬워졌습니다. 이것이 사람들이 효과와 효과의 개념을 이해하는 데 도움이 되는가, ZIO가 아니라요. ZIO 사용법을 가르치려는 것이 아닙니다.

ZIO 사용법은 다른 책이나 문서를 통해 배울 수 있지만, 우리는 효과의 개념과 그것이 당신과 당신의 코드에 어떻게 도움이 되는지를 가르치고 싶습니다.

>> 네, 좋습니다. 우선 제 편집자에게 감사를 표하고 싶습니다.

방금 하신 말씀이 좋네요. 제 편집자는 '중요한 건 맞지만, 필수적인가?'라는 말로 요약하곤 했습니다.

저는 필수적인 것을 찾는 데 충분한 시간을 할애하지 못했습니다. 하지만 이 책을 읽을 가치가 있는지 고민하는 분들에게 말씀드리고 싶습니다.

마치 제가, 마치 당신이 그걸 그런 종류의 것으로 증류하는 데 엄청나게 성공했다는 사실처럼요.

그것이 스스로 떠 있는 것이 아니고 현실 세계에 적용되지 않는 것이 아니라, 매우, 아시다시피, 원한다면 그것을 뒷받침하는 것들을 찾을 수 있지만 그럴 필요는 없습니다.

매우 순수합니다. 그래서 이것이 작동한다는 증거가 됩니다.

그래서 Kotlin JetBrains에서 만든 새로운 AI 프레임워크가 있는데, 사실 바로 지난주 DevOps에서 그들을 만났는데, 그들이 이 Kook AI 내의 워크플로 정의 시스템을 설계한 방식에 대한 디자인이 실제로 팩터링에서 영감을 받았으며, 사이드 이펙트 조각들을 워크플로 정의로부터 분리하고 싶었다고 말했습니다.

그래서 저는 '좋아요, 우리가 책을 썼을 때 우리가 있던 영역과는 완전히 다른 영역이네요'라고 말했습니다.

하지만 그것은 누군가에게 이 라이브러리를 설계하는 데 효과 중심적인 접근 방식을 취하도록 영감을 주었고, 그것은 정말 멋진 소식이었습니다. 나중에 그것에 대해 더 물어봐야겠어요.

네, 그게, 제 다음 질문은 우리가 이것을 충분히 놀렸기 때문입니다.

그래서 효과는 무엇인가요? 이것이 핵심이죠? 그래서 저는 그것들이 무엇인지 안다고 생각했지만, 몰랐습니다. 하지만 이제 책을 읽었기 때문에 알아요.

이것에 관심 있는 사람들을 위해, 효과는 정말 무엇인가요? 당신의 매우 철저한 책을 더 짧은 간단한 설명으로 요약할 수 있다면, 무엇이 있을까요?

네. 음, 현재 제가 생각하는 방식은 효과는 구성할 수 있는 연산이라는 것입니다.

오히려, 객체 지향 프로그래밍으로 구성을 이야기하고, 객체들을 함께 붙이지만, 객체들보다는 연산들이고 그것들을 구성할 수 있습니다.

그리고 그렇게 하면 구성할 수 있는 새로운 연산을 얻게 됩니다.

그래서 그것은 우리가 처음부터 컴퓨터 과학 전체에서 추구해 온 일종의 성배 같은 것입니다.

더 작은 조각들로 더 큰 조각들을 어떻게 만들 수 있을까요? 그리고 여기서의 과제는 주로 사이드 이펙트가 구성을 시도할 때 어떻게 망치느냐였습니다.

결국에는 좀 더 쉬워지지만, 결국에는 부작용이 생겨서 더 어려워지고 프로그래머가 이러한 변경을 할 때마다 많은 반복적인 맞춤 작업을 해야 합니다.

저는 여기서 우리가 실제 세계에 미치는 영향을 강조해야 한다고 생각합니다. 프로세서 영역 밖에서 작동하는 것이기 때문입니다. 숫자를 두 개 더하는 것은 구성되는 연산입니다.

하지만 숫자를 두 개 더한 다음 다른 시스템에 메시지를 보내는 경우 상황이 근본적으로 바뀌었습니다.

여러분은 외부 세계에 영향을 미쳤고, 그것은 새로운 유형의 위험과 결과를 가져옵니다. 중요한 부분 중 하나는 효과가 보편적으로 되돌릴 수 없다는 것입니다.

일단 메시지를 세상에 보냈다면, 나비가 날갯짓을 시작했고, 그 결과가 어떻게 될지 모릅니다.

그래서 이러한 것들을 특별히 조심해야 합니다. 왜냐하면 예상치 못한 곳으로 확산될 수 있기 때문입니다.

따라서 효과는 언제 어떻게 실행할지 매우 신중하게 결정해야 합니다.

Bill이 설명한 방식으로는 할 수 없습니다. 세상에 이런저런 일들이 벌어지고 있습니다.

이것이 이러한 연산을 구성하기 어렵게 만드는 요인입니다. 따라서 효과는 자체 부작용을 캡슐화하여 모든 것을 추적하고, 이것이 구성을 가능하게 합니다.

그리고 저는 이것이 단지 '이 코드는 데이터베이스에 무언가를 넣는다' 또는 '이 코드가 실행될 때 데이터베이스에 무언가를 넣을 것이다'의 차이라고 생각합니다.

그리고 '이제 실행하거나 더 조작할 수 있는 것이 생겼다'라는 약간의 변화가 있습니다.

우리는 그것을 더 억제할 수 있습니다. 우리는 거기에 새로운 행동을 추가할 수 있습니다. 그것이 비원칙적인 방식으로 실행되지 않는다는 사실만으로도 그렇습니다.

언제 이것이 실행될 것인지 항상 매우 신중해야 합니다. 그리고 그 지연된 실행은 여러분이 모든 종류의 임의적인 방식으로 행동을 구성하고 변경할 수 있도록 하는 데 매우 근본적입니다.

네, 왜냐하면 그것은 저에게 큰 인상을 주었던 것인데, 여러분 모두가 분명히 아시다시피, 저는 기능적 프로그래밍을 이해하고 파악하려고 노력하면서 많은 시간을 보냈습니다.

제 세상의 많은 부분이 부작용과 관련되어 있었기 때문입니다. FP, 즉 핵심 FP를 할 때는 '걱정하지 마세요.'라고 말합니다.

그건 나쁜 거니까요. 우리는 이런 것들에 대해 생각하지 않아요. 하지만 제가 하는 모든 일은 부작용이었어요.

하지만 빌이 말한 것처럼, 이런 종류의 유형과 결정론을 예측 불가능한 모든 것들의 세계로 확장하는 것이죠?

나비가 날갯짓을 할 때처럼 말이죠. 하지만 외부 세계와 소통할 때 발생하는 예측 불가능성을 관리할 수 있는 올바른 핸들을 제공하는 것이 정말 마음에 듭니다.

Effect Oriented Programming • Bill Frasure, Bruce Eckel, James Ward & Andrew Harmel-Law

스크립트