Why is Functional Programming Difficult to Understand?
For many programmers, functional programming is a knowledge system that falls into the categories of:
- Unknown Unknowns "the ones you don’t know you don’t know"
and
- Unknown Knowns "the ones you don’t know you know"
And it's rare for these "realizations" to be explained carefully.
Many Explanations of Functional Programming Overflowing in the Streets
Functional programming is about:
Combining pure functions
Pure functions should not have side effects
Variables are immutable
Strive for referential transparency
These are generally the features and specifications listed along with new terms. All of these are quite strict constraint rules , and there's no doubt that they are requirements that programmers have not been conscious of so far. They take away the freedom of coding and can feel like they are tying the hands and feet of the programmer.
The true nature of each term's concept is never fully explained to the reader until the very end. "What is it really?" Because it's not properly processed, it's often forced upon the reader with new code, saying things like "You can write such beautiful code" and "Did you feel the benefits somehow?"
In reality, these new terms and concepts have a simple and robust common point , and there's a fundamental concept that should be realized first. That should be thoroughly explained first.
That is a great process of "realization." Ideally, " realization" is an intellectual exploration and adventure and should be very interesting.
However, because the primary goal of many explanations in the streets is to cover these listed features and attach seemingly persuasive explanations to each, this most important "realization" is either lightly touched upon as if it were an extra or completely skipped over.
Even the person explaining may "not really understand" (I think this case is very common when I see it), or even if they do understand, it's troublesome to kindly explain because it requires skill, so it's easy to get away with "I said it for the time being."
Of course, the author does not know all the explanations, but I think most of the explanations fail for this reason.
Knowns | Unknowns - "the ones you know" "the ones you don't know"
For a person, there are Knowns | Unknowns - "the ones you know" "Things you don't know" in the world.
Of course, there are overwhelmingly more "Things you don't know" in the world, and the size of "the ones you know" is greatly exaggerated for the sake of explanation.
Gradually, the act of expanding the area of Knowns "the ones you know" to replace the area of Unknowns "Things you don't know" becomes the acquisition of knowledge.
For example, if we limit it to the field of programming and IT,
I want to learn the programming language Rust!
I want to be able to use UnrealEngine5!
I want to know practical techniques for Docker!
It would be something like this.
But, you "realized" that it was Unknowns "Things you don't know," right?
Rust, UnrealEngine5, Docker, and others are well-known technologies in the programming and IT world.
Here, well-known means that everyone knows the content of the technology, is familiar with it, and is proficient in it, but rather, the name is well-known, well-recognized, and realized.
Unknown "Unrealized" Unknown Territory
In other words, whether or not you know the content of the technology, there is an Unknown "Unrealized" unknown territory that is not even well recognized in general, outside the well-known Known area.
Changing Unknown "Unrealized" to Known "Realized"
`
Since the "parts" of functional programming are not well-known technologies like Rust and Docker,
To learn functional programming,
Before
Unknown (Unrealized)
After
Known (Realized)
This process = realization is the most important thing.
However, many explanations of functional programming overflowing in the streets try to explain the new concepts that are necessary for functional programming and probably unknown to the reader, as if they are already well-known in the streets.
This approach does not work.
As a result,
"Functional programming has a concept called pure functions."
"Pure functions are referentially transparent."
"Pure functions do not cause side effects."
It's like building something in the air without a foundation, trying to explain an unknown concept with another unknown concept, and it's completely meaningless. The explanation is in normal mode.
Or, in cases where they instinctively realize that it's not good, they set up a very unique example and try to persuade the reader by writing sample code.
Basically, it's one of these two choices, and at the bottom line, the true nature of the fundamental concept, "realization," is not touched upon and ends without being explained, and there is definitely no explanation that gives the reader the realization.
Explaining an unknown word with another unknown word ← Out of the question
Showing a unique example of sample code and reconstructing an unknown concept in the reader's brain ← There are few geniuses who can do such a thing
There is also a "combination of both."
That is the pattern of writing Haskell code and calling it an "introduction to functional programming and category theory."
Explaining new concepts of functional programming with the unknown language specifications of an unknown language called Haskell
Showing sample code of an unknown language called Haskell and reconstructing unknown concepts of functional programming and category theory in the reader's brain
This "combination of both" is obviously bad, but there is actually a harsh reality in the programming world where people who have become convinced by this approach, or at least can actually write Haskell code themselves, endlessly reproduce the same approach they had to go through.
Unknown "Unrealized" Knowns | Unknowns
Unknown "Unrealized" knowledge includes:
Knowns "the ones you know"
Unknowns "Things you don't know"
Both are there.
To clarify this, although it is a problem of the concept diagram of classification, the graph can be rewritten.
First, the lower half is usually realized, well-known, Known area.
To repeat, if the subject you want to learn is already a well-known technology, such as Rust, UnrealEngine, or Docker, this approach works.
However, this approach does not work in functional programming.
Unknown Knowns "the ones you don’t know you know"
First of all, it is very important to reconfirm Known Knowns "the ones you know and realize."
For example, "addition," "subtraction," "multiplication," and "division," which we learned in elementary school math at the beginning, should be "very well known" to everyone.
This book actually starts from this level, and it is designed that way more strategically than the above policy.
After all, learning is nothing but expanding knowledge based on "the ones you know and realize."
What you already know very well, in fact, when compared to functional programming, is this kind of thing, right?
Before
Unknown Knowns "the ones you don’t know you know"
After
Known Knowns "the ones you know and realize"
This is the process of "realization," and since the work of bringing in new Unknowns "Things you don't know" does not occur, it is very easy and smooth.
In other words, "addition," "subtraction," "multiplication," and "division," which everyone who graduated from elementary school "knows very well," are solid knowledge for that person, and there is no need to redo the arithmetic drill again.
This is the great intellectual asset that the person had to struggle to acquire during his or her elementary school days.
However, how does this "arithmetic operation," called "algebraic structure," connect to the concept called functional programming and Monad (monad)? Most people don't know, they are not informed.
And once you get the "realization," this "arithmetic operation," which you struggled to acquire, can be used as is, in its entirety, for the knowledge of functional programming.
Therefore, not making this "realization" realized, not informing, not teaching, not explaining, is outrageous, and it is either the laziness of the explainer or simply that the explainer himself does not understand well, but in fact, the latter case is very common.
In this book, this work is consciously and thoroughly attempted.
If you "do not realize" this, it would be worth reading this book just for that.
Stepping into the area of Unknown Unknowns "the ones you don’t know you don’t know"
The next step is to step into the area of Unknown Unknowns "the ones you don’t know you don’t know" based on this Unknown Knowns "the ones you know but don't realize."
This includes, for example, the theoretical physics perspective of "the flow of time."
A famous book that introduces the theoretical physics perspective of "handling time" in functional programming is "Structure and Interpretation of Computer Programs" (the original title abbreviation SICP is often used).
Exists.
The theoretical physics perspective of "handling time" in functional programming is, at least as far as the author remembers, I have not seen a single explanation except for SICP, so it is considered to be an important theme that is still neglected in the world.
In this book, this work is consciously and thoroughly attempted.
If you "do not realize" this, it would be worth reading this book just for that.
MarkdownNote (VSCode Extension)
In writing this book, I developed and used my own WYSIWYG editor (VSCode extension) to efficiently paste a large number of images and write Markdown.
Top comments (0)