Slashdot Mirror
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.
the example used was RMS's distaste for C++, not exactly a strong point against RMS
So RMS doesn't like C++ -- this doesn't stop people who can use it properly from writing their projects in it, does it?
Does RMS actually have control over what GNU projects are implemented in? If so, I'd say that's quite a strong point against GNU -- throw the whole "right tool for the job" bit out the window because one dude doesn't like it?
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
What is it with open-source leaders and their irrational hate of C++?
I don't think it's irrational. It's just for different reasons than many individuals may have.
It is perfectly possible for someone extremely competent in C++ to write code that someone else, with an equal level of knowledge and experience, can't make heads or tails of without some serious review time.
And then there's an additional problem that, because C++ is such a complex language, it's possible for people with more experience to write better code that people with less experience simply can't yet understand. And by less experience, I mean someone who understands the problem and the general solution, but only has 5 years of heavy C++ use. This problem of pure language complexity and a huge ramp-up time may not be unique to C++, but it's something C does not really suffer from.
I say this as someone who absolutely loves C++ and uses it daily. I love the complexity. I love to play around with templates to do some micro-optimization that I'd probably never put in live code. But I must say, the idea of being a maintainer -- reviewing and committing a diverse set of patches like Linus has to do -- for a C++ project sounds incredibly daunting for the reasons given above.
Often, this leads to atrocious usage guidelines that significantly hamper the flexibility and power of the language in an attempt to make it more accessible.
On the other hand, it's the only mainstream language I know that supports both very low-level and very high-level programming style. This can be a real plus for compute intense signal processing, were a small minority of the code really requires low-level implementations. Being able to mix that with high-level abstractions (e.g. linear algebra factorizations) can give both efficient and maintanable code.
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.
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
This sort of reasoning is what gets us bloated and slow desktop apps.
No, it's what keeps people from ever getting around to fixing those issues because they're still busy chasing down application crashes and memory leaks, combined with a fear of throwing out bad code in favor of new code with equally severe bugs. Do any kind of profiling and you will see it's all long tail, a few sections of code are called extremely often and the rest rarely if ever during normal operation as they're error handlers and such.
Except that CPU you're wasting is CPU you can't use for other things. It's expensive to build a data center twice as big because your code performs poorly.
More expensive than the time and cost spent developing, maintaining and dealing with the fallout of bugs in your high performance delicate code? And again it's the long tail, you probably have 10% of the software you use taking 90% of the capacity leaving 10% for the other 90%. Even if their execution time doubled you'd need 110% capacity, not 200% capacity. All I'm saying is write your slow code as clean, safe and maintainable as possible and optimize the few things that really matter.
Live today, because you never know what tomorrow brings