GNU Grep and Sed Maintainer Quits: RMS and FSF Harming GNU Project
In a scathing rant posted to a GNU project mailing list, the maintainer of grep and sed announced that he was quitting the GNU project over technical and administrative disagreements. Chief among them: He believes RMS is detrimental to the project by slowing down technical innovation (the example used was RMS's distaste for C++, not exactly a strong point against RMS). Additionally, he noted that the FSF is not doing enough to help GNU "Projects such as gnash are bound to have constant funding problems despite being (and having been for years) in the FSF's list of high priority projects.". Finally: "Attaching the GNU label to one's program has absolutely no
attractiveness anymore. People expect GNU to be as slow as an elephant,
rather than as slick as a gazelle, and perhaps they are right. Projects
such as LLVM achieve a great momentum by building on the slowness of
GNU's decision processes, and companies such as Apple get praise even
if they are only embracing these projects to avoid problems with GPLv3."
The author is quick to note that he has no philosophical disagreements with GNU or the FSF.
True, but those few people who use C++ correctly seem to have learned their lessons with C. I'm thinking of Sam Leffler, I've held up his clean programming in his HylaFAX software as examples of *how* to do C++, instead of merely holding up the numerous examples of how not to do it.
Unfortunately for comparisons, Sam is one of the authors of BSD UNIX. Not NetBSD, OpenBSD, FreeBSD, or invent-yet-another-pointless-license-scheme-BSD. But original BSD. *Brilliant* programmer. Junior programmers should review Sam's code to unlearn the bad lessons taught by people who don't understand how object oriented work should be used.
C++ is a horrible language, and I say this as a professional C++ programmer.
C++ stands alone as the only major programming language with hiding but without memory safety. Strostrup is in denial about this, which prevents fixing the problem.
Templates don't help. Trying to make templates into a compile-time programming environment results in a language that makes Perl look readable. Just because templates are a Turing-complete term-rewriting system doesn't mean you want to use them that way. Papering over the safety issues with templates doesn't help; the mold always seeps through the wallpaper. Usually at system calls that demand raw pointers.
(Somewhere in the 1980s, low-level programming took a wrong turn. We had Pascal, the Modula family, and Ada. Things seemed to be getting better. Then Modula crashed and burned along with DEC, and Ada declined due to its bulk and overly expensive compilers. We all had to go back to C. That we're still stuck there is embarrassing. It's probably the worst major engineering standard since the British buffer-and-chain coupler from 1830 still in wide use.)
If anything, the dislike for C++ from people who use C++ regularly is much deeper than the more casual dislike that C programmers have. C programmers just think C++ is too complex and unnecessary, but C++ programmers find themselves so consumed by their dislike they end up doing things like writing a point-by-point rebuttal to the entire C++ FAQ.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Agreed. There are edge cases in the language where the bolted on features don't work together because the implementation issues weren't fully considered before the feature was adopted, and efficiency is a higher priority that not having exceptional cases in syntax. Since most of the language works with itself you only develop this hatred if you've got experience in other nicer languages with syntax isn't broken in places, or until you've mastered the language and been prevented from using it by its own design. The crux of the problem is two fold: C++ tries to distance itself from implementation details, while accepting implementation details as limitations for language constructs (polymorphism + multiple inheritance + template class + method & operator overloading == uninstantiated functions and indeterminate or uncompilable code) C++11 has addressed some of this, but IMO the language just isn't complete! Furthermore the strain is compounded due to C++ being forced to squeeze the substance of its syntax out of the meager scraps of symbol space left over from the voracious host language, C (without support for which the language would have never seen widespread adoption).
Thus, the hatred graph is like a bathtub curve: It seems irrational to those intermediately knowledgeable about the language, but perfectly sane to many new comers and seasoned veterans of C++. A large amount of adoption is due to ease of code migration from C to C++, as opposed to say, Java, and is thus won on no real merit of the language itself, but by it's martyrdom at the altar of compatibility with C. Many of the C to C++ converts never "move the furniture", so to speak, and thus the missing paneling in the corner or dark stains under the rugs is never known to them.
That said, I still use the language, it has its merits, but never all of its features at once -- That's impossible, unlike with most every other language that exists. This is where the hatred has its roots.
Imagine a great Enchantresses who can open their spell book and can command the full fabric of her reality, then imagine a Powerful C++ Wizard who's book of spells has contradictory elements and seemingly arbitrary restrictions based only on the syntax of the spell definitions, they've each trained a mighty Sorcerer who's now well versed in both arcane books of magic, and its his turn to take on an apprentice. The sorcerer advises against C++ for the most serious of wizardry since more elegant alternatives exist. However, the young apprentice can't fathom why... The simple C++ spells she learned seem to work fine, a natural extension of the C illusionist lessons she learned; Did not re not her object oriented magic of mops and buckets allow cleaning the kitchen floors with any sort of bucket and mop? It's unthinkable that this spell shouldn't be applied to every floor -- NAY -- every surface and abolish cleansing chores forevermore... Soon the Sorcerer arrives to dispel the tangled templated abominations of multi-inherited broom-mop-bucket hybrids so overloaded they're smashing stacks of dishes with their many scrubbing appendages, and overflowing the tower with heaps of infinite buckets.
If anything, the dislike for C++ from people who use C++ regularly is much deeper than the more casual dislike that C programmers have. C programmers just think C++ is too complex and unnecessary, but C++ programmers find themselves so consumed by their dislike they end up doing things like writing a point-by-point rebuttal to the entire C++ FAQ.
I think they're just more vocal. Not everyone hates C++. My job involves writing in C, C++, and C#. I love C++. In my ideal world, I'd have C++ with all the .net libraries (and no, managed C++ isn't that. C# is far preferable to writing in managed C++, as C# is actually a pretty good language and managed C++ doesn't give you any of the cool features of C++ that C# doesn't have).
I find people's arguments against C++ to be quite illogical. For example, one of the reasons I really like the language is because it can do true multiple inheritance. People everywhere will then immediately correct me with, "multiple inheritance is bad, mmk?" Then they'll back up that statement by talking about the diamond problem, and how I should use interfaces. I do use interfaces, but they're not a replacement for multiple inheritance because it's still forcing me to duplicate code when I wouldn't otherwise have to. Besides, the language handles the problem in a reasonable way (the order in which you define the inheritance matters), and, as a programmer, if you're inheriting from two classes that have a method with the same signature, then those methods should be virtual, and you should override the method to do exactly what you want. The diamond problem isn't this beast for which there is no reasonable solution. It's just something you need to be cognizant of when coding.
There's also the people who complain about all the incredibly hard to debug crazy stuff people do with templates. You're really just complaining about bad coding. Templates allow you to build more reusable code than generics, and that's how you should use them. If you're going beyond that just because they're turing complete and you can do more with them, well...you might as well complain about C after looking at last year's winner of the obfuscated C contest.
Warning: Opinions known to be heavily biased.
throw the whole "right tool for the job" bit out the window because one dude doesn't like it?
Imagine a conversation goes like this. (Imagine that this is a shop that does C development right now).
New guy: This project that needs doing. I could do it in C++, I could do it a lot faster than in C.
Old manager guy: If we do it in C++ it means we have to keep C++ capable people on around. Even if you stick around 10 years from now you might be out of practice coding.
New guy: Ok, but if we don't do it in C++ we're probably not going to get it done at all, because we don't have the resources to do it in C at all.
Old manager guy: If it means we lock ourselves into a future of more skills than we have, it's not worth doing, because we can't guarantee being able to support it, and I don't want our name on abandonware.
They'd both be right. And that would be why GNU still doesn't consider itself to have a stable release. If you demand everything be done exactly perfectly you'll never even finish one thing, and if you accept 'good enough' you can easily end up with bits of code clinging to life that you will eventually have to just rewrite.
I just was on a project where one of the other software guys took all of the function names of a MS windows package, and completely rewrote how quite a lot of them behaved (not just implemented the same API differently, he actually completely changed what the functions do), but that was about 10 years ago. Now, to try and update that code and use the new version of the actual MS api we had a nightmare of a time, trying to figure out what he changed, and why was actually really hard and wasted a lot of money. And yet, it meant he had a working piece of software out the door 10 years ago that kept him in business for 10 years.
That would not be a very good idea, since certain valid C constructs that are also valid C++ constructs behave differently.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The comments below seem no more relevant than this "slightly off topic" thread... I find that unfortunate. Of people who have made the world a better place, I list RMS near the top. He's done so in a selfless manner that makes me proud to be human. Sure, I don't agree with him half the time, but if I could trade my life for one where I could do as much good as he's done, yeah... I'd do it. Have you ever heard of Gandhi? Ever read about that flake? He slept (as in sleeping - not sex) naked with young girls to prove to himself he could control his animal impulses. Yet few argue about what Gandhi did for the world. It kills me to hear about people complaining about RMS's views on C++, on which he happens to be mostly right, and even if you disagree this is not naked girl territory. We should acknowledge the outcome of his life's effort: the world runs on free software. Standing ovation for RMS! Imagine how much harder it would be to write awesome code if we didn't have all this free stuff!
That said, RMS both promotes and harms the goals of the free software movement. As the "Cathedral and the Bazaar" pointed out, RMS brings a central control view to free software that is counter to the whole environment that made GNU/Linux awesome. Debian, IMO, epitomizes this flaw. Rather than helping young new programmer share code and ideas, you have to pray to the Debian Gods and hope they take pity on your pitiful new package before it can be share across the Debian universe. Sure, Debian has it's place... deep in the innards of server racks where 99.9% up time is required, but not on a bright young programmer's desktop. If you want to be part of the new innovative group of coders, go learn about programming for Android.
I hope this message can finally be heard by RMS and those most central to the free software movement: we volunteer programmers are sick and tired of dealing with the wall of red tape you've built. Please get out of the way and let us do our thing. But you're right about C++.
Celebrate failure, and then learn from it - Nolan Bushnell