[Beijing website production] Reasons for learning functional programming

Strangely, few people use functional programming languages every day. If you program in Scala, Haskell, Erlang, F # or some Lisp dialect, no company will probably hire you. Most people in this industry use object-oriented programming languages like Python, Ruby, Java or C # - they are easy to use. Yes, you may occasionally use one or two "functional language features", such as "block", but people will not do functional programming.

However, for many years, we have been taught that functional programming languages are great. I still remember my confusion when I first read ESR's famous paper on learning Lisp language. Perhaps most people are more familiar with Paul Graham's article Beating The Averages:

Among those who convert to functional programming, the common consideration is that learning this new, functional language "is good for you"; It's like some people suggest that 30 minutes of gym activities every day will "make you healthy". But it also implies the difficulty and effort required. Lisp language is different from Haskell, Ocaml and Scala languages. It is considered to be notoriously difficult to learn and can be said to be notorious. Elegant people say that this is the embodiment of "depth&breadth" of Lisp language. Unclassified people say that this is "wanton" or "academic play" or simply "unnecessary". I think its difficulty is related to whether you are familiar with it or not. Moreover, this difficulty is an important indicator that learning such a language will make you more efficient and capable in programming.

It gives you an unfriendly first impression

I started programming when I was 7 years old. In the long, boring summer in the suburbs, I fooled around on my grandfather's computer. I learned BASIC and used it to draw a bouncing ball on the screen. I learned Pascal and used it to write a program that can play music through PC speakers. When I was about 10 years old, I learned C language, but I met a wall that I couldn't cross until I went to high school. That is: pointer. Even excluding these damned pointers, I also encountered countless failures in writing, reading, learning and practicing. I destroyed my grandfather's hard disk twice (once by accident), and finally I had to reinstall the operating system myself many times. I failed again and again.

Maybe you have a similar story with me, maybe a completely different one. But I think that almost all people who have learned programming have experienced difficulties. After learning some basic knowledge, we will inevitably encounter some recognized conceptual gateways, such as "pointer". Many computer science professors describe pointers as filters in their courses. If you want to be a good programmer, you must be able to understand pointers. Few people can master them easily. Most people, including me, need constant practice and reference examples to understand what pointers are and why they are important.

This difficult process of effort is not accidental, but an almost universal phenomenon. Pointer is a very powerful and basic concept. Learning it can make you a better programmer and make your thinking more visual. Even though your language does not provide such features as pointers, data structures and concepts similar to pointers can be found everywhere.

Novelty

Once you have learned several languages, all languages begin to look similar. People who know Python may not encounter too many problems when learning Ruby. People who know Java will feel familiar when learning C #. Yes, there are also some accidents. Ruby enthusiasts will be surprised by its comparison when learning Python, and Java users will be confused about delegation in C #. Again, if you only glance at them, they are very similar. I can guarantee that if you have never known this before, once you learn a Lisp language, you will find that all Lisp variants are very similar.

Some people say that most people are completely at a loss when they first use Haskell or Ocaml. Hell, in Haskell, even the semicolon is different from others. This is not a question of grammar; Haskell and ML are completely based on a different concept and a new language paradigm. You need to develop applications in different ways, organize applications in different ways, and expand applications in different ways.

Many of these new concepts are incredibly powerful. The Monads in Haskell are as basic and powerful as pointers (you may have used them without knowing their name). Therefore, unlike learning C # after learning Java, those who aspire to learn functional languages need to go further and learn more basic concepts before continuing to learn. It's like learning the pointer all over again. And, just like when we first started to learn programming, some big concepts will seem confusing and frustrating until you tackle them (and fail).

Take your pills and find your pharmacist

Although it is not easy to learn, I firmly believe that learning these functional programming languages will be good for your career. I believe some people will turn their eyes to the sky when they read this. It is hard to imagine that these monoids or monads will be useful for them when using Java or C #. For me, I am not surprised that such thinking has prevented them from learning functional language; They need to learn a new concept as basic as pointers and recursion. They need a kind of patience and fighting spirit that only professionals can have when they complete clear business goals. Few people can bear setbacks after they have passed the plastic age -- setbacks again and again -- or we would have become experts now, wouldn't we?

There are more complex things. A large number of language and algorithm studies are implemented in functional languages (especially Haskell). It's easy to get lost in these unfamiliar concepts - such as taxonomy theory, half refined abstractions, and some failed studies. Without a clear guidance (such as a good book written by a pragmatic author), the already difficult learning task becomes more terrible.

These combined complex factors have led to no unexpected results: many people are reluctant to invest time in functional programming learning. It is easy to understand this reluctance, "Why don't I spend my time learning these things on what to achieve?" But this idea also shows that you are never willing to waste time on any new technology (only those familiar to you). In a rapidly changing industry like software technology, I don't think this is a correct judgment.

Seeing is believing.

The most obvious benefit of learning a functional programming language is that you can learn the functional concepts in this type of language. It can help your brain to have the ability to think clearly and process some amazing important concepts. This is not that functional programming has magic; The emergence of various languages and paradigms is to deal with a specific category of problems. The killer of functional programming is to deal with the growing trend of parallel programming and metadata programming in the world today.

For example, we study a simplified, local version of Google's famous MapReduce example. It is incredibly clear and concise to describe this example in a functional way:

1. mapReducer data partitioner mapper  reducer  =  
2. let   partitions  =  partitioner  data  
3. in reduce reducer (map mapper partitions)  

It is easy to enable such code to support parallel computing or distributed parallel computing (for local parallel computing, many function packages support "pmap" and "produce" - just use some simple features of functional languages). Concepts such as maps, partitions, generators, streams, reductions, folds, and function chaining are similar to each other in various functional programming languages. Therefore, anyone familiar with Lisp, Haskell, OCaml, and even languages with some features of functional languages -- Python and Ruby -- will easily understand the essence of this idea.

Let's take a moment to consider how to use an object-oriented language to clearly describe this architecture in a common object-oriented pattern. At least what you need to do is to define the declaration used to describe mapper and reducer. If you are curious, please try to use your favorite object-oriented language to describe a minimal "object-oriented" MapReduce. I found it very wordy. If you use a Java style language, it will look like this:

1. interface Mapper {  
2. B map(A input);  
3. }  
4.  
5. interface Reducer {  
6. Y reduce(X a, X b);  
7. }  
8.  
9. abstract class MapReduce {  
10. private Mapper mapper;  
11. private Reducer reducer;  
12.  
13. public MapReduce(Mapper map, Reducer reduce) {  
14. // ...  
15. }  
16.  
17. public run(SeqenceType data) {  
18. // ...  
19. }  
20. }  
21.  

Even without loop logic, this lack of the use of nouns and verbs common in functional mode makes MapReduce difficult to define. This kind of definition is almost ridiculous, but it can remind you of functional concept. Another good example is how the Scala language uses the complete Java Fork/Join class library to easily integrate it into its own syntax.

Each has his own requirements

Therefore, I encourage any programmer who wants to make progress: please consider learning a functional language. Haskell and OCaml are excellent choices, and F # and Erlang are also quite good. They are not easy to learn, but perhaps this is a good thing. Try to understand the complex concepts you encounter and see if others are using them; Often, you will make a breakthrough in thinking when you are looking for the real purpose of these unfamiliar concepts.

When you start learning, please pay attention and don't care too much. Just like anything else that requires you to spend time and energy, it is dangerous to invest too much energy in functional programming. If you fall into the cognitive trap, your investment will cost you nothing. You can easily forget that there are countless computing models in the world, and you can easily forget how many excellent software does not use any functional concept at all.

The road of learning will become more and more difficult, but on the other hand, in your daily programming, you will find more and more important concepts and models that can be used. You will be more and more adaptable to such a compact programming style. Inevitably, you will also have a new understanding of how to become a better software engineer.

supplement

Some major asked me the same question after reading this article: "Sounds good, David, but what kind of language should I learn?" Of course, this is a problem they gave me.

I think if you are an experienced programmer, the answer to this question is: "Choose one that meets your needs". If you need to work on the JVM, choose Scala or Clojure. If you want to develop large-scale distributed software systems quickly, choose Erlang. If you want a super working language with a super compiler, please select Haskell or RCaml. If you want a prototype tool that is more powerful than Ruby or Python, choose Scheme.

Please remember that the purpose of what we are doing here is for practical skills and self-improvement. If you can spare time to learn these, go out of your comfort environment and challenge yourself.

Because I have learned Lisp and Erlang and used OCaml for professional work, I decided to study Haskell, which is a completely different world. I found that the only way to help me understand this language is to rely on two useful guidance materials, Learn You A Haskell and Real World Haskell. These writings are very good and valuable, and can be found online for free. If you want to try Haskell, these books can be used as your treasure hunt map.

label: Website production