Original article address.Functional-Light-JS
Original article by. Kyle Simpson - Author of You-Dont-Know-JS

Chapter 1: Why Use Functional Programming?

Functional programmers: No functional programmer names variables x, functions f, and module code "zygohistomorphic prepromorphism". James Iry ‏@jamesiry 5/13/15 https://twitter.com/jamesiry/status/598547781515485184

Functional Programming (FP), is not a new concept, it has been around for almost the entire history of programming. I'm not sure it's reasonable to say that, but it's pretty certain: it's only in the last few years that functional programming has become a mainstream idea throughout the development community. So I think the field of functional programming is more like the field of academics.

Yet everything is changing.。 Not just from a programming language perspective， Some libraries and frameworks are showing an unprecedented interest in functional programming。 Chances are you're also reading related content， Because you finally realize that functional programming is something that can't be ignored。 Or maybe you're like me.， Have tried many times to learn functional programming， But it's hard to understand all the terms or mathematical symbols。

Whatever your reason for flipping through the book, welcome to join us!

degree of confidence

I have a very simple premise that underlies everything I do as a software development teacher (JavaScript): code you can't trust is code you don't understand. In addition, with code you don't trust or understand, you won't be able to determine if the code fits your business scenario. You can only pray for luck when the code runs too.

What does trust mean? Trust means that you understand what the code can do by reading it, not just running it, and not just staying at the level of what it might be doing. Perhaps we shouldn't always be inclined to verify that a program is correct by running a test program. I'm not saying that testing is bad, but that we should know the code like the back of our hand so that we know for sure that it will run before we run the test code.

By just reading the code we can have more confidence in our programs, and I believe that the foundational components of functional programming techniques are designed with this mindset in mind. People who understand functional programming and practice it with care in their programs benefit from the proven principles of functional programming and are able to write highly readable and verifiable code to achieve what they want.

I hope that by understanding the principles of lightweight functional programming, you'll feel more confident in the code you write and be able to get better afterwards.

Communication channels

Why is functional programming so important? To answer this question, let's take a step back and first discuss the importance of programming itself.

I don't think code is a bunch of instructions in a computer, and it may seem strange to you to say that. The fact that the code can instruct the computer to run is a surprise.

I'm convinced that the main purpose of code is to facilitate human interaction.

As you may know from past experience, sometimes spending a lot of time "programming" is really just reading existing code. Most of our time is actually spent maintaining other people's code (or our own old code), and only a small amount of time is spent knocking out new code.

Do you know what kind of data has been given by experts who have studied this topic? 70% of our time in maintaining code is spent reading and understanding it. It's no wonder that the average number of lines of code per day for programmers worldwide is 5. We spend seven and a half hours a day reading the code and figuring out where those five lines of code should go.

I think we should focus a bit more on the readability of the code. It might be worth spending a little more time on readability if possible. Incidentally, readability does not mean a minimum amount of code, and familiarity with the code also affects readability (which has also been proven).

Thus, if we want to spend more time focusing on code readability and comprehensibility, then functional programming provides a very convenient model for us. The principles of functional programming are well established, thoroughly researched and reviewed, and can be verified.

If we use the principles of functional programming， I believe we will write code that is easier to understand。 Once we know these principles， They will be identified and familiar in the code， This means that when we read a piece of code， We will spend less time locating。 Our focus will be on how Assemble all known“ Lego Clip”， Instead of these“ Lego Clip” What does it mean?。

Functional programming is one of the most effective tools for writing readable code (and probably others). This is why functional programming is so important.

Readability curves

It's important that I first take a moment to talk about a phenomenon that has puzzled and frustrated me for years, and the issue was particularly poignant at the time of writing this book.

This may also be a problem that many developers will encounter. Dear reader, as you read this article, you may find yourself in the same situation. But pick yourself up, stick with it, and the steep learning curve will always pass.

We will discuss this issue in more depth in the next chapter. But you may have written some imperative code, like if statements and for A statement like loop. These statements are intended to precisely guide the computer how Finish one thing. Declarative code, and the code we write in an effort to follow the principles of functional programming, is more focused on describing the end result.

There is also a brutal problem on the horizon that I spent a lot of time on while writing this book: I needed to spend more effort and write more code to improve the readability of the code and minimize, if not eliminate, the parts of the code that could introduce program errors.

This is a bit unrealistic if you expect that code refactored with functional programming will immediately become more beautiful, elegant, smart, and concise; the change takes a process.

Functional programming takes a different approach to thinking about how code should be organized to make the flow of data more obvious and to get the reader to understand your ideas quickly. The effort is well worth it, however the process is arduous and you may need to spend a lot of time tweaking the code based on functional programming until the code readability becomes better.

Also, my experience is that it takes about six attempts to convert to declarative code before you do it. To me, writing code that conforms to functional programming is more of a process than a binary conversion from one paradigm to another.

I also refactor the code I've written frequently. That is, after writing a piece of code, looking at it again in a few hours or a day will feel different. Usually, the code before refactoring is rather messy, so it needs to be tweaked repeatedly.

The process of functional programming didn't leave me penciled in on an artistic canvas for an audience to applaud. Instead, the programming process was arduous and vivid, feeling like riding in an unreliable wagon through an overgrown copse.

I'm not trying to dampen your passion, but I truly hope that you too will be able to navigate your way through programming. After that I finally saw the readability curve extend upwards and it was worth all the effort, and I'm sure you'll feel the same way.

accept

We need to systematically learn functional programming and explore to discover the most basic principles that I believe disciplined functional programming programmers will follow and use as a framework for development. However, in most cases, we mostly choose to avoid obscure terms or mathematical symbols that could otherwise easily frustrate learners.

I think it doesn't matter what you call a technology, it's important to understand what it is and how it works. That's not to say that sharing terminology isn't important; it can certainly simplify communication between seasoned professionals. But it's a bit distracting for the learner.

So I wanted the book to focus more on basic concepts rather than fancy jargon. That's not to say there isn't terminology, there definitely is. But don't get too caught up in the glitz and glamour of the words; go after the meaning behind them, and that's what this book is all about.

I call this lack of formal practice "lightweight functional programming" because I think the formalism of true functional programming lies in the fact that I think if you're not used to the ideas that functional programming espouses, you might have a hard time using it. This is not just speculation, but my own experience. Even after preaching the functional programming process and completing this book, I can still say that the formalization of terms and notation in functional programming is very, very difficult for me. I have tried again and again and found most of them to be very difficult to master.

I know many functional programming programmers who would argue that the formalism itself helps with learning. But I think it's a pit that you step in when you try to get some kind of comfort with formalism. But if by chance you have a math background and even some CS experience, these problems may come easily to you. But some of us don't have those conditions, and no matter how hard we try, formalism always holds us back.

Therefore, this book introduces some of the concepts that I think functional programming will involve, which won't directly benefit you but will help you understand the whole process of functional programming step by step.

You don't need it.

If you've spent a long time planning a project， Then someone will definitely tell you“YAGNI” —— “ You don't need it.”。 This principle comes primarily from extreme programming， Emphasize the high risk and cost of building features， This risk and cost stems from whether the project itself requires。

Sometimes we think about a feature we might use in the future and think that building it now will make it easier to build other applications, only to realize that we guessed wrong and it turns out that the feature isn't needed, or is needed for a different set of applications altogether. Another scenario is where we anticipate the right features, but build them too early, which equates to taking time away from developing existing features. Kind of like a loss and a loss.

The YAGNI challenge tells us that even if there are features that are counter-intuitive in a situation, we should often defer building them until the feature is currently needed. We tend to inflate mental estimates of the future refactoring cost of a feature, but often that refactoring is done in the future when it is needed.

The above holds true for functional programming as well, but I'll start with a warning bell: this book contains plenty of interesting development patterns that you'll want to try, but that doesn't mean your code has to use them.

What sets me apart from many functional programming developers is： Just because you've mastered functional programming doesn't mean you have to use it。 moreover， There are many ways to solve the problem， Even if you have mastered a more refined approach， Can be more sensitive to maintenance and scalability" Stand the test of the future"， However, a lighter functional programming model may be more appropriate for the scenario。

In general, I recommend that you seek balance in your code and that you remain cautious in your application as you get the hang of functional programming. The principles of YAGNI also apply when deciding whether a pattern or abstraction makes parts of the code more readable, or whether it simply introduces smarter libraries.

As a word of caution, some unused extension points are not only a waste of energy, but may get in your way. Jeremy D. Miller @jeremydmiller 2/20/15 https://twitter.com/jeremydmiller/status/568797862441586688

Remember, every line of code you write has to be maintained by someone afterwards, and that person could be a member of your team or it could be you in the future. If the code is written too complex, then whoever is maintaining it will be doubly stressed about your showy staged cleverness.

The best code is code that is readable because it seeks just the right balance between what is right (idealistic) and what is inevitable (correct).

sources

I wrote this article with reference to a number of different resources. I'm sure you'll benefit from them too, so I wanted to take a moment to list them.

Book Recommendations

Some functional programming / JavaScript books that you must read.

Blogs and sites

Some additional authors and related content for review.

Some libraries

The code snippets in this book do not use libraries. Each operation we find will derive how to implement it in separate, ordinary JavaScript. However, when you start building more real code using functional programming, you'll soon be using the more reliable and efficient generic features available in existing libraries.

by the way， You'll want to make sure to check the documentation for the library functions you're using， to make sure you know they are how working。 It has many similarities to the code built in this article， But no doubt there are some differences even compared to the most popular libraries。

Here are some popular JavaScript versions of functional programming libraries to start you on your way to discovery.

Appendix C shows the libraries that use some of the examples in this book.

conclude

This is JavaScript lightweight functional programming. The goal is to learn to communicate with the code, not to be weighed down under a mountain of symbols or jargon. I hope this book starts you on your journey!

Recommended>>
1、Meitu bot paints celebrities a week after debut diagnoses skin problems in addition to face
2、Did you see all these products on the first day
3、Blockchain 30 says its going to be big storage TCFS is born who wins with TCFS as well as IPFS
4、Huawei surprisingly is the first passthrough economy
5、Regular expressions in Java