www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ launched its community survey, too

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei
Feb 27 2018
next sibling parent Andrea Fontana <nospam example.com> writes:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


... and D is listed as an alternative.
Feb 27 2018
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


I have submitted, already. My major complaints boils down to the 
fact that they refuse to deprecated features due to religious 
like devotions to backwards compatibility support.
Feb 27 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 27, 2018 at 05:33:52PM +0000, 12345swordy via Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
 
 Andrei


 
 I have submitted, already. My major complaints boils down to the fact
 that they refuse to deprecated features due to religious like
 devotions to backwards compatibility support.


And just about every new dmd release, people fume on this forum about
regressions and gratuitous code breakages.


T

-- 
It only takes one twig to burn down a forest.
Feb 27 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:

 And just about every new dmd release, people fume on this forum 
 about regressions and gratuitous code breakages.


Not all deprecations/code breakages are *regressions* and 
*gratuitous*.

You just need to do a cost/benefit look at it. For C++ though, 
supporting decades of very widespread use is doing to adjust the 
cost calculus of a change relative to D, of course.
Feb 27 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 27, 2018 at 05:46:58PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:

 And just about every new dmd release, people fume on this forum
 about regressions and gratuitous code breakages.


 
 Not all deprecations/code breakages are *regressions* and
 *gratuitous*.
 
 You just need to do a cost/benefit look at it. For C++ though,
 supporting decades of very widespread use is doing to adjust the cost
 calculus of a change relative to D, of course.


Of course.  The amount of code breakage caused by a new release of dmd
is surely less than the amount of code breakage that would be caused by
an implementation of a new backward-incompatible C++ standard.  That's
why it's not going to happen.

Well, OK, there *have* been backward-incompatible changes in the C++
standard (I experienced some myself just these past 2 weeks while
updating an old C++98 project of mine... which was also motivation for
ditching C++ completely and migrating the whole codebase to D).  But
you're not going to see the sort of fundamental change that will fix
some of the longstanding inherent design problems with C++, because that
would mean alienating the majority of existing C++ projects out there.
Even if the C++ committee went ahead with such a revision, it will
surely not fly: nobody will want to implement it.

We saw a similar situation, though on a smaller scale, with the whole
D1/D2 Tango vs. Phobos fiasco. Even today that scar still persists in
outsiders' perception of D, despite all our efforts to bury that ugly
past.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win
are idiots.
Feb 27 2018
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 27 February 2018 at 18:42:20 UTC, H. S. Teoh wrote:

 [snip]
 Well, OK, there *have* been backward-incompatible changes in 
 the C++ standard (I experienced some myself just these past 2 
 weeks while updating an old C++98 project of mine... which was 
 also motivation for ditching C++ completely and migrating the 
 whole codebase to D).  But you're not going to see the sort of 
 fundamental change that will fix some of the longstanding 
 inherent design problems with C++, because that would mean 
 alienating the majority of existing C++ projects out there. 
 Even if the C++ committee went ahead with such a revision, it 
 will surely not fly: nobody will want to implement it.


The economic way of thinking is to consider whether the marginal 
benefit of a breaking change on all future code and whether that 
would exceed the marginal cost of a breaking change requiring old 
projects to be re-written. As most of us recognize, if the amount 
of old code that needs to be re-written is large and the cost of 
re-writing it is high, then it would overwhelm any changes of 
little benefit. Thus, I'm not sure this resistance to 
backward-incompatible changes is something all that specific to 
C++. I would guess that if D were as popular as C++, then the 
rational thing to do would be to be slow moving and be very 
careful about making costly breaking changes.
Feb 27 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 27 February 2018 at 19:01:57 UTC, jmh530 wrote:

 

 The economic way of thinking is to consider whether the 
 marginal benefit of a breaking change on all future code and 
 whether that would exceed the marginal cost of a breaking 
 change requiring old projects to be re-written. As most of us 
 recognize, if the amount of old code that needs to be 
 re-written is large and the cost of re-writing it is high, then 
 it would overwhelm any changes of little benefit. Thus, I'm not 
 sure this resistance to backward-incompatible changes is 
 something all that specific to C++. I would guess that if D 
 were as popular as C++, then the rational thing to do would be 
 to be slow moving and be very careful about making costly 
 breaking changes.


"The economic way of thinking is to consider whether the marginal 
benefit of a breaking change on all future code would exceed the 
marginal cost of a breaking change requiring old projects to be 
re-written."
Feb 27 2018
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 27 February 2018 at 17:46:58 UTC, Adam D. Ruppe wrote:

 On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:

 And just about every new dmd release, people fume on this 
 forum about regressions and gratuitous code breakages.


 Not all deprecations/code breakages are *regressions* and 
 *gratuitous*.

 You just need to do a cost/benefit look at it. For C++ though, 
 supporting decades of very widespread use is doing to adjust 
 the cost calculus of a change relative to D, of course.


+1
Feb 27 2018
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:

 On Tue, Feb 27, 2018 at 05:33:52PM +0000, 12345swordy via 
 Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
 
 Andrei


 
 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


 And just about every new dmd release, people fume on this forum 
 about regressions and gratuitous code breakages.


 T


Which doesn't bother me at the slightest as there are reasonable 
trade offs for this.
Feb 27 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2018 9:41 AM, H. S. Teoh wrote:

 And just about every new dmd release, people fume on this forum about
 regressions and gratuitous code breakages.


On Tuesday, sure.

Then on Wednesday the same people propose breaking changes :-)

Everybody wants it both ways, including me.
Feb 27 2018
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


You're not the only one who thinks so -

https://www.youtube.com/watch?v=ND-TuW0KIgg

;)
Feb 27 2018
parent 0xFFFFFFFF <0xFFFFFFFF mail.com> writes:
On Tuesday, 27 February 2018 at 19:03:54 UTC, Mark wrote:

 On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


 You're not the only one who thinks so -

 https://www.youtube.com/watch?v=ND-TuW0KIgg

 ;)


Modules couldn't make it but we have a new syntactic sugar for 
SFINAE.

[someone should make for Dlang too]
Feb 28 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu

 wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite
 -2018-02

 Andrei


 I have submitted, already. My major complaints boils down to the
 fact that they refuse to deprecated features due to religious
 like devotions to backwards compatibility support.


The main problem with that is that the fact that as soon as you're willing
to break backwards compatability in C++, then you lose one of the major
benefits of C++ (that the same code compiles pretty much forever) and that
if you're willing to give up on that, you might as well be using another
language like D or Rust. I'm sure that there's a crowd who would love to
break some aspects of backwards compatability with C++ and stick with it
rather than switching to another language, but if someone actually really
tried to fix C++, you wouldn't end up with C++ anymore. You might not end up
with D or Rust, but it would definitely be a new language, and if you're
willing to do that, why stick with C++?

The other problem is that many of C++'s problems come from being a superset
of C, which is also a huge strength, and it would be a pretty huge blow to
C++ if it couldn't just #include C code and use it as if it were C++. To
truly fix C++ while retaining many of its strengths would require fixing C
as well, and that's not happening.

- Jonathan M Davis
Feb 27 2018
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:


 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just #include 
 C code and use it as if it were C++. To truly fix C++ while 
 retaining many of its strengths would require fixing C as well, 
 and that's not happening.


That's why it would be a big deal to be able to directly include 
C header files in D projects (as was discussed around here not 
that long ago).
Feb 27 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote:

 On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
 wrote:


 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just 
 #include C code and use it as if it were C++. To truly fix C++ 
 while retaining many of its strengths would require fixing C 
 as well, and that's not happening.


 That's why it would be a big deal to be able to directly 
 include C header files in D projects (as was discussed around 
 here not that long ago).


I'm working on this.

Atila
Feb 28 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves wrote:

 On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote:

 On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
 wrote:


 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just 
 #include C code and use it as if it were C++. To truly fix 
 C++ while retaining many of its strengths would require 
 fixing C as well, and that's not happening.


 That's why it would be a big deal to be able to directly 
 include C header files in D projects (as was discussed around 
 here not that long ago).


 I'm working on this.

 Atila


You do ?
Please link me to your progress if you can.
Feb 28 2018
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 28 February 2018 at 12:06:38 UTC, Stefan Koch wrote:

 On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves 
 wrote:

 On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote:

 On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M 
 Davis wrote:


 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just 
 #include C code and use it as if it were C++. To truly fix 
 C++ while retaining many of its strengths would require 
 fixing C as well, and that's not happening.


 That's why it would be a big deal to be able to directly 
 include C header files in D projects (as was discussed around 
 here not that long ago).


 I'm working on this.

 Atila


 You do ?
 Please link me to your progress if you can.


I had an earlier version with could successfully #include 
nanomsg, then I ran into problems doing the same thing with curl, 
and restarted from scratch. My DConf talk submission is on this.

Atila
Feb 28 2018
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:

 On Tuesday, February 27, 2018 17:33:52 12345swordy via 
 Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu

 wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite
-2018-02

 Andrei


 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


 The main problem with that is that the fact that as soon as 
 you're willing to break backwards compatability in C++, then 
 you lose one of the major benefits of C++ (that the same code 
 compiles pretty much forever) and that if you're willing to 
 give up on that, you might as well be using another language 
 like D or Rust. I'm sure that there's a crowd who would love to 
 break some aspects of backwards compatability with C++ and 
 stick with it rather than switching to another language, but if 
 someone actually really tried to fix C++, you wouldn't end up 
 with C++ anymore. You might not end up with D or Rust, but it 
 would definitely be a new language, and if you're willing to do 
 that, why stick with C++?

 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just #include 
 C code and use it as if it were C++. To truly fix C++ while 
 retaining many of its strengths would require fixing C as well, 
 and that's not happening.

 - Jonathan M Davis


Yes I know that backwards compatibility comes with benefits, but 
gosh darn it, it doesn't stop me from complaining about it. Even 
more so it's very popular language to develop video games on it.
Feb 27 2018
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:

 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just #include 
 C code and use it as if it were C++. To truly fix C++ while 
 retaining many of its strengths would require fixing C as well, 
 and that's not happening.


I think you can have C plus another language just fine.

In C++ you use extern "C" as a wrapper, you could easily run a 
completely different parser within an extern "C" block and build 
a different type of AST for it.

This was probably out of reach in the 80s and early 90s when 
compiler resources was an issue, but with LLVM and gigabytes of 
RAM I think it would be quite reasonable to do something like 
that.

People don't do it because the basic counter argument always is 
"but we already support C through linkage", but that doesn't mean 
that there would be no real productivity advantage to building C 
into the language.

Not that I would do it if I designed a system level language, 
mostly because I think it would be better to build tools for 
transpiling code from C to the new language. C is a dead end now, 
I think.

Ola
Feb 28 2018
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:

 On Tuesday, February 27, 2018 17:33:52 12345swordy via 
 Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu

 wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite
-2018-02

 Andrei


 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


 The main problem with that is that the fact that as soon as 
 you're willing to break backwards compatability in C++, then 
 you lose one of the major benefits of C++ (that the same code 
 compiles pretty much forever)


No, you wouldn't, just do what D did with the 2.0 branch: put all 
the breaking changes in a new version, while continuing to 
support those clinging to old codebases with an older branch.  D 
did it and survived the branch with much less resources, I see no 
reason C++ couldn't do the same with their massive resources.


 and that if you're willing to give up on that, you might as 
 well be using another language like D or Rust. I'm sure that 
 there's a crowd who would love to break some aspects of 
 backwards compatability with C++ and stick with it rather than 
 switching to another language, but if someone actually really 
 tried to fix C++, you wouldn't end up with C++ anymore. You 
 might not end up with D or Rust, but it would definitely be a 
 new language, and if you're willing to do that, why stick with 
 C++?


Those people are more likely to leave when you don't clean up 
C++, including deprecating bad features. Users are always coming 
and going: you need to have some vision of what C++ will evolve 
into that will keep a lot of them, while still keeping enough 
backwards compatibility that most don't leave.

However, the way the politics works at any large, successful 
organization is that the ones pushing to maintain the status quo 
win out: after all, they've won out so far, so they clearly know 
what they're doing?  Then, they inevitably fade away, as they 
lose touch with reality in their bubble.

The _only_ time this pattern breaks is if they're on the verge of 
dying and the crisis allows for radical change, such as when they 
brought Steve Jobs back to Apple and let him clean house, and 
that's almost always too late.  C++ is not in crisis yet, so 
nothing will happen.


 The other problem is that many of C++'s problems come from 
 being a superset of C, which is also a huge strength, and it 
 would be a pretty huge blow to C++ if it couldn't just #include 
 C code and use it as if it were C++. To truly fix C++ while 
 retaining many of its strengths would require fixing C as well, 
 and that's not happening.


There are ways to clean up that C integration though, as D has 
shown with one approach.  There's no reason to carry around this 
legacy baggage forever.

C++ stagnates because of a lack of creativity, will, and vision, 
which is going to happen to any organization that gets fat and 
successful.  There are many things they could do to change this 
descent, but they lack those essential ingredients to do them.
Mar 03 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]

 The main problem with that is that the fact that as soon as you're
 willing to break backwards compatability in C++, then you lose one of
 the major benefits of C++ (that the same code compiles pretty much
 forever)


Not strictly true.  My old C++98 project no longer compiled with the
latest g++, because it contained things allowed in C++98 that are no
longer allowed in C++17.  Some things were relatively simple to fix, but
others were quite painful to fix, so I ended up using --std=c++11 as a
workaround instead.  In the frustrating process of trying to fix things
C++17 complains about, I threw in the towel and decided to rewrite it in
D instead.


[...]

 The other problem is that many of C++'s problems come from being a
 superset of C, which is also a huge strength, and it would be a pretty
 huge blow to C++ if it couldn't just #include C code and use it as if
 it were C++.


Not strictly true either.  Most modern C header files come wrapped with:

	#ifdef __cplusplus
	extern "C" {
	#endif

	...

	#ifdef __cplusplus
	}
	#endif __cplusplus

because without that, a lot of C headers actually would *not* compile.

Granted, though, this is a lot easier than having to write JNI wrappers
or (carefully!) translate C headers into D.  It would be nice if you
could actually just copy-n-paste a C header into an extern(C) block in D
and have it Just Work(tm), but practically all C headers are dependent
on macros one way or another that it would require including an entire C
processor inside the D compiler, which is not exactly an inviting
proposition.



 To truly fix C++ while retaining many of its strengths would require
 fixing C as well, and that's not happening.


[...]

Actually, C and C++ have already somewhat diverged. The C subset of C++
is an actually older dialect of C, and no longer 100% compatible with
modern C.  Though it's true that it's still 95% compatible, which is
Good Enough(tm) for most purposes.


T

-- 
A program should be written to model the concepts of the task it performs
rather than the physical world or a process because this maximizes the
potential for it to be applied to tasks that are conceptually similar and, more
important, to tasks that have not yet been conceived. -- Michael B. Allen
Feb 27 2018
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:


 Granted, though, this is a lot easier than having to write JNI 
 wrappers or (carefully!) translate C headers into D.  It would 
 be nice if you could actually just copy-n-paste a C header into 
 an extern(C) block in D and have it Just Work(tm), but 
 practically all C headers are dependent on macros one way or 
 another that it would require including an entire C processor 
 inside the D compiler, which is not exactly an inviting 
 proposition.


Walter has said that he has considered doing that now that DMC is 
Boost licensed:
https://forum.dlang.org/post/p58q2l$1d35$1 digitalmars.com
Feb 27 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 27, 2018 at 09:44:45PM +0000, bachmeier via Digitalmars-d wrote:

 On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
 

 Granted, though, this is a lot easier than having to write JNI
 wrappers or (carefully!) translate C headers into D.  It would be
 nice if you could actually just copy-n-paste a C header into an
 extern(C) block in D and have it Just Work(tm), but practically all
 C headers are dependent on macros one way or another that it would
 require including an entire C processor inside the D compiler, which
 is not exactly an inviting proposition.


 
 Walter has said that he has considered doing that now that DMC is
 Boost licensed:
 https://forum.dlang.org/post/p58q2l$1d35$1 digitalmars.com


Wouldn't that cause compatibility issues with gdc/ldc?


T

-- 
Give me some fresh salted fish, please.
Feb 27 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, February 27, 2018 15:28:21 H. S. Teoh via Digitalmars-d wrote:

 On Tue, Feb 27, 2018 at 09:44:45PM +0000, bachmeier via Digitalmars-d 


wrote:

 On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

 Granted, though, this is a lot easier than having to write JNI
 wrappers or (carefully!) translate C headers into D.  It would be
 nice if you could actually just copy-n-paste a C header into an
 extern(C) block in D and have it Just Work(tm), but practically all
 C headers are dependent on macros one way or another that it would
 require including an entire C processor inside the D compiler, which
 is not exactly an inviting proposition.


 Walter has said that he has considered doing that now that DMC is
 Boost licensed:
 https://forum.dlang.org/post/p58q2l$1d35$1 digitalmars.com


 Wouldn't that cause compatibility issues with gdc/ldc?


It wouldn't if the idea were to move parts of dmc into the frontend, and
_something_ would have to be put in the frontend for such a thing, even if
it meant accessing the C/C++ compiler via library rather than adding the
C/C++ stuff into the frontend itself. But I don't know what Walter is
thinking exactly.

- Jonathan M Davis
Feb 27 2018
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

 On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via 
 Digitalmars-d wrote: [...]

 [...]


 Not strictly true.  My old C++98 project no longer compiled 
 with the latest g++, because it contained things allowed in 
 C++98 that are no longer allowed in C++17.  Some things were 
 relatively simple to fix, but others were quite painful to fix, 
 so I ended up using --std=c++11 as a workaround instead.  In 
 the frustrating process of trying to fix things C++17 complains 
 about, I threw in the towel and decided to rewrite it in D 
 instead.

 [...]


The fun with C++
the same expression means completely different things in C++98 
and C++11

     fon< fun< 1 >>::three >::two >::one

and there's no context change, it's parsing rules that changed.

https://gustedt.wordpress.com/2013/12/18/right-angle-brackets-shifting-semantics
Feb 28 2018
prev sibling parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

 It would be nice if you could actually just copy-n-paste a C 
 header into an extern(C) block in D and have it Just Work(tm), 
 but practically all C headers are dependent on macros one way 
 or another that it would require including an entire C 
 processor inside the D compiler, which is not exactly an 
 inviting proposition.


Watch this space...
Mar 10 2018
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 11 March 2018 at 02:21:30 UTC, Laeeth Isharc wrote:

 On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

 It would be nice if you could actually just copy-n-paste a C 
 header into an extern(C) block in D and have it Just Work(tm), 
 but practically all C headers are dependent on macros one way 
 or another that it would require including an entire C 
 processor inside the D compiler, which is not exactly an 
 inviting proposition.


 Watch this space...


And we have warp which is a C preprocessor written in D, just 
saying ;)
Mar 11 2018
prev sibling parent German Diago <germandiago gmail.com> writes:
On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


 I have submitted, already. My major complaints boils down to 
 the fact that they refuse to deprecated features due to 
 religious like devotions to backwards compatibility support.


Well, not religious but... they are removing things too slow. 
There is a paper about stability and velocity of C++ that 
proposes to widen things to move forward faster and... btw I 
complained about exactly that as well. Things are getting bigger 
and bigger, just discard things. I also complained about the 
following:

1.- everyone is saying stop the preprocessor... modules support 
no preprocessor after import... ok, then, why feature test 
macros? They should be enums or constexpr but never a 
preprocessor macro.
2.- the single thing that bothers me the most... initialization 
is a mess, especially after adding {} vs (). With good intention, 
but the cognitive overhead and room for surprises is too big.
3.- if constexpr cannot simply compete with static if. I 
suggested adding: if constexpr that does not require a template 
function, and some alternative if constexpr mechanism (I do not 
care about the name or if it is a separate feature) that can 
conditionally compile structs or block scopes a la version() in 
D. This feature is needed to kill the preprocessor if they really 
want to take that seriously, especially with modules on its way.

BTW, I have been trying a bit of D lately and I like how flexible 
things such as opDispatch and static if are. I love modules as 
well. I like a lot also the fact that you do not need to be 
prefixing all things all the time because of potential hijacking. 
The static reflection has also been useful for me. I was just 
coding a SNES ROM parser but that was enough already to show some 
of the advantages.
Mar 01 2018
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


D community survey is coming soon? :)
Feb 27 2018
parent Seb <seb wilzba.ch> writes:
On Tuesday, 27 February 2018 at 20:25:32 UTC, JN wrote:

 On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
 Alexandrescu wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


 D community survey is coming soon? :)


Yes. Stay tuned.
Feb 27 2018
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


really, online surveys are dodgy at best.

btw. Bjarne Stroustrup recently received the 2018 Charles Stark 
Draper Prize for Engineering - 
https://www.nae.edu/Activities/Projects/Awards/DraperPrize/DraperWinners/2018Draper.aspx

I think that is dodgy too. Why give someone a prize for creating 
C++. I just don't get it.

It should have gone to the Java developers - cause they deserved 
it.

C++ is the worst thing to have ever come out of computer science!

The only reason it's still with us, is because corporations are 
stuck with it, and force it on us all, cause it's too expensive 
for them to replace.

I want no part of it.

The answer to Q:15 => I'd go back in history and make Stroustrup 
a fluffy dog, or a fluffy cat or something.
Feb 27 2018
parent reply Zoadian <no no.no> writes:
On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit 
wrote:

 It should have gone to the Java developers - cause they 
 deserved it.

 C++ is the worst thing to have ever come out of computer 
 science!


yes c++ is not the greatest language (thats why i use D). but 
java is the worst language i've ever used.
Feb 28 2018
parent reply TheFlyingFiddle <none none.com> writes:
On Wednesday, 28 February 2018 at 10:15:13 UTC, Zoadian wrote:

 On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit 
 wrote:

 It should have gone to the Java developers - cause they 
 deserved it.

 C++ is the worst thing to have ever come out of computer 
 science!


 yes c++ is not the greatest language (thats why i use D). but 
 java is the worst language i've ever used.


My least preferredlanguage of all times would be Perl. With (PHP 
5.3) coming in at a close second :)

Perl is just... I get it, you can write somewhat nicer bash 
scripts in the language. But people... they just go with it and 
build these huge crazy systems that somehow 10+ years later 
become my problem. The designer of Perl was clearly insane. Let's 
store everything in fun global "invisible" variables, functions 
don't specify arguments... And lets have the first letter of the 
variable define how/what $,  , %, with fun auto conversions 
everywhere :D.

PHP is better but there is some really weird stuff in it. Of the 
top of my head is the auto type conversion system. This works, by 
design...

//PHP
$a = 5;
$b = $a * "10 trains";
echo $b; //$b is now 50... Fun and interesting stuff right there

Compared to them, programming in C++ or Java for that matter is 
like a dream. But when I can, I always use D. Mainly because 
unlike every other language, it has static introspection, ctfe 
and mixins. A whole new world of expressive power is gained by 
this. Only thing missing is the ability to do arbitrary system 
calls during compilation :D
Feb 28 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 28, 2018 at 06:45:29PM +0000, TheFlyingFiddle via Digitalmars-d
wrote:
[...]

 My least preferredlanguage of all times would be Perl. With (PHP 5.3)
 coming in at a close second :)
 
 Perl is just... I get it, you can write somewhat nicer bash scripts in
 the language.


I was actually a Perl (5) fan for many years, before finding D.  As you
said, it's very nice for replacing brittle (and ugly!) shell scripts,
not to mention with superior performance instead of spawning a
subprocess (somtimes multiple) for basically every command, even
fundamental things like evaluating an expression. (Though bash may have
built-in some of it... but still.)

PHP is just... well, OK, one has to admit that the idea of embedding
code in HTML and vice versa in a smooth syntax that you can easily
transition into and out of, was an extremely clever one.  It removed the
burden of constant escaping (aka the leaning toothpick syndrome) that
was prevalent in such kind of code back in the day.  But other than
that.. PHP has some pretty serious fundamental design flaws that became
calcified as features because just about everything depended on it, and
after a while, it was just a monster of a language, most eloquently
described as:

	https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/



 But people... they just go with it and build these huge crazy systems
 that somehow 10+ years later become my problem.


Yeah... Perl is great for one-off scripts and clever hacks.  But the way
it's designed also makes it not very scalable.  Once you get past a
certain size, the quirky syntax and general looseness (in typing,
semantics, data structures, etc.) just start becoming more and more of a
maintenance burden.

At least, that was the case for Perl 5, which was around the time I
found D and left Perl behind.  Can't speak for Perl 6 or later.



 The designer of Perl was clearly insane. Let's store everything in fun
 global "invisible" variables, functions don't specify arguments... And
 lets have the first letter of the variable define how/what $,  , %,
 with fun auto conversions everywhere :D.


The idea of sigils is actually not a bad one.  It does, after all, have
basis in natural languages. But the way it was implemented in Perl is,
shall we say, rather quirky, leading to all sorts of unexpected
interactions with other things and generally become a cognitive burden
in large projects, where a disproportionate amount of time is spent
fighting with syntax rather than getting things done.  (E.g., is it
 $x[$y] or $x->y or ${x}{y} or ${x->$y}[$z] or something else?)

D's dot syntax, by comparison, is worlds better. One dot to rule 'em
all.  Symmetry is powerful. ;-)



 PHP is better but there is some really weird stuff in it.


Actually, IMO, PHP is far worse than Perl.  Perl is pretty crazy, yeah,
but it does have a certain kind of logic behind it (albeit a twisted
one, just like its creator :-P), a kind of consistency that makes you go
"yeah, in retrospect it *does* make sense, even though it's still really
weird".  PHP, OTOH, is full of exceptions and corner cases *without* any
underlying consistency.  There is no pattern to it, not even a twisted
one, it's just a bunch of arbitrary exceptions and special cases that
you basically have to memorize.  And random things just Don't Work(tm),
just because they don't, for no discernible reasons whatsoever.  Like
the inability to overload class constructors, even though polymorphism
is supported, a very strange combo.  And the word "overload" is used in
a strange, different sense, just to confuse you.



 Of the top of my head is the auto type conversion system. This works,
 by design...
 
 //PHP
 $a = 5;
 $b = $a * "10 trains";
 echo $b; //$b is now 50... Fun and interesting stuff right there


Yeah, that's 10 trains worth of WATs right there. :-D

And the whole thing about == vs === is just one huge WAT.  It "makes
sense" if you understand why it's necessary, but it just begs the
question, why, oh why, wasn't the language designed properly in the
first place so that such monstrosities aren't necessary?!



 Compared to them, programming in C++ or Java for that matter is like a
 dream.


C++ is hardly any better, actually:

	https://bartoszmilewski.com/2013/09/19/edward-chands/

Java... well, Java is a walled garden, a somewhat nice (if verbose) one
that's somewhat detached from reality, but forcefully anchored to it by
big commercial interests.  As a language it's not too bad; the core
language is pretty nicely designed -- in an idealistic, ivory tower sort
of sense.

But in practice, it's more of a Write Once, Debug Everywhere deal.  The
verbosity and IDE dependence sucks.  The OO fanaticism also sucks
(singleton classes IMO is a big code smell, esp. when it's really just
syntactic lip service to the OO religion for what's essentially global
functions).  The lack of real generics is total suck, and a showstopper
for me. Even the half-hearted attempt at generics that they shoehorned
into it later doesn't fully save it from being sucky.  The only saving
grace of Java is the extensive library support -- you can find just
about anything you might imagine as a library, which saves you from
dealing with the suckier parts of the language. Most of the time.



 But when I can, I always use D. Mainly because unlike every other
 language, it has static introspection, ctfe and mixins. A whole new
 world of expressive power is gained by this.


D to me is like the nexus of all the best things from the languages I
worked with: it has the conciseness and expressive power of Perl and is
suitable for one-off, shell-script-like utilities, yet with the safety
of static typing and the sanity of clean syntax.  It also has a GC, one
of the non-sucky aspects of Java, which saves it from being C hell in
large projects where 90% of your mental energy is spent worrying about
memory management instead of focusing on the problem domain, or C++ hell
with a pathological syntax that must be parsed before it can be lexed.
It has templates with a sane syntax, unlike C++, but goes beyond that
with static introspection, CTFE, and mixins like you said.

D also empowers the user to build their own functionality where the
built-ins aren't good enough. This is actually a huge point for me.
Recently I started a thread complaining about the new int promotion
deprecation rules, and not long after, somebody described an almost
beautiful workaround that uses operator overloading and `alias this` to
basically completely bypass the casts.  The fact that such a thing is
*possible* in D speaks volumes.

If this were in, say Java, I would have basically been told, "what you
want isn't supported. Suck it up, or go to another language". As Andrei
wrote in TDPL, (and I paraphrase,) it sucks when built-in types have
magical abilities inaccessible to user code.  This is a common defect in
many programming languages... the "magical" behaviour is wonderful when
it works. But if you need something that said "magic" doesn't cover,
you're left up the creek without a paddle.  In D, however, you're given
the tools to build your own equivalents of language built-ins.  Language
built-ins not good enough?  No problem: we give you the tools to write
your own.

The concept of empowering the user (rather than shoehorn everything into
a preconceived cage) is a powerful one, that would-be programming
language designers would do well to take heed to.



 Only thing missing is the ability to do arbitrary system calls during
 compilation :D


AKA compile-my-source-code-and-get-a-trojan-installed-on-your-system.
:-D  If this (mis)feature ever gets merged into DMD, give me a call
right away -- I have a lot of source code to sell you. For free. :-D


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a
much more efficient method; it is much closer to reality. -- D. Knuth
Feb 28 2018
next sibling parent reply TheFlyingFiddle <none none.com> writes:
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:

Just to give some background. At work I spend most of my time 
maintaining legacy systems adding some small features or 
replacing subcomponents. So most of what I do is reading code and 
making some minor changes (unless it's buggy code then you get to 
rewrite :))


 The idea of sigils is actually not a bad one.  It does, after 
 all, have basis in natural languages. But the way it was 
 implemented in Perl is, shall we say, rather quirky, leading to 
 all sorts of unexpected interactions with other things and 
 generally become a cognitive burden in large projects, where a 
 disproportionate amount of time is spent fighting with syntax 
 rather than getting things done.  (E.g., is it  $x[$y] or $x->y 
 or ${x}{y} or ${x->$y}[$z] or something else?)


Perl is a maintenance nightmare. It just takes so much time to 
figure out what the code actually does. Particularity if it has 
been changed by multiple people over the years.
That's the main reason Perl is at the top of my most disliked 
languages.


 Yeah, that's 10 trains worth of WATs right there. :-D

 And the whole thing about == vs === is just one huge WAT.  It 
 "makes sense" if you understand why it's necessary, but it just 
 begs the question, why, oh why, wasn't the language designed 
 properly in the first place so that such monstrosities aren't 
 necessary?!


Another personal favorite.
function foo($myArray) {
    return $myArray['test'];
}

$myString = "hello, world";
$test = foo($myString);

echo $test; // $test = 'h'; Because you know 'test' auto converts 
to 0.

Now PHP does have many WATs but it's still simpler to read than 
Perl so it has an edge over Perl for me atleast.


 Compared to them, programming in C++ or Java for that matter 
 is like a dream.


 C++ is hardly any better, actually:

 	https://bartoszmilewski.com/2013/09/19/edward-chands/


Yeah... C++ is interesting in that way. Mostly what I have seen 
is that for any given project they have a strict policy of how to 
do memory management and error handling. Also it's not really a 
pleasure reading C++ templates :D.


 Java... well, Java is a walled garden, a somewhat nice (if 
 verbose) one that's somewhat detached from reality, but 
 forcefully anchored to it by big commercial interests.  As a 
 language it's not too bad; the core language is pretty nicely 
 designed -- in an idealistic, ivory tower sort of sense.

 But in practice, it's more of a Write Once, Debug Everywhere 
 deal.  The verbosity and IDE dependence sucks.  The OO 
 fanaticism also sucks (singleton classes IMO is a big code 
 smell, esp. when it's really just syntactic lip service to the 
 OO religion for what's essentially global functions).  The lack 
 of real generics is total suck, and a showstopper for me. Even 
 the half-hearted attempt at generics that they shoehorned into 
 it later doesn't fully save it from being sucky.  The only 
 saving grace of Java is the extensive library support -- you 
 can find just about anything you might imagine as a library, 
 which saves you from dealing with the suckier parts of the 
 language. Most of the time.


The awful and nice part of Java is that since your forced to do 
things a certain way then things will actually be done in that 
way. In this case OOP and all of that. It's nice when you read 
the code, awful when you actually have to code in it.



 Only thing missing is the ability to do arbitrary system calls 
 during compilation :D


 AKA 
 compile-my-source-code-and-get-a-trojan-installed-on-your-system. :-D  If this
?
 (mis)feature ever gets merged into DMD, give me a call right 
 away -- I have a lot of source code to sell you. For free. :-D


Why must you ruin my perfect plan of getting a free botnet! :D
Feb 28 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 28, 2018 at 09:46:49PM +0000, TheFlyingFiddle via Digitalmars-d
wrote:

 On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
 
 Just to give some background. At work I spend most of my time
 maintaining legacy systems adding some small features or replacing
 subcomponents. So most of what I do is reading code and making some
 minor changes (unless it's buggy code then you get to rewrite :))


In spite of my job title being SW engineer, this actually almost exactly
describes what I do. :-D  Well, OK, sometimes a larger feature is asked
for and I get to write fresh code, but 90% of my daily duties is reading
other people's code, fixing bugs, and making relatively minor changes.


[...]

 Perl is a maintenance nightmare. It just takes so much time to figure
 out what the code actually does. Particularity if it has been changed
 by multiple people over the years.


That applies to almost any code changed by a large number of people over
the years. :-D  Especially when it's code written in a commercial
environment where there's a high turnover and people are forced to
implement last-minute hacks due to customer demands and impractically
tight deadlines. Over time, the hacks accumulate on top of each other
into a brittle tower of cards that pretty much is guaranteed to break at
the slightest change, mostly in apparently unrelated places where you
won't notice until something blows up later.

Sometimes I just have to shake my head and walk away, and admit defeat
that I *don't* understand what the code does, and neither do I want to,
because I might need therapy afterwards.  :-D



 That's the main reason Perl is at the top of my most disliked
 languages.


In my case, that also applies to badly-maintained C/C++ code!


[...]

 And the whole thing about == vs === is just one huge WAT.  It "makes
 sense" if you understand why it's necessary, but it just begs the
 question, why, oh why, wasn't the language designed properly in the
 first place so that such monstrosities aren't necessary?!


 
 Another personal favorite.
 function foo($myArray) {
    return $myArray['test'];
 }
 
 $myString = "hello, world";
 $test = foo($myString);
 
 echo $test; // $test = 'h'; Because you know 'test' auto converts to 0.


Hahaha... yeah. This is one of the things that make me hate dynamically
typed languages so much.  Your types can change from under you at any
time without any warning, usually with disastrous consequences, but
should you be so unlucky as to have said consequences masked by more
"convenient" auto type conversions, you quickly find yourself wishing
for a real type system.  Like when you mistype the name of an optional
field in a data structure, and the receiving code simply ignores the
mistyped field.  No warnings or indications whatsoever of what went
wrong.


[...]

 Compared to them, programming in C++ or Java for that matter is
 like a dream.


 
 C++ is hardly any better, actually:
 
 	https://bartoszmilewski.com/2013/09/19/edward-chands/


 
 Yeah... C++ is interesting in that way. Mostly what I have seen is
 that for any given project they have a strict policy of how to do
 memory management and error handling.


Yes, essentially the only way to work with C++ in a sane way is to
restrict yourself, either by convention or by policy, to a strict subset
of C++.  Google, for example, places heavy restrictions on what parts of
C++ are allowed in their codebase.  Full C++ contains just too many
pathological things that code that's actually free-for-all in that way
quickly becomes completely unmaintainable.

Reminds me of a C++ project I had to work with once, where useful work
was done in dtors via side-effects.  Good luck figuring out what the
code does from glancing at it!  (It begins with a mystified "why does
this function only contain some variable declarations and nothing
else?", and goes downhill from there.)



 Also it's not really a pleasure reading C++ templates :D.


C++ template syntax makes me cringe every time I see it.  Reminds me of
all those battle scars I accumulated in the 2 decades or so I was
actively using C++.


[...]

 The awful and nice part of Java is that since your forced to do things
 a certain way then things will actually be done in that way. In this
 case OOP and all of that. It's nice when you read the code, awful when
 you actually have to code in it.


I dunno, I've seen Java code written in a way that's anything but OO,
with 10-page long functions that contain essentially the entire program,
and other clear symptoms of spaghetti code and general cloudiness in the
author's mind.  All "nicely" wrapped up, of course, in a class, complete
with a bow-tie, in lip service to OO.

As somebody once said, A true programmer can write assembly code in any
language. :-D



 Only thing missing is the ability to do arbitrary system calls
 during compilation :D


 
 AKA
 compile-my-source-code-and-get-a-trojan-installed-on-your-system.
 :-D  If this (mis)feature ever gets merged into DMD, give me a call
 right away -- I have a lot of source code to sell you. For free. :-D


 
 Why must you ruin my perfect plan of getting a free botnet! :D


'cos I want one of my own. :-D


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees
and try again."
Feb 28 2018
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:

 As Andrei wrote in TDPL, (and I paraphrase,) it sucks when 
 built-in types have magical abilities inaccessible to user 
 code.  This is a common defect in many programming languages... 
 the "magical" behaviour is wonderful when it works. But if you 
 need something that said "magic" doesn't cover, you're left up 
 the creek without a paddle.  In D, however, you're given the 
 tools to build your own equivalents of language built-ins.


Not true for implicit construction of a user-defined type. So you 
can't have a `struct Pointer` wrap a pointer fully because you 
can't pass null to a function taking a Pointer. You can't do the 
same for Algebraic element types, they're not Algebraic. In C++ 
you can, but it's by default, so you get implicit construction 
even when the *type author* didn't intend it to work.
Mar 07 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2018 at 03:52:19PM +0000, Nick Treleaven via Digitalmars-d
wrote:

 On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:

 As Andrei wrote in TDPL, (and I paraphrase,) it sucks when built-in
 types have magical abilities inaccessible to user code.  This is a
 common defect in many programming languages... the "magical"
 behaviour is wonderful when it works. But if you need something that
 said "magic" doesn't cover, you're left up the creek without a
 paddle.  In D, however, you're given the tools to build your own
 equivalents of language built-ins.


 
 Not true for implicit construction of a user-defined type. So you
 can't have a `struct Pointer` wrap a pointer fully because you can't
 pass null to a function taking a Pointer. You can't do the same for
 Algebraic element types, they're not Algebraic. In C++ you can, but
 it's by default, so you get implicit construction even when the *type
 author* didn't intend it to work.


Yeah, D does still have some dirty corners where built-in types still
have "magical" behaviour. It's much better than other languages in this
regard, though, AFAIK.


T

-- 
Why do conspiracy theories always come from the same people??
Mar 07 2018
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

 https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

 Andrei


"If you could wave a magic wand and change one thing about any 
part of C++, what would it be, and how would that change help 
your daily work?"

Deprecate C++, endorse D, and allocate all existing resources to 
either improving D, or implementing a fork of D.

"Do you have any additional feedback for C++ standardization?"

It's time for C++ to retire, and make room for better, emerging 
languages.  I hate having to use it.
Feb 27 2018