상태를 안 쓰는 금욕주의자들은 하스켈 하다가 전부 굶어 죽었음





OOP에는 시간에 대한 관리 모델이 없어서 (단 하나의 시간 흐름을 가정)

문제가 있다는 의견이 있음




So, let’s look at Java. It’s easier; there’s no asterisk. This is like even better. So what’s the problem with this? It’s simpler, it’s definitely simpler. Right? Now, we only have references to managed memory and we have automatic memory management. We have garbage collection. This is much, much better. It’s much easier. Except, again, we have this hidden complexity. Right? Is this a mutable thing or not? When will I see a consistent value? If I look at this right now and I walk through its fields, will some of the things I’ve seen represent a consistent value? All right. This isn’t just a concurrency problem. Right? There is a concurrency problem and it’s a big one.


But even before we had threads and all that part, this is a big source of incidental complexity in programs because we don’t know when we have a stable value. Right? Can I store this date off and look at it later and know I’m going to see what I saw when I was handed it? You don’t know. In addition, if you hand a date or some mutable thing – I mean, I know the mutable things have been all deprecated. They’re fixing date or whatever. I’m not trying to beat up on date. But if you hand a mutable thing to somebody and they may hand it to other people, and then you need to change it, who is going to be affected by that? You have no idea.


So this looks really easy. Now, this is true. This is not just Java. This is every single language I listed that allows for mutable objects has this problem and there’s no way to fix it. So what’s the problem here? I’m going to say the problem here is we don’t have any standard time management. Okay? That may be a really confusing thing. Hopefully, it won’t be as we go along.



갓바와 메인 스트림 OOP 언어에는 시간에 대한 표준화된 관리 모델이 없음.

그로 인해 의도하지 않은 복잡함이 발생함




So how did we make this mistake? What’s the real nature of this mistake? Right? It looked like we could change memory in place. Right? We were doing it. There’s PEEK and POKE and it looked like we could see that. We could read. But there was nothing about what we were putting in memory that had any correlation to time. Right? It was live again. And now we’re finding, “Well, look at these new computer architectures. Where is the variable?” Well, there’s one version over here from one point-in-time. Right? And another one over here. And that’s on its way to a place that this over there might see at some point. It’s live. Now we see the problem. Right? There are no changing values. There’s values at points in time and all you’re ever going to get is the value for a point-in-time. Right? And values don’t change. Right?


So the biggest key insight of Whitehead was there’s no such thing as a mutable object. We’ve invented them. We need to uninvent them. Okay? And Whitehead’s model, which I am grossly oversimplifying. Okay? I don’t even understand it. The book is completely daunting, but it’s full of really cool insights. And what’s he’s built is a model that says there’s this immutable thing. Then there’s a process in the universe that’s going to create the next immutable thing.


And entities that we see as continuous are a superimposition we place on a bunch of values that are causally-related. We see things happen over time and we say, “Oh, that’s Fred!” or “Oh, that’s the river outside the back of my house” or “That’s a cloud.” Right? We know you can look at a cloud for enough time, and all of a sudden it’s like, well, that was three clouds or the cloud disappeared. Right? There is no cloud changing. Right? You superimpose the notion of cloud on a series of related cloud values.



어떤 시간대의 값을 사용하거나 의존해야 할 때, 메모리가 변경되었다면 찾을 수가 없음.






https://youtu.be/E4RarTAZ2AY

Clojure 만든 사람 강연인데 한번 보시면 좋을 듯


https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/AreWeThereYet.md

이건 저 강연 스크립트임


저두 불변성 이야기 나와서 생각 나서 보는 중