Is C language dead? Original text and "refuelling" and "refuelling '"

Recently, a piece of "C language is dead, five reasons to forget it" has aroused a heated discussion before the beginning, and "refuelling" and "refuelling" have emerged one after another. The following are three parts: Article Original:

C language is dead, five reasons to forget it

 

Now, there are a lot of C/C ++ProgramEmployees are always pretentious and look down on other developers. In fact, others may look down on him more!

I was also fascinated by C/C ++ in the age of students, but today I have never been able to write impeccable C ++.CodeSo I always think that I will not C/C ++. Over the years, I have been searching for the best mode to write c ++ code. However, to be honest, I have never seen any good C ++ programmer or the code written by very good. C/C ++ code is always ugly and has bugs!

I have been programming in C language for more than 20 years. I have written C language compilers, C language debugger, other languages developed with C, games, client programs, and server programs! I have never written any more. And my bookshelves are filled with K & R and Steele books. I know the C language too well, but I hate him. Very annoying!

When I read a blog titled "Why should every programmer learn C language ?" I am really goose bumps. If you are a professional programmer, you must think this is a big joke, although the author's intention may not be like this. This refuted article is a bit interesting, but still does not grasp the essence. So I expanded it. There are five reasons to explain why programmers who use C language should not only use other languages, but also forget the annoying things they are learning C language.

1. Memory Allocation

I can write a whole article about this. Maybe I can write a book, or even write so much content that can be filled with library technical books. Memory Allocation and storage unit allocation are indeed very troublesome. You need to allocate too little memory, or allocate too much memory to waste. The question here is: How to initialize it to zero? Or simply don't initialize it. However, the initial step is to release the memory. All the existing toolkit will help you confirm whether you have released the memory allocated for each bit, whether you will never use it after the release, and will stop you, never release it twice. What's more, memory allocation and memory release are both slow and slow in the C language. When using memory allocation, I really don't want to think about the special situations that need to be considered. As long as the problem (object) size is appropriate, I prefer stack space or pre-allocated structural space. If I do this, I will have more troubles. Again, the man who invented the spam should have won the Nobel Prize.

2. Multithreading

I used to like C language, really. Until I start to develop and maintain multi-threaded servers with C. In terms of protecting data for conflicting threads, the C language does not provide programmers with a little help. Every intuition and experience you gain when using a single thread is wrong when using multiple threads. At least Java has memory for keywords indicating synchronization and proof files (but a strange file), but even so, unless you use the new javax. concurrent, otherwise it will only crash in front of the massive parallel machines. Return to the C language: in a simulated production environment, debug a deadlock in the data center for a week (this has actually happened ). Java only needs Ctrl + break! Oh, my God !!!

3. pointer

Pointers are too difficult to control, so they are too sinister. I don't even have a way to describe them. Every year, I spend several months debugging strange pointer problems every year. I used to try to get all the secrets, such as unintelligible constructor, Consortium and offset, reuse the last two tags, and all the other tricks. But I find that this is not worthwhile at all. Static references in other languages can be solved.

4. Premature Optimization

Speaking of tricks, have you ever wasted brain cells to study whether * P ++ is faster than P [I? Have you ever spent time trying to make some changes to replace multiplication, or try to make the inversion in the loop run faster? Still worried about the speed of passing a parameter and adding a structure against it, and the speed of passing it? Stop!AlgorithmIt is the key to speed. The programmer's level determines which algorithms he will use. Knowing this can make your program better, faster, and reduce your head's muscles. Well, there are some examples that can be done in this way ...... No, you just need to stop doing that!

5. Test

Which of the following is your favorite unit test tool for C? Well... I cannot think of one? Unit Testing is definitely not important at all, right? It may be too troublesome, difficult to keep up with the progress, and a waste of time. You can use this time to make it take up only 1% of the work time, which is more appropriate. Or in the data center, debug the problem caused by only 100 simultaneous online users through optimized unlabeled images.

I should have said some more reasons, but five are enough now; now I feel better. C used to be great... That was in 1984. Today, I was pleasantly surprised by the new code written in C... If you make me compare, I think C ++ is just a little better than C. If you want to learn some older languages, try forth, Lis, or APL. These old-fashioned languages can at least teach you how to think about your programs in different and elegant ways.

A simple explanation and a biased argument: "C language is dead"

 

Nowadays, many C/C ++ programmers are always arrogant and look down upon other developers. In fact, others may look down on him more!

> The biased one is always an individual, not a group. The author adds the following sentence to prove that it is not the C/C ++ programmer who is biased, but himself.

I was also fascinated by C/C ++ in the age of students, but today, I have never been able to write impeccable C ++ code, so I always think that I will not C/C ++. Over the years, I have been searching for the best mode to write c ++ code. However, to be honest, I have never seen any good C ++ programmer or the code written by very good. C/C ++ code is always ugly and has bugs!

> This paragraph is even more ridiculous. Have you ever seen good C/C ++ code? The C ++ standard library (STL) is so elegant. What's more, there are so many classic C/C ++ open-source files and the Windows NT core source code that is inadvertently leaked, which is not a peerless task? I am very sorry for the author.

I have been programming in C language for more than 20 years. I have written C language compilers, C language debugger, other languages developed with C, games, client programs, and server programs! I have never written any more. And my bookshelves are filled with K & R and Steele books. I know the C language too well, but I hate him. Very annoying!

When I read a blog titled "Why should every programmer learn C language? ", I really have goose bumps. If you are a professional programmer, you must think this is a big joke, although the author's intention may not be like this. This refuted article is a bit interesting, but still does not grasp the essence. So I expanded it. There are five reasons to explain why programmers who use C language should not only use other languages, but also forget the annoying things they are learning C language.

1. Memory Allocation

I can write a whole article about this. Maybe I can write a book, or even write so much content that can be filled with library technical books. Memory Allocation and storage unit allocation are indeed very troublesome. You need to allocate too little memory, or allocate too much memory to waste. The question here is: How to initialize it to zero? Or simply don't initialize it. However, the initial step is to release the memory. All the existing toolkit will help you confirm whether you have released the memory allocated for each bit, whether you will never use it after the release, and will stop you, never release it twice. What's more, memory allocation and memory release are both slow and slow in the C language. When using memory allocation, I really don't want to think about the special situations that need to be considered. As long as the problem (object) size is appropriate, I prefer stack space or pre-allocated structural space. If I do this, I will have more troubles. Again, the man who invented the spam should have won the Nobel Prize.

> Memory management is the most classic topic in programming. GC is undoubtedly a great change in memory management, but I just think of it as a solution for memory management, rather than the only solution. More elegant solutions than GC are not necessarily available. I prefer to select a suitable memory management solution under specific circumstances, instead of having no choice, which is just the greatness of C/C ++. All GC languages (such as Java and C #) impose this solution on programmers, which reduces the burden on programmers to a certain extent, but it also limits the initiative of programmers. "Allocating memory and releasing memory are slow in C Language "? I do not know where the author draws the conclusion.

2. Multithreading

I used to like C language, really. Until I start to develop and maintain multi-threaded servers with C. In terms of protecting data for conflicting threads, the C language does not provide programmers with a little help. Every intuition and experience you gain when using a single thread is wrong when using multiple threads. At least Java has memory for keywords indicating synchronization and proof files (but a strange file), but even so, unless you use the new javax. concurrent, otherwise it will only crash in front of the massive parallel machines. Return to the C language: in a simulated production environment, debug a deadlock in the data center for a week (this has actually happened ). Java only needs Ctrl + break! Oh, my God !!!

> The C/C ++ language does not have much support for multithead, which is expected to change after C ++ 0x is released. However, remember that C/C ++ always tends to use mature libraries to solve the problem.

3. pointer

Pointers are too difficult to control, so they are too sinister. I don't even have a way to describe them. Every year, I spend several months debugging strange pointer problems every year. I used to try to get all the secrets, such as unintelligible constructor, Consortium and offset, reuse the last two tags, and all the other tricks. But I find that this is not worthwhile at all. Static references in other languages can be solved.

> Pointer is a reflection of the flexibility of C/C ++. Code with pointers can be ugly but elegant. -- There is no difference in the language used for this. I believe that you can write elegant Java code, and write the same elegant C/C ++ code. Otherwise, it is not necessary (because some C ++ paradigms are not supported by Java ). There are too many choices in C/C ++, which is indeed confusing, but not necessarily a disadvantage. My advice to C/C ++ programmers is to learn more about and use the C ++ standard library, rather than getting too entangled in pointer-related details.

4. Premature Optimization

Speaking of tricks, have you ever wasted brain cells to study whether * P ++ is faster than P [I? Have you ever spent time trying to make some changes to replace multiplication, or try to make the inversion in the loop run faster? Still worried about the speed of passing a parameter and adding a structure against it, and the speed of passing it? Stop! Algorithms are the key to speed. The programmer's level determines which algorithms he will use. Knowing this can make your program better, faster, and reduce your head's muscles. Well, there are some examples that can be done in this way ...... No, you just need to stop doing that!

> Algorithm optimization is the key to program design. But in general, programmers in all languages (including C/C ++) study the optimization of key paths. Is * P ++ faster than P [I? I believe this is something that should be considered by the implementers of the standard library. The difference is that C/C ++ programmers can consider these details like the authors of the standard library, and programmers in other languages are deprived of this right.

When it comes to optimization, there will be more topics. I have inserted 0.1 billion integers (read from more than 10 thousand text files) into the dictionary of C #, and found that the program is still not completed all afternoon. I switched to C ++'s STD: map, and it took 20 minutes. Try sorting 0.5 million custom struct data records again. I believe that, like you and me, you will enjoy the efficiency and elegance of C ++.

5. Test

Which of the following is your favorite unit test tool for C? Well... I cannot think of one? Unit Testing is definitely not important at all, right? It may be too troublesome, difficult to keep up with the progress, and a waste of time. You can use this time to make it take up only 1% of the work time, which is more appropriate. Or in the data center, debug the problem caused by only 100 simultaneous online users through optimized unlabeled images.

> The author did not even think of the C ++ testing tool. I can only guess that he prefers to make wheels on his own. Can't you think of cppunit corresponding to JUnit? Speaking of cppunit, I used it for unit testing, but in terms of implementation architecture, I Think It inherits the bloated Java code. I provide a mini version of cppunit in winx. The Code volume is about several hundred lines, and the function is no weaker than cppunit. (For more information about winx, see here ).

I should have said some more reasons, but five are enough now; now I feel better. C used to be great... That was in 1984. Today, I was pleasantly surprised by the new code written in C... If you make me compare, I think C ++ is just a little better than C. If you want to learn some older languages, try forth, list, or APL. These old-fashioned languages can at least teach you how to think about your programs in different and elegant ways.

> New languages must be improved on the basis of absorbing old languages. Looking at the vitality of a language doesn't mean looking at its shortcomings. Things will develop and tend to improve. I believe that after C ++ 0x is released, the C/C ++ language will gain new vitality. Looking at several new generations of languages such as Java and C #, with so many c ++ brands, it proves that the impact of C/C ++ is huge. It is a simple language.

It's not a prejudice. It's also a barrier to say that 'C language is dead '"

 

> The biased one is always an individual, not a group. The author adds the following sentence to prove that it is not the C/C ++ programmer who is biased, but himself.

Wrong, truth is on the side of a few people. When a change will happen, prejudice is often caused by the masses being a traditional force.

> This paragraph is even more ridiculous. Have you ever seen good C/C ++ code? The C ++ standard library (STL) is so elegant. What's more, there are so many classic C/C ++ open-source files and the Windows NT core source code that is inadvertently leaked, which is not a peerless task? I am very sorry for the author.

The STL code is not elegant, and the lack of C ++ supported by the functional programming mechanism is very far-fetched for implementing algorithm. For example, I want to find (v. begin (), V. end (), compare); (V is a custom structure), I must write a comparison function outside the function, if you want to include some context, you have to write a functor class, which is ugly and has a low practicality. For FP systems, it is natural to write an anonymous function. The concepts such as containers and algorithms advertised in STL have long been supported by native FP and require elegance. As for the NT code, I have never heard of it, but it is said that there are many complaints about bugs and design mistakes left by programmers in the code.

> Memory management is the most classic topic in programming. GC is undoubtedly a great change in memory management, but I just think of it as a solution for memory management, rather than the only solution. More elegant solutions than GC are not necessarily available. I prefer to select a suitable memory management solution under specific circumstances, instead of having no choice, which is just the greatness of C/C ++. All GC languages (such as Java and C #) impose this solution on programmers, which reduces the burden on programmers to a certain extent, but it also limits the initiative of programmers. "Allocating memory and releasing memory are slow in C Language "? I do not know where the author draws the conclusion.

To be honest, I do not like GC either. C without GC can work well, but it cannot work correctly without GC for FP languages, so I still have to accept GC. Of course, I prefer the method of combining the two.

> The C/C ++ language does not have much support for multithead, which is expected to change after C ++ 0x is released. However, remember that C/C ++ always tends to use mature libraries to solve the problem.

C/C ++ cannot adapt to the future development of the multi-core era, which is the biggest reason for its decline. Libraries cannot really solve the problem. What we need is further language development.

> Pointer is a reflection of the flexibility of C/C ++. Code with pointers can be ugly but elegant. -- There is no difference in the language used for this. I believe that you can write elegant Java code, and write the same elegant C/C ++ code. Otherwise, it is not necessary (because some C ++ paradigms are not supported by Java ). There are too many choices in C/C ++, which is indeed confusing, but not necessarily a disadvantage. My advice to C/C ++ programmers is to learn more about and use the C ++ standard library, rather than getting too entangled in pointer-related details.

> Algorithm optimization is the key to program design. But in general, programmers in all languages (including C/C ++) study the optimization of key paths. Is * P ++ faster than P [I? I believe this is something that should be considered by the implementers of the standard library. The difference is that C/C ++ programmers can consider these details like the authors of the standard library, and programmers in other languages are deprived of this right.

When it comes to optimization, there will be more topics. I have inserted 0.1 billion integers (read from more than 10 thousand text files) into the dictionary of C #, and found that the program is still not completed all afternoon. I switched to C ++'s STD: map, and it took 20 minutes. Try sorting 0.5 million custom struct data records again. I believe that, like you and me, you will enjoy the efficiency and elegance of C ++.

Many years ago, programmers still inline assembly in the C program to achieve code-level optimization, but no one has done so now, because the CPU is getting more and more complex, in most cases, compilers do better than manual ones. Today's Java/. net jit engine has been able to reach a very high level of optimization, and the advantages of C code in performance have become increasingly less obvious. In the future, code-level optimization will no longer be the focus. Whoever can adapt to multi-core development will become the leader in performance.

> New languages must be improved on the basis of absorbing old languages. Looking at the vitality of a language doesn't mean looking at its shortcomings. Things will develop and tend to improve. I believe that after C ++ 0x is released, the C/C ++ language will gain new vitality. Looking at several new generations of languages such as Java and C #, with so many c ++ brands, it proves that the impact of C/C ++ is huge. It is a simple language.

If a language is dead, it does not mean that it completely disappears. Instead, it is withdrawn from the mainstream development languages and is gradually marginalized. Over the years, fewer and fewer people advocate C/C ++, in many development fields, C/C ++ has been used by Java ,.. net, script language, and so on. C ++ 0x is no longer important, but the emergence of C ++/CLI brings some new ideas to C ++. However, although I really appreciate C ++/CLI, but it will not become the mainstream. At the time of multi-core arrivalProgramming LanguageWe are not ready yet. In the future, we will not be faced with a 2-core, 4-core, but-core scale. This will not only continue to develop in the algorithm field, programming languages also need a major change to adapt to this development. Where is the direction, the FP language may bring you some inspiration.