Something about functional and abstract

Take the content in the above reply and explain: I will try to solve any problem in the last two years by looking for the FP solution (not just the form. Regardless of the Language C ++, C #, Python, and JS, regardless of the characteristics of the target. Of course, some may say, "How are you doing in areas not suitable for FP... ", but I adopted this strategy to find out the applicability of FP in terms of ideas and forms.

The solution to some of these problems is particularly logical, and the design and implementation indeed reflect the characteristics of the FP abstract mode. In other cases, it will be found that there is only a difference between the form and the use of imperative sub-methodology. Either of these two parts is also feasible, just as the head says using OO as a tool, but there is a difference in comfort.

However, in some cases, FP is not suitable and must be returned to an imperative design. In this case, even if Javascript is still a language that supports native FP, it will feel that if FP is used for design, there are too many awkward things in both thinking and form (it is not so comfortable to replace FP with OO ).

Familiar with imperativeProgramFrom the perspective of personnel, I don't think it's because I have a certain level of FP skills as a specimen or I know a little bit about it. I think most of my start-ups and long-term use of imperative languages, but friends who are interested in FP should be at least two years later, in general, there will be no more idle time and freedom than I have to try it out on practical issues.

On the other hand, I dare not say that I have enough knowledge of FP, mainly because I am not working with Chen Mao, for example, this makes me encounter situations where I think FP is extremely difficult to handle. I don't know if other people do not have such ideas. However, my subjective feelings are as follows: there is a major category of problems. If pure FP is used to solve these problems, it would be too difficult.

My self-feeling is that some of these problems may be due to my insufficient FP skill, so I did not find the correct method, but there are definitely some problems because of the inapplicability of FP (the key is to look at the problem from a certain perspective), and the ideas generated in the imperative style are, this kind of "not applicable" is fewer than FP.

For example, LR (k)AlgorithmCan it be as comfortable as imperative if you use a pure FP idea and adopt a corresponding form? But on the contrary, the recursive descent Implementation of LL (k) (that is, it can be pure FP or not) can be easily modified to use the imperative predictive analysis method; at the same time, it is easier to implement the recursive descent method based on the imperative idea.

Another example is that the idea of using FP for regular-expression automatic machines is still relatively well processed. A possible focus is on the design of the delta function in the quintuple (because it is the most difficult to process; the connection, merger, and closure of the two languages can all be used for a new delta function. If we only implement the content in the textbooks, this is still very smooth.

But when I work more in this way, I feel that many (further) aspects will be subject to elbow. In turn, using a set of objects to represent the elements in the graph will also generate a lot of redundancy for an automatic machine that solves specific problems, in general, it is more intuitive and easy to make various adjustments and modifications than the FP method.

More commonly, for example, some JS components I have written, these components will use a large amount of intermediate data structures and statuses from the imperative point of view. To convert to a pure FP style, you may need a monad framework (for efficiency) or constantly generate new computing results (whether it is an object or a function ). Once a high level of organization needs to be created, it will be a lot of trouble if you only use the concept of FP.

In the end, there will be both FP and OO in a project. However, it takes some effort to ensure the style transition at the interface so that the entire project is relatively unified. (Previously discussed with the head)

In these aspects, not only do I use such a bad singer, but do I think that imperative programmers learn FP benefits more than disadvantages? What is your experience? Sorry.CommunityThere is also a lack of such communication, which makes the FP learning efficiency worse in comparison, which is also one of the reasons why the FP learning has become * cost-effective * low (the previous articleArticleNot mentioned ).

This is not completely involved in the previous article about the abstract thinking passed on by SiC. At that time, I meant that the abstract thinking of the same (or equivalent to the effect) could be gradually mastered through the sub-style methodology below any imperative, there is no need to say that it is not a learning idea, especially considering the cost of time.

In particular, I would like to ask this question: is it impossible to grasp a certain abstraction?

"And imagine that a polygon is hollow and its surface is made of thin rubber. If we cut one side, we can stretch the remaining surface to a plane without tearing it up ...."

The above idea is derived from the proof of Euler's polygon conjecture by kherk [1813a.

Here, we reference it not to learn the truth, but to illustrate the beneficial process for people (even those who make people look up and down) to find ideas and express their ideas, abstract tools are largely separated from various levels of abstraction. The methods and methods taught by textbooks such as SiCp are too specific. They are only one of several tools.

I am not opposed to FP or anything (for example, learning certain abstract methods through SiCp). Anyone who is comfortable with FP will use it (including myself ), the key is to take a look at the process of learning and practice like mine. If a person is more competent than me, or for whatever reason (internal and external) he is confident that he can earn enough profits with a small investment, he can certainly learn FP.

My conclusion is just as concluded by winter-CN: whether it is to better solve the problem or continue to improve its own capabilities, we should avoid blindly turning to learning a specific abstract tool that is not yet mastered and is not irreplaceable.