Linus:c++ is a bad language.

This article was excerpted from http://blog.csdn.net/turingbook/article/details/1775488

C + + is a bad (horrible) language. And because there are a lot of substandard programmers in use to make the situation worse, it is very easy to produce downright rubbish (total and utter crap). To be honest, choosing C is about kicking out C + + programmers. ...... I have come to the conclusion that any programmer who likes to develop projects in C + + rather than C may be the ones I want to kick out of, lest they mess with the projects I'm involved in. C + + can lead to very, very bad design choices. You c + + programmers always come up with the "beautiful" library features such as STL, boost and other downright rubbish, which may be "helpful" to your program, but it can lead to:

--Endless torment when the library doesn't work (don't tell me what the STL, especially the boost is stable and portable, it's all crap, and it's not funny at all)

--inefficient abstract programming model, perhaps two years later you will notice that some of the abstract effect is not good, but all the code has been dependent on its design around the ' beautiful ' object model, if you do not rewrite the application, can not be corrected.

That is, the only way to use good, efficient, system-level, and portable C + + is ultimately to use all the features of C itself. Project restrictions only use C, meaning that the person involved does not make trouble, and also means that there are many programmers who really understand the underlying problem without tossing the idiot "object Model" garbage.

So, I'm sorry, but for the software like Git's main goal of efficiency, C + + 's so-called advantage is just a big mistake. And the exclusion of those who do not see it is a huge plus.

If you want a version control system written in C + +, go play monotone. They did use the "real database", using "nice object-oriented libraries" and "pretty C + + abstractions." But to be honest, all of these design decisions, which are attractive to some computer professionals, ultimately result in a bunch of horrible, hard-to-maintain rubbish.

in fact, git is better than other software configuration management software, and good taste (taste) and C are one of the reasons. to be more specific:

-Simple and clear core data structures, very lean (lean) and ambitious code to manage them, "Simple is better than fancy" This approach works to the extreme.
--consciously not abstract data structures and algorithms, because they are exactly the entire elements of the Git core (whole point).

If you want to use a more fancy language, C + + is definitely the worst choice. If you want real advanced features, then choose to have garbage collection or good system integration, rather than lack of C's simplicity (sparseness) and lack of C's direct and no important concept of high-level binding (high-level bindings to Important concepts) of things.

Word, C + + is in a difficult situation, it does not help to prototype or simple GUI programming enough to be really usable, not C as actively encourage you to use simple and direct language constructs the lean system programming language.

Good taste will never go out of fashion. Comparing C with assembly language means that you lack a minimum concept of what you are talking about (don ' t has a friggin idea). "

string/memory management doesn't really matter. Let's go to the source code (I bet you haven't seen it). This is not an important part, and it is not complicated. The only really important part is the design. Some parts are written in "prototyped language", precisely because they are not core and are slowly replaced by C. C + + has no way to replace shell scripts or Perl code. and C + + has no way to make the real core part better.

C is much better than C + + in many ways (better than C #), including portability, as well as interfaces and low-level support.

You can of course write bad code in any language. However, some languages, especially those with some mental baggage, are very bad in themselves. A novice like you running to point out some absolutely insignificant patch features (which should refer to C + + 's enhanced features) as a language superior argument (which the original author does not like), the fact that it just means that you are full of confused concepts and should be well awakened.

What really matters to git core code is something like this: Writing your own object allocation code to make the memory footprint as small as possible, so that you can efficiently record the flags of millions of objects. This is actually a very optimized parser for many objects in a tree-shaped relationship, because there is no abstraction here. This is definitely at the original memory byte level.

Can these things be written in a language other than C? Of course. But those who think the high-level features of C + + string processing are important must not be written.

In fact, that's what C is good at. It refers not only to the language itself, but also to a necessary mindset (mentality). One of the biggest advantages of c is that it doesn't make you think the program is something high up. It's the latter mindset that makes you obviously biased toward other languages, but in fact from a git perspective, the so-called "top" is just wrong.

Linus:c++ is a bad language.