| |||||||||||||
GNU sed 4.2.2 released; maintainer resignsGNU sed 4.2.2 released; maintainer resignsPosted Dec 22, 2012 22:15 UTC (Sat) by aigarius (subscriber, #7329)Parent article: GNU sed 4.2.2 released; maintainer resigns
I might not be involved in the particular processes, but to me both a decision to switch to C++ in GCC and a decision to use JavaScript in GNOME Shell sound like horrible technical choices. If those are the best examples of GNU "failure", then ... more power to them!
(Log in to post comments)
GNU sed 4.2.2 released; maintainer resigns Posted Dec 22, 2012 23:36 UTC (Sat) by HelloWorld (guest, #56129) [Link]
C++ was the only option for GCC to transition to. C is simply not an option nowadays, it doesn't offer the facilities that people want: generic, type-safe, fast algorithms and data structures, at least some help with resource management and perhaps support for OOP abstractions. Add the requirements that the new language must be compatible enough with C for a transition to be feasible and that GCC must ship a frontend for it in order to stay self-hosting, and C++ is pretty much the only choice.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 0:25 UTC (Sun) by udp (guest, #80701) [Link]
Or rather, C doesn't offer the facilities that _GCC_ wanted. C is perfectly fine for many other projects, so saying it's "simply not an option nowadays" is a bit unwarranted.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 3:11 UTC (Sun) by JoeBuck (subscriber, #2330) [Link] If it were up to RMS, GCC never would have been permitted to switch to C++, but RMS doesn't get a veto over technical matters with GCC, only with issues that affect core free software principles (and even those issues can be very sticky).One nice feature of LLVM is that the competition has made it easier to push back against RMS's innate conservatism. His typical reaction to significant proposals has often been something like: this change might be exploitable by the enemies of free software, so let's not do anything but talk about it for a year and a half. Now we can say that if he blocks features that users and developers want and need, everyone will drop GCC and switch to LLVM. He now seems to get this, so it's been easier lately.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 22:27 UTC (Wed) by stevenb (guest, #11536) [Link]
How cynical, that you'd need another, competing project to change RMS's mind. Does he also "get" that by the time it's gotten that far, it may already be too late?
I've contributed to GCC for many years now, but and it's still a complete mystery to me why the EGCS project had to merge back and become GCC. I can't help feeling that EGCS stand-alone, without the "help" of the FSF and RMS, would have been much better off, long term.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 7:54 UTC (Sun) by lu_zero (guest, #72556) [Link]
In all fairness GCC is hindered by the horrible, eye poking GNU coding style.
You can do in C everything you do in C++ and be as terse if not more.
The C++-subset used by Opera, fdk-aac and harfbuzz is a good trade-off for non-system libraries and tools. Yet the system compiler (and incidentally C++ libraries among the rest) should support the most basic language (for bootstrapping) so it could be compiled properly no matter which is the compiler currently available.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 11:31 UTC (Sun) by khim (subscriber, #9252) [Link] You can do in C everything you do in C++ and be as terse if not more. This is kinda pointless argument. I mean: of course! Just embed interpreter of your favorite language and stuff the real program in a string. This being said C++ can be used to improve readability and maintainability. Gold is great example: in cases where you need to support different types similarly yet slightly differently where "real" C program will be forced to use plethora of macro definitions which are not just harder to write and read but which are extremely hard to debug (and yes, both classic ld and gcc suffer from this malady) C++ program just uses templates with partial specialization. The big question is not whether it's possible to use C++ to write more readable and/or maintainable program but specifically if GCC developers will be able to do that: C++ enthusiasts are notoriously hard to keep in check and this is where coding standards are vital. Standards which RMS quite expressly refuses to develop.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 15:08 UTC (Sun) by lu_zero (guest, #72556) [Link]
See my point regarding C++-subset. You are scare of macros and you feel happier with templates (that just suck differently).
Gold is a great example on why clean slate rewrites can work decently w/out the second system syndrome. Yet gold is a really small subset of ld.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 16:57 UTC (Sun) by khim (subscriber, #9252) [Link] See my point regarding C++-subset. Where is said point, pray tell? In the end you can just take Cfront and extend it enough to prove that everything you can do in C++ you can do in C, too—but this is an illusion: yes, that proves that theoretically some kind of superhuman can do in C everything real human can do in C++, but we don't have superhumans here, only humans—and they can do things in C++ which they can not do in C. You are scare of macros and you feel happier with templates (that just suck differently). This has nothing to do with my opinions and everything to do with facts. Templates may be ugly and awkward to use, but they can used by real-world humans to write nice libraries like Eigen. C macros can not be used for this goal: when people try to do that (see ATLAS or FFTW) they usually invent their own macro system to do that. And that's my point: C macros are not suitable for the task if real humans are involved while C++ templates are suitable. Gold is a great example on why clean slate rewrites can work decently w/out the second system syndrome. Yet gold is a really small subset of ld. May be, but it implements everything needed for most used and it's much easier to support because of C++ template system.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 22:33 UTC (Sun) by lu_zero (guest, #72556) [Link]
This long rebuttal seems to explain quite well why most of C++ is wrong.
That said, I never said C is perfect, just that between broken preprocessor and the demented templating system I prefer the broken preprocessor.
Had I a choice I would use a saner preprocessor or/and better tools, e.g. having proper annotations so macros can be tracked decently during debugging and error reporting.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 22:54 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
C++ is broken in the sense that it can't do everything perfectly.
C is broken because you have to do EVERYTHING from scratch. And in 99% of cases you'd do it much worse than in C++.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 9:19 UTC (Mon) by landley (guest, #6789) [Link]
C++ has a fundamental design problem which neither C nor scripting languages share.
C is more or less a portable assembly language, with minimal abstraction between the programmer and what the machine is doing. If you want to know how something is implemented you can dig in and get all the details, even write your own replacement version (uClibc, musl, dietlibc, klibc, newlib...).
Scripting languages like python, ruby, lua, and so on abstract away memory management and type conversions, providing opaque abstractions that you can use without caring how they're implemented. Is a dictionary a hash table or a tree? Is the garbage collector mark and sweep or reference counting? It doesn't matter, it just works. Scripting languages even do away with the source/binary distinction, running the source code directly with no need for makefiles.
C++ provides thick layers of abstraction built on top of manual resource management and static typing, but most of all on top of pointers (instead of references). C++'s abstractions leak implementation details, and C++ advocates blame programmers for "not using the language right". As for the complexity of the build process, templates are literally turing complete at compile time (there's no guarantee a C++ program compilation will ever terminate) and teaching a debugger to name demangle a function pointer to an overloaded member function in a virtual base class is hard enough without bringing cross compiling into it.
This is a fundamental problem: C is a simple language because it has no abstraction, scripting languages are simple by having opaque abstractions that truly hide complexity. C++ provides leaky abstractions that embody enormous complexity but require knowledge of their implementation details down to the hardware to use correctly. Most of the complexity of C programs comes from the program. A significant part of the complexity of C++ programs comes from the language.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 16:38 UTC (Mon) by heijo (guest, #88363) [Link]
The whole point of C++ is to provide the maximum amount of abstraction possible while still allowing to have almost full control of the generated assembly code, memory layout, runtime behavior and performance of your program.
And I think it's absolutely excellent at that, to the point that it is the only language widely used in that niche, while other niches have lots of competing languages.
If you want maximum abstraction and programmer comfort at the cost of not being able to generate arbitrary assembly/memory layout or obtain arbitrary runtime behavior and performance tradeoffs, then C++ is just not the right language to use, and I'd recommend Scala or C# instead.
Note however that in some areas like algorithms, data structures and numerics C++ has FAR better support and abstractions than most (probably all) languages, since for instance in Java and C# you can't do arithmetic with variables with a generic type, and C++ probably has more powerful algorithmic libraries than any other language (STL, Boost, GMP++, LEDA, CGAL, LEMON, etc.).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 21:53 UTC (Tue) by marcH (subscriber, #57642) [Link]
> The whole point of C++ is to provide the maximum amount of abstraction possible while still allowing to have almost full control of the generated assembly code, memory layout, runtime behavior and performance of your program.
If that's not the definition of "kitchen-sink" then I don't know what is. Strong agreement with the previous poster.
> Note however that in some areas like algorithms, data structures and numerics C++ has FAR better support and abstractions than most (probably all) languages, since for instance in Java and C# you can't do arithmetic with variables with a generic type, and C++ probably has more powerful algorithmic libraries than any other language (STL, Boost, GMP++, LEDA, CGAL, LEMON, etc.).
By the way: C++ was born under "C with classes" name. Now here is an excerpt from an fantastic interview with the man behind the C++ STL:
"Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI [...] I find OOP technically unsound...."
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 3:23 UTC (Wed) by artem (subscriber, #51262) [Link]
In my experience, every time I use a library with OO API I have to resort to downcasting or run-time type checking whenever I need to do something non-trivial - often it's the documented and officially recommended way. That's what the man probably meant by 'technically unsound' - looks like his standards of soundness are way above average industry level.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 19:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
C++ has a fundamental advantage - it's the only game in the town for complex code with manually managed resources. It's a complex task and most of C++ problems are a result of this.
There's simply nothing that can replace it. Mostly because any C++ replacement would end up being C++ with a different syntax.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 22:13 UTC (Tue) by marcH (subscriber, #57642) [Link]
> C++ has a fundamental advantage - it's the only game in the town for complex code with manually managed resources. It's a complex task and most of C++ problems are a result of this.
> There's simply nothing that can replace it.
The "ideal replacement" is to use a mix of languages and manually manage resources ONLY where required: in the critical path. The right tool for each job. In this respect big C++ programs are premature optimization.
It's unfortunately not always practical. For instance JNI is horrible. Fading memories of ocamlmklib look better. How is Python.h ?
Of course it's not just a technical problem: programmers fluent in several (and very different!) languages are hard to find. Teamwork to the rescue?
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 0:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
The problem is - that approach fails very fast. Especially with complex software that needs to do something different from processing text files using pipes.
For example, look at Mesa3D or GIMP.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 15:46 UTC (Wed) by marcH (subscriber, #57642) [Link]
Thanks for the examples.
I had a 2 minutes look at a tutorial explaining how to write a GIMP plugin in Python and saw nothing wrong with it. It even looked cool. When and how does this fail?
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 16:37 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Yup. I knew you'd say this. How about writing the bulk of GIMP itself in Python?
We actually have an example of this - it's called 'Blender'. If you look inside it then you'll see quite a lot of horror when their developers simply had to do some cross-layer hacks to achieve tolerable performance. Because even as a thin glue layer Python is not fast enough.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 16:57 UTC (Wed) by marcH (subscriber, #57642) [Link]
> For instance JNI is horrible.
... which is OK since it is seldom required.
Apologies for stating the obvious: plain Java (no JNI) is actually one decent answer to C++. Other and unrelated sins aside, Java's abstraction level sits in a very sweet spot. Just far enough from the hardware to avoid tedious and error-prone and insecure coding. Equipped with enough abstractions to enable programming at large.
I suspect .NET is at the very same point in the spectrum.
Interesting that these two are immensely successful in "enterprise" applications and very little on the desktop.
http://arstechnica.com/features/2012/10/windows-8-and-win...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 17:16 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> Interesting that these two are immensely successful in "enterprise" applications and very little on the desktop.
COBOL was also immensely successful in "enterprise" applications
being successful in that market does not equate to being a great language
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 18:34 UTC (Wed) by marcH (subscriber, #57642) [Link]
Please find a counter-example that is less than 50 years old...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 19:06 UTC (Wed) by hummassa (subscriber, #307) [Link]
This whole discussion is quite silly, and the C++-bashing people on it are acting the silliest...
There is no perfect language. There are lots of languages and development environments, and to each problem there is a proper solution. And the solution depends on external factors (where I work today there are many corporate apps written in Delphi7; why? because we have a lot of tenured developers that are fluent in it, so Delphi7 it is.)
Of course C++ is not a perfect language. Personally, having more than ten years of experience developing and maintaining sofware on both C++ and Java, I tend to prefer some aspects of C++ (especially the algorithmic libraries, STL, boost and others), and I suffer with Java's latencies, XMLims, and endless repetitions of the same thing when I need its nice multitiered web development tools.
For graphical apps, C++ (with your preferred UI toolkit -- mine is Qt) is excellent, I'm sorry, no need to have a multilanguage team. And, having supervised a multilanguage team, I can say one thing to you: a monolanguage team (of the same size/capable of writing the same app) is cheaper, because of the interface between languages, where things WILL get problematic...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 0:12 UTC (Thu) by marcH (subscriber, #57642) [Link]
> This whole discussion is quite silly, and the C++-bashing people on it are acting the silliest...
You are really too kind spending time reading it nevertheless and - even better - enlightening it with your post. Thank you so much.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 1:55 UTC (Thu) by hummassa (subscriber, #307) [Link]
You are so welcome!
Yes, I know what sarcasm is and I can even detect it more than 75% of the time!!
Seriously, my "enlightening" comment had one of the following intents:
1. To show off how old I am and that I am here since the dawn or time, or the invention of C++ by Stroustroup, whichever came first (hint: NOT); or
2. To try to break up a language war when there are no two languages really competing.
My point, if in the last post it didn't come across is that there is no competition for C++. There is no competition for Java (ok, maybe clojure :-D). There is no competition for Python, Perl and definitively no competition for my fellow countrymen's Lua.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 19:07 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
how about the widespread use of Windows?
In Enterprise Programming, the prior fad was C++. Different languages have different strong points, but just because they are used a lot by some group doesn't mean that they are great languages overall.
in a different field, mortgage backed securities
or as your mother probably put it "If all your friends were to jump off a bridge, would you do so as well"
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 0:08 UTC (Thu) by marcH (subscriber, #57642) [Link]
> in a different field, mortgage backed securities
Anything even more distant and off-topic?
> In Enterprise Programming, the prior fad was C++
... and it got replaced for some reason(s) [excellent point]
> "If all your friends were to jump off a bridge, would you do so as well"
This can explain to some extend why C++ got replaced by _only a few_ competitors but it's not enough to explain why C++ lost the throne. You don't get fired for buying the same as everyone else but you do get fired for wasting time and money throwing away for no clear benefit older technology that do the job. Many CEOs and CFOs could not care less about technology - even less technology fads.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 28, 2012 12:34 UTC (Fri) by khim (subscriber, #9252) [Link] how about the widespread use of Windows? Thanks for the reminder. In Enterprise Programming, the prior fad was C++. Absolutely not. The prior fad was called Visual Basic (by some estimates half of the “programmers” in circa 2000 were Visual Basic programmers. And before that it was xBase (dBase, Clipper, etc). The fact that enterprise programming graduated to some [relatively] modern and sane language is kind of astonishing, but it just shows that “enterprise programmers” are improving. “Enterprise programming” is not about good code. It's as in the following dialogue: Chode: Ok, they might have been slightly used. Chode talks about saving big on the “dutritium rods” and “enterprise programming” is about saving big on the software engineers but the principle stays: it's about something barely functioning but “even cheaper then “cheap, cheap, cheap””. Enterprise programming do advance over time: remember that it started with “ADD b TO c GIVING a” because “a = b + c” was considered too cumbersome for these “cheap, cheap, cheap” programmers. If you'll view evolution of “enterprise programming” from this POV then Java is indeed the pinnacle of said evolution: you can finally easily construct anything you want in the “enterprise language” (you don't need these expensive C++ programmers to create “components” now! yay!) and language even tries to detect and report most problems—what's not to like? As usual, the fact that some language is widely used by “enterprise programmers” probably means that is's too inefficient to use for the projects where people actually know what they are doing, but, gasp, it's finally language which you can actually use to create [somewhat] efficient programs! Finally, after all these years!
GNU sed 4.2.2 released; maintainer resigns Posted Dec 28, 2012 21:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, Java is exactly "ADD 1 TO COBOL GIVING COBOL". The same in Java is: java.setValue(java.getValue()+1).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 29, 2012 1:15 UTC (Sat) by hummassa (subscriber, #307) [Link]
C++
That's why I don't understand how can people can find it ugly. :-D
GNU sed 4.2.2 released; maintainer resigns Posted Dec 29, 2012 1:39 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
This is a good writeup.
Along similar lines, many of these same managers see DevOps as a way to eliminate those expensive *nix admins (I've heard many people use this as an excuse for using Windows, even in non-profit orgs with *nix people volunteering)
and many such managers are embracing the "cloud" because it again lets them eliminate expensive admins, and in addition the expensive facilities people
One world Posted Dec 29, 2012 11:51 UTC (Sat) by man_ls (subscriber, #15091) [Link] I cannot possibly see how replacing the expensive sysadmin with a very expensive developer is a good move. Keep in mind that your average coding monkey will not know a thing about DevOps.I see value in having a homogeneous set of workers which can both work on development and administration; in fact that is how I prefer to work. Having two worlds where one side hurls undeployable code to the poor sysadmin side creates unnecessary barriers; while deploying your own code is good, and also makes sure that deployment is simple enough. Same goes for cloud deployments. Commercial cloud services are really expensive compared with buying and maintaining your own servers, even when you factor sysadmin salaries. What they give is flexibility, and the ability to play around without waiting for decades to get hardware. Sysadmin people, it's time to sharpen your development skills. And viceversa. We are one world once again.
One world Posted Dec 29, 2012 17:33 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> I cannot possibly see how replacing the expensive sysadmin with a very expensive developer is a good move. Keep in mind that your average coding monkey will not know a thing about DevOps.
Ahh, you just don't "get it", developers actually produce something, as a result, their expense can be justified.
But Sysadmins are just overhead, eliminating pure overhead is good, and DevOps promises to make things easier and faster by letting the developers do whatever they want. (this is not what DevOps is supposed to be, but this is what managers hear it to be)
> Having two worlds where one side hurls undeployable code to the poor sysadmin side creates unnecessary barriers
I agree with this, but I don't agree that every developer and sysadmin should be equally skilled in both specialities. They need to understand enough of the other's tasks to respect them, and to appriciate the expertise that they bring to the table.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 29, 2012 11:45 UTC (Sat) by marcH (subscriber, #57642) [Link]
> you can finally easily construct anything you want in the “enterprise language” (you don't need these expensive C++ programmers to create “components” now! yay!) and language even tries to detect and report most problems—what's not to like?
Yes. Massively reducing the amount of rope the programming masses used to be given to hang themselves with: definitely a major progress for the human kind. Really don't care if this requires double or triple more hardware to run since that's much cheaper than education.
As the experienced C++ developer you seem to present yourself as you should be happy because I think a rising tide lift all boats - even the C++ boat. I mean, even while C++ (or any other expert language) is losing market *share* there will still be increased demand for them if the overall market is growing fast.
[OT] my language is better than yours Posted Dec 27, 2012 8:58 UTC (Thu) by oldtomas (guest, #72579) [Link]
> Please find a counter-example that is less than 50 years old...
Microsoft Visual Basic for Applications?
(Sorry. I was to weak to stay out of this language flamefest. I tried, I tried).
[OT] my language is better than yours Posted Dec 27, 2012 12:43 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Microsoft Visual Basic for Applications?
A more relevant example indeed.
Not a great language but infinitely better (and especially: safer) than C++ in the hands of Joe the 8-to-5 enterprise software developer.
Both recently displaced by Java and .NET languages as explained in this brilliant, on-topic and highly recommended article:
> (Sorry. I was to weak to stay out of this language flamefest. I tried, I tried).
It looks like any complex computing technology is bound to make computer "scientists" emotional and irrational. Maybe because of the enormous brain investment they require?
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 12:22 UTC (Thu) by vonbrand (subscriber, #4458) [Link] COBOL is a great language for its intended purpose (frobbing sequential files to generate voluminous, complex printouts). The world changed around it, there is little use for that in today's environment. (Yes, I did get turned off by it at first sight too, but you have to look into the more advanced language features like the REPORT WRITER and such to really "get it".)
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 20:09 UTC (Mon) by khim (subscriber, #9252) [Link] Scripting languages like python, ruby, lua, and so on abstract away memory management and type conversions, providing opaque abstractions that you can use without caring how they're implemented. This is only true if you don't care about the ability to actually use said program or when all the inputs are non-hostile. That's why scripting languages are good for software development and awful for anything else. Is a dictionary a hash table or a tree? …say you to yourself and happily use them everywhere. Ten days after release your service is killed by a well-crafted attack and you suddenly need to urgently redo everything while your company is rapidly losing money. Is the garbage collector mark and sweep or reference counting? You may not care till your circular structures fill all the memory (if that's reference counting GC and you “don't know and don't care about that”) or, alternatively, till all your backends are tied by the uncollected “Connection” objects and your site no longer accessible. It doesn't matter, it just works. …till it does not. Sorry, but all the scripting languages are unbelievably leaky. Most of the complexity of C programs comes from the program. A significant part of the complexity of C++ programs comes from the language. This is true for most higher-level languages, not just for C++. And C++ is, in fact, one of the best ones. In my own practice it's much easier to tame C++ compiler rather then JVM's histrionics (and let's not even try to talk about Python). With C++ quite often you find out that code which should compile for some reason refuses do to so, or sometimes it does something strange, but rarely code does what you need in tests but falls apart under real load while “great” scripting languages tend to behave this way regularly.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 23:09 UTC (Thu) by marcH (subscriber, #57642) [Link]
> > Is a dictionary hash table or a tree?
> …say you to yourself and happily use them everywhere. Ten days after release your service is killed by a well-crafted attack [link to Python hash collision security issue] and you suddenly need to urgently redo everything [huh, why "everything"?!]
Are you seriously saying that you'd rather deal with the gazillion of security and obfuscation issues that every junior/average engineer in your team routinely leaves in your product (since most of them don't understand C++), as opposed to simply patching a successful, massively used, open source and well maintained external component?
At least for this example you must have been kidding.
landley, stop hitting the Turing complete strawman Posted Dec 27, 2012 2:04 UTC (Thu) by jwakely (subscriber, #60262) [Link]
> As for the complexity of the build process, templates are literally turing complete at compile time (there's no guarantee a C++ program compilation will ever terminate)
Oh noes, how will I ever stop the compiler from consuming all the computing resources in the universe and turning the Earth to grey goo?
Oh wait, Ctrl-C. Or it will just hit an instantiation limit, or memory limit.
Has this ever been a problem for anyone? If not why do you keep making this stupid argument? (http://lwn.net/Articles/504751/ for the last time I know of.)
> and teaching a debugger to name demangle a function pointer to an overloaded member function in a virtual base class is hard enough without bringing cross compiling into it.
How often do you need to do that and can't use existing demangler code?
landley, stop hitting the Turing complete strawman Posted Dec 27, 2012 8:50 UTC (Thu) by khim (subscriber, #9252) [Link] Oh wait, Ctrl-C. Or it will just hit an instantiation limit, or memory limit. The fact that we can not classify all the programs is not a big deal, the fact that often C++ programs are very slow to compile is. Not only C++ templates are Turing complete language, they are extremely inefficient Turing complete language. Still, as Cyberax rightfully pointed out: C++ is the only game in town for what it does, so we are stuck with it.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 28, 2012 0:09 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> See my point regarding C++-subset. You are scare of macros and you feel happier with templates (that just suck differently).
In what universe? The preprocessor has all the drawbacks of templates (poor error messages, potential for code bloat and misuse) and a lot more.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 13:25 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> You can do in C everything you do in C++ and be as terse if not more.
No you can't, please stop spreading this kind of nonsense.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 15:02 UTC (Sun) by lu_zero (guest, #72556) [Link]
Absolutely you do
We can continue saying "yes you can, no you cannot" till you try to provide an example.
Between C (and its dreadful macro system bound to cause aberrations) and C++ (and its horrible template system bound to spawn horribly verbose code as hard to track, if weren't for clang error reporting mitigating it) you have a
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 23:22 UTC (Sun) by robert_s (subscriber, #42402) [Link]
"code as hard to track"
What do you mean "hard to track"? At least templated code is fully interactive-debuggable - good luck trying to use debugging tools on code than heavily uses macros.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 12:03 UTC (Wed) by lu_zero (guest, #72556) [Link]
gcc annotates macro and let you track them in gdb up to a point. That's something I'd love to see improved surely.
clang let you delve in template nests a lot better than gcc and that makes it a really useful tool on the other hand
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 23:27 UTC (Sun) by daglwn (subscriber, #65432) [Link]
You cannot do RAII in C. End of story.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 23:36 UTC (Sun) by walters (subscriber, #7396) [Link]
You can in GNU C:
http://codingrelic.geekhold.com/2009/01/variable-scoping-...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 8:15 UTC (Mon) by khim (subscriber, #9252) [Link] If you have GCC then you have C++, too. The lu_zero's fit of hysteria is related to the fact that you may have only some other, quite limited and deficient compiler instead. Which probably means that not only GCC extensions are not permittable but that ANSI C is "too new" and K&R C should be supported forever. I think that since it's exclusively his problem (most other guys do a bootstrap using some other platform with full-blown GCC nowadays not a vendor-provided compiler) he can support any compiler he wants in said state, but it's not a good enough reason to make life for everyone else miserable.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 12:06 UTC (Wed) by lu_zero (guest, #72556) [Link]
Would be _nice_ to stick to the standards and have standards improve.
The great thing about gcc is/was the fact you can get a good compiler to replace the shoddy one you had or that is just there.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 20:02 UTC (Wed) by daglwn (subscriber, #65432) [Link]
1. That is not C.
2. That does not cover all cases.
One must have proper exception handling as well as destructor-like routines.
talloc as an RAII alternatives in C Posted Dec 24, 2012 8:35 UTC (Mon) by scottt (subscriber, #5028) [Link] > You cannot do RAII in C. End of story.Apache and Samba manage resource handles through apr_pool_t and talloc and they fair pretty well despite being written in C.
talloc as an RAII alternatives in C Posted Dec 24, 2012 19:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. They don't have RAII, they have refcounted pools. It's about the best you can do in plain C.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 22:31 UTC (Mon) by paulj (subscriber, #341) [Link]
You can do RAII in C, you just need explicit scaffolding to setup the context that will destroy the objects. E.g. you can lift the destruction out of the code doing the work, by using a wrapping function that holds the state and cleans up after the "work" function - explicitly doing something equivalent to what a C++ compiler would do.
We've been in a thread on this before, which was also interesting: http://lwn.net/Articles/424527/
If you define RAII as requiring destruction to be tied into the scope in the language, then yes C doesn't have it. If you mean something more abstract, then you can implement it in C just fine. You have to implement it yourself then, of course, rather than let the C++ compiler do the work, but it's still possible, AFAICT. Surely?
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 0:18 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, yeah. You can do pretty much anything in C (except non-sjlj exceptions which require true compiler support), but you have to do it manually.
And that's the point - doing things manually is error-prone and code-bloating.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 12:47 UTC (Tue) by paulj (subscriber, #341) [Link]
Having to create your own infrastructure - doing it manually - doesn't of course mean you have to do it manually from scratch at every point. You can re-use your infrastructure of course. It will take a little more typing than "}" though, sure. That needn't mean it's more error-prone though, imho.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 21:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Everything that is not automatic is error-prone. Especially in rarely-tested code paths.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 20:17 UTC (Wed) by lu_zero (guest, #72556) [Link]
Everything is error prone then.
One of the issues I do have with C++ is that you must use a really strict subset (defeating the whole purpose of having such large standard library) in order to be reasonably sure your code will build and behave as you expect across different compiler/libstdc++ implementations.
And that because C++ is so complex and hard to implement that you have lots of interesting pitfalls.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 20:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Not everything, only the stuff that humans do directly.
> One of the issues I do have with C++ is that you must use a really strict subset
> (defeating the whole purpose of having such large standard library) in order to be reasonably sure your code will build and behave as you expect across different compiler/libstdc++ implementations.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 16:53 UTC (Thu) by bronson (subscriber, #4806) [Link]
> ... you must use a really strict subset in order to be reasonably sure your code will build and behave as you expect across different compiler/libstdc++ implementations.
To be fair, this is true of libc too. "Always use glibc" dodges the problem (and not very successfully since glibc has so many obscure, dark corners).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 20:03 UTC (Wed) by daglwn (subscriber, #65432) [Link]
> If you define RAII as requiring destruction to be tied into the scope in
> the language, then yes C doesn't have it.
Well of course that's what I mean! That is the whole point.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 7:49 UTC (Sun) by lu_zero (guest, #72556) [Link]
The switch to C++ will make me move to clang since then GCC would not have any practical advantage in bootstrapping new systems.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 15:23 UTC (Sun) by stevenb (guest, #11536) [Link]
Right, because bootstrapping is something most of us do every day. Twice.
Oh, wait...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 22:35 UTC (Sun) by lu_zero (guest, #72556) [Link]
Some do that as part of their job...
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 18:05 UTC (Mon) by heijo (guest, #88363) [Link]
Ever heard of cross compilation?
This idea that you need to support bad compiler is bullshit, just use your x86-64 g++ to compile an x86-64 to $bootstrap g++, then use the latter to compile a native $bootstrap g++.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 10:49 UTC (Wed) by CopperWing (guest, #82856) [Link]
The GCC switch to C++ changes completely nothing in terms of system bootstrap. Zero lines of code must be changed anywhere because of that.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 10:40 UTC (Wed) by CopperWing (guest, #82856) [Link]
So you leave GCC because of its switch to C++, to embrace llvm and clang which are completely written in C++ as well? Does not make sense at all.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 12:11 UTC (Wed) by lu_zero (guest, #72556) [Link]
You use the tool that works better, bootstrapping a system clang isn't exactly impossible (see FreeBSD) yet has some pitfalls. Bootstrapping gcc as system compiler and libstdc++ is/was more straightforward.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 13:40 UTC (Wed) by CopperWing (guest, #82856) [Link]
I was not complaining about your choice, just found quite contradictory the reason you gave for it.
I build quite often the arm-linux-gnueabi GCC cross-compiler and a Linux root file system for my work, and after the switch to C++ I didn't find any issue in doing that. It's neither more nor less straightforward than before, just the same.
Conversely if you plan to rebuild the Linux kernel with llvm/clang, be prepared to get some headaches. Last time I checked, some components still needed to be recompiled with GCC and the resulting kernel was not at all stable.
So, for real work on Linux, GCC is still the only choice. Until someone volunteers to improve the situation (FreeBSD with clang didn't came exactly for free).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 23, 2012 4:32 UTC (Sun) by ovitters (subscriber, #27950) [Link]
Suggest to read the email again. He listed other reasons.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 3:53 UTC (Mon) by dberlin (subscriber, #24694) [Link]
Do you contribute to GCC?
The reality is that the inability to sanely represent concepts in C cleanly was a huge maintenance burden.
Yes, you can make OOP like stuff in C.
But you only have to look at GCC to see what happens you do your best to simulate C++ concepts in C.
Yes, it's possible. Heck, I spent almost a year creating a sane structure hierarchy for the tree structures using the first member rule.
Compared to real classes and overloading, it's a joke.
But hey, rather than argue this point with me, you should just go and prove everyone wrong. Make GCC sane to maintain. Show us all how it's done. If you do that, i'll happily say you were right. Because a lot of smart people thought very hard about how to make GCC easier to maintain, and they are the ones that moved it to C++.
FWIW, so far they have been right.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 4:20 UTC (Mon) by cmccabe (guest, #60281) [Link]
I haven't contributed to gcc, except by bug reports.
However, I have worked with many C and C++ projects. In my experience, you CAN represent objects very cleanly in C-- the kernel is a good example. C++ has its advantages for certain applications, but it's far from a cure-all. It's kind of funny that on "Linux weekly news" people haven't read the opinions of the creator of Linux about C++.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 7:46 UTC (Mon) by boudewijn (subscriber, #14185) [Link]
I have read those opinions, and dismissed them as more of the bigoted nonsense that Linus is apt to spout when he feels like flaming off a bit.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 24, 2012 15:05 UTC (Mon) by dberlin (subscriber, #24694) [Link]
Of course i've read it, but what does that have to do with anything.
The kernel is not exactly the bastion of clean maintainable code, despite Linus's opinions.
Nobody complaining about C++ has yet come onto the GCC mailing list and explained, in clear concrete terms with examples, how they could make GCC more maintainable using C than it would be using C++.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 22:41 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> However, I have worked with many C and C++ projects. In my experience, you CAN represent objects very cleanly in C-- the kernel is a good example.
I disagree, the typical implementation of objects with vtables etc. is ugly in C, and manual implementations of advanced concepts like multiple and virtual inheritance are hard to use and maintain. C++ also has a lot more to offer than OOP (esp. templates).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 1:14 UTC (Wed) by ramon_garcia (subscriber, #67060) [Link]
Freedom and responsability is the right way to manage projects.
GNU should let maintainers be free to manage their projects, with very limited constraints. And judge the results, only the results. This is why GNU is killing its developers.
|
|||||||||||||