www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interesting talk about language design and evolution

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
A somewhat lengthy but very interesting talk about the tradeoffs for
language design and evolution.

[CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and
Future"](https://www.youtube.com/watch?v=_wzc7a3McOs)

In particular the part about direction
https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about tradeoffs
for new features
https://youtu.be/_wzc7a3McOs?t=30m16s.
Sep 23 2016
parent reply Brad Anderson <eco gnuk.net> writes:
On Saturday, 24 September 2016 at 03:39:00 UTC, Martin Nowak 
wrote:

 A somewhat lengthy but very interesting talk about the 
 tradeoffs for language design and evolution.

 [CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, 
 Present and 
 Future"](https://www.youtube.com/watch?v=_wzc7a3McOs)

 In particular the part about direction
 https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about 
 tradeoffs
 for new features
 https://youtu.be/_wzc7a3McOs?t=30m16s.


Relevant is this list of C++17 features (many of which already 
work in popular compilers).

http://stackoverflow.com/a/38060437/216300

I've got to admit, the D side of me is jealous of a few things on 
this list. Structured bindings, init ifs (one of those "why did 
it take so long to come up with this?" ideas), and constructor 
IFTI. Not sure if it's in C++17 yet but the stackless coroutines 
look nice too.

The baby steps toward CTFE are welcome, of course. It appears C++ 
still has a long way to go though.
Sep 24 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2016 11:11 AM, Brad Anderson wrote:

 Relevant is this list of C++17 features

 http://stackoverflow.com/a/38060437/216300



Finally has hex floating point literals!


 (many of which already work in popular
 compilers).


Digital Mars C++ has had hex floating point literals since about 1992. (Didn't 
invent them, they were first proposed by the NCEG (Numerical C Extensions Group 
of which I was a member.)
Sep 24 2016
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/24/2016 02:11 PM, Brad Anderson wrote:

 Relevant is this list of C++17 features (many of which already work in
 popular compilers).

 http://stackoverflow.com/a/38060437/216300

 I've got to admit, the D side of me is jealous of a few things on this
 list. Structured bindings, init ifs (one of those "why did it take so
 long to come up with this?" ideas), and constructor IFTI. Not sure if
 it's in C++17 yet but the stackless coroutines look nice too.

 The baby steps toward CTFE are welcome, of course. It appears C++ still
 has a long way to go though.


Every time I go back and look at it, C++'s evolution just seems more and 
more like "Let's do a poor imitation of D, without really admitting it, 
and without doing the real fundamental cleanups that D did and C++ still 
desperately needs."

All the work that's gone into C++ the past decade...if even half of that 
had been directed into D instead, then years ago they would have already 
been far ahead of where they are now. But they just keep building more 
and more on top their busted foundation.

C++ was already kind of a monster of a language during the period I was 
using it most (late 90's, early 2000's). Instead of improving my opinion 
of it, all of this new stuff from C++11 onward merely makes me even more 
terrified of ever going near it again, because all it does is add more 
cruft when "too much cruft" was already its biggest problem to begin with.

I don't care if the political correctness wind IS blowing against it - I 
*still* think D's biggest strength is that it's "C++ done right". That's 
what drew me to D in the first place, and that's what keeps me here.

About the "if inits": Those do seem take make a lot of sense, I've hit 
cases where it could be used, and I have zero objection to it...but it 
still seems incredibly minor to me, and it just strikes me as "really, 
C++, you have *far* better things to be focusing on then adding yet more 
syntax, just for minor benefit". Like, oh, I don't know, modules maybe? 
Compiling in under a day? And fixing up that goofy ".cpp vs .hpp" system 
where so many people honestly believe it's "implementation vs 
interface", but if you really look at it you find the *genuine* truth of 
"what goes in which file" is really far, FAR more random than that. 
Seriously, last time I used C++, I was amazed: It is INSANE how much of 
a load of BS the conventional wisdom is about header files being 
"interface" - there is a TON of implementation shit that must be in the 
so-called header. May have been true in C (if you ignore macros), but 
definitely not in C++.
Sep 24 2016
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Saturday, 24 September 2016 at 18:11:25 UTC, Brad Anderson 
wrote:

 On Saturday, 24 September 2016 at 03:39:00 UTC, Martin Nowak 
 wrote:

 A somewhat lengthy but very interesting talk about the 
 tradeoffs for language design and evolution.

 [CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, 
 Present and 
 Future"](https://www.youtube.com/watch?v=_wzc7a3McOs)

 In particular the part about direction
 https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about 
 tradeoffs
 for new features
 https://youtu.be/_wzc7a3McOs?t=30m16s.


 Relevant is this list of C++17 features (many of which already 
 work in popular compilers).

 http://stackoverflow.com/a/38060437/216300


Well if you follow the argumentation of the talk, they are not 
relevant, none of them are enabling features, most are syntax 
sugar.


 I've got to admit, the D side of me is jealous of a few things 
 on this list.


Comparing pointless feature lists really isn't that interesting, 
but figuring out how to do relevant features is.


 Structured bindings


Somewhat undecided about this. Better support for multiple return 
values would be nice, but tuple fixes most of the needs.
Kenji's full tuple proposal also included pattern matching, but 
is that more than a functional programming abbreviation of 
if-else?


 init ifs (one of those "why did it take so long to come up with 
 this?" ideas)


We removed those from D, didn't we?


 stackless coroutines look nice too.


They aren't, but they are indeed nice, and we should consider 
some async/await support for D as well. For I/O bound stuff 
Fibers are performant/resource-friendly enough though.
Cheap coroutines can efficiently connect ranges with trees, very 
nice
Sep 24 2016