GNU Grep and Sed Maintainer Quits: RMS and FSF Harming GNU Project 476
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.
Why does C++ matter? (Score:5, Interesting)
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?
Re:slightly off topic (Score:2, Interesting)
RMS is OK (not perfect, but OK).
For Paolo Bonzini, the grapes, they are sour...
Re:Why does C++ matter? (Score:5, Interesting)
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.
Re:Distaste of C++ (Score:5, Interesting)
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.)
Re:Distaste of C++ (Score:5, Interesting)
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 [yosefk.com].
Re:Distaste of C++ (Score:5, Interesting)
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 [googlecode.com] that significantly hamper the flexibility and power of the language in an attempt to make it more accessible.
Re:Distaste of C++ (Score:4, Interesting)
And for good reason, C++ in kernel space is a recipe for disaster.
I hear this fairly often, but never with any compelling argument behind it. What parts of C++ wouldn't work well for kernel-mode, exactly? How are these specific parts, combined, enough to give a blanket "recipe for disaster" statement?
The one poor argument I've heard is that some C++ features requires runtime support, and people seem to think this runtime support is some user-mode voodoo that is impossible to implement in kernel-mode. Which is complete nonsense.
I've written drivers (albeit for Windows, not Linux), and I'm a bit of a language lawyer when it comes to C++. I can't say I've ever encountered a problem in kernel-mode where I thought C++ wouldn't be able to do the job. And not with some crappy subset of it, either. I mean full-blown, properly-used C++.
Re:grep -p (Score:4, Interesting)
lol AIX who uses that shit
/me raises hand
It's not modern or "sexy", but it is incredibly stable.
Re:Distaste of C++ (Score:4, Interesting)
Re:Distaste of C++ (Score:5, Interesting)
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.
Re:Distaste of C++ (Score:5, Interesting)
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 [yosefk.com].
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.
Re:Distaste of C++ (Score:4, Interesting)
It sounds like you have more experience than myself, but after reading the below article I was of the opinion that C++ in a kernel is not a good idea right now.
C++ for Kernel Mode Drivers: Pros and Cons [microsoft.com]
The advice seems somewhat relevant for platforms other than Windows.
Re:Why does C++ matter? (Score:5, Interesting)
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.
Re:Why does C++ matter? (Score:5, Interesting)
That would not be a very good idea, since certain valid C constructs that are also valid C++ constructs behave differently [wikipedia.org].
Re:slightly off topic (Score:5, Interesting)
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++.
Re:Distaste of C++ (Score:4, Interesting)
When you write C the "right way", you end up basically manually coding, what C++ gives you automatically.
In C++, you still have to do things by hand that other languages give you automatically (and in ways that need not be the case). For example:
The standards committee missed its chance to really make C++ competitive against modern languages with C++11. I suspect they will miss the mark again in C++14, and probably in C++17 as well. Eventually C++ is going to die, because programmers will be less concerned with things like compatibility with the error-prone and incomprehensible programming techniques of the 1970s and more concerned with solving bigger problems and writing reliable code (I seriously doubt that C++ will be a winner in healthcare systems; there is just too much working against C++ there, and too little in its favor).
Re:Horribleness in C++ (Score:4, Interesting)
There's nothing dangerous in throwing from constructors. Of course destructors are a different matter.
Unless the object is being constructed in the global scope, in which case there is nowhere for the catch block to be placed. Or if the object is being constructed as part of the destructor of another object, which would happen if you were using smart pointers and the destructor passed a smart pointer object to some function.
Remember, this is about C++ being a horrible language compared to C.
Fair enough, although for all of the complexity of C++ it does little to solve the problems we see with C (perhaps not more dangling pointers, but not substantially less either).
Ruby is NOT on the "right track". (Score:1, Interesting)
I'm sorry, I find it extremely laughable that you can suggest that "Ruby is on the right track."
Nearly everything about Ruby is wrong. That's why it has such a rotten community surrounding it, and such rotten frameworks and apps (like Rails) built upon it. Pick just about any factor, and Ruby will be doing it the worst way possible.
1) Performance: Ruby's performance is virtually always abysmal, while C++ code generally performs very well. This makes Ruby pretty much unusable for anything serious. When foolish people do try to use it for something serious, they usually end up having to throw far more hardware than should be necessary at it, or have to rewrite their code in a better-performing language.
2) Portability: C++ is far more portable than Ruby. It's also much more convenient to distribute C++'s binaries to end users than it is to have to distribute a Ruby implementation, or have the user try to provide the correct version themselves.
3) Community: The C++ community is made up of some of the best minds there are. These people usually have extensive academic backgrounds, followed by decades of real-world software development experience. They are professionals in every sense of the word. The Ruby community, on the other hand, is absolutely toxic. But that's not surprising, given how many of them are still inexperienced teenagers, and "manchild" is the best way to describe the ones who are older. Oh, the C++ community also welcomes women, and treats them as equals, while the Ruby community has been shown to hold extremely sexist and bigoted attitudes toward women.
4) Maintainability: The features of C++ help with the creation of large-scale software systems, often worked on by thousands of people over many years. C++ software is extremely maintainable compared to Ruby code. Ruby advocates failed ideas like dynamic typing and monkey patching, both of which hurt the maintainability of an application. It's far easier to get up-to-speed with a complex C++ system than it is to do so with even a simple Ruby app.
5) Developer Productivity: C++ has far more robust development tools, including compilers, IDEs and debuggers, than we see available for Ruby. Furthermore, C++'s compiled nature catches many issues early, which makes unit testing and bug fixes far less of an issue than we find when using Ruby.
I think you get the idea. It's clear that C++ is superior to Ruby in essentially every way. In reality, there's no comparison between the two. C++ is the more sensible language to use, even for web development.
Re:Distaste of C++ (Score:5, Interesting)
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.
ESR latest project, a python disaster (Score:3, Interesting)
This reminded me of the latest project of ESR: a system to replace the CIA IRC bot that sends messages to IRC channel when people commits things to repositories. http://www.catb.org/esr/irker/ [catb.org]
He chose to implement it in Python, probably because of distaste for C++.
After several days of trying to use it and running into severe bugs (random crashes, often locks up, doesn't deal well with unstable connections, excessive memory and CPU consumption, data races and general unreliability -- and of course it required latest python and some very svn version of some library dependency, no fun otherwise) I gave up on trying to fix it and rewrote it from scratch in C++ instead.
In two hours I had a working lightweight and extremely robust implementation of the protocol he defined. I followed the project for a while and it seems it kept having major usability issues for weeks, to the point where many people were reporting bugs and contributing hacks to fix them.
All because it was poorly designed and overengineered. The guy actually made the whole thing multi-threaded (with no knowledge of how to synchronize things properly) even though it wasn't needed.
I think one of the bad aspects of that old generation of notorious hackers is that they're not that good, but their name pulls people in.
Software liberation not necessary for open source (Score:1, Interesting)
but this is my account of Richard Stallman's presentation to the Yorktown High School Computer Club [blogspot.com] for anyone who would be interested.
Reading that linked article reminded me - the printer deal that was the cause of him starting this whole thing - it could have been solved w/o an anti-business manifesto demanding that all software be free. All he needed to have done was demand that whenever software changes hands - legally or illegally, the source code must accompany it. He needn't have said squat about re-distribution rights.
After all, a lot of companies did agree that open source, as in making sure that source code always accompanies binaries, is a good idea. As long as they are allowed to restrict distribution to only their paying customers, this is not an anti-business business model. The software vendor sells their software - both binaries and source code - to their customers, and in the license, they explicitly prohibit its redistribution. That way, if the customer needed to customize the thing for their own usage, they could hire their own programmers, dip into the source code, make whatever modifications they need, and use it in-house, w/o threatening the business of the ISV. Or if the ISV goes tits up, the customer can hire their own programmers to maintain that software as long as they need to, rather than be forced to sink cash into a new platform. This is a win-win scenario for both the ISV and customers.
By focusing on the liberation of software, rather than just ensuring that the source accompany the binaries, Stallman screwed a fantastic opportunity here - maybe deliberately, given his Marxist world views. The above idea would preserve the interests of ISVs as well as that of customers, making it truly workable. But by insisting that the ISV can't prevent re-distribution, Stallman made the GPL essentially a poison pill. After all, as it has been demonstrated, there are very few ways to make money on software that is GPLed. All this would also have avoided a gazillion licenses, since most of the variations are due to variations in redistribution clauses.
Open-source, as defined by OSI, has some of the same issues by insisting on the freedom of re-distribution. Since they are not leftist fanatics like Stallman, one would hope that at least they would see it this way, and allow for a total non-free software to get open source endorsements as long as source code accompanied the binaries. That would achieve all the OSI goals of promoting better software, while also earning it the broad based support of the software industry.
Getting back to the FSF, the other issues that they espouse, such as security & privacy, are things they could support, but which are totally separate issues from open source. One could put bots and other spyware into open sourced software as well, and a consumer would still have to know where to look for them to flush them out. Instead, have totally different movements on those other issues.
But given how everyone knows that TINSTAAFL, the 'free-software' or 'software-freedom' concept has to go. Free is a beautiful word, and doesn't deserve to be maligned by the Orwellian language of Stallman and his club.
Re:Horribleness in C++ (Score:4, Interesting)
But for the rest of us, this line adequately demonstrates how little self-awareness Stroustrup brought to the language design process.
Nah, what I read when I see that is, if your going to be writing code for 30-40 years, spending a few to learn the details of an extremely powerful tool will make the remaining much more satisfying.
Of course you should spend a little time getting proficient in some alternatives. You may find that they agree with your more. But, I've been writing C++ code for nearly 20 years now. I've programmed professionally in a few other (non C based), and played around with dozens of others in my spare time. What I find is that for the core of a project I tend to return to C++, and I enjoy that work. Sure there may be significant amounts of code written in other languages (often for the UI) better suited to some particular task, but C++ tends to be the glue binding everything together, if for no other reason that its higher level than C, yet interfaces very cleanly with the C binary calling conventions. It also tends to be a language I can depend on to provide a reasonably efficient solution to any problem I may come across. I find, time and time again, doing work in a "higher" level language, some language feature turns out to be a fatal Achilles heel requiring some really hacky solution (often dropping to C) to solve.
Modern servers, are amazing pieces of hardware, but I don't think a lot of the programmers writing code on them really realize it. When I see a little 4U server pulling down tens of GB/sec of external IO, and pumping millions of transactions a second, I wonder why the management UI (probably written in java) checking the status of a piece of hardware takes 30 seconds to start and lags for a second or two every time I click something. I wonder what it could possibly be doing that pegs out a 3Ghz CPU for longer than it took to boot an apple II GS at 2.5Mhz. I think, hey its running some kind of long self test, but I know that the self test options on buried elsewhere and take even longer...
Re:Eheh, explain Linux vs BSD then (Score:3, Interesting)