C++14: Papers

[Tony]

Growing number?

Yes. Consider that if developers chomping for another language found C++
adequate, then there would be no need for languages such as the three I listed
(Go, Rust, D), and of course I developing a language too and surely others
(individuals and companies) are doing the same. (I'm not yet abandoning C++, but
I hope to). While the D project has been around for ages, Go and Rust are recent
(in programming language time). I've glanced at them and I'll investigate them
in detail (meaning actually using them a little bit) in the future.

 

[Ian Collins]

Yes. Consider that if developers chomping for another language found C++
adequate, then there would be no need for languages such as the three I listed
(Go, Rust, D), and of course I developing a language too and surely others
(individuals and companies) are doing the same. (I'm not yet abandoning C++, but
I hope to). While the D project has been around for ages, Go and Rust are recent
(in programming language time). I've glanced at them and I'll investigate them
in detail (meaning actually using them a little bit) in the future.

New languages come and go. A decade ago java was going to replace C++
and no one would want to employ C++ programmers anymore, the language
was doomed. Two decades ago C++ was going to replace C!

Some new languages have succeed in usurping a previous incumbent of a
particular niche (Python/perl?) or created a new one (JavaScript Ruby
and PHP?). Nothing has yet usurped C and probably nothing current will
usurp C++ because they are used in so many domains. If a language (C++)
that can match or better C in almost every domain can't end C's
dominance, a new language would have to be particularly impressive to
replace C++.

 

[Tony]

Any language which seriously attempts to replace C++

I don't think that is the goal of those developing new languages exactly, though
surely languages which do achieve some level of popularity will bite into C++'s
market share.

should easily
compile and embrace existing C++ code, just as C++ itself did it with C.

The primary problem with C++ is that it is based on C an requires backward
compatibility with it. That would be a fatal design decision. THAT language
already exists: C++! No need to make another one. I think that is what the
problem with D is: it's basically C++ with all its warts (and a few of it's own
thrown in for good measure?). Someone posted that C++ has a seeming lack of any
"philosophy". Well, I think that can be said of D also.

In this way existing projects could be migrated gradually. Nobody will
want to spend a couple of years for porting a million-line application
without having any real confidence in how well the result will work.

I don't worry about the existing codebase (let's just call all that
"spaghetti"), but rather NEW development. If that works out, then people will
begin rewriting code, and even millions of lines of it where it is beneficial.

Some more esoteric and especially troublesome features can be banned,
like C++ did with the old C function declaration syntax.

Well have at it! I think it's the wrong approach, but that doesn't matter. What
matters is that you think it is the RIGHT approach. Go for it.

I just have hard
time to imagine what those features could be, even raw arrays are
extensively used all over the place. Banning trigraphs would not help
much. And one just cannot throw templates out and claim to have something
superior to C++.

In short, it appears that any *successful* successor of C++ would
necessarily be at least as convoluted and complex as C++, and probably
much more as it needs to bring along some real added value.

I think your analysis is way off-base and that is why you conclude as you do.
IOW, you began with a "non-starter" and then ended up nowhere.

 

[Tony]

But if it compiles C++ code, surely it's just going to be C++14, 17, or
96...

The problem with C++ is exactly that back compatibility - some of the
syntax is strange. Yet powerful.

Yes, I noticed he said that too. Confirmation then that Paavo is way off-base.

One of the ideas behind Microsoft's C# was to learn from C++, and make a
cleaner, better language. They've ended up with one that's cleaner,
easier to write - but less powerful. It's undoubtedly not an accident
that it's less portable too.

C# has proven to be a good language (pretty much for Windows) but it has been
conceded that C++ is still the powerhouse. IOW, it was a nice try, but no cigar.
I have tried it out (wrote a program in it and studied the syntax and features a
bit) and found it to not be worth my time since I already am a C++ user. Some of
the rejection, though, was because of the abhorrent .net framework. I can
imagine that if C# was a first language for a programmer, they would probably
find C++ to be inferior (on Windows).

 

[Tony]

What's your point? COBOL is still alive. C++ will still be alive in 30 years.

But in a coma? (Something had to be said about quality vs. quantity).

 

[Tony]

New languages come and go. A decade ago java was going to replace C++
and no one would want to employ C++ programmers anymore, the language
was doomed.

Having had the managers/owners of the consulting company I was working for at
that time asking me if I was going "move to Java, since it is obviously so much
better than C++" was bizarre to for I never saw it as being in the same realm as
C++. A couple of years before that, when I was being interviewed, brokers tried
to suggest to me that VB was the way to go (and it's true that in the GUI-to-
the-database world, VB was useful (but hardly an ENGINEERING TOOL OR SKILL!)).
In-between, it was Delphi (Borland Pascal).

My point is that I don't think that (most) developers think like you said above,
but rather the stupid brokers and managers do. Java found a niche though. I
don't recall if they were ever seriously positioning it as a C++ replacement, as
I had no reason to follow it since I was a C++ developer/engineer already and
had no interest in doing only programming and learning every language and tool
under the sun.

Some new languages have succeed in usurping a previous incumbent of a
particular niche (Python/perl?) or created a new one (JavaScript Ruby
and PHP?). Nothing has yet usurped C and probably nothing current will
usurp C++ because they are used in so many domains. If a language (C++)
that can match or better C in almost every domain can't end C's
dominance, a new language would have to be particularly impressive to
replace C++.

Maybe language projects get to a certain point that they are happy with and find
no need to pursue C++ replacement as a goal because the goals of the languages
are to solve specific problems. Perhaps they didn't want to be language
designers or did not have that skill set as a forte.

 

[Ian Collins]

But in a coma? (Something had to be said about quality vs. quantity).

No, but a very different language to the one we use today. If I were
give some of the C++ code I write now back in the early 90s, I would
wonder what language it was!

 

[Tony]

No, but a very different language to the one we use today.

Then that's not really C++ but just a reuse of the name. It sounds like a
strategy to attempt to "capitalize" on years. It's a common strategy in all
kinds of areas (technical personnel trying to one-up each other based upon their
years in the field, or trade union seniority in a union shop, e.g.). IOW, when
you can win based up capability, tout years of "experience" (or existence or
some similar bullshit).

That said, while you are waiting for the C++ of "thirty years down the road", I
need a solution yesterday, so I'll just have to do it myself.

If I were
give some of the C++ code I write now back in the early 90s, I would
wonder what language it was!

But your level of skill today compared to back then would surely be a stronger
factor than the evolution of the language, yes?

 

[Tony]

Well, this was an answer to your own question, namely if Go or Rust or D
realistically attempt to replace C++ (as proposed by James).

OK. I'd like to hear his thoughts on why he may think that they won't do that to
any significant degree, if he thinks that.

I just tried
to imagine what might mean to "realistically replace C++" and to draw
some logical conclusions from this.

Of course, in the environments in which those languages are being developed,
they have already replaced C++. "replacing C++" is an idea mostly brought from
die-hard C++ users, I think. Defensive posturing or something. Language
developers/development usually arise out of need to solve a particular problem
(and that problem may be something like "C++ is so difficult and expensive to
use, let's invent something else and use it") without a care to "compete with
C++".

Sorry if you don't like the result. I
am not sure I like it either (though I have no problems with C++ being
over-blown or something, if it is too complex for the job at hand I just
use some other tool (typically bash/grep/awk or something like that)).

Languages are tools, to help out with specific jobs, so I find all these
quests for the "best language" a bit silly. Hopefully my conclusion (that
any "replacement" of C++ would be necessarily much more hairy than C++
itself) helps to show how ridiculous this all is.

I think you are thinking about it the wrong way. You are basically saying that
to "replace C++" it "has to be C++". You are being in-the-box paradigmatic.
Maybe the most significant issue with C++ is that it tries to be too broad,
people buy into that, and then have to deal with all the trapping of C++ all of
the time when most times they are not necessary. It's like wanting to be
prepared for the worst all of the time, and that time may never or usually
doesn't arrive. There is going to be another hurricane in Florida. I don't know
when, but I am sure there is going to be. So, better keep the plywood on the
windows all of the time, because it IS going to come.

When I chose C instead of Pascal, even though there was all kinds of push to get
me to learn Pascal, even in college, and then in industry, I chose C because I
didn't want to close any doors on what I could build with the language. I did do
some work in Fortran and Basic too, but ultimately rejected those for C also. In
retrospect, that is not a good strategy when there is a better tool for the job.
That "job" may be the language of choice for 80% of the coding while C++ may be
the niche 20%. Like C is to assembly language! That's probably what I'm after
with my language creation: relegation of C++ to the niche 20% to avoid being
faced with all that heaviness when it is just an unnecessary nuisance. But I
digress.

D is probably too close indeed and does not offer so much added value.

As a first language it stands a better chance than with those already knowing
C++. For me it would not have made the cut even if I didn't already know C++,
because D seems to be so heavily defined by GC. So maybe it's characterizing
trait is GC. That's my perception anyway. You don't have to use the GC, but I
think that lops off a big chunk of the feature set and libraries (?).

What benefits would these be?

Well, money talks. James likes to tout "large scale development" as a stronghold
of C++. I think C++ is in a precarious position with that because I think it
will be easy to deliver projects for less cost using something else. Simple
answer: money.

Rewriting millions of lines is bound to
introduce a lot of new bugs (i.e. additional costs) unless the new
language is really good (an order of magnitude better than anything we
have so far).

That is weaselly: "order of magnitude". It doesn't have to be "10 times
cheaper". Half as much may be fine. 10% may be. Some other project, maybe 1%.
Expense is expense: less is better.

Of course, rewriting a million lines of C++ code in the new language, would
result in some significant number of lines less than that. Less code = less
bugs. Better language constructs = less bugs. Increased developer productivity =
less expense... etc.

I know how to do this. I just don't know how long it's going to take and how
much it is going to cost to build it and prove it. What I DO know is that when
the project is done, the actuals will match the planned, exactly.

 

[Ian Collins]

Then that's not really C++ but just a reuse of the name. It sounds like a
strategy to attempt to "capitalize" on years.

Nope, it's a sign of a living language, not a stagnant one.

But your level of skill today compared to back then would surely be a stronger
factor than the evolution of the language, yes?

Not really. Templates where new and not supported in my first (C-front)
compiler, so there wasn't any of what we know as the standard library.

 

[Tony]

Nope, it's a sign of a living language, not a stagnant one.

"This is the same ax George Washington used to cut down the cherry tree--it sure
is. The handle has been replaced twice, the head just once."

 

[Rui Maciel]

Languages are tools, to help out with specific jobs, so I find all these
quests for the "best language" a bit silly.

Quite true.

Hopefully my conclusion (that
any "replacement" of C++ would be necessarily much more hairy than C++
itself) helps to show how ridiculous this all is.

Not necessarily. To replace a tool, it isn't necessary to outperform it in
all aspects. It is enough that it outperforms only on a set of features
which are deemed relevant.


Rui Maciel

 

[Rui Maciel]

Nope, it's a sign of a living language, not a stagnant one.

That statement doesn't make any sense when applied to programming languages.
C++98 doesn't change, doesn't ceasse to exist, and won't ceasse to be used
in millions of LoC which already have been written, just because C++11 has
been defined. You may start a project with features which relies on
features introduced to the standard with C++11, you may rewrite existing
code to include C++11 features, but once the ISO standards have been
published, that language died the moment it was born. And it stays dead.
And that's how everyone expects it to stay, because that's the whole point
of standardizing a language.


Rui Maciel

 

[Stefan Ram]

But in a coma? (Something had to be said about quality vs. quantity).

»Today's C++ programs will be tomorrow's unmaintainable
legacy code. As [GWS 94] says of C++:

"The seeds of software disasters for decades to
come have already been planted and well fertilised."«

retrieved in 2007 from:
http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index005.htm

 

[Nick Keighley]

you know its possible to engage in technical discussion without
ranting, name calling or ascribing base motives to other participants.

That's silly. C++ is not the standard by which all other languages will be
judged. You keep on propagandizing (apparently so it seems) with this "all of
the expressivity of C++" BS.

so is C++ not very expressive? What do you ascribe its popularity to?
What language is more expressive than (or equally to) C++. Lisp?
Pascal? Ruby?

To me it seems, correct me if I am wrong, that you
are chomping at the bit for any language to dare show it's face so that you can
say "see, yada, yada, this new language does not have all the expressivity that
C++ has".

I don't see him doing that. I simply see him saying that designing a
language with the expressive of C++ and a cleaner syntax would be a
large and difficult undertaking and that when you'd finnished the
world would have moved on. I'm not sure I agree (I think at some point
C++ will be superceded) but I don't think he's obstructing such
attempts.

Can you see how that sounds weaselly?

well yes, but he didn't say that

Are you preaching James? To
whom? Are you trying to hook youngsters on cigarettes knowing that "once a
smoker, always a smoker"? Am I imagining you are doing that or are you doing
that?

you're assuming. You seem a very angry person.

This "expressivity" think you allude to does not seem to me to be a winning
topic for C++. How many years before a programmer can harness "all the
expressivity of C++"?

quite a while. I don't think anyone would argue with that. Though
"Accelerated C++" would make you productive quite quickly.

Is template metaprogramming included in "all the
expressivity of C++"?
sure


Just say yes, because I know you mean that too. It's a
non-starter.

why? Just plonking your opinions down doesn't make it so.

If C++ could fry eggs and make breakfast, you'd throw that in the

"all the expressivity of C++" and then say "see, that new language cannotfry
eggs, as if frying eggs were a compelling feature to have in a programming
language.

now you're being silly

Have I keyed-in on your M.O. James? C'mon, fess up.

you seem to have a strange hatred of C++ and make personnel attacks on
anyone who tries to support it.

 

[Nick Keighley]

Hmm.  I've been using pthreads (or prior to that, SVR4.2MP M-N threads)since
1990.  On multiple unix and linux systems.    That's over two decades
of threaded C++ code.    I'd call that good.





That would be pretty silly, wouldn't it?

As it happens, none of the compilers
that we have available to us at CPOE are C++11, so I couldn't use the language features
anyway, so we'll continue to use pthreads in our code.

I'd argue that C++ is feature-rich enough already for 99.99% of all applications
and the added cruft in C++11 (e.g. lambdas) and the stuff proposed for C++14 are unnececessary
features that complicate the language and make code maintenance more demanding
(actually the introduction of templates in C++ 3.0 was the beginning of the downfall
of C++, in my opinion, which I'll admit is hardly universal).

the places I work there's barely any awareness of C++11. Using boost
is regarded as a bit brave. I'm still explaining CTOR initialiser
lists, auto_ptr and the wonders of RAII to people.

 

[Nick Keighley]

You could make the exact same argument to promote C.

If you want to use C, nobody's stopping you.


And you lost all your credibility with that.

It's precisely templates that make C++ vastly, vastly superior to C and
is single-handedly one of the features that's superior to almost any
other programming languages.

it made the STL possible and the STL is either number 1 or number 2 C+
+ selling point (RAII being the other). STL and RAII seem to be
unmatched by any other language.

 

[Nick Keighley]

C doesn't have explicit support for virtual functions in its core language.

Having said that, if anyone is willing to put in the legwork, function
pointers are all that is needed to simulate virtual functions.

I've done it. Its not as painful as you might think.

 

[woodbrian77]

it made the STL possible and the STL is either number 1 or number 2 C+

+ selling point (RAII being the other). STL and RAII seem to be

unmatched by any other language.

I'm not really sure which is more important, but if
I had to pick one I'd say classes/RAII.

Today we have on line code generation. C++ has the lead
in this area also.

Brian
Ebenezer Enterprises - in G-d we trust.
http://webEbenezer.net

 

[James Kanze]

So do you feel, then, that C++'s primary domain is large-scale
development and that is the litmus test upon which to judge
competitive-with-C++ness? If not, what other criteria is
relevant, in your opinion?

I don't feel anything about it, in particular. I simply
observe. In many cases, there simply isn't any viable
alternative. C++ wins by default. No other language is
actually being used for many types of applications, at least not
to any measurable extent.

You say "actual use", but in the short term, a new language is
going to be behind because of the existing base of C/C++ code
and developers. I think a more strategic approach to thinking
about it is necessary. That is, one should be capable of
assessing the viability of a language offering given what it
is feature-wise and how use of a particular language can be
exploited going forward (aka, "forward-thinking"). By
"feature-wise", I don't mean just thinks like "has move
constructors", but also things like "is simple and elegant".

We can always dream.

Not insignificant is that your "position" (for lack of
a better word that I can't think of right now) seems to lay
down the criteria where C++ CAN compete: big budget software,
where it can be afforded. There's no doubt about it, C++
development is expensive.

I don't have a "position". I simply observe. One of my
observations (based on actual projects): the reason for choosing
C++ is that it is less expensive to develop software in it than
in other languages.

That is an "attack surface": a major, major problem inherent
of C++, in that it is expensive to use.

Compared to what? It's less expensive than Java, for example.
The companies I see choosing C++ are choosing it because the
total development costs are lower than for other languages.

[...]

Superior to inferior existing languages,

It's hard to compare it with something that doesn't exist.
Given that my comparisons are based on experience, and not
someone's pipe dreams.

you mean, and not the languages under development currently
(and perhaps I'm just starting on it today ) and yet to
find success. (I'm not agreeing with you). YOU can say that,
but you have many years of C++ use and knowledge, etc. YOU,
though, are too expensive, and you know it. A better language
would be one that makes you obsolete (I mean the two or three
or more decade learning curve). Yes, YOU can create and
maintain those very complex systems, some (perhaps much) of
the complexity arising from the use of C++, but YOU and others
like you are a small group. That is a problem awaiting
solution. Agree?

People have been trying to make programming languages accessible
to non-professionals for years. The most blatent example is
COBOL (which was designed to look like human language).
Nobody's succeeded yet. It seems a safe bet that no body will
succeed before I retire.

Can C++ even have "modules"?

There was a proposal for them before the committee. The
committee lacked the time to handle it correctly, but I wouldn't
be surprised if it were in the next version of C++.

Doesn't that make it something else?

Originally, C++ didn't have templates nor exceptions. Does
there presence make it something else?

There are probably more differences between C++11 and C++ circa
1988 than there are between C++ circa 1988 and C. On the other
hand... There are even more differences between the latest
Fortran and Fortran IV.

Heck, add GC
and don't you then have D?

Not at all.

[...]

Having separate headers and implementation files were not
considered by Bjarne to be a worthwhile improvement apparently
or there maybe was not enough budget or maybe C++ is Bjarne's
quick-hack gone awry, who knows (Bjarne knows! Time for
another book Bjarne!).

Or maybe he just felt that the C solution was "good enough" at
the time. Not perfect, but certainly better than what Java
offers. And maybe he just felt that adding templates would be
more fun.