My lot github.com/zhuanyongxi…

This is probably an oft-revised article that captures my rudimentary understanding of functional programming today.

Functional programming is not a tool library on Github, it is much older than JavaScript, it is a programming paradigm that has been proven to work by many computer scientists for decades. It’s not just about learning the apis of a few functional programming tools. It’s more about a change in programming thinking. For a more concrete code example, see pointFree and Declarative Programming for JavaScript Functional Programming.

So why use functional programming anyway?

If it can be summed up in one word, it’s for fun. Where’s the cool? Read and write.

This may strike you as dismissive, and reading and writing may not be the most important thing for you. But to my current level of knowledge, design patterns, programming paradigms, and even programming languages themselves are all about these two words.

Code is for people to see

A programming language, for example, is “language”. What is “language” for? Communicate. Communicate with whom? With people, not machines. The code we write is compiled layer by layer, and finally converted into zeros and ones before it can be executed by the computer. So why do we go to all the trouble, instead of just programming in zeros and ones? Because it’s hard to write and hard to read. If you’re fast enough and smart enough, you can program with zeros and ones. But in that case, do you still need a computer? Although the process of layer upon layer compilation is bound to reduce efficiency, there is no need to worry about Moore’s Law.

What makes a function “easy to read”?

It’s pretentious to talk about design patterns and programming paradigms when all you need is a few lines of code. We need these things because reading and writing code becomes a problem as the amount of code increases.

How does functional programming solve these problems?

For example, pure function has many advantages, the most important of which is that it significantly reduces our cognitive load.

Let’s start with the most common function:

var a = 1;
function A(val) {
  a = 2;
  return a + val;
} 
Copy the code

Here, the variable A is the global variable that everyone sneers at. It is very bug-prone, and when there is a lot of code, it is likely to be overwritten by the same name, causing other programs that use this variable to fail. Even with normal modification, when we use function A again, it is very difficult to make clear the current state of variable A, which makes function A difficult to understand, and the difficult to understand function will not be trusted by users.

Object-oriented programming “encapsulation” solves this problem to some extent:

var obj = {
  a: 1.A: function(val) {
    return this.a + val; }}Copy the code

After encapsulation, global variables are greatly reduced, even if there are two objects with the same name, relative to the above situation, it is not so much burden to modify. But it doesn’t solve the problem completely, because property A is mutable, and it’s still not easy to figure out the state of property A every time method A is called.

Functional programming does not have this problem. In functional programming, using mutable external variables is not allowed. Such as:

var a = 1;	// All functions that use the variable a are not pure functions, except when passed as arguments
function A(val) {	// Not a pure function
  return a + val;
}


const b = 1;
const B = function(val) {	/ / pure functions
  return b + val;
}
Copy the code

As the amount of code increases, the advantages of this approach become more obvious, and if you can further reduce coupling, you can largely “take things out of context” without considering the context. Every pure function can be trusted to output only the parameters passed in.

Not only in functional programming, object-oriented programming often recommends writing pure functions.

Pure functions also have great benefits for debugging code, which is one of the benefits of functional programming: easy debugging.

When beginners of functional programming, it is hard to understand this, because when we use pure functions to help us solve the problem, always can not get the desired results, especially in the use of functional tool library function composition, breakpoint debugging is very difficult, even if you put the breakpoint hit the third-party tools repository, Are you sure you can read someone’s source code in a short time? The only way to do this is to go to console.log. However, this problem can be solved through continuous learning summary. The same is true even when programming in other ways and not being familiar with the tools being used; this is not a problem with functional programming.

The vast majority of bugs are caused by side effects. That’s the change in the state of the system. This can’t be solved by learning. Can you memorize thousands of states and keep track of their changes? But if we are in functional programming and use a lot of pure functions, since pure functions have no side effects, we only need to debug the parts that have side effects when debugging.

In functional programming, all the tricks are aimed at making your code more functional. However, the high cost of learning some techniques has led some to question the “readability” of functional programming.

In fact, the readability of functional code is directly related to the functional programming ability of the person reading the code. The diagram below:

Imperative programming is very much in line with the habits of the human mind and is cheap to get started, while declarative functional programming has a certain threshold to learn and may be almost unreadable to beginners. Only after continuous in-depth study, this readability advantage will gradually be reflected. This is probably the main reason why functional programming is not widely used.

Some problems with functional programming

  1. Confusion about readability. The declarative approach to Pointfree sometimes makes it hard to tell whether it improves or decreases readability, especially if you don’t name a function well enough to specify its functionality, parameters, and return values. . True functional programming languages have type signatures, and of course you can comment your functions that way. However, it is not an easy thing to master type signature.
  2. Too few people use it. Perhaps because of the barriers to entry, most programming today is still object-oriented. It might not be a big deal if you just use a functional library to help with the data. However, if you use advanced techniques such as functors and categorical formulas in real projects, your colleagues who are less familiar with functional programming may frown upon you.
  3. Functional programming often makes heavy use of corrification, which theoretically affects performance and thus experience. However, due to the variety of operating environment, this point is not easy to quantify, according to the specific situation of the discussion.
  4. Once you’re used to imperative programming, switching to functional programming can be a bit difficult. The better you get at object-oriented, the harder it’s likely to be. When I (and I’m not very object-oriented) use functional programming these days, A lot of the time I think about it in an imperative way and then switch to functional. It takes a lot of power to put a compiler in your head.

If I have to…

  1. For declarative programming with a lot of code, naming functions can be hard… ?

Functional programming versus object-oriented programming

Object-oriented programming tends toward encapsulation, while functional programming tends toward abstraction.

The result of an object-oriented programming abstraction is a class; the result of a functional programming abstraction is a procedure (a function).

What is the difference between encapsulation and abstraction?

They don’t have clear boundaries, abstraction is achieved through encapsulation, and I can’t find an example where it’s just abstraction and not encapsulation. Encapsulation and abstraction serve slightly different purposes. Simply put, encapsulation simply wraps up operations that will be used again, waiting for the next time. Abstraction can also be “wrapped up”, but it is more about drawing boundaries. It’s like explaining a concept. If you say “I understand it, but I can’t say it”, chances are you don’t understand it. Whether we can say it clearly or accurately depends on how well we draw the boundaries of the concept in our minds. Without it, there is no way to make a definitive statement about what it is and what it is not. The same is true of abstraction, which requires us to figure out what it does, to get rid of things we shouldn’t do. The clearer the “what it is”, the more abstract the encapsulation becomes.

References:

  • JS functional programming guide
  • Functional-Light JavaScript