www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ACCU 2013 and D

reply Russel Winder <russel winder.org.uk> writes:
As some of you know, the C User Group UK and the European C and C++ User
Group long ago merged to create the Association of C and C++ Users
(ACCU). Over the years, the emphasis on C and C++ gave way to a more
diverse approach including patterns, Java, Python, Go, agile processes.
Even the name of the group formally changed to ACCU to lose the direct C
and C++ link. Due to the history, members of the group had and retain
roles with the British Standards Institute, as the UK representatives on
the C and C++ standards committees, especially the C++ one. When it is
the UK's turn to host a C++ standards committee meeting, the meeting is
either before or after the ACCU conference, and the obvious suspects get
drafted in to do keynotes and other talks at the conference, as well as
ACCU members attending the open meetings of JTC1/SC22/WG21.
http://accu.org/index.php/conferences/accu_conference_2013

This seems like an ideal opportunity to do a lightning talk (5 mins) on
why C++ is crap and D is the only native code language that should be
used. (I have a history in this group of bashing C++ :-) It would be
really helpful to create a few one liners (with code examples) as to why
D is the clear language of choice for native code working and, C++, Go,
Rust, Clay, etc. should be consigned to the dustbin of history. People
will expect me to emphasize concurrency and parallelism issues so it
would be good to throw others into the mix as well.

Thanks in advance for any input. Attribution of sources if appropriate
will be given unless people prefer anonymity!

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 20 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 20 January 2013 at 09:15:36 UTC, Russel Winder wrote:

 Thanks in advance for any input. Attribution of sources if 
 appropriate
 will be given unless people prefer anonymity!


static if vs enable_if is always very convincing. OK, bashing 
template in C++ is easy, but showing that it can be easy is 
usually worthwhile.

scope statement replacing bunch of try/catch is also very 
demonstrative.
Jan 20 2013
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 20.01.2013 10:15, schrieb Russel Winder:

 As some of you know, the C User Group UK and the European C and C++ User
 Group long ago merged to create the Association of C and C++ Users
 (ACCU). Over the years, the emphasis on C and C++ gave way to a more
 diverse approach including patterns, Java, Python, Go, agile processes.
 Even the name of the group formally changed to ACCU to lose the direct C
 and C++ link. Due to the history, members of the group had and retain
 roles with the British Standards Institute, as the UK representatives on
 the C and C++ standards committees, especially the C++ one. When it is
 the UK's turn to host a C++ standards committee meeting, the meeting is
 either before or after the ACCU conference, and the obvious suspects get
 drafted in to do keynotes and other talks at the conference, as well as
 ACCU members attending the open meetings of JTC1/SC22/WG21.
 http://accu.org/index.php/conferences/accu_conference_2013

 This seems like an ideal opportunity to do a lightning talk (5 mins) on
 why C++ is crap and D is the only native code language that should be
 used. (I have a history in this group of bashing C++ :-) It would be
 really helpful to create a few one liners (with code examples) as to why
 D is the clear language of choice for native code working and, C++, Go,
 Rust, Clay, etc. should be consigned to the dustbin of history. People
 will expect me to emphasize concurrency and parallelism issues so it
 would be good to throw others into the mix as well.

 Thanks in advance for any input. Attribution of sources if appropriate
 will be given unless people prefer anonymity!


Modules already here. C++ might get them, if ever, around 2020. Who
knows how the computing landscape will look then.

Compile time meta-programming via use of templates and mixins.

C++ has lots of nice features, however with the increasing size of the 
standard, I doubt anyone will be able to understand it past the planned 
C++17 revision.

And the most dear to my heart, C's legacy just opens the door to 
security exploits by design, which force you to rely on third-party 
tools to assess that you not doing any buffer overrun, strange pointer 
manipulation and so on.

As for arguments against the other languages you pointed out.

Beating on Go is kind of easy, due to the stubbornness of the language 
designers to leave certain common features out, like the ever recurring
discussion on generics that even I take part in go-nuts.

Plus showing that certain Go PR features are actually also available in 
D, like actors having a similar role to channels, strides, fast 
compilation times.

Actually I kind of like Rust, since I am a big ML fan. They just should
give up on their Perlisms for pointer definitions. And the language is 
not yet fully defined.

I would rephrase the "clear language of choice for native code working" 
to "clear language of choice for system native code working", because 
almost any mainstream static type language also has native code 
compilers available.

--
Paulo
Jan 20 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 20 January 2013 at 10:46:04 UTC, Paulo Pinto wrote:

 C++ has lots of nice features, however with the increasing size 
 of the standard, I doubt anyone will be able to understand it 
 past the planned C++17 revision.


Given how D is evolving, we will be soon at the same point.
Jan 20 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:


 Given how D is evolving, we will be soon at the same point.


The complexity of a language comes partially from the number of 
its features, but I think most of it comes from the unwanted and 
unexpected side interactions between different features.

Bye,
bearophile
Jan 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-20 11:46, Paulo Pinto wrote:


 Modules already here. C++ might get them, if ever, around 2020. Who
 knows how the computing landscape will look then.


Clang has already started to implement them.

-- 
/Jacob Carlborg
Jan 20 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 20.01.2013 12:16, schrieb Jacob Carlborg:

 On 2013-01-20 11:46, Paulo Pinto wrote:


 Modules already here. C++ might get them, if ever, around 2020. Who
 knows how the computing landscape will look then.


 Clang has already started to implement them.


They are still experimental and who knows if the standard will ever get 
them.

The last time I did a 100% fully new C++ project was back in 2005. Since 
then I have replaced quite a few "legacy" C++ applications by JVM/.NET 
based solutions.

Will modules be part of C++17?

Will anyone care about C++17 or will it be like ISO Extended Pascal or 
COBOL 2002? Standards that no one cares to implement.

It is 5 years until 2017, now look back at the IT industry for the past 
5 years and imagine a similar set of changes.

--
Paulo
Jan 20 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 20 January 2013 at 09:15:36 UTC, Russel Winder wrote:

 As some of you know, the C User Group UK and the European C and 
 C++ User
 Group long ago merged to create the Association of C and C++ 
 Users
 (ACCU). Over the years, the emphasis on C and C++ gave way to a 
 more
 diverse approach including patterns, Java, Python, Go, agile 
 processes.
 Even the name of the group formally changed to ACCU to lose the 
 direct C
 and C++ link. Due to the history, members of the group had and 
 retain
 roles with the British Standards Institute, as the UK 
 representatives on
 the C and C++ standards committees, especially the C++ one. 
 When it is
 the UK's turn to host a C++ standards committee meeting, the 
 meeting is
 either before or after the ACCU conference, and the obvious 
 suspects get
 drafted in to do keynotes and other talks at the conference, as 
 well as
 ACCU members attending the open meetings of JTC1/SC22/WG21.
 http://accu.org/index.php/conferences/accu_conference_2013

 This seems like an ideal opportunity to do a lightning talk (5 
 mins) on
 why C++ is crap and D is the only native code language that 
 should be
 used. (I have a history in this group of bashing C++ :-) It 
 would be
 really helpful to create a few one liners (with code examples) 
 as to why
 D is the clear language of choice for native code working and, 
 C++, Go,
 Rust, Clay, etc. should be consigned to the dustbin of history. 
 People
 will expect me to emphasize concurrency and parallelism issues 
 so it
 would be good to throw others into the mix as well.

 Thanks in advance for any input. Attribution of sources if 
 appropriate
 will be given unless people prefer anonymity!


Arrays and slices. They might be very "basic" features, but don't 
underestimate how having something basic as a starting point can 
transcend through an entire language.

Also: Unicode. And algorithms that are Unicode aware.

Forget the high level fancy stuff. I cam to D for all those basic 
things. All the rest is (very tasty) sugar.
Jan 20 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/20/2013 1:15 AM, Russel Winder wrote:

 Thanks in advance for any input. Attribution of sources if appropriate
 will be given unless people prefer anonymity!


SFINAE vs static if
Jan 20 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 20 January 2013 at 18:10:47 UTC, Walter Bright wrote:

 On 1/20/2013 1:15 AM, Russel Winder wrote:

 Thanks in advance for any input. Attribution of sources if 
 appropriate will be given unless people prefer anonymity!


 SFINAE vs static if


  Substitution failure is not an error. Wasn't that where if the 
template use/instantiation failed it would go onto the next one 
(and hope one of them worked)? Although it could work assuming 
you have enough templates to handle the cases, being able to 
determine if they quality (as in D) is a superior solution.

  Reminds me... Wasn't there a problem with the min/max in C++ 
where to correctly make it work there was some 90+ templates for 
the STL? (I think it was rejected). Makes you wonder sometimes 
what they are thinking when they decide this stuff.
Jan 20 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 20.01.2013 19:58, schrieb Era Scarecrow:

 On Sunday, 20 January 2013 at 18:10:47 UTC, Walter Bright wrote:

 On 1/20/2013 1:15 AM, Russel Winder wrote:

 Thanks in advance for any input. Attribution of sources if
 appropriate will be given unless people prefer anonymity!


 SFINAE vs static if


   Substitution failure is not an error. Wasn't that where if the
 template use/instantiation failed it would go onto the next one (and
 hope one of them worked)? Although it could work assuming you have
 enough templates to handle the cases, being able to determine if they
 quality (as in D) is a superior solution.

   Reminds me... Wasn't there a problem with the min/max in C++ where to
 correctly make it work there was some 90+ templates for the STL? (I
 think it was rejected). Makes you wonder sometimes what they are
 thinking when they decide this stuff.



I do miss using a language like C++ on my daily job, but then I read 
articles about "great ideas" like SFINAE.

--
Paulo
Jan 20 2013
prev sibling parent "angel" <andrey.gelman gmail.com> writes:
Concurrency and parallelism may be emphasized well with this 
simple example:

     foreach(i, ref elem; task_pool.parallel(logs)) {
         elem = log(i + 1.0);
     }

Keeping the (straight forward) serial semantics, we write 
parallelizable code.

Another good example, that demonstrates concurrency model 
borrowed from Erlang is:

     while (cont) {
         receive(
             (int msg) { writeln("int received: ", msg) },
             (string msg) {
                 cont = (msg == "stop") ? false : true;
             }
         );
     }

The 'send' part you can easily add by yourself.

Both examples emphasize requiring little and giving much.
Jan 21 2013