December 10, 2012 at 10:19Rich Hickey's Unofficial Brain Guide
- Transfer
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 arose from my understanding of Rich Hickey's programming thoughts. 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 put my mind in order.
In this article (and possibly in future ones) I will try to streamline and catalog the unique point of view of Mr. Hickey. Ultimately, I would like to get a brief summary of his ideas. I hope this leads to a searchable reference for those who write in Clojure, and an accessible introduction for those who do not use Clojure.
All of the following text is based on Rich Hickey ’s talk “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 have explicit definitions of the following concepts, these definitions are incorrect:
Below, we will contrast the points of view of OOP and Functional Programming (hereinafter FP) for each of these points. But first, let's look at the reality models that underlie OOP and FP - this is exactly the fundamental difference that leads to the application of so many different approaches to the definition of the above concepts.
As a rule, when it comes to metaphysics, things begin to lose their clear form, but, fortunately, this makes some sense.
As Wikipedia teaches us, metaphysics tries to answer as broadly as possible two main questions:
Rich Hickey explains the difference between the metaphysics of OOP and FP by the example of the answer to the question “What is a river?”.
According to OOP metaphysics, a river is what actually exists in the real world. I know, I know, I even hear you asking: “Yes, and what?”, But, believe me, the accuracy of this statement did not let many philosophers sleep.
The trick is that the river is constantly changing, and its waters never stop flowing. In terms of the PLO, we would say that a river has a mutable state, and it (state) is constantly fluctuating.
The fact that the condition of the River Object and the Objects as a whole is never constant in the real world, however, does not prevent us from considering them as fundamental building blocks of our programs. Moreover, this is exposed by the advantage of OOP - no matter how the state changes - you interact with a rigidly described interface and everything works exactly as you expect. An object can change, but for all observers it continues to be exactly the same object.
This is consistent with our intuitive perception of the world. The electrons in my cup of coffee move, but it still tastes like coffee, as I expected.
After all, in OOP objects think. 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. The Man object pushes the Door object and moves to the House object.
According to the metaphysics of the FP, we would say that we cannot enter the same river twice. What we see is a discrete, lacking continuity thing that exists in the world regardless of changes and is a combination of other discrete and unchanging things.
A “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 - this is just a concept.
What really exists is particles and processes. A river is not a stable object, but rather, it is a sequence of bound particles that is created by a certain process.
These particles do not act on each other, and they cannot be changed. They cannot do anything. 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.” This is the same as saying that HEAD points to a new commit in the Git repository.
Alright, enough with metaphysics! Now we will describe more useful topics, starting with Value.
It is obvious that the numbers 3, 6 and 42 are values. The numbers are constant, unchanging.
It should also be obvious that OO languages do not have the correct definition for values in this sense. As Rich Hickey points out, you can create a class whose instances consist of immutable 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 torn your hair, trying to figure out how the attribute of the object was changed? In fact, in object-oriented languages there is no built-in mechanism to determine whether the state of an object is stable or not.
This is one of the reasons why competitive programming is so hard. Even in single-threaded applications, this is a problem, and this is why we are forced to write extensive test suites. You cannot be sure that calling the method on the Wig object will in no way lead to a change in the Hipster Points object.
In functional languages, on the other hand, the emphasis is 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 FP, we operate with a simple name, which we gave a sequence of bound particles. The “river” corresponds to the sequence R1, R2, R3, etc., produced by the process of the “flow” of the river. There is a direct analogy to HEAD in git - it's just a name that points to the actual values. In OOP there is no such difference.
Or, as he himself says:
In OOP, there is no clear definition of state. Maybe this is the "value of all the attributes of the object right now." And this is compelled "right now", because there is no linguistic mechanism that allows you to look into the past.
This becomes more clear if you make a comparison with the concept of identity in FP. In the Hixian universe, State is a specific value at a particular point in time. (For me, this definition really put everything in its place.)
In OOP, there is no real idea for time. Everything is happening right now. This is what leads to problems in competitive programming.
In contrast, in the world of FP that we study, the concept of time is well defined. Time is a byproduct of the process of naming (identifying) states.
Finally, the behavior. I don’t have much to write here - I’ll probably still watch the speeches, but I’ll still give a quote from Mr. Hickey inviting you to think:
Maybe this is what prompted Steve Yegge to write “Execution in the Kingdom of Nouns”
Well, that's all for today. I hope this post has been helpful. If you have any suggestions, I would love to hear them!
The article is not entirely fresh, but it seemed interesting enough to me, and in the comments to the original post, probably more interesting. Unfortunately, the translation of the discussion is beyond the scope of my participation.
December 6, 2012
translation of the article The Unofficial Guide to Rich Hickey's Brain
In part, my pleasure in learning Clojure arose from my understanding of Rich Hickey's programming thoughts. 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 put my mind in order.
In this article (and possibly in future ones) I will try to streamline and catalog the unique point of view of Mr. Hickey. Ultimately, I would like to get a brief summary of his ideas. I hope this leads to a searchable reference for those who write in Clojure, and an accessible introduction for those who do not use Clojure.
All of the following text is based on Rich Hickey ’s talk “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 have explicit definitions of the following concepts, these definitions are incorrect:
- Value
- State
- Identity
- Time
- Behavior (Behavior)
Below, we will contrast the points of view of OOP and Functional Programming (hereinafter FP) for each of these points. But first, let's look at the reality models that underlie OOP and FP - this is exactly the fundamental difference that leads to the application of so many different approaches to the definition of the above concepts.
Metaphysics, programming, and you: Comparing OOP and FP
As a rule, when it comes to metaphysics, things begin to lose their clear form, but, fortunately, this makes some sense.
As Wikipedia teaches us, metaphysics tries to answer as broadly as possible two main questions:
- What is there?
- What does it look like?
Rich Hickey explains the difference between the metaphysics of OOP and FP by the example of the answer to the question “What is a river?”.
Object Oriented Programming
According to OOP metaphysics, a river is what actually exists in the real world. I know, I know, I even hear you asking: “Yes, and what?”, But, believe me, the accuracy of this statement did not let many philosophers sleep.
The trick is that the river is constantly changing, and its waters never stop flowing. In terms of the PLO, we would say that a river has a mutable state, and it (state) is constantly fluctuating.
The fact that the condition of the River Object and the Objects as a whole is never constant in the real world, however, does not prevent us from considering them as fundamental building blocks of our programs. Moreover, this is exposed by the advantage of OOP - no matter how the state changes - you interact with a rigidly described interface and everything works exactly as you expect. An object can change, but for all observers it continues to be exactly the same object.
This is consistent with our intuitive perception of the world. The electrons in my cup of coffee move, but it still tastes like coffee, as I expected.
After all, in OOP objects think. 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. The Man object pushes the Door object and moves to the House object.
Functional programming
According to the metaphysics of the FP, we would say that we cannot enter the same river twice. What we see is a discrete, lacking continuity thing that exists in the world regardless of changes and is a combination of other discrete and unchanging things.
A “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 - this is just a concept.
What really exists is particles and processes. A river is not a stable object, but rather, it is a sequence of bound particles that is created by a certain process.
These particles do not act on each other, and they cannot be changed. They cannot do anything. 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.” This is the same as saying that HEAD points to a new commit in the Git repository.
Alright, enough with metaphysics! Now we will describe more useful topics, starting with Value.
Value
It is obvious that the numbers 3, 6 and 42 are values. The numbers are constant, unchanging.
It should also be obvious that OO languages do not have the correct definition for values in this sense. As Rich Hickey points out, you can create a class whose instances consist of immutable 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 torn your hair, trying to figure out how the attribute of the object was changed? In fact, in object-oriented languages there is no built-in mechanism to determine whether the state of an object is stable or not.
This is one of the reasons why competitive programming is so hard. Even in single-threaded applications, this is a problem, and this is why we are forced to write extensive test suites. You cannot be sure that calling the method on the Wig object will in no way lead to a change in the Hipster Points object.
In functional languages, on the other hand, the emphasis is 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, thing.”
In FP, we operate with a simple name, which we gave a sequence of bound particles. The “river” corresponds to the sequence R1, R2, R3, etc., produced by the process of the “flow” of the river. There is a direct analogy to HEAD in git - it's just a name that points to the actual values. In OOP there is no such difference.
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 the labels that we use to name time periods. ”
State
In OOP, there is no clear definition of state. Maybe this is the "value of all the attributes of the object right now." And this is compelled "right now", because there is no linguistic mechanism that allows you to look into the past.
This becomes more clear if you make a comparison with the concept of identity in FP. In the Hixian universe, State is a specific value at a particular point in time. (For me, this definition really put everything in its place.)
Time
In OOP, there is no real idea for time. Everything is happening right now. This is what leads to problems in competitive programming.
In contrast, in the world of FP that we study, the concept of time is well defined. Time is a byproduct of the process of naming (identifying) states.
Behavior
Finally, the behavior. I don’t have much to write here - I’ll probably still watch the speeches, but I’ll still give a quote from Mr. Hickey inviting you to think:
“There is no behavior. When lightning struck you, who is "behaving"? "
Maybe this is what prompted Steve Yegge to write “Execution in the Kingdom of Nouns”
the end
Well, that's all for today. I hope this post has been helpful. If you have any suggestions, I would love to hear them!
Translator Notes
The article is not entirely fresh, but it seemed interesting enough to me, and in the comments to the original post, probably more interesting. Unfortunately, the translation of the discussion is beyond the scope of my participation.