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
