View mode: basic / threaded / horizontal-split · Log in · Help
January 20, 2013
ACCU 2013 and D
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!

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
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
January 20, 2013
Re: ACCU 2013 and D
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.
January 20, 2013
Re: ACCU 2013 and D
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
January 20, 2013
Re: ACCU 2013 and D
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.
January 20, 2013
Re: ACCU 2013 and D
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
January 20, 2013
Re: ACCU 2013 and D
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.
January 20, 2013
Re: ACCU 2013 and D
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
January 20, 2013
Re: ACCU 2013 and D
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
January 20, 2013
Re: ACCU 2013 and D
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
January 20, 2013
Re: ACCU 2013 and D
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home