Feelings of reading "Programming Pearl"
"Programming Pearl" (hereinafter referred to as "Zhuji") in the preface clearly raised two questions: one is how to abstract the actual problem and find out the unique nature of the problem. The second is an interesting little topic: "How to sort integers in a set consisting of several elements in 0~10^7 in 1MB memory (within 10s )". At first I thought about merge sort, but the book proposes that we can use the bit vector of the bitmap, without considering any sorting algorithm, just need to traverse twice, and suddenly there is a sense of dizziness, from this simple example, you can I got a glimpse of some ideas: bitmap data structures, simple design, time - space compromises... The whole book is actually built around these two points, which I find very helpful.
There are a lot of things covered throughout the book, but the first thing that caught my attention was the algorithm. Perhaps it is the after-effects of "Data Structures and Algorithms" on the computer last semester, and now I am more sensitive to algorithms. Algorithms have the same status as other ideas, but I think at a general programming level it has a more significant impact. For example, the example in the book: "Given an English dictionary, find all the anagram sets in it, such as pots , stop , tops are anagrams of each other." Direct processing is more complicated and requires a lot of calculations and comparisons . Since we only need to find the apposition, we actually only need to make the apposition code the same. I think that an algorithm is first and foremost an orderly idea (of course requires rigorous mathematical logic proof), but just an idea is not enough, it also needs to be able to solve problems efficiently and correctly. As a person learning algorithms, we should not assume that algorithms have standard answers. In fact, different problems often have different suitable algorithms. What we need to do is not simply to "find" an optimal one from the existing algorithms, but also to have our own ideas.
So the situation of the actual problem is very complicated, how should we choose the appropriate solution based on the actual situation? "Pearl" tells us: think more. There are many techniques in the book, such as design strength estimation of Brooklyn Bridge in Rough Estimates, code tuning, and more. However, it is not enough to talk on paper, and we still have to rely on practice to gain true knowledge. As discussed by several classmates in the Soft Work Group before. What impressed me was the elaboration of a relatively good classmate in the group. He said that he often refactored the code he wrote because sometimes his selection had better choices. At the same time, he believes that code refactoring is a good way to improve his ability, which I deeply agree with. I occasionally refactor my code, and then I will find out how many bugs there are in my previous code... and I can also recognize where I should pay attention. And the process of writing new code is also a process of exercising yourself. Some things are not guaranteed to be bug free next time if you write them once (in fact, generally not). If things go on like this, I can't say that I can guarantee that I can become a great person, but at least I can say something after typing the code at a decent speed: "Without him, I only know you well."
The general experience is like this. I just read a few questions and didn't have time to do them in detail. It's a small regret. During the summer vacation, strive to be able to do it and appreciate it deeply.