Wang Yin: How to master the programming language

Wang Yin: How to master the programming language

Learning programming language is the only way for every programmer. But there are too many programming languages in the world, each claiming to have the latest "features." So the trouble with programmers is that they always need to learn all kinds of strange language, and must keep up with the "trend", otherwise fear of being eliminated by the times.

Learning programming language is the only way for every programmer. But there are too many programming languages in the world, each claiming to have the latest "features." So the trouble with programmers is that they always need to learn all kinds of strange language, and must keep up with the "trend", otherwise fear of being eliminated by the times.

As a program language researcher, I am deeply aware of the root cause of this psychology. The programming language actually has a very simple, immutable principle. When you see them, you can learn and start using any new language in a short period of time, rather than spending a lot of effort learning one language after another.

A variety of misconceptions about programming languages

Those who learn the language of programming often have the following kinds of psychology, so that they will feel that they have not learned something, or embark on the wrong path. I'll take a brief look at these psychological factors below.

1. Procedural language useless theory. This is a common mistake in the education of computer departments in domestic universities. Professors often instill in students: "What programming language is not important, but the algorithm is important." In fact, the programming language is more than the essence of the algorithm of things. Any algorithm and its complexity analysis are relative to some computational model, and the programming language is the symbolic system that describes the computational model. The algorithm must be expressed in some language, usually the algorithm designers use pseudo-code, which is actually not rigorous, prone to inference loopholes. Algorithm design is good, if do not understand the principle of programming language, it is impossible to achieve efficient. Even if implemented, there can be significant problems with modularity and scalability. Some algorithmic experts or mathematicians write programs that are naïve because they ignore the importance of programming languages.

2. Pursue "new language". The basic philosophy tells us that new things are not necessarily "new things", they may be historical setbacks. The new language, it turns out, may not be as long ago as it has been. In fact, how many "new concepts" of modern language do not exist in some of the oldest languages? The programming language is like a commodity, and every home is advertised for programmers, and most of their designs may be superficial and short-lived. If you can't see through the design of these things, they will be blinded by them. Many language designers do not really understand the principle of programming language design, so often in the design of repeating the previous mistakes. But in order to promote their own language and system, they have to talk and make religious propaganda.

3. "Existence is reasonable". Remember someone who said: "There is no need for a language that does not bring new ways of thinking." "What he said was quite right. There are so many languages in the world, what brings new ways of thinking? actually very little. The vast majority of the language brought to the world is actually chaos. One might argue, "How can you say that A language is not necessary?" I want to use the library L, other languages do not support, can only use A. "But note that what he says is the" necessity "of existence. If you take the existence of the "facts" as the "necessity" of existence, then the logic of confusion. As if we had not defeated Hitler in World War II, and now we have done his slave, then you say: "Hitler should exist, because he feeds us." "Your logic is obviously problematic because if history goes another way (that is, Hitler does not exist), we will live a free and happy life, so Hitler should not exist." It is the right logic to compare the two possible consequences of a thing being and not being, and then making judgments. According to this reasoning, if the poorly designed a language does not exist, then the better-designed B language is likely to get more support to achieve or even surpass the functions of the L library.

4. Pursue "new features". Programming language designers always like to "invent" new nouns, like speculation. Most of these "new concepts" actually have advanced and fashionable appearances, but they have no substantive connotation, as ordinary handlers often see. Often just learn a language A, another language B, said it has a new feature called XYZ. So you start learning B again, so continue. In the eyes of insiders, these so-called "new features" are mostly new bottles of wine. Many people write essays like this title: "Xyz:a novel Method for ...". This caused the concept to explode, but there was no real progress.

5. Pursue "Tips". Many programming books like to show off some tips to teach you how to make a program appear "short". For example, they will tell you what the "(i++) – (++i)" should get, or the precedence of the operator, saying that it can be done with less braces, or that you can say "if there is only one line of code to do without braces", and so on. Little did not know these tips, in fact, most of the programming language design failure. They bring not clear ideas, but logical confusion and a burden of cognition. For example, the C + + operator, which appears because C language designers originally used a small amount of computer memory, and "i++" obviously than "I=i+1″ 2 characters less, so they feel can save some space." Now we are no longer missing that memory, but the chaos and confusion of the + + operator has been handed down. Now some of the newest languages also like to play this grammatical trick. If you pursue these tips, you often can't grasp the essence.

6. For "specialized areas". Many languages do not have new things, in order to occupy one side of the land, claiming that they are suitable for a specific task, such as text processing, database query, Web programming, game design, parallel computing. But do we really need a different language to do these things? In fact, most of these things can be solved in the same common language, or make small changes on the basis of existing languages. But for various political and business reasons, different languages are designed to occupy the market. As far as learning is concerned, they are actually irrelevant, and the "burden of learning" that they bring is almost a cover-up of the benefits they bring. In fact, from some well-designed universal language, you can learn the essence of all these "specialized languages" without having to learn them specifically.

7. Religious beliefs. Many people have religious beliefs about programming languages. This is similar to the belief that people have religious beliefs about the operating system. In fact, if you understand the nature of the programming language, you will find that there is absolutely no need to argue with people about something. A language has shortcomings, it should be able to speak directly, but many people are taboo, because points out the shortcomings are always provoke controversy and hatred. The reason may be that the design of programming language is not science, it is similar to the Bible, it can not be "falsified." No experiment can conclude that the language is right and that it is wrong. So while you think you're justified, it's hard to be convincing. No one will argue about which burger is better, but there are many who argue that language is better. Because many people regard the language of programming as their God, if you criticize my language, you are blasphemy against my God. The solution may be to not take the language you are using too important. What you think is right now may soon be what you think is wrong, and vice versa.

How to Master program language

Seeing some common misconceptions, let's talk about what way of thinking will be easier to master programming language.

1. Focus on "essence" and "principle". Just like all science, the most essential principles of programming language are only a few, but they can be used to construct many and complex concepts. But people tend to overlook the importance of simple principles, and then go after a quick look to pursue the latest, complex concepts. They have not noticed that most of the latest concepts can be combined with the simplest concepts. The smattering of the basic concepts led them to see the essence of those complex concepts. One important part of these concepts, for example, is recursion. Many students in the domestic understanding of recursion only stay in the Han Nota such procedures, and the efficiency of recursion is also a great misunderstanding, that recursion is not a cycle efficient. In fact, recursion is much stronger than cyclic expression, and the efficiency is almost the same. Some programs, such as interpreters, cannot be completed without recursion.

2. Implement a programming language. The best way to learn to use a tool is to make it, so the best way to learn a programming language is to implement a programming language. This does not require a complete compiler, but simply to write some simple interpreters to achieve the most basic functionality. Then you'll find that all the new features of the language you probably know how to achieve, not just the user's level. The quickest way to implement a programming language is to use a language like Scheme that can be used as data. It allows you to quickly write a new language interpreter. My GitHub has some examples of the interpreters I've written (such as this short code that implements the lazy semantics of Haskell).

Several common styles of language

Let me briefly describe some of the common language styles and their problems.

1. Object-oriented language

It turns out that the whole concept of "object-oriented" is fundamentally wrong. Its popularity is due to the original "Software crisis" (God knows if there is a real crisis). The design is designed to separate the "interface" and "implementation" so that changes to the underlying implementation do not affect the functionality of the upper layer. But most object-oriented languages are designed to follow a fundamentally wrong principle: "All things are objects (everything is an object). "So that all functions must be placed in the so-called" object ", not directly passed as arguments or variables. This leads to a lot of times when you need to use tedious design patterns (patterns) to achieve even the right thing for C. In fact, the "interface" and "implementation" of the separation, do not need to put all the functions in the object. Other concepts, such as inheritance and overloading, actually bring more problems than they solve.

The overuse of the "object-oriented approach" has begun to cause negative effects on the industry as a whole. Many programmers in the company like to mechanically some unnecessary design patterns, in fact, what good things do not do, just make the program lengthy and difficult to understand.

So how do you look at object-oriented languages with higher-order functions, such as Python, JavaScript, Ruby, Scala? Of course, with higher-order functions, you can express a lot of things directly without the need to use design patterns. However, due to the pernicious influence of design patterns, some programmers actually use cumbersome design patterns in these languages that do not require design patterns, making people laugh and cry. So when learning, it is best not to use these languages, so as not to be unnecessarily disturbed. When necessary, then come back to use them, you can take its essence, to its dross.

2. Low-level process language

Is it better to have a "low-level language" like C? Actually, it's not. Many people are advocating C because it can bring people closer to the "bottom", that is, to the representation of the machine, which means that it is fast. Here are actually three questions:

1) is it good to be near the "bottom"?

2) What does "fast language" mean?

3) is the language near the bottom of the ground a certain speed?

For the first question, the answer is no. In fact, the most important idea of programming is high-level semantics (semantics). Semantics constitute a matter of human concern and algorithms for solving them. A specific implementation (implementation), such as an integer expressed in a few bytes, is important, but not critical. If achievement is the main goal of learning, it will be put to the cart. Because the implementation can be changed, and the nature of their expression will not change. So a lot of people find that they have learned things, not long after the "outdated". That is because they are not learning the essence, but only the concrete realization.

Secondly, talking about the "speed" of language is actually an empty word. Language is only responsible for describing a program, and the speed of the program, in fact, most of it does not depend on language. It mainly depends on the 1) algorithm and the quality of the compiler (2). Compilers and languages are fundamentally different. The same language can have a lot of different compiler implementations, each compiler generates code quality may be different, so you can't say "A language faster than B language." You can only say "A-language X compiler generated code that is more efficient than the code generated by the Y compiler of the B language". This almost equals nothing, because B may have other compilers that make it faster to generate code.

Let me give you an example. In history, the Lisp language enjoys the reputation of "turtle speed". Some people say that "Lisp programmers know the value of each thing, but do not know the price of anything", that is the matter. But that's a long time ago, and modern Lisp systems can compile very efficient code. For example, the commercial Chez Scheme compiler can compile itself within 5 seconds, compiling the generated target code very efficiently. It can directly compile the Scheme program to a variety of processor machine instructions, and not through any third-party software. Some of its internal algorithms are actually much more advanced than open source LLVM.

Other functional languages can also generate efficient code, such as OCaml. In a program language summer course, Professor Robert Constable of Cornell told a story that they re-implemented a system with OCAML, and found that the OCAML implementation was 50 times times faster than the original C language. After the C-language team optimized the algorithm several times, the OCaml version was several times faster. The reason for this is actually two things. The first is that the functional language frees programmers from the underlying details, allowing them to quickly implement and modify their ideas, so they can quickly find better algorithms. The second is because OCaml has an efficient compiler implementation that makes it possible to generate very good code.

From the above example, you may have seen that the language that is close to the bottom is not necessarily fast. Because the compiler can actually have a very high level of "intelligence", and can even go beyond the bottom-up optimizations that anyone can do. But the compiler has not yet evolved to the point where people can be used to make algorithms. So what people need to do now is simply to design and optimize their own high-level algorithms.

3. High-level process language

Early in the day, the first programming class for the Chinese computer department students was Pascal. Pascal is a very good language, but many people didn't realize it at the time. When I was in college, my Pascal teacher said to us: "Our school is too backward in teaching." Other schools are starting to teach C or C + +, and we're teaching Pascal. "Now that I really understand the design principles of programming languages, I really feel that Pascal is a better language than C and C + + design." It not only frees people from the bottom-level details, has no object-oriented thinking yoke, but also has some very good designs, such as strong type checking, nested function definitions, and so on. But the computer world is really a fallacy, some people criticize Pascal, the advantages are said to be shortcomings. For example, Brain Kernighan's "Why Pascal was not My favorite programming Language", now seems to be a real fallacy. Pascal is now hardly used by anyone. This is not a pity, because it has been wrongly called "shortcomings" in fact, and appears in some of today's most popular languages: Java, Python, C #, ...

4. Functional language

Functional languages are relatively the best design of the day because they not only focus on algorithms and problem solving, but also have no limitations on the thinking of object-oriented languages. However, it is important to note that not every functional language feature is a good thing. Their supporters often say their shortcomings as merit, and you are actually hanging on to some unnecessary shackles. For example, OCaml and SML, because there are many immature designs in their type system, you need to remember too many unnecessary rules.

5. Logical language

Logical language (such as Prolog) is a new idea that transcends functional language, so it requires some special training. A program written in a logical language can "run in reverse". Common Program language written by the program, if you give it an input, it will give you an output. But the logical language is special, and if you give it an output, it can give you all the possible inputs in turn. In fact, through a very simple method, you can easily convert the program from a functional to a logical type. But the logical language is generally in the "pure" case (that is, there is no complex assignment operation) in order to reverse the operation. Therefore, it is best to learn the logical language from the functional language, in the understanding of recursion, pattern matching and other basic functional programming skills to see Prolog, you will find that logic programming is a lot simpler.

Where to begin

But learning programming always starts with a language. What kind of language is that? In my opinion, you can start with Scheme and learn some Haskell (but not all), and then the rest will be comprehend by analogy. You don't need to learn all the details of them, but only the most essential ones. All the remaining details will be easily filled in the actual use. Now I recommend some of the better books.

"The Little schemer" (TLS): I think Dan Friedman's Little schemer is now the best, most essential programming primer. The book is very thin and very incisive. Its predecessor is called "The Little Lisper". Many senior program language experts have learned Lisp from this book. Although it is called "the Little schemer", it does not use all the features of scheme, but ignores some of the problems of scheme and goes directly to the most critical topic: recursion and its basic principles.

"Structure and interpretation of computer Programs | the construction and interpretation of computer programs (SICP): The Little schemer is actually a relatively difficult reading, so I recommend it as a reading to be proficient in the next step. SICP is more suitable as the first textbook. But I need to remind you that you only need to read the first three chapters at most. Since the beginning of the fourth chapter, the author began to implement a Scheme interpreter, but the author's implementation is not the best way. You can learn these things better from somewhere else. But maybe you can read the first chapter of SICP and start looking at TLS.

"A Gentle Introduction to Haskell": For Haskell, I start with a Gentle Introduction to Haskell, because it's very short. I already had Scheme, so I didn't need to learn the basic functional language. What I learned from this document is only Haskell's concept of type and pattern matching.

Excessive to object-oriented languages

So if you get started with functional languages, how do you transition to object-oriented languages? After all, most companies use object-oriented languages. If you really learn functional language, you will find that object-oriented language is easy. Functional languages are designed to be simpler and more powerful than object-oriented languages, and almost all functional language textbooks (such as SICP) teach you how to implement an object-oriented system. You'll see the nature of object-oriented and the problems it has, so it's easy to figure out how to write object-oriented programs and find some tricks to avoid their limitations. You will find that even if you have to use object-oriented language in your actual work, you can avoid object-oriented thinking, because the majority of object-oriented thinking is chaos and redundancy.

Deep in nature and bottom

So is it completely unnecessary to learn the bottom? Of course not. But at the beginning of learning the underlying hardware, it will be complicated by the hardware design to deceive the mind, can not see the essence of simple principle. After learning the high-level language, you can learn "semantics" and " compiling principles".

In short, semantics (semantics) is the symbol of the research program that shows how to produce "meaning" to the machine, and the semantics of learning typically includes the implementation of lambda calculus and various interpreters. The compiler principle (compilation) is to study how to translate high-level languages into low-level machine instructions. The compiler principle actually contains the principle of the computer, such as the binary structure and arithmetic, the structure of the processor, memory addressing and so on. But combining semantics and compiling principles to learn these things will do more with less. Because you will intuitively see why the current computer system is designed to look like this: Why is there a register (register) inside the processor, why the stack is needed, why the heap is needed, and what the nature of it is. These are even problems that many hardware designers don't understand, so their hardware often contains unnecessary stuff. Because they don't understand semantics, they often don't understand what parts and instructions their hardware needs. But interpreting them from high-level semantics will reveal their nature, so you can understand how to design more elegant and efficient hardware.

That's why some programming language experts later also started designing hardware. One of the founders of Haskell, for example, Lennart Augustsson later designed Bluespec, a high-level hardware description language that can be 100% synthetic (synthesis) as a hardware circuit. Scheme is also widely used in hardware design, such as Motorola, Cisco and the former Transmeta, and their chip design contains many Scheme programs.

This is basically my preliminary advice on the language of learning programming. Some of the content may be elaborated in more detail later.

Wang Yin: How to Master the Program language (turn)