C++14: Papers

[Tony]

Yeah, how dare they try to add even more utility features to the
language! Who needs things like multithreading or vectorization?
In the good old days we coded directly in asm. Using pencil and paper.

Is there agreement now to how to do multithreaded software? Are the language
constructs in C++ for such adequate to cover all bases? Does C++ embrace just
one paradigm (locking)?

 

[Tony]

What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

Please do the following this weekend: port C++ to some platform (any platform
you wish--pick the easiest if you wish). Then, post here about how portable or
unportable C++ is. Are you still worried more being added to the C++ standard?

 

[Tony]

Are you THE Thomas Richter, author of Windows programming books?

 

[Tony]

One of the reasons often cited for the failure of Algol 60, was the failure
to include I/O in the standard.

No, that wasn't it. The reason was because of its Pascal-like syntax. Any
lexically-scoped programming language not adopting curly braces to designate
scope for blocks and functions is doomed.

 

[Tony]

With the major difference that there doesn't seem to be any new
competition.

Go? Rust? D?

C++ seems to have beat out Ada-95,

Because Ada syntax is Pascal-like (no curly braces) and their encapsulation
constructs are much to confus(ing)/(ed).

and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it.

Go? Rust? D?

If something new does come along, that is to C++
what Python is to Perl,

Go? Rust? D?

I'd jump on it,

Meaning what? That you'd try it? Use it on a project or product? Are you a
programmer or a software developer? Would you sign a non-disclosure agreement?

but I don't see it
happening.

I don't see it NOT happening, but C++ does seem to be clearing-up enough of its
warts to keep it viable for some time to come. Is C++ now too far ahead and it's
too late to play catch-up? Google doesn't think so. Walter Bright doesn't think
so. More so, they don't even think that way. C++ is definitely improving (even
I'm chomping for VC++ to introduce more C++ 11 features).

In the case of C++, the total is simply too large:
in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, C++ will
have added new functionality that are missing in the new
language.

It goes both ways though. Freed from the complexity of C++, the programming
language design space is not limited and that enables what cannot be had in C++,
at least not simply and elegantly. So, given the exact same functionality as in
C++ (not that that is the goal), AND the elusive "simplicity and elegance", the
"only" things C++ has going for it is the existing code base (no small potatoes)
and existing (expensive) programmers. New development not requiring a link to
the existing and the past may indeed be better off with the simple and elegant
offering.

You brought up a very good point: What is called for, C++, or something simple
and elegant? With the growing number of languages positioning themselves as C++
alternatives (at least eventually), is there any doubt that C++'s dominance is
not a matter of "if", but rather of "when"?

 

[Tony]

Actual use. Maybe I'm not looking in the right places, but I
don't see any large scale applications being developed in
Objective-C. It's use seems to be limited to small "apps" for
one particular system.

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?

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".

The fields I know best are network management and investment
banking. In both cases, the engines which actually do the work
are written almost exclusively in C++.

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. That is an "attack surface": a major, major problem
inherent of C++, in that it is expensive to use. This may be somewhat offset by
the availability of libraries, but largely not so because C++ is not amenable to
mixing libraries from multiple developers. Integration of libraries may be more
expensive than reinventing the wheel, and many accomplished developers do
exactly that, but it is definitely not for the faint of heart either. Hence
another major problem.

I don't think C++ can change enough to keep it "good enough". At some point the
gas-guzzler will be a museum piece rather than a daily driver. Cadillac
Escalade? What if people (finally) "get a clue" and figure out that driving all
over the place like little ants is a waste of time and money and is dangerous
(not only accidents, but snipers!)? (I digress).

C++ is superior
for large, stable applications which need to be maintained over
time.

Superior to inferior existing languages, 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?

Now that we have threading, modules and garbage collection are
the two things missing in the language itself.

Can C++ even have "modules"? Doesn't that make it something else? Heck, add GC
and don't you then have D? It's one thing to say C++ will still be here for many
years, but isn't that like the George Washington ax?

Which is
surprising if you realize that both were present and working in
Modula 3, 15 or more years ago. It's not as if the solutions
aren't known.

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!). I wonder what kinds of major faux paus I will make that
won't be readily seen until looking back historically. Bjarne has a valid excuse
(backward compatibility), I on the other hand, do not have such a crutch, for I
am starting with a clean slate--the design space is wide open. (I promise not to
name my language "the james kanze eliminator" . Remember, you said you'd use
it! Then again, you'll be retired by then. ).

 

[Tony]

(I'm not singling-out you by following-up on YOUR posts, but you write things
that make me feel the need to do so. I think this post will shed some light on
that. I think you are either trying to artificially bolster-up the "superiority
of C++" or you don't even realize that you may be doing that.)

All I claim is that there is a large class of applications for
C++ is more or less the only solution.

That could be akin to "self-fulfilling prophecy" or such. Consider, the
"interface" of C++ is so broad, complex, esoteric, that once some large amount
of C++ code is in place it is hard to get away from it, given that the
investment in time and money is so great. Consider a hypothetical successful
application which cost a billion dollars to produce, and then someone creating
the same thing for a fraction of the cost by changing the approach, say, using
another, perhaps *new* language. What's to keep the manager of the the billion
dollar project from getting a pink slip?

Then again, I AM being very hypothetical because there is not that simple and
elegant language you referred to earlier (that you'd try, mind you). I know it
can be had, though, and I know I can make it (really I can). I just don't know
how long it will take to be liked by other people. That is, how long it's going
to take to get to feature-"complete" 1.0 state. I wouldn't want to rush it at
all. I want to get it right before "freezing" features. At some point when the
synthesis is has become relatively flat it could be considered pretty much
"done". It's not like I want to spend the rest of my life creating a language--I
want to build software with it (and I have lots of things I want to build, or
seen built or have built or something)!

Today (and I often
wonder why Ada 95 didn't get more consideration).

Stop wondering: Pascal-like syntax and ugly constructs (one reason). Too
unevolved. Designed by committee to the extreme. Not that Ada to any degree
achieved simplicity or elegance, but there should be some balance between
achieving that in the usage of the language, and its implementation reflecting
that. If a language designer or wannabe language designer does not get that, I
don't see how good result could be forthcoming. I really don't.

This is seeming, to me, to be less and less of a difficult thing to do. I don't
have to do what has already been done with C++. I mean I don't have to invent
THOSE things. I just have to re-implement them (those that make the cut, that
is). That wouldn't be my starting point, but at some juncture I'd list all the
C++ features select the good ones and nix the bad ones. I've done that a lot
already, informally. Sometimes a bad example is the best example!

That doesn't mean that it's the only language, or the best
language for everything. Where I work, we use Excel,
Mathematica, Python and C# as well, not to mention specialized
languages like SQL, or individual choices for local tools (e.g.
I'll often use bash, or even the Bourne shell, with sed and
awk, and the rest for small, quick tools). All of the real work
is done in C++, but there's a lot of "glue" as well.

I'll put that on the list: replace all of those and it's golden.

 

[Tony]

That's really sad; I can only hope your analysis is wrong.

He seems to be using weasel words. You can't win against the weaselly "the
expressivity of C++". I don't know if he's being honest (actually knows what he
means) or if he is purposely stating it so that by his criteria it is impossible
to create or even envision a language "on par with the C++ god". I don't know.

C++ is so obviously a
group effort, with no discernable philosophy, the damned thing just grew and
grew and it is still growing.

I does lack coherence, doesn't it. D tried/is-trying to be something else, but
it suffers from the same "lack of philosophy" you mention. That may be over-
stated, what I just said. If esotericism is the philosophy and if that can be a
philosophy, then I think that has been achieved.

We have ridiculous brevity, '%' means modulo?
Give me a break.

Is there an actually a modulo operator symbol in mathematics?

And that is mixed with monstrously long identifiers in STL
that would be very much at home in COBOL

How about templates at all? Maybe I'm just not evolved enough, but I think I
refuse to succumb to all that and think it is not necessary. Rather than
succumb, I rather envision eliminating the need for all of that (in a new
language).

All that in one language?? . And
in an era in which GUI is THE way to interface with humans, an add on
library is needed to write a real program. Oh, this program is written in
C++ with the whatchamacallit GUI. You three guys leave the room while we
discuss this problem.

I think a language could and can drive innovation in that area, but I don't
think that is possible within the context of C++. It would be all templates
probably! I'm not saying a GUI library cannot be made, many have been. I see
that (many have been made, many more will be made) as a problem to be solved.
(Yeah, yeah, I know there are many who love C++ for the very fact that is has
templates and turing complete to boot. Similarly, the Boost guys love the
preprocessor).

Just pathetic, really. This disgusting piece of crap is the best the human
mind can come up with?

"It is what it is". I wouldn't call it crap. It's useful. I wouldn't call it
*very* useful, but I live in a fantasy world where the NBL (Next Big Language)
already exists. And maybe I don't want that. How will I get paid for all the
years gone by? Maybe I just want the competitive advantage and build software
with it.

 

[Tony]

Java's "cleaner" because it doesn't try to address many of the
issues C++ addresses. It's actually an interesting case: where
C++ has a less than optimal solution to a problem, Java solves
it by pretending that the problem doesn't exist, and banishing
all solutions to it.

Yes, with C++, one can do anything, anywhere, but there is hefty price to be
paid for that. What you just implied is that "one size fits all" is not
appropriate. C++ does try to be that to some degree and then less general
solutions are decidedly better. If you take away all the capabilities of C++
(whatever they are) that make it useful in all the "niche" domains (whatever
they are), maybe that defines the design space from where a language can become
the 80% solution (that is, 80% of projects (whatever that means) and C++ can
then be relegated to the esoteric niches where is is CLEARLY better. Creating
another Frankenstein is not the goal, C++ fills that niche quite nicely. (And of
course D is "bride of Frankenstein" then! )

That said, I can conceive that someone could do no invention/innovation at all,
and just gather the correct parts (features) from existing languages, put them
together correctly, and have a successful language. No one is selecting the
right combination of parts and putting them together correctly and that is why
there is no movement away from C++--there is no reason to move and much reason
to stay (currently). That wouldn't be my approach, but I do think something like
that could be done. I tend to avoid analyzing the existing practice at first, so
as not to be blinded by it. When I encounter a C++ intricacy I that is not
compelling, I avoid it an am happy to know that some day I'll be able to
implement the software properly when that simple and elegant language is
available. As I have been holding my breath for it to arrive for a long time, I
can't wait for it anymore and I guess I'll just have to do it myself!

 

[Tony]

He doesn't really explain what he means by that, but right before that
he writes "I maintain that C++'s type system and semantics are cleaner
than its syntax".

Well he can "maintain" as he pleases, but he's still wrong about that. C++'s
type system gets a grade F from me (and surely others): it's simply an incorrect
answer. That makes C's type system incorrect also. To base a new language on
that is one thing and wouldn't be so bad for an in-house hack, but for it to get
as popular as it did is quite astounding (if not bizarre or even disheartening).

 

[Tony]

]
Or "in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, the new
language would become no more clean, simple or elegant than C++".

There's something to that, but I think it's more: in the time
it would take to design a new language with all of the
expressivity of C++, but clean, simple and elegant, our
understanding of what is required in the language will have
evolved so that the new language would not meet the new
criteria.

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. 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". Can you see how that sounds weaselly? 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?

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++"? Is template metaprogramming included in "all the
expressivity of C++"? Just say yes, because I know you mean that too. It's a
non-starter. 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 cannot fry
eggs, as if frying eggs were a compelling feature to have in a programming
language. Have I keyed-in on your M.O. James? C'mon, fess up.

The reason for C++'s success is certainly not its simplicity or
its elegance.

Really? Ya think? I mean, do ya really, really think so?

The real reason, I'm convinced, is Bjarne's (and
now the committee's) decision to never close a door, even when
it seems only to open to poor programming practice at the time.

I don't think that is it, for it is a single reason. I think it's simply the
lack of anyone's ability or desire to build the better thing. C++ makes no
choices and the also-rans make the wrong choices. What's left is for a language
which makes the right choices. Now when I used "right" in the preceding
sentence, I meant technically superior (or at least, correct!). Maybe your job
security is instead the "right" choice and C++ facilitates that. I don't know. I
know that I want to use the simple and elegant language (that's too confining
but for lack of any better definition of it in this thread, sufficient) so I
know a few others do too and that's good enough reason for me to pursue it (Why
did you climb the mountain, someone asked. "Because it's there", another
replied. In our case, because it's NOT there!).

C is a very good language for defining API's, because it is so
much like a portable assembler.

No, it's because it limits the toolbox that programmers have to work with so
there is much less rework necessary to integrate a C library than a C++ library.
C++ fails at the component level across developers. That it has not a standard
ABI does not help matters either. Integrating C++ libraries brings fragility
because the glue becomes a major engineering challenge and there are a hundred
different avenues of failure based upon the stylistic usages of C++ across
libraries: one is template-centric, another is abstract interfaces, another goes
through great pains to avoid exceptions while another embraces them, etc.

 

[Tony]

That seems a rather odd challenge. You just need to implement a backend
to something like LLVM and you are done. (As a bonus, you have just ported
a bunch of other languages to that platform as well.)

It wasn't a well-thought-out post. There's a point in there somewhere, but not
worth discovering. Something about how complex C++ is and is anything really
achieved if the interface to the big black box is smaller and that big black box
is still a complex and inaccessible to the common programmer. Consider that one
can post something to an open source (read, a million lines of code and
thousands of developers submitting code) project and get the response back that
the bug cannot be fixed because the complexity deep down in the code is such
that know one really knows how it works anymore, it just kinda does usually. I
got that exact response from one of the web browser projects awhile ago. So
that's where I was coming from when I posted that.

 

[Tony]

I recall one of the reasons being performance. Apparently any language
that allocates stack dynamically on entry and exit from local scopes is
doomed to run slowly. :}

Oh yeah, and that too!

 

[Stefan Ram]

I recall one of the reasons being performance. Apparently any language
that allocates stack dynamically on entry and exit from local scopes is
doomed to run slowly. :}

What does »:}« intends to convey here?

 

[osmium]

What does »:}« intends to convey here?

In this case I think it means: "I am cool".

 

[Victor Bazarov]

In this case I think it means: "I am cool".

I thought one ought to use «B)» for that (a "sunglasses-wearing
smiley"). ;-)

V

 

[Rui Maciel]

What does »:}« intends to convey here?

My money is on a Salvador Dalí stare.


Rui Maciel

 

[Stefan Ram]

It was meant to be a twisted smile.

I asked, because I wanted to known whether it was
intended to mark the preceding text as irony or
to modify the meaning of the preceding text in some
other way. (Before I then might write something in
response to this text.)

 

[Tony]

With the growing number of languages positioning themselves as C++
alternatives (at least eventually), is there any doubt that C++'s dominance is
not a matter of "if", but rather of "when"?

That should have been:

With the growing number of languages positioning themselves as C++
alternatives (at least eventually), is there any doubt that THE END of
C++'s dominance is not a matter of "if", but rather of "when"?

 

[Ian Collins]

That should have been:

With the growing number of languages positioning themselves as C++
alternatives (at least eventually), is there any doubt that THE END of
C++'s dominance is not a matter of "if", but rather of "when"?

Growing number?