Unofficial guide to the brain of Rich Hickey
Flying Machine Studios blog
December 6, 2012
translation of the article The Unofficial Guide to Rich Hickey's Brain
In part, my pleasure in learning Clojure came about because I was familiar with Rich Hickey’s thoughts about programming. Rich has his own view on the fundamental concepts of programming, clear and consistent, and I think that every programmer could win using it. Every time I watch one of his speeches, I get the feeling that someone took and brought my mind in order.
')
In this article (and, possibly, in future) I will try to organize and catalog the unique point of view of Mr. Hickey. Ultimately, I would like a brief summary of his ideas. I hope that this will lead to a searchable reference for those who write on Clojure and an accessible introduction for those who do not use Clojure.
All subsequent text is based on Rich Hickey’s “Are we there yet?”
Modern OOP languages ​​- Ruby, Java, Python, etc. - contain a fundamental flaw - they introduce unforeseen difficulties, based on an inaccurate model of the external world and reality. Although they contain explicit definitions of the following concepts, these definitions are incorrect:
Below, we will oppose the points of view of OOP and Functional Programming (hereinafter OP) for each of these points. But first, let's consider the models of reality that underlie OOP and FP - this is exactly the fundamental difference that leads to the use of so different approaches in the definition of the above-described concepts.
As a rule, when it comes to metaphysics, then things begin to lose a clear form, but, fortunately, this has a certain meaning.
As Wikipedia teaches us, metaphysics tries to answer as widely as possible two basic questions:
Rich Hickey explains the difference between OOP and FP metaphysics using the example of the answer to the question “What is a river?”.
According to the PLO metaphysics, the river is what actually exists in the real world. I know, I know, I even hear you ask: “Yes, so what?”, But believe me, the accuracy of this statement prevented many philosophers from sleeping.
The trick is that the river is constantly changing, and its waters never cease to flow. In OOP terms, we would say that a river has a changing (mutable) state, and it (state) constantly fluctuates.
The fact that the state of the River Object and the Objects in general is never constant in the real world, nevertheless, does not prevent us from considering them as fundamental building blocks of our programs. Moreover, it is exposed by the advantage of the OOP - no matter how the state changes - you interact with the hard-coded interface and everything works exactly the way you expect it to. An object can change, but for all observers it continues to be exactly the same object.
This corresponds to our intuitive perception of the world around us. The electrons in my cup of coffee are moving, but it still tastes like I expected.
In the end, in OOP objects are thought. They act on each other. And again, this corresponds to our ideas about the world, where changes are the result of actions of some objects on others. Object The person pushes the object Door and moves to the object Home.
According to the metaphysics of FP, we would say that we cannot enter the same river twice. What we see is a discrete, continuity-free thing that exists in the world regardless of changes and is a combination of other discrete and immutable things.
“River” is not a thing in itself, but a concept that we impose on a sequence of phenomena associated with it. This concept is very useful - I will not bother with explaining this - it is just a concept.
What really exists is particles and processes. A river is not a stable object, but rather a sequence of connected particles, which was created by some process.
These particles do not act on each other, and they cannot be changed. They can't do anything. The change is not the result of the action of one object on another, the change is the result of a process applied to an immutable particle. To say that something has changed is like saying: “Oh, this is a new particle in this stream of particles.” It's like saying that HEAD points to a new commit in the Git repository.
Well, enough with metaphysics! Now we will describe more useful topics, starting with Meaning.
It is obvious that the numbers 3, 6 and 42 are values. The numbers are constant, unchanged.
It should also be obvious that OO languages ​​do not have a proper definition for values ​​in this sense. As Rich Hickey points out, you can create a class whose instances are composed of unchanging parts, but you do not have a high-level concept that would generally express the class as an immutable value.
This is one of the main causes of headaches when using OOP. How many times have you tore your hair, trying to figure out how the object attribute was changed? In fact, in object-oriented languages, there is no built-in mechanism for determining whether the state of an object is stable or not.
This is one of the reasons why competitive programming is so heavy. Even in single-threaded applications, this is a problem, and this is why we have to write extensive test suites. You cannot be sure that calling a method on the Wig object will in no way alter the object of the Hipster Glasses object.
In contrast, in functional languages, emphasis is placed on working with immutable data. Since the values ​​do not change, the whole class of problems simply disappears.
In a speech, Mr. Hickey says:
In the OP, we operate with a simple name, which we gave sequences of related particles. "River" corresponds to the sequence R1, R2, R3, etc., produced by the process of "flow" of the river. There is a direct analogy with HEAD in git - it's just a name that indicates actual values. There is no such distinction in OOP.
Or, as he himself says:
There is no clear definition of state in OOP. Maybe this is the "value of all attributes of an object right now." And this is forced “right now”, because there is no language mechanism to look into the past.
This becomes clearer if you compare it with the concept of identity in FP. In the Hixian Universe, a State is a specific value at a specific point in time. (For me, this definition really put everything in its place.)
OOP has no real view for time. Everything is happening right now. This is what leads to problems in competitive programming.
On the contrary, in the world of FP, which we are studying, the concept of time is well defined. Time is a byproduct of the state naming (identification) process.
Finally, the behavior. I don’t have much to write here - I’ll probably watch the performances, but I’ll still give Mr. Hickey’s phrase inviting you to think:
Maybe this is what inspired Steve Yegge to write "Execution in the Kingdom of Nouns"
Well, that's all for today. I hope this post was helpful. If you have any suggestions, I'd love to hear them!
The article is not entirely fresh, but it seemed to me quite interesting, and in the comments to the original post, probably more interesting. Unfortunately, the translation of the discussion goes beyond my participation.
December 6, 2012
translation of the article The Unofficial Guide to Rich Hickey's Brain
In part, my pleasure in learning Clojure came about because I was familiar with Rich Hickey’s thoughts about programming. Rich has his own view on the fundamental concepts of programming, clear and consistent, and I think that every programmer could win using it. Every time I watch one of his speeches, I get the feeling that someone took and brought my mind in order.
')
In this article (and, possibly, in future) I will try to organize and catalog the unique point of view of Mr. Hickey. Ultimately, I would like a brief summary of his ideas. I hope that this will lead to a searchable reference for those who write on Clojure and an accessible introduction for those who do not use Clojure.
All subsequent text is based on Rich Hickey’s “Are we there yet?”
Introduction
Modern OOP languages ​​- Ruby, Java, Python, etc. - contain a fundamental flaw - they introduce unforeseen difficulties, based on an inaccurate model of the external world and reality. Although they contain explicit definitions of the following concepts, these definitions are incorrect:
- Value
- State
- Identity
- Time (Time)
- Behavior (Behavior)
Below, we will oppose the points of view of OOP and Functional Programming (hereinafter OP) for each of these points. But first, let's consider the models of reality that underlie OOP and FP - this is exactly the fundamental difference that leads to the use of so different approaches in the definition of the above-described concepts.
Metaphysics, programming and you: Comparing OOP and FP
As a rule, when it comes to metaphysics, then things begin to lose a clear form, but, fortunately, this has a certain meaning.
As Wikipedia teaches us, metaphysics tries to answer as widely as possible two basic questions:
- What is there?
- What does it look like?
Rich Hickey explains the difference between OOP and FP metaphysics using the example of the answer to the question “What is a river?”.
Object Oriented Programming
According to the PLO metaphysics, the river is what actually exists in the real world. I know, I know, I even hear you ask: “Yes, so what?”, But believe me, the accuracy of this statement prevented many philosophers from sleeping.
The trick is that the river is constantly changing, and its waters never cease to flow. In OOP terms, we would say that a river has a changing (mutable) state, and it (state) constantly fluctuates.
The fact that the state of the River Object and the Objects in general is never constant in the real world, nevertheless, does not prevent us from considering them as fundamental building blocks of our programs. Moreover, it is exposed by the advantage of the OOP - no matter how the state changes - you interact with the hard-coded interface and everything works exactly the way you expect it to. An object can change, but for all observers it continues to be exactly the same object.
This corresponds to our intuitive perception of the world around us. The electrons in my cup of coffee are moving, but it still tastes like I expected.
In the end, in OOP objects are thought. They act on each other. And again, this corresponds to our ideas about the world, where changes are the result of actions of some objects on others. Object The person pushes the object Door and moves to the object Home.
Functional programming
According to the metaphysics of FP, we would say that we cannot enter the same river twice. What we see is a discrete, continuity-free thing that exists in the world regardless of changes and is a combination of other discrete and immutable things.
“River” is not a thing in itself, but a concept that we impose on a sequence of phenomena associated with it. This concept is very useful - I will not bother with explaining this - it is just a concept.
What really exists is particles and processes. A river is not a stable object, but rather a sequence of connected particles, which was created by some process.
These particles do not act on each other, and they cannot be changed. They can't do anything. The change is not the result of the action of one object on another, the change is the result of a process applied to an immutable particle. To say that something has changed is like saying: “Oh, this is a new particle in this stream of particles.” It's like saying that HEAD points to a new commit in the Git repository.
Well, enough with metaphysics! Now we will describe more useful topics, starting with Meaning.
Value
It is obvious that the numbers 3, 6 and 42 are values. The numbers are constant, unchanged.
It should also be obvious that OO languages ​​do not have a proper definition for values ​​in this sense. As Rich Hickey points out, you can create a class whose instances are composed of unchanging parts, but you do not have a high-level concept that would generally express the class as an immutable value.
This is one of the main causes of headaches when using OOP. How many times have you tore your hair, trying to figure out how the object attribute was changed? In fact, in object-oriented languages, there is no built-in mechanism for determining whether the state of an object is stable or not.
This is one of the reasons why competitive programming is so heavy. Even in single-threaded applications, this is a problem, and this is why we have to write extensive test suites. You cannot be sure that calling a method on the Wig object will in no way alter the object of the Hipster Glasses object.
In contrast, in functional languages, emphasis is placed on working with immutable data. Since the values ​​do not change, the whole class of problems simply disappears.
Identity
In a speech, Mr. Hickey says:
“The biggest problem is that we confuse two things. We expressed the idea that something that changes in time is our object, a thing. ”
In the OP, we operate with a simple name, which we gave sequences of related particles. "River" corresponds to the sequence R1, R2, R3, etc., produced by the process of "flow" of the river. There is a direct analogy with HEAD in git - it's just a name that indicates actual values. There is no such distinction in OOP.
Or, as he himself says:
“Correspondence is the connection of an imaginary object with a series of causally-related values ​​(states) over time. These are labels that we use to name time frames. ”
State
There is no clear definition of state in OOP. Maybe this is the "value of all attributes of an object right now." And this is forced “right now”, because there is no language mechanism to look into the past.
This becomes clearer if you compare it with the concept of identity in FP. In the Hixian Universe, a State is a specific value at a specific point in time. (For me, this definition really put everything in its place.)
Time (Time)
OOP has no real view for time. Everything is happening right now. This is what leads to problems in competitive programming.
On the contrary, in the world of FP, which we are studying, the concept of time is well defined. Time is a byproduct of the state naming (identification) process.
Behavior
Finally, the behavior. I don’t have much to write here - I’ll probably watch the performances, but I’ll still give Mr. Hickey’s phrase inviting you to think:
“There is no behavior. When you were struck by lightning, who does “lead” yourself? ”
Maybe this is what inspired Steve Yegge to write "Execution in the Kingdom of Nouns"
the end
Well, that's all for today. I hope this post was helpful. If you have any suggestions, I'd love to hear them!
Translator's notes
The article is not entirely fresh, but it seemed to me quite interesting, and in the comments to the original post, probably more interesting. Unfortunately, the translation of the discussion goes beyond my participation.
Source: https://habr.com/ru/post/161885/
All Articles