brainwagon

Pingback from Skis / Toys / Fun » We need ‘D’ {death to C++}
Time 9/12/2007 at 8:34 am

[…] Friend posted a comment on a rant by linus […]

Comment from David Koblas
Time 9/12/2007 at 9:43 am

Sorry, but I like C++ … While one can rant against STL I’m sick and tired of writing C linked lists, trees, etc.,etc.

Comment from Mark VandeWettering
Time 9/12/2007 at 11:47 am

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.

Comment from David Koblas
Time 9/12/2007 at 8:17 pm

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.

Comment from metamerist
Time 9/13/2007 at 4:46 am

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?

Comment from Eric Wolf
Time 9/16/2007 at 6:55 pm

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.

Comment from anon
Time 12/17/2008 at 9:58 am

“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.