Heh, I was following an innocuous link this morning, and found this little rant by Linus (yes, that linus) about the use of C instead of C++ in git. He could have been channelling me.
[RFC] Convert builin-mailinfo.c to use The Better String Library.
[tags]Rants and Raves, C++[/tags]
Pingback: Skis / Toys / Fun » We need ‘D’ {death to C++}
Sorry, but I like C++ … While one can rant against STL I’m sick and tired of writing C linked lists, trees, etc.,etc.
I’m sorry that you like C++ too Dave.
The problem with C++ isn’t that they tried to solve the problems with C (which are easy to name, and well-documented), but that they chose to do so in such a grotesquely obtuse manner. C has one primary virtue in my book: you can understand what operations are undertaken in each line of code. An assignment is made. A function is called. A value is returned. Two things are added.
In C++, if you read “a = b ;”, you have no way of knowing what operations are actually performed. Is it a deep copy? Shallow? Are constructors or destructors called? You don’t know. Indeed, you can’t know without actually dissecting the code.
C++ “solves” certain problems, but the solution turns out to be worse than the disease.
Opererator overload… it’s both good and bad. I can’t say that I would ever encourage anybody to overload operator= with anything that didn’t follow the intention of assignment.
I’ve written C++ classes that overload “=” to handle reference counting large data blocks. You could argue that that’s not the intention, but the other choice is to start doing .addRef() and .delRef() which effectivly add clutter.
A great paper, which influences many of my language thoughts over the years.
http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
With this in the conclusion:
The elegance-is-efficient rule: A shorter (in terms of lines of code) solution to the same problem will often also run faster than a longer one.
Hence the belief that a “good” C++ library will allow you to write a shorter program, which is hence more efficient.
Hear hear!
I do know a few good C++ programmers, but the sad truth is they’re good because, after repeated scarring and burning, they survived the fire swamp of C++. This leads to a simple question: Is trial by fire a hallmark of a good language?
The problem with C++ isn’t so much the language as it is the programmers. Until recently, most of my experience with C++ has been rewriting other programmers’ bad code in C because it wasn’t portable. In fact, most of my programming career has been refactoring other peoples’ code. I judge all languages that way. Which is why Perl is my least favorite language of all time. There’s no place for “magic” in programming (e.g., magic variables). Operator overloading is like “magic”. There’s no hard-set rule that a = b has to perform some kind of copy operation. It could do something completely different. And that’s bad.
My problem with OOP in general has to do with object design. If you start with crappy objects, you get really crappy code. With procedural C, it’s easy to come in and refactor functions with little impact on the rest of the program.
About a decade ago, I got to explain to folks at Microsoft during a job interview why I still wrote C code. I found myself doing it again a few months ago with Google.
“Sorry, but I like C++ … While one can rant against STL I’m sick and tired of writing C linked lists, trees, etc.,etc.”
Well using plain C and something like http://apr.apache.org/ and you have the few good things that C++ delivered without all the ugly and bad stuff. And for real high-level stuff (like frontends etc.), you are better of with Python and Friends anyway.