| |||||||||||||
GNU sed 4.2.2 released; maintainer resignsGNU sed 4.2.2 released; maintainer resignsPosted Dec 23, 2012 16:57 UTC (Sun) by khim (subscriber, #9252)In reply to: GNU sed 4.2.2 released; maintainer resigns by lu_zero Parent article: GNU sed 4.2.2 released; maintainer resigns
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.
(Log in to post comments)
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.
|
|||||||||||||