According to Linus Torvalds, C++ is crap.
He says "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." He maybe has seen a tendency of C++ programmers to write sloppy code. I have seen that in many languages, I wouldn't say C++ programmers are lousier than other programmers, but a C++ programmer with 3 years of experience writes code equivalent to a Java programmer with 6 months of experience.
Since most people "retire" from programming between 3 to 9 years since they start programming and move into management, it means that C++ programmers never surpass the ability of a Java coder who has been programming 1.5 years.
He says "In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C." It is very interesting that this is exactly what happened in a project I worked in 1999 at Microsoft: No one was allowed to use C++ features like user defined operators, templates, etc. We were programming in C, but using a C++ compiler. We even didn't use exceptions.
The result was not easy to understand, to stabilize and didn't perform very well, but I think there were other reasons for this.
Also it was very interesting that I managed to add "<<" operators to reduce clutter in the logging facility. At first they didn't like it because it was dog slow. Then I used references (&) and it became faster than the original code. My boss, who originally fought this idea, eventually congratulated me on this one. It was totally unexpected that C++ could do stuff like this, and in my opinion that's pretty lame, because he was working at Microsoft for 14 years back then.
I mean, don't they leave time for developers to learn new tricks? I just worked there for a year and realized that not only you don't have time to learn, you don't have time for anything else. You are not encouraged to learn, and I find that amazing in a company that is supposed to hire only knowledge workers.
how do you think I got that job in the first place? I studied, really read a lot of C++ books, design patterns and even C++ papers. The C++ papers were the really helpful here, because they try to show the result of some research, which may or may not have got good results, and may or may not have been integrated in the compiler you are using. So it makes you think of alternatives. This helps a lot in the recruiting process and I would say the recruiting process is a piece of cake when compared with reading C++ papers and trying to implement those ideas.
Where did I take the time to do that? First, you need to solve problem once and forever, so that you have time to do your stuff. Next, you need to read a lot. Find the material and read it. Next, classify the ideas and implement some of them. Develop prototypes. Rewrite programs using this new techniques so that with fewer lines of code you can achieve the same funcitonality.
Next create abstraction layers that hide the mechanisms. Only let intent to be the interface.
Being an effective C++ programmer takes time. Before working at Microsoft I developed a rule set of about 30 rules that you needed to learn before touching the code. It simply reduced the amount of C++ developers who could work at our group to 3, then 2 then just me. Not very nice. Then I learned about Smalltalk and how all my ideas were already found out and fixed in the language itself. And the humbling thought that it was in 1980, 12 years before I even started to realize about these rules in 1992...
The lesson here is that I think C++ is really crap, but you still can manage to produce simple,, compact and fast code if you follow 30+ simple rules. Which I'm not giving you here because I can manage to make some money from them from time to time and there is a tendency in me to not let go information that was very hard to conquer and that I consider key for every C++ project, but that since I wrote it down and never looked at it again, I forgot. Not completely, but I forgot. In my defense I can say that I haven't programmed in C++ in 7 years and I feel very nice about it, but I'm sure I would get the same information if I program in C++ again (which I expect not to happen).
On the other hand, you can use Smalltalk or Java and you will get those advantages for free in the language itself.
The material
Linus says "C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app."
The problem as explained very concisely by Linus is that you can write code very quickly but when it doesn't compile or when it doesn't do what it is expected to do, you spend hours if not days trying to find out what went wrong. It is a big waste of time and I've seen projects fail because of this.
Also he mentions that the code is coupled. No shit! Of course it is coupled because C and C++ assume that you want to #include your code. Have you ever seen those #ifdef ... #endif to avoid .h be included twice?
Well, that is a language mistake being fixed by the programmer. Now picture a .h with a class. In a class declaration you can put a struct (which is a class) and some inline methods.
Now change an inline method. Oops! You need to recompile a lot of stuff. And compilation of C++ takes 10 times more than compilation of equivalent Java code. Oops!
Make a mistake with pointers here and you will see your progran blow up somewhere else. Not everytime in the same place, mind you. Oops!
Eventually your code and your project becomes unmanageable.
Suscribirse a:
Enviar comentarios (Atom)
3 comentarios:
tell us the 30 tips. please. i'll give you $2.
Well, well, well...
Let's see if I can remember, it's almost 7 years since I don't write C++:
1. Single root hierarchy. This can't be enforced by the compiler and you are out of luck if you are using 3rd party libraries.
2. Select either copy semantics or reference semantics for parameters. Java has shown that reference semantics is better, but automated object destruction in C++ was simpler than using finally.
3. Make all objects clonable (there are some exception like sockets and the like).
4. Use deep copy semantics everytime. Java takes a different approach using shallow copy, and although it is more efficient, it is harder to prove a program to be correct.
5. Hide threads in classes so that you can use pools of threads to do useful work.
6. Return the memory in the functions that allocate it and use tools to detect leaks: http://www.andreasen.org/LeakTracer/
7. Use reference counting for objects that need to remain alive longer.
8. All instance variables should be private and all methods public or protected. Protected instance variables make it hard to preserve the invariant and private methods are a sign that more classes are needed.
9. Each class should have 3 instance variables or less, otherwise the class is taking too much responsibility.
10. Each method should have 3 parameters or less, otherwise it becomes error prone to use. One simple solution is to create classes that gather parameters together. This is the builder pattern.
11. Each class should have at most 10 methods, otherwise it has too much responsibility.
12. The objective of each class should be specified in the class comment. Not 2 classes should have the same objective.
13. All classes should implement equals and hashCode. This is the same as in Java. The reason is obvious.
14. Unit test every class.
15. Run all unit tests with every compilation.
16. Check-in after every significative change.
17. All methods should be 10 lines or less. The natural size of method is either 1 or 3 lines of code.
18. No methods should use global variables.
19. No method should use an if inside a for and vice versa.
20. Hide global variables behind methods, so that they can be redefined.
21. No method should change the value of a parameter. This is hard to do in practice, but it is a very important goal, since it simplifies code a lot.
22. No repeated code. Ever.
23. Instance variables should start with m_.
24. Classes should be easy to use, so that it is impossible to use them in a wrong way. It does not matter if they are hard to write, since classes are writtenn only once but used many times. (this is of course not true if you write big classes that have a lot of dependencies).
25. Abstractions must depedent on abstractions and concrete classes must depend on abstractions.
26. Code that is not been used should be eliminated.
27. Objects must exit the constructor fully constructed.
28. What do you do if a method invoked inside a constructor fails?
29. If new fails, does it raise an exxception or it returns null? Do you check for nulls? Is your code consistent? Do you have written code conventions that every developer is aware in your project and every one follows and rutinary code reviews are performed before every check-in?
30. Are you constantly looking at the code trying to find repetitive defects and informing your developers about the defects found so that they don't do it anymore?
Ok, I just made this list up, because I can't remember it in cold like this.
Although most of the stuff isn't C++ specific, I think it is important for every project anyway.
And besides all of that, doing unit tests reduces the amount of debugging to almost zero WHEN WELL APPLIED!!!
I just worked at a place which I don't want to mention its name in which they wrote unit test BUT NEVER RUN THEM!!!
Needless to say, that is a huge waste of time. My time. Their time is irrelevant, since if you fix that, they will loose their time doing another nonsense.
Being incompetent, but truly incompetent, the kind of incompetence that doesn't even realize how incompetent they are, and working long hours doing trivial stuff that a 6 year old would do in 5 minutes...
Everyone would think (or at least me) that they are going to be replaced by more competent developers, but it turns out that they are not in the mainstream line of business, they are like the accounting department, if they produce more, who cares?
So, incompetence is like a religion. Be in your job from 8 am to 23 pm avery day and in 5 months your brain will become dry and unable to think. Remembering is not thinking.
I can't remember... ;-D
yeah you are right.
c++ was at the best a demo of OO ( a very stupid and early implementation )
the [gains - (missing features + broken stuff)] is a big big negative number.
I'll never use it on something i have control over.
Publicar un comentario