How to quickly become familiar with a language

[[142469]]

First of all, please forgive me for the somewhat grand title. I just hope you can be inspired by my experience.

I see that many people without a programming background have also collected this article. I will annotate the parts that are too academic.

Programming has always been my hobby. My favorite part is the part related to graphics and images, but in the past few years, I have been learning about electronics. I first started programming through the mathematical software Mathematica, which is also a powerful functional programming language. So I learned FP languages ​​such as Haskell/Scheme/Prolog. Later, I took a course on distributed systems. In order to design distributed systems, I learned Erlang. Because it is also functional programming and a lot of syntax is borrowed from Prolog, I have used it for a long time.

FP refers to functional programming, which is a language based on functions. The corresponding language is imperative language. Programs in imperative languages ​​execute instructions one by one, and each instruction will affect the data of certain storage units or devices. Functional languages ​​are relatively abstract, using operations (functions) themselves instead of the objects being operated on, and functions themselves can be described by other functions. It is a very self-consistent system. Haskell and Scheme are both classic FP languages.

I spent three years studying FPGAs in the second half of my undergraduate studies and during my graduate studies. I have been using Verilog and VHDL. They are languages ​​for describing circuit logic, which means that these codes will eventually correspond to the circuits of a chip. However, there are many similarities with Erlang, probably because they both describe concurrent systems. So at that time, I had the concept that languages ​​are limited to the systems they describe.

FPGA is called Field Programmable Gate Array. We all know that the signals of integrated circuits are 0 and 1, that is, high and low points, and these 0 and 1 can control the on and off of other circuits. This is the basic principle of digital circuits. We know that the memory also stores 0 and 1, so some geniuses thought of whether a memory stick could be used as a switch to control the on and off of a large number of circuits? This thing was later realized. A man named Ross Freeman eventually realized commercial FPGA and founded Xilinx, establishing a large industry. (However, Ross Freeman died of cancer not long after realizing FPGA, and did not see the large industry he initiated. This is a digression.)

Simply put, an FPGA is equivalent to a circuit whose structure can be constantly changed, much like a human neural network. Currently, FPGAs are mainly used in high-frequency trading in the financial field, but Google has built an FPGA farm for deep learning, analyzing all the data stored in Google's data centers (including YouTube videos) to find implicit connections between different data. If one day Google Search can fully understand natural language, it must be the credit of FPGAs.

In the second half of my graduate studies and the first two years of my doctorate, I was working on wireless sensor networks. The wireless sensor nodes used a magical operating system called Contiki. The characteristic of this system is that it uses protothread, which is a concept between process and thread. When the scheduler switches processes, it only remembers the current instruction pointer and does not save the context, so all the content must be stored in global variables. The reason for this is that protothread is very simple to implement, and the processor memory used by the wireless sensor is only 2K.

Wireless sensor networks are basically what we often call the Internet of Things. Each node is mainly composed of a small wireless transceiver chip and a small processor. Due to power consumption limitations, the performance of these chips cannot be too high, so being able to design an operating system (and multi-tasking) on ​​these chips is really something that only people with ingenuity can do. (Of course, any processor nowadays is much faster than the PDP-11 that developed UNIX back then)

In the last year of my PhD, I worked on software radio, which used USRP + GNURadio to implement OFDM communication and find areas for improvement in current WiFi (802.11a/g/n). But after returning to China, I stopped working on hardware and returned to my favorite graphics and images. However, graphics and images are two very different fields. Generally speaking, graphics (computer graphics) refers to how to display images, while images (computer vision) refers to how to recognize and process images. The two have only a small overlap. The two entrepreneurial projects I am currently working on are related to WebGL and QR code recognition.

Having worked on so many projects in the past few years, the span is very large. I sincerely feel that knowledge is endless, and it is better to learn quickly than to know more. The most important thing is that you can quickly find the entry point and quickly build confidence.

0. Why should you quickly become familiar with a language/framework?

You have seen many people arguing about which language or framework to use online. Before that, you have also heard about whether Chinese people should learn English. Language has always had two functions. The first one is a pragmatic function, which is to communicate with people. Every time you master a new language, you can understand the people or objects that use this language and further control them. If you can speak VHDL, you can control FPGA. If you can speak CUDA or OpenCL, you can control GPU. If you can speak kext scripts, you can control various Apple products. If you can use English search fluently, you will accumulate computer knowledge much faster than programmers of the same age and qualifications.

The second function is the emotional function, that is, people who use the same language seek mutual recognition. It is very different when you meet a fellow villager after years of wandering, or when you suddenly return to your hometown and find that you can understand everything everyone says, even some subtle things or situations that are difficult to express in other languages. Programmers tend to find a sense of belonging in the language they use, and build confidence through the language they are familiar with. This will make people proud and block the way to continue learning.

Languages ​​themselves are neither good nor bad. The birth of a new language is always related to the environment in which it is used. If a language is not related to the environment in which it is used, it will not be popular even if its design is elegant, such as Haskell and Lisp dialects, and vice versa, such as JavaScript. You learn a language or framework to do something and to work with people who use the language together, so don't judge the language or framework at any time. After all, all of this is created by people, and people always have limitations. The ultimate goal is to control the machine and communicate with people, not to indulge yourself.

1. Build a debugging platform

Before reading any book, follow the documentation to set up the debugging environment on your machine. It is useless to know the history of the language, the usage scenarios of the language, or even to memorize all the keywords and APIs of the language. This is as ridiculous as thinking that memorizing words will contribute to learning English well. There are few quantifiable indicators for success or mature mastery of a skill. If you have to find an indicator to measure how close you are to success or proficiency, the closest thing is how many times you have failed in practice.

2. Study the most basic data structure

The most basic data structure in almost all languages ​​is a marked sequential structure like Array/List, which we call "table". Tree/graph/Dictionary/matrix can be regarded as an extension of table. In database, there are a lot of CRUD operations on dictionaries, which allow you to pile different things into the table, and the structure can be very diverse. However, in graphics and images, there are a lot of matrix operations, and the objects of operation are very neat data.

When writing code, there is a principle that is summarized through practice, which rarely appears in textbooks, that is, the information transmitted between code blocks (code blocks are a word I thought of temporarily, because the units of language are different in different paradigms, such as classes in Java, objects in Python, prototypes in JS, processes in Erlang, etc.) should be as simple and general data structures as possible, and preferably not very complex objects. That is to say, a code block receives such information, and after some operations, it becomes information with complex structure and large capacity. Then this code block should simplify this information to a simple and general data structure as close as possible, so as to complete one thing. If this code block returns a huge amount of data, and another code block also receives a huge amount of data, then the functional division of this code block is problematic.

This is why UNIX chooses text files as the basic information organization unit, and all files are allowed to be processed as text files, and it is clearly stated that a program should be able to output text, so you can see that the programs inside UNIX will output stderr, so that you can view their footprints through dmesg. Since it is based on text files, it is not surprising that UNIX attaches great importance to regular expressions (grep, sed, awk, perl, ...). These small components are collectively called coreutils. Only by mastering these small components can you understand the powerful power of the *x system (including OS X, of course). Now almost all languages ​​based on tables have begun to support operations such as map/reduce/filter, and naturally introduce lambda functions, precisely because they greatly expand the expressive power of table structures.

In JavaScript, Array is a basic data structure, but so is Object, which is compatible with JSON. Array and Object can be replaced without any difference, but in JS engine, the expressions of Array and Object are completely different, and Array is usually optimized. If the index of Array is not an integer that increases continuously from 0 (for example, there is an element in the middle that is undefined), then it will be degraded to Object when stored, and the search will also be performed in the way of matching the key of Object, which will be much slower.

In OpenCV, since most operations are related to images, cv::Mat has become the basic data structure, and various matrix operations include transposition, inversion, merging and splitting, SVD, etc. OpenCV has made many optimizations to this basic data structure to minimize the I/O overhead at runtime. For example, there is now TBB support for Intel processors. TBB explicitly expresses the concurrency of the program. Of course, this part of the mechanism is encapsulated by OpenCV. For example, when performing RANSAC operations (to fit a straight line or ellipse in a bunch of points), you need to search in a large point set and continuously perform SVD to solve the equation to find the coefficients of the model. With TBB, SVD operations can be executed concurrently, greatly improving performance. So the first thing you need to do is to become familiar with various operations related to Mat.

GNURadio is a software radio framework that requires a wireless transceiver to directly up and down convert the frequency. The CPU encodes and decodes the code through the program. These things were previously done by hardware circuits, but now they are all CPU instructions, which are very sensitive to delays. In GNURadio, there is a mechanism similar to TBB, which converts operations into different modules, such as FFT and IFFT, power spectrum density, etc., and the interface between these modules not only defines the data type, but also includes the maximum and minimum allowed data rate.

The languages ​​used in different fields vary greatly, and the core concepts behind the languages ​​may vary even more. In the field of 3D graphics, matrix operations are the main method of expression. In some contexts, matrices are not a very convenient way of expression, so there are Euler angles and quaternions. These notations are more concise, but also more difficult to understand. In the field of 2D images, there are some very magical algorithms, such as Hough to find lines and ellipses, RANSAC to fit planes, and SIFT/FAST to find image features. In the field of wireless communications, all this is different. However, no matter which field, there is always a most basic way to communicate with people outside the field, and this is the basic data structure.

3. Debugging

I mentioned starting with the basic data structures because the results of operations on basic data structures are the easiest to predict. When the code starts to become complex, the compiler or runtime environment may not be able to tell you clearly where the error is. Sometimes there is no error, and sometimes there is no error (which is more misleading).

The feedback from the compiler or runtime environment is the best information to understand the computer, but for various reasons this information may not be comprehensive. If you rely solely on this information, you will waste a lot of time, so you need to try to make your code provide you with more information. When writing C code, I will use a lot of printf to help me, mainly with the following functions:

1. Printing operation results
2. Print which fork in the if-else control flow statement the code flows to
3. Under what conditions does the print loop terminate?

There are three reasons why bugs occur:

1. You don't know enough about what you are going to do
2. You don't know enough about the grammatical features of the language you are using
3. You don’t know enough about the functions/libraries/frameworks you use

So when a bug occurs, you should first determine which of the above problems your bug comes from. Of course, it is very likely that all of these problems are included. In this case, the error will be very difficult to find. Let's consider the second one first. If you don't understand the syntax features well enough, please go back to the basic data structure level, make various simple examples, and solve all the syntax problems at that level. If it is the third one, then you need to read the documentation and source code carefully.

If you don't know enough about what you are doing, this involves a very subtle and interesting thing. Let me tell you that a person's programming ability is ultimately determined by his ability to master his mother tongue. If a person cannot explain to another person how to do something, then he naturally cannot describe it clearly to a computer. Therefore, for science students who embark on the path of programming, no matter how outstanding their mathematical thinking is, the language class they fell behind in the past will become a shortcoming in the future. On the contrary, if you observe the presentations of various technology conferences in the United States, or programmers who have contributed to open source projects for a long time, their eloquence and writing are not bad.

So how do you find errors? When the code gets an incorrect result, or does not run normally, or fails to compile, there is a place that does not meet your expectations, causing an error. You can start looking from the last expected result, or trace back along the final error. Of course, the best thing is that you can provide detailed information for each key step so that you can modify it later. Most unit testing frameworks now encourage or even require people to do this. This is not a very high-end and cool technology, but it fully takes into account the various defects of human thinking.