Re: C++ haters: What about performance?
>>If you have performance-critical systems then C++ is a sound choice.<<
Performance is not an excuse for C++'s complexity. Good clean languages can also be compiled to perform very competitively with C++.
Calm yourselves, readers. The Spring 2015 C++ Standards Committee Meeting takes place next week in Lenexa, Kansas. And at that meeting much of the discussion is expected to consider C++ 17, a major revision of the programming language due in 2017. C++ is currently in version 14, which was released last year, but last week C++ …
There are many ambiguities in the existing Standards - C++11 and C++14 - many of which have been reported in the Standard DR's.
Could these be clarified, please?
I understand that, sometimes, condensing a complex concept into Standardese English can be very dificult, and is inherently fraught with problems and/or ambiguities. But clarification of these ambiguities would go a long way in helping C++ compiler front-end developers, such as myself. Many of us - myself included - spend a lot of time trying to divine "what did they mean by this?". Or we need help from a Language Lawyer[tm].
That little line-item in their roadmap is going to present some unresolvable problems - the root cause being that hardware is inherently concurrent, and C++ is inherently sequential. No amount of hacks like threads, templates, or bolt-on frameworks like OpenCL will ever make that fact go away.
It is time to recognize that C++ is a dead branch in the language tree - any further hacks will only make the language even more obtuse.
Ask yourself why hardware engineers are able to design devices with billions of components that all operate in unison in a highly reliable and performant way - it's because they use this old language called VHDL which has concurrency at its roots.
It is time to put these computer 'scientists' out to pasture, recognize that they have failed to capture reality, and start thinking about languages beyond von Neumann, using concurrency from the bottom up. There are cool new tools like Cryptol that can be used to try out ideas that would be impossible in C/C++.
> There are cool new tools like Cryptol that can be used to try out ideas that would be impossible in C/C++.
That sounded interesting, so I had a look - domain-specific languages can be interesting. Ooh, look:
this is implemented on top of CVC4 for solving constraints and guess what CVC4 is implemented in? Yup, C++
I like the C++ I write, I just hate having to understand the C++ other people write. If you pick a limited feature set that does what you and your team wants and stick to it for the most part (re-evaluating as necessary), C++ is great. It's when you start going mad and doing things just because you can and the language supports it that things go terribly, terribly wrong. Even though it's anathema to many, I find just using it as "a better C" is usually the way to go. To be fair though, my projects are usually smaller in nature (<<1 million LOC), developed by a small team, and most of the actual function is firmware written in C/assembler, so I'm not an expert. I do know that Bjarne's book, "The C++ Programming Language," is one of the most infuriating texts on the subject of programming languages ever written. It's hard not to read that and get the impression that Bjarne had aspirations of academia (or maybe even politics), whereas K&R just wanted to get things done.
Couldn't agree more... the best C++ programmers are those who know what parts to leave out.
Templates are quite cool, but they're a fucking disaster in the hands of fools. It's inexcusable that a missing 'const' can lead to pages and pages of compiler errors (I'm looking at you boost)
I used Clang++ to test compile modules on the side for a project for precisely that reason, even though the project itself was ultimately compiled with GCC. Clang gives lovely error messages in color and can parse through all the template crap. Instead of the wall of text indicating errors in header files nested ten deep, it prints the text and line of your own code and is even pretty good at guessing what the actual error is, even indicating where with a little caret (it would spot constness errors for sure). I'm not sure what the most recent versions of GCC do (this was 4.7.x), but Clang saved me massive headaches for that one reason alone. It's an ugly kludge hopping between compilers like that and probably not practical in most organizations, but the way template errors are handled in GCC is intolerable. I think Visual Studio might produce reasonable error messages too, but I haven't used that in a while.
If you judge tools based solely on your personal feelings about a company involved in their development then I pity your employers and co-workers. And, um, also Clang is free (as in beer, so not supporting anyone), and open source under a BSD-like license (forget which, exactly, but it's GPL compatible). It's a reasonably good bit of work, actually, though not without its caveats.
I do hate Objective-C passionately and probably hold a not totally justified prejudice against it, though. So it does go to show that nobody is perfect.
> Bjarne had aspirations of academia (or maybe even politics), whereas K&R just wanted to get things done
And therein lays the rub
C is a language built by engineers for engineers; to get things done
C++ is a langues designed by comp sci profs, for comp sci students; to appeal to an ideology
You know who I mean ... Dijkstra and the reset of the evil language elves.
>>C is a language built by engineers for engineers; to get things done<<
Software development is not engineering. It is abstraction. K&R built C on very limited hardware with very limited compiler technology. We have moved way past that. We don't need the deficiencies of C or C++ any more.
Way before C there was ALGOL and ALGOL is still a far superior language (and the first used for high-level OS development in an OS that still survives and is still the best in the industry).
I said: "Software development is not engineering. It is abstraction."
Moonshine replied: "Well that's killed of 1000,0000+ software engineers in one stroke!"
That's a lot of software developers who are calling themselves 'engineers' falsely. Software development is not engineering. There are some things that can be borrowed from engineering to help run projects, but mostly not - that's what Agile is about (although flawed itself, test-centred development rather than axiomatic development (contracts) for e.g.).
The wish to apply 'engineering' to software development is to give software some 'credence'. But it is false credence. Software needs it's own discipline (what I call AMAR analysis for Abstraction, Manipulation, Axiomatization, Representation - a technique espoused by Tony Hoare in Structured Programming).
Even David Parnas (one of the greatest software people of the 20th century, and a qualified engineer) when he was asked to teach software engineering said he really didn't understand what the term meant and he was sure it was not right.
Software is a fundamentally different entity to hardware. Hardware needs long design cycles and then the design is fixed. Software is what it is because it is not fixed and flexible. That makes it a very different process.
Thus software development is NOT engineering.
Long John Brass: >>You know who I mean ... Dijkstra and the reset of the evil language elves.<<
What a silly thing to say. Your complete ignorance is on display for everyone. The rest of your posts is just the usual platitudes swallowed by the gullible trying to justify their own existence and narrow-minded approach to computing. It is why the profession of programming is in such a mess now.
C++ is a langues designed by comp sci profs, for comp sci students; to appeal to an ideology
By "ideology" i think you mean "methodology". Well... Perish the thought that we should be using the proven OOD methodology to successfully develop increasingly large and complex applications over the last 20 years.
Yes, the best way to deal with C++ is to throw out everything but a small sensible subset of it. The problem with this is, that different people will choose different subsets. This happens with many standards and usually is a sign that the standard is _way_ to complex to be useful.
"At first glance, Stroustrup's suggestions appear to be concerned with ensuring C++ remains relevant to the “cloud-native” application crowd, without losing its soul along the way."
I didn't see *anything* in the presentation that looked remotely cloudy. In fact, the absence of some throwaway sop to appease those with their heads in a cloud was quite refreshing. It was straight down to business with stuff that will make it easier to write large and strongly typed software running on the bare metal.
I'd like to see some new keywords added to help express human concepts. For example:
"consider" - this block is taken into account while the program runs.
"occasionally" - the following block sometimes runs, sometimes not.
"eventually" - the block runs, but not right now.
"tentative" - the block runs but can be reneged upon later if it turned out to be a bad idea.
Anyone have any others?!
for sheer sumptuousness of ways to write unintelligible code.
Sure, you can do even better with Perl, but those folks do it for the pure art of play, and it's in a different dimension of languages (translated, not compiled, meant for the quick fix, natter, natter).
Stroustrop likes to imagine that his book is up there with K & R's.
It is not, it is an opaque mess, his attitude is to talk down to the lowly reader.
Anyone unfortunate enough to have worked with early C++ will know that half the stuff in the book that isn't C JUST DID NOT WORK for years.
Since they finally made most of it work, there has been a never-ending effort to pile on more and more ways to write unreadable code.
People should look at Eiffel:
and read any of Bertrand Meyer's writings:
especially Object-Oriented Software Construction:
Your mastery of software development will improve out of sight.
Of course for functional (reactive) programming you should look at Haskell.
Biting the hand that feeds IT © 1998–2020