Flutterby™! : software idiocies 2007-09-16 21:00:10.207062+00

software idiocies

2007-09-16 21:00:10.207062+00 by Dan Lyke 3 comments

The obvious pull quote from this wonderful Linus Torvalds rant about C++ is:

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. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

But the closer one is:

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.

Link came from Brainwagon where Mark said "Linus is channeling me".

Which brings me to installers on Windows, today's challenge. Why is it so damned hard to say "copy these files to the appropriate place in "Program Files", these to the user's Documents directory as an example, and set up uninstall behavior, and make sure that the supporting frameworks from the systems vendor are installed, either from the distribution media, if available, or from the net"? You'd think that these would be things that'd be specified at the OS in some sort of policy that'd be easy. In Microsoft's case, you'd be wrong.

I have said for years that 1) C++ is a way to try to force people who don't know any better to try to write the kind of C code they should have been writing in the first place and 2) it is a cure worse than the disease.

Mind you, I don't write much of either anymore, because I can work faster in Perl and it seems to suit my temperament. A lot of people assume that means bad code. Actually, a lot of people seem to assume that Perl automatically means bad code. It doesn't. The problem is Perl gives you the leeway to be lazy, and every time you're lazy - unless you have carefully roped it off and said, "I was lazy here, I need to go fix that later" - it will bite you on the ass.

I felt that was true of C as well, the only difference being that it was harder to cut corners in C. But apparently enough people did it that someone felt C++ was necessary.

My ongoing project at this job is gradually removing a hugely arcane class/object structure in our Perl codebase which is far too complex for our needs and which serves only to obscure all useful information about what the code is actually doing. I never met the guy who wrote it, but I bet he was a big secret admirer of C++.

Just want to add that I threw in the Perl comment BEFORE I read the brainwagon page, and especially Eric Wolf's comment. He has a point about "magic" - on the other hand, one man's magic is another man's painkiller. I wasted too many hours of my life worrying about type conversion in C, or trying to make string wrangling invisible enough to be painless. Since nine tenths of what I do in applications falls into one of two general categories:

I urgently need strings that don't have to be handled as arrays of characters, except when they do have to be; I need arrays and hashes that are easily finagled and iterateable in multiple ways; I need reference and indirection without having to think about pointers. If that's "magic," so be it, and Wolf is welcome to waste his time toiling at a lower level than I'm comfortable with.

If, on the other hand, he's just making the point that it's too easy to do something which will be utterly incomprehensible to a programmer two years later (even if the programmer is the same person!) I agree, and that's why we comment code. Furthermore, I would hold that it's easy to do that in C too.

My fallback response about Perl has always been that it's so productive to rewrite stuff in Perl that any maintenance issues are moot. Modularize it, and when it doesn't work throw it away and do it again.

Unfortunately, in C++, people tend to "write for the future" which generally means that they're writing code for problems they don't understand, and you end up with code that's not only evolved what it needs to do, it's got this extra cruft from when people didn't understand the problem to begin with.

I'm not sure I'm ready to go back to C, but I'd go to a C++ without operator overloading or templates that just had a decent virtual dispatch mechanism in a heartbeat, as everything else can be done more sanely with the preprocessor.