Schools of programming

[[142408]]

There are always people who like to argue about this kind of question, whether "Functional Programming" (FP) is better or "Object-Oriented Programming" (OOP) is better. Since there are two gangs, there are people who actively join them, spitting and despising each other. Then there is the "Good Guys Gang", and the people in this gang like to say, who cares what paradigm it is, a tool that can solve the problem is a good tool! Personally, I don't belong to any of these three gangs.

Object-Oriented Programming

If you look beyond the surface, you will find that "object-oriented programming" itself does not introduce many new things. The so-called "object-oriented language" is actually the classic "procedural language" (such as Pascal) with a little abstraction capability. The so-called "classes" and "objects" are basically records (records, or structures) in procedural languages. In essence, they are a "map" from names to data. You can use the name to extract the corresponding data from this table. For example, point.x is to use the name x to extract the corresponding data from the record point. This is a very convenient thing compared to arrays, because you don't need to remember the subscripts where the data is stored. Even if you insert new data members, you can still use the original names to access the existing data without worrying about the subscript misplacement problem.

The so-called "object concept" (different from "object-oriented") is actually a further abstraction of this data access method. A classic example is the data structure of a plane point. If you store a point as:

 struct Point {
 double x;
 double y;
 }

Then you can access its X and Y coordinates directly using point.x and point.y. But you can also store it in "polar coordinates":

 struct Point {
 double r;
 double angle;
 }

In this way, you can access its magnitude and angle using point.r and point.angle. But now the problem comes, if your code defines Point as an XY method at the beginning, using point.x, point.y to access the X and Y coordinates, but later you decide to change the storage method of Point to polar coordinates, but you don’t want to modify the existing code containing point.x and point.y, what should you do?

This is the value of "object thinking". It allows you to change the semantics of point.x and point.y through "indirection" (or "abstraction"), so that the user's code does not need to be modified at all. Although there are no x and y members in your actual data structure, since .x and .y can be redefined, you can "simulate" them by changing the definition of .x and .y. When you use point.x and point.y, the system is actually running two pieces of code, and their role is to calculate the values ​​of x and y from r and angle. In this way, your code feels that x and y are real members, but in fact they are temporarily calculated. In languages ​​like Python, you can directly change the semantics of point.x and point.y by defining "properties". In Java, it is a little more troublesome, and you need to use point.getX() and point.getY(). However, their ultimate purpose is actually the same - they provide a layer of "indirection" (abstraction) for data access.

This kind of abstraction is sometimes a good idea, and it can even be related to the so-called "unobservability" of quantum mechanics. Do you think there are 10 electrons in this atom? Maybe they are just illusions like point.x gives you, maybe there is no such thing as electrons in the universe, maybe every time you see so-called electrons, they are temporarily generated to tease you? However, the value of object thinking ends here. Almost all the so-called "object-oriented thinking" you have seen can be extended from this idea. Most of the features of object-oriented languages ​​have actually been provided by procedural languages ​​for a long time. Therefore, I think that there is actually no language that can be called an "object-oriented language." Just like a person contributing a little code to a company is not enough for the company to be named after him.

As a way to access data, "object thinking" has certain benefits. However, "object-oriented" (with the word "oriented") is a far-fetched and over-developed idea. Many object-oriented languages ​​claim that "everything is an object", put all functions into so-called objects, called "methods", and ordinary functions are called "static methods". In fact, as in my previous example, only when abstraction is rarely needed, you need to use "methods" that are embedded in objects and closely integrated with data. At other times, you actually just want to express the transformation operations between data, which can be expressed with ordinary functions, and it is simpler and more direct. This practice of putting all functions into methods is putting the cart before the horse, because functions do not actually belong to objects. Most functions are independent of objects and cannot be called "methods". Forcing all functions to be put into objects to which they do not belong and treating them all as "methods" leads to excessive complexity of object-oriented code logic. It is a very simple idea, but it takes a lot of detours to express it clearly. A lot of times it's like stuffing your head into your ass.

This is why I like to joke that object-oriented programming is like the Flat Earth Theory. Sure, you can say the Earth is flat. That's fine for local, small-scale phenomena. But it's not natural, simple, or straightforward for general, large-scale situations. To this day, you can still find endless evidence and bend the laws of physics to justify the illusion of a flat Earth, but it makes your theory very complicated, often patched up, and difficult to understand.

Object-oriented languages ​​not only have their own fundamental errors, but also because the designers of object-oriented languages ​​are often half-way through, without strict language theory and design training, but pretentious, they often come up with other weird things. For example, in JavaScript, each function can also be used as a constructor, so each function has an implicit this variable. When you nest multiple layers of objects and functions, you will find that you cannot access the outer this and have to bind it. Python does not distinguish between variable definition and assignment, so when you need to access global variables, you have to use the global keyword. Later, it was found that if you want to access the "middle layer" variables, there is no way, so a nonlocal keyword was added. Ruby has had four lambda-like things, each with its own quirks... Some people ask me why some languages ​​are designed like that. I can only say that many language designers actually don't know what they are doing!

The software industry loves to create sects. "Object-oriented" took advantage of the situation and became a sect under various pretexts, brainwashing many people. What kind of language is considered an "object-oriented language"? There is still no definite answer to such a basic question, which is enough to show that the so-called object-oriented language is basically nonsense. Whenever you point out the shortcomings of an OO language X, someone will tell you that X is not an "authentic" OO language, and you should look at another OO language Y. When you find that Y also has problems, someone will ask you to look at Z... Until ***, they tell you that only Smalltalk is an authentic OO language. Isn't this funny? Saying that a language that no one uses is an authentic OO language is like saying that only dead people's words are right. It's like a group of politicians passing the buck and shirking responsibility. When you really look at Smalltalk, you will find that the fundamental problems of object-oriented languages ​​actually come from it. Smalltalk is not a very good language. Many people still don't know that many of the advantages of the "object-oriented language" they use are inherited from procedural languages. Whenever there is a war of words between functional languages ​​and object-oriented languages, there will always be object-oriented supporters who bring up the advantages that procedural languages ​​have long had to refute them: "You say object-oriented languages ​​are bad, look at what it can do..." Using the advantages of others to prop up your own facade, but failing to see the essential advantages of things, such a debate is purely talking to the deaf.

Functional Programming

Functional languages ​​have always been relatively low-key, until recently, due to the emergence of bottlenecks in concurrent computing programming and the strong advocacy of language communities such as Haskell and Scala, it has suddenly become a sect. Some people blindly believe that functional programming can miraculously solve the problem of concurrent computing, but fail to see the real problems that are independent of the language. The gang brainwashed by functional languages ​​like to deny everything about other languages ​​and look down on other programmers. In particular, some beginners in programming regard functional programming as a magic pill to lose 20 pounds a day. They think that since they start with functional languages, they can talk nonsense about old programmers with more than ten years of experience, as if others don't know anything without using functional languages.

Advantages of functional programming

Functional programming certainly provides its own value. The greatest value of functional programming over object-oriented programming is the correct understanding of functions. In functional languages, functions are "first-class citizens". They can be born at any location, just like "values" such as 1, 2, "hello", true, objects, etc., and can be passed to other places through variables, parameters and data structures, and can be called at any location. These are things that many procedural languages ​​and object-oriented languages ​​cannot do. Many so-called "object-oriented design patterns" are because object-oriented languages ​​do not have first-class functions, so each function must be wrapped in an object before it can be passed to other places.

Another contribution of functional programming is their type system. Functional languages ​​are often very strict about type thinking. The type system of functional languages ​​is often more rigorous and simpler than that of object-oriented languages. They can help you to make rigorous logical inferences about programs. However, the type system is a double-edged sword. If you take it too seriously, it will bring unnecessary complexity and over-engineering. I will talk about this below.

Various white elephants

The so-called white elephant is something that is sacred, expensive, but has no practical use. Functional languages ​​have good things, but they have many redundant features, which are similar to the properties of white elephants.

The "advocates" of functional languages ​​often believe that the world should be "pure" and should not have any "side effects". They regard all "assignment operations" as low-level and *** practices. They care a lot about so-called tail recursion, type deduction, fold, currying, maybe type, etc. They are proud of being able to write code that uses these features. However, they do not know that those things, in addition to comforting themselves and creating the illusion of superiority, do not necessarily bring truly excellent and reliable code.

Pure functions

A half-full pot of water always makes a jingle. Many people who like to call themselves "functional programmers" often don't really understand the essence of functional languages. Once they see the way procedural languages ​​are written, they sneer. For example, the following C function:

 int f( int x) {
 int y = 0 ;
 int z = 0 ;
 y = 2 * x;
 z = y + 1 ;
 return z / 3 ;
 }

Many functional programmers may frown when they see those assignment operations, but what they fail to see is that this is a truly "pure function", which is essentially the same as functions in languages ​​like Haskell, and perhaps even more elegant.

Those who blindly despise assignment operations do not understand the concept of "data flow". In fact, whether assigning values ​​to local variables or passing them as parameters, it is essentially like putting something into a pipe or putting an electrical signal on a wire, except that the direction and style of placement of this pipe or wire in different language paradigms are slightly different!

Ignoring data structures

Another important and fatal thing that the followers of functional languages ​​have not seen clearly is the fundamentality and importance of data structures. Some problems of data structures exist "physically" and "essentially", and they cannot be magically eliminated by changing languages ​​or styles. Supporters of functional languages ​​like to blindly believe in and use lists, without seeing its essence and the time complexity it brings. The problems brought by lists are not just the complexity of programming. No matter how cleverly you use it, many performance problems cannot be solved at all, because the topological structure of the list is not suitable for doing some things!

From the perspective of data structure, the so-called list in Lisp is a one-way linked list. You must access the next node from the previous one, and each "indirect addressing" takes time. Under this data structure, simple functions like length or append have a time complexity of O(n)! In order to bypass the shortcomings of this data structure, the so-called "Lisp style" tells you not to append repeatedly, because the complexity is O(n2). If you need to add elements to the end of the list repeatedly, you should first repeatedly cons and then reverse it. Unfortunately, when you have recursive calls at the same time, you will find that the cons+reverse method is upside down and very easy to make mistakes. Sometimes the list is positive, sometimes it is reversed, and sometimes part of it is reversed... This method is okay to use once, but after a few more layers of recursion, you will confuse yourself. After finally getting it right, you may make mistakes again when you modify it next time. However, some people like to show their intelligence and like to abuse themselves, and they bravely move forward in the face of such artificially created "difficulties" :)

Ironically, half-baked Lisp programmers prefer lists, while truly profound Lisp masters know when to use records (structures) or arrays. At Indiana University, I took a course on Scheme (a modern Lisp dialect) compilers, taught by R. Kent Dybvig, the author of Chez Scheme, the world's most advanced Scheme compiler. The data structures (including AST) of our course compiler were all represented by lists. At the end of the semester, Kent said to us: "Your compiler can already generate code comparable to my Chez Scheme, but Chez Scheme not only generates efficient target code, but its compilation speed is more than 700 times faster than yours. It can compile itself in 5 seconds!" Then he revealed a little about the reason why Chez Scheme is so fast. One of the reasons is that Chez Scheme's internal data structure is not a list at all. At the beginning of compilation, Chez Scheme has already converted the input code into a fixed-length structure like an array. Later, my experience and lessons in the industry also taught me that arrays do have a significant performance improvement over linked lists in some cases. It is an art to know when to use linked lists and when to use arrays.

The fundamental value of side effects

The neglect of data structures has a lot to do with the "doctrine" of pure functional languages ​​that blindly reject side effects. Excessive use of side effects is of course harmful, but side effects are actually fundamental and useful. Regarding this, I like to tell people this: when computers and electronic circuits were first invented, all circuits were "pure" because logic gates and wires had no ability to remember data. Later, someone invented the flip-flop, which gave rise to the so-called "side effects." It is the side effects that allow us to store intermediate data, so that all data does not need to be transmitted to where it is needed through different wires. A language without side effects is like a world without radio and light. All data must be transmitted through real wires. These many complicated cables must be properly connected and organized to achieve the desired effect. Why do we like WiFi, 4G network, and Bluetooth? This is why a language should not be "pure."

Side effects are also an important component of some important data structures. One example is the hash table. Advocates of pure functional languages ​​like to blindly reject the value of hash tables, saying that they can achieve the same effect with pure tree structures. However, the fact is that these pure data structures cannot achieve the performance of data structures with side effects. So-called pure functional data structures often require a lot of copying of data because they need to keep the old structure every time they are "modified", and then rely on garbage collection (GC) to destroy the old data. You must know that memory allocation and release both take time and energy. Blindly relying on GC leads to too frequent memory allocation and release of pure functional data structures, which cannot achieve the performance of data structures with side effects. You must know that side effects are advanced functions supported by electronic circuits and physics. Blindly believing in and using pure functional writing is actually wasting existing physically supported operations.

fold and others

Code that uses fold and currying extensively may seem cool to write, but is unnecessarily painful to read. Many people do not understand the essence of fold at all, but they always like to use it because they think it is the "essence" of functional programming and can show their intelligence. However, what they do not see is that fold actually contains only a "general template" for recursion on a list. This template requires you to fill in three parameters to generate a new recursive function call. So every fold call essentially contains a recursive function definition on a list. The problem with fold is that it defines a recursive function without giving it a clear name. The result of using fold is that every time you see a fold call, you need to reread its definition and figure out what it does. Moreover, the fold call only shows the part required by the recursive template, and hides the main body of the recursion in the "framework" of the fold itself. Compared with writing the entire recursive definition directly, this veiled approach is actually more difficult to understand. For example, when you see this Haskell code:

 foldr (+) 0 [ 1 , 2 , 3 ]

Do you know what it does? Maybe you figured it out empirically after a second that it is summing the numbers in [1,2,3], which is essentially equivalent to sum [1,2,3]. Although it only took a second, you still need to figure it out. If fold contained a more complex function instead of +, you might not be able to figure it out for a minute. It didn't take much effort to write it, but why do I need to see + and 0 every time I read this code, which have nothing to do with my intention? What if someone accidentally wrote it wrong and there is actually something wrong with + and 0? Why do I need to figure out the relative positions of +, 0, [1,2,3] and their meanings? This way of writing is actually better than writing a recursive function honestly and giving it a meaningful name (such as sum), so that when you see this name being called later, such as sum [1,2,3], you don't have to think about what it does. Defining a name like sum slightly increases the work of writing code, but it makes it easier to read the code. Using fold for the sake of simplicity or coolness actually increases the mental overhead of reading the code. You should know that the code is read many times more often than it is written, so using fold is often not worth the effort. However, people who are brainwashed by functional programming cannot see this. They care too much about showing others that I will use fold too!

Similar to fold, there are other white elephants such as currying and Hindley-Milner type inference. They seem cool, but when you think about it carefully, you will find that they bring more trouble than the problems they solve. Some features claim to solve problems that do not exist at all. Now I will briefly list some features of functional languages ​​and the traps they contain:

1. Fold. Fold and other "recursive templates" are equivalent to inserting recursive function definitions into the calling party without giving them names. This results in the need to understand almost the entire recursive function definition every time you read the code.

2. Currying. It seems cool, but the parameters of the partial call can only be arranged from left to right, in order. How to arrange the order of parameters becomes a problem. Most of the time, it is better to directly create a new lambda and call the old function internally, so that the order of parameters can be arranged arbitrarily.

3. Hindley-Milner type inference. In order to avoid writing the types of parameters and return values, a lot of restrictions are added to the programmer's code writing. In order to make the type inference engine happy, a lot of completely legal, reasonable and elegant code cannot be written. In fact, it is better to ask programmers to write the types of parameters and return values ​​directly. This workload is really not much, and it can accurately help readers understand the range of parameters. The fundamental problem of HM type inference is that it uses the unification algorithm. Unification can actually only express the "equivalence relation" in mathematics, and the most important relation in programming languages, subtyping, is not an equivalence relation because it does not have symmetry.

4. Algebraic data types. The so-called "algebraic data types" are not as universal as ordinary type systems (such as Java). Many algebraic data type systems have the so-called sum type, which actually brings too much type nesting and is not as good as the general union type. People who blindly worship algebraic data types often blindly believe that "mathematics is a beautiful language." But the fact is that mathematics is a language left over from history with many problems. The language of mathematics has not been systematically and globally designed. Often mathematicians just write a symbol on the blackboard and say that this represents XX concept, and then it is finalized.

5. Tuple. In languages ​​with algebraic data types, there is often a construct called Tuple. For example, in Haskell, you can write (1, "hello") to represent a structure of type (Int, String). This construct is often seen as too noble, so that it is used in places beyond its capabilities. In fact, Tuple is a structure without a name (similar to C's structure), and the fields in the structure also have no names. It seems very convenient to use Tuple temporarily because you don't need to define a structure type. However, because Tuple has no name, and the fields inside it cannot be accessed by name, it becomes very troublesome once there is more data inside. Tuple can often only obtain the fields inside through pattern matching. Once you add a new field, all pattern matching codes containing this Tuple need to be changed. Therefore, Tuple can generally only be used when the size does not exceed 3, and you must be sure that no new fields will be added in the future.

6. Lazy evaluation. It seems elegant in mathematics, but it actually has serious logical loops. Because bottom (infinite loop) becomes an element of any type, taking each value may lead to an infinite loop. It also makes the code performance unpredictable because the evaluation is too lazy, so too much work may be done at the last minute, wasting CPU time. Since the evaluation is only done when needed, the computing power of multiple processors cannot be effectively utilized.

7. Tail recursion. Most tail recursions are equivalent to loop statements, but unlike loop statements, they do not have clear intentions. You need to carefully look at the return conditions of each branch of the code to determine whether there is a branch that is tail recursive, and then you can determine that the code is a loop. The loop statement is known to be a loop from the keywords (for, while). Therefore, the tail recursion that is equivalent to a loop is actually best written as a special loop statement. Of course, tail recursion is useful in other situations that are not equivalent to loops. Using loops in this case often requires complex break or continue conditions, making the loop difficult to understand. Therefore, both loops and tail recursion are actually necessary.

Good Mr.

Many people avoid the "functional vs object-oriented" debate, and thus become "good guys". This kind of people unprincipledly believe that any tool that can solve the current problem is a good tool. This is the same person who likes to use shell scripts and likes to toss various Unix tools, because obviously, they can solve his "problem at hand".

However, this trend of thought is extremely harmful, and its harm is actually worse than relying on functional or object-oriented approaches. The unprincipled good guys are busy "solving problems" but cannot clearly see why these problems exist. The so-called problems they see are often due to design errors in existing tools. Because of their "easy-going" attitude, they never think about how to eliminate these problems from the root. They patch up a pile of historical garbage and try to build reliable software systems using poorly designed tools. Of course, the cost is very high. Not only is it laborious, but it may not solve the problem at all.

So whenever someone asks me to talk about "functional vs. object-oriented", I avoid saying "each has its own advantages", because then I will easily be regarded as an unprincipled good guy.

Symbols must simply model the world

As you can see from the above, I am neither a die-hard "functional programmer" nor a die-hard "object-oriented programmer", nor am I a nice guy who likes to say "each has its own advantages". I am a principled critical thinker. I not only see through the essence of various languages, but also see through the unified relationship between them. When I program, I don't see the superficial language and program, but something like a circuit. I see the flow and exchange of data, and I see the bottleneck of efficiency, which has nothing to do with specific languages ​​and paradigms.

In my mind, there is only one concept, which is called "programming", without any additional qualifiers (such as "functional" or "object-oriented"). My teacher Dan Friedman likes to call his field "Programming Languages" for the same reason. Because what we study is not limited to a certain language, nor is it limited to a certain type of language, but all languages. In our eyes, all languages ​​are just a combination of various features. In our eyes, the so-called "new languages" that have appeared recently are unlikely to have any real innovation. We don't like to say "invent a programming language" and don't like to use the word "invention" because no matter how you design a language, almost all the features already exist in existing languages. I prefer to use the word "design" because although a language does not have any new features, it may be more elegant in details.

The most important thing in programming is to make the written symbols able to simply model the actual or imaginary "world". The most important ability of a programmer is to intuitively see the correspondence between symbols and real objects. No matter how cool a language or paradigm looks, if it has to go around in circles to express the model in the programmer's mind, then it is not a good language or paradigm. Some things have "states" that change over time. If you insist on using a "pure functional" language to describe it, of course you will enter a dead end like monad. Not only can you not express this side effect efficiently, but you also make the code more difficult to understand than a procedural language. If you go to the other extreme and must use objects to express the originally pure mathematical functions, then you will also complicate simple problems. Many of Java's so-called design patterns create such problems without solving any problems.

Another problem with modeling is that the model you have in mind is not necessarily perfect, nor does it have to be designed that way. Some people do not have a clear and simple model in mind, and think that certain languages ​​are "useful" because they can model their twisted and complicated models. So you can't tell such people why this language is not good, because obviously this language is useful to them! How to simplify the model has gone beyond the scope of language, so I won't go into details here.

The purpose of designing the Yin language is to enable people to model the world in the simplest and most direct way, and to help them optimize and improve the model itself.