www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - "Competitive Advantage with D" is one of the keynotes at C++Now 2017

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/

I have to say it took me a very long time to come up with the title and 
the abstract. How could I sell D to C++ experts? Luckily, I asked Manu 
and among a long list of ideas he said "it's about saving time" and 
"time is money". How can you argue with that? ;)

Do you agree or disagree that D brings competitive advantage? Please let 
me know.

Are you attending the conference?

Ali
Apr 10 2017
next sibling parent reply FreeSlave <freeslave93 gmail.com> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/

 I have to say it took me a very long time to come up with the 
 title and the abstract. How could I sell D to C++ experts? 
 Luckily, I asked Manu and among a long list of ideas he said 
 "it's about saving time" and "time is money". How can you argue 
 with that? ;)

 Do you agree or disagree that D brings competitive advantage? 
 Please let me know.

 Are you attending the conference?

 Ali
D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows.
Apr 10 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-04-11 08:50, FreeSlave wrote:

 D can't compete with C++ until it gets proper dynamic library support on
 all platforms. As far as I understand there're still problems on Windows.
And no official support on macOS. -- /Jacob Carlborg
Apr 11 2017
next sibling parent reply Arek <arychlinski gmail.com> writes:
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote:
 On 2017-04-11 08:50, FreeSlave wrote:

 D can't compete with C++ until it gets proper dynamic library 
 support on
 all platforms. As far as I understand there're still problems 
 on Windows.
And no official support on macOS.
And no output for ARM64. :/ Arek
Apr 22 2017
parent David Nadlinger <code klickverbot.at> writes:
On Saturday, 22 April 2017 at 10:12:04 UTC, Arek wrote:
 And no output for ARM64. :/
LDC has beta-quality support for AArch64. --David
Apr 22 2017
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote:
 And no official support on macOS.
LDC officially supports shared libraries on macOS. -David
Apr 22 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-04-22 13:35, David Nadlinger wrote:

 LDC officially supports shared libraries on macOS. -David
That's great. -- /Jacob Carlborg
Apr 23 2017
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/11/2017 08:50 AM, FreeSlave wrote:
 D can't compete with C++ until it gets proper dynamic library support on
 all platforms. As far as I understand there're still problems on Windows.
Go fix it ;). Yes, we still need to make `export` work to replace `dllimport`/`dllexport`, then we can address the couple of low-level linking and TLS issues. Benjamin Thaut works on this and has a workable solution [¹]. Once this is done, DLL support should be on par with OSX/Linux/FreeBSD. Depending on what you want to do, you can already use D DLL's now, but atm. each DLL comes with it's own copy of the standard library, so different DLLs cannot talk to each other (see [²]). As with any ambitious project, we always want to do more than we have resources for, so things tend to not move as fast as everybody wants them to. -Martin [¹]: [pending PR https://github.com/MartinNowak/DIPs/blob/fbad186cf9ac8dce335344e64d3b1d880bb750c0/DIPs/archive/DIP45.md) [²]: [Issue 7020 – Exception thrown across DLL is not caught.](https://issues.dlang.org/show_bug.cgi?id=7020)
Apr 11 2017
prev sibling next sibling parent reply qznc <qznc web.de> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/
Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;)
Apr 11 2017
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/11/2017 02:22 AM, qznc wrote:
 On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/
Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;)
I *think* the third one will be related to Haskell but don't quote me on that. I applaud the organizers for inviting other languages. Their keynote theme for this year is "What can C++ learn from other languages?" Ali
Apr 11 2017
prev sibling next sibling parent qznc <qznc web.de> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/

 I have to say it took me a very long time to come up with the 
 title and the abstract. How could I sell D to C++ experts? 
 Luckily, I asked Manu and among a long list of ideas he said 
 "it's about saving time" and "time is money". How can you argue 
 with that? ;)

 Do you agree or disagree that D brings competitive advantage? 
 Please let me know.
Safety (bounds checking, safe, memory safety) is huge for debugging. You can probably steal a lot from Walters DConf Talk. Compilation time, because a quick iteration of edit-compile-test is significant for productivity and really underrated. C++ interop, so you can migrate from C++ to D in small steps and without building a C API bridge. Little things C++ lacks because it is too old: A package manager, a standard string type. Meta programming naturally, but "static if" might trail into discussions about concepts, so it is a little bit dangerous?
Apr 11 2017
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 Do you agree or disagree that D brings competitive advantage? 
 Please let me know.
Agree. There are different tradeoffs, obviously, and it won't suit all use-cases, but the ability to iterate fast through highly performant and provably correct code is very striking. If you manage your compile-time generics well -- i.e. using them to generalize for use cases that you definitely have, rather than premature generalization -- you can get a lot of power out of this that really helps with _effective_ code re-use. Compile time checks, contracts, and easy built-in unittests all make a big help in being able to make changes to code while maintaining confidence in its correctness -- again, making it faster to get things done. And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast.
 Are you attending the conference?
Not C++Now, I'm afraid. But will we see you at DConf? :-)
Apr 11 2017
next sibling parent Patric Dexheimer <patric.dexheimer gmail.com> writes:
On Tuesday, 11 April 2017 at 09:35:39 UTC, Joseph Rushton 
Wakeling wrote:
 And the simple clarity of the syntax really helps compared to, 
 say, C++.  It's much easier to write and much easier to read 
 and understand.  So, once again, it's easier to move fast.
As a D beginner I have to say that this one was very visible for me. I´m able to look at any D project read it and undertand it with ease. Very few times I was able to do it that easy looking on c++ sources.
Apr 11 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/11/2017 02:35 AM, Joseph Rushton Wakeling wrote:
 will we see you at DConf? :-)
Yes. I'm looking forward to it. :) Ali
Apr 11 2017
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Tuesday, 11 April 2017 at 14:36:18 UTC, Ali Çehreli wrote:
 On 04/11/2017 02:35 AM, Joseph Rushton Wakeling wrote:
 will we see you at DConf? :-)
Yes. I'm looking forward to it. :)
Great! And, likewise :-)
Apr 11 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Monday, April 10, 2017 23:08:16 Ali Çehreli via Digitalmars-d-announce 
wrote:
 I will be presenting D as a time-saving tool at C++Now:

    http://cppnow.org/

 I have to say it took me a very long time to come up with the title and
 the abstract. How could I sell D to C++ experts? Luckily, I asked Manu
 and among a long list of ideas he said "it's about saving time" and
 "time is money". How can you argue with that? ;)

 Do you agree or disagree that D brings competitive advantage? Please let
 me know.
They may yet make it into C++ in some form or another, but the lack of ranges in C++ is one of the things that I find really frustrating when I doing stuff for work. In particular, it's incredibly quick and easy to write parsing code for stuff in D with Phobos, whereas it takes a lot more time and effort to write it in C++. But just in general, I find that putting stuff together in D is faster than using C++. C++ is very powerful, but it's also quite clunky. - Jonathan M Davis
Apr 11 2017
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I will be presenting D as a time-saving tool at C++Now:

   http://cppnow.org/

 I have to say it took me a very long time to come up with the 
 title and the abstract. How could I sell D to C++ experts? 
 Luckily, I asked Manu and among a long list of ideas he said 
 "it's about saving time" and "time is money". How can you argue 
 with that? ;)

 Do you agree or disagree that D brings competitive advantage? 
 Please let me know.

 Are you attending the conference?

 Ali
Coming from C++, I think you can talk about compilation times first and the easiness of making a new program with dub (even with dependencies). Because imho library integration and waiting for the compiler are the biggest pain points with C++, actually I'm not sure memory safety will make trench workers switch. Newer C++ almost erased leaks and memory errors if you follow it.
Apr 11 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2017 8:10 AM, Guillaume Piolat wrote:
 Newer C++ almost erased leaks and memory errors if you follow it.
C and C++ don't have memory leaks if you are careful. The trouble is, there's no checking.
Apr 23 2017
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 23 April 2017 at 10:16:14 UTC, Walter Bright wrote:
 On 4/11/2017 8:10 AM, Guillaume Piolat wrote:
 Newer C++ almost erased leaks and memory errors if you follow 
 it.
C and C++ don't have memory leaks if you are careful. The trouble is, there's no checking.
The rules of leak-free, exception-safe C++11 aren't so hard. - single-owneship for everything, invent fake owner if needed - std::unique_ptr for owning pointer, raw pointers for borrowed (unique_ptr neatly avoids to write a RAII wrapper for everything) When teams internalize these rules, no more leaks, no more double-free, etc. Hence Rust that sanctified this style.
Apr 23 2017
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 23 April 2017 at 12:04:08 UTC, Guillaume Piolat wrote:
 Hence Rust that sanctified this style.
And why it's not that interesting to the modern C++ programmer.
Apr 23 2017
parent Atila Neves <atila.neves gmail.com> writes:
On Sunday, 23 April 2017 at 12:29:24 UTC, Guillaume Piolat wrote:
 On Sunday, 23 April 2017 at 12:04:08 UTC, Guillaume Piolat 
 wrote:
 Hence Rust that sanctified this style.
And why it's not that interesting to the modern C++ programmer.
Actually, writing Rust made me realise how bad my C++ code actually is. Even with unique_ptr et al. Atila
Apr 25 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/23/2017 5:04 AM, Guillaume Piolat wrote:
 The rules of leak-free, exception-safe C++11 aren't so hard.
 - single-owneship for everything, invent fake owner if needed
 - std::unique_ptr for owning pointer, raw pointers for borrowed
   (unique_ptr neatly avoids to write a RAII wrapper for everything)

 When teams internalize these rules, no more leaks, no more double-free, etc.
 Hence Rust that sanctified this style.
The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as being memory safe.
Apr 23 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:
 The trouble is, one cannot look at a piece of code and tell if 
 it follows the rules or not.

 I.e. it's not about it being possible to write memory safe code 
 in C or C++ (it is), it's about verifying an arbitrary piece of 
 code as being memory safe.
I don't think D and Rust fare any better than modern C++ as far as ARBITRARY code goes. Swift and Java does...
Apr 24 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.04.2017 13:33, Ola Fosheim Grøstad wrote:
 On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:
 The trouble is, one cannot look at a piece of code and tell if it
 follows the rules or not.

 I.e. it's not about it being possible to write memory safe code in C
 or C++ (it is), it's about verifying an arbitrary piece of code as
 being memory safe.
I don't think D and Rust fare any better than modern C++ as far as ARBITRARY code goes. Swift and Java does...
Swift allows raw pointer manipulation. Java implementations expose similar unsafe features. JVMs have bugs. Also, Java's type system is unsound.
Apr 24 2017
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote:
 Swift allows raw pointer manipulation.
I didn't know that Swift had that as a language construct. Link? I know that it provides library solutions for raw pointers, but that can be said for most languages.
 Java implementations expose similar unsafe features.
You think so?
Apr 24 2017
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/24/2017 11:17 AM, Timon Gehr wrote:
 Also, Java's type system is
 unsound.
Not doubting you, but this sounds interesting. Further info or links?
Apr 24 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote:
 On 04/24/2017 11:17 AM, Timon Gehr wrote:
 Also, Java's type system is
 unsound.
Not doubting you, but this sounds interesting. Further info or links?
https://dev.to/rosstate/java-is-unsound-the-industry-perspective
Apr 24 2017
prev sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I have to say it took me a very long time to come up with the 
 title and the abstract. How could I sell D to C++ experts? 
 Luckily, I asked Manu and among a long list of ideas he said 
 "it's about saving time" and "time is money". How can you argue 
 with that? ;)
I do agree, but C++ people may be less open to buy the whole package at once... The other speakers (Rust, Haskell) will talk about specific things that they regard as nicer in their languages compared to C++ (safe memory access, concurrency in Rust; side effect safety in Haskell). C++ users can more easily agree to these individual points and later become interested in the other languages. It's true that D's paradigm is less different from C++ and it's more about being better designed and safer as a whole. It's like, sure you can write 80% of D programs in C++ with only twice the typing at most, as long as your compiler supports C++14 at least, and you're super careful with memory... but you'll still be driven insane by the remaining 20% ;)
Apr 25 2017
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 25 April 2017 at 13:57:53 UTC, XavierAP wrote:
 On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
 I have to say it took me a very long time to come up with the 
 title and the abstract. How could I sell D to C++ experts? 
 Luckily, I asked Manu and among a long list of ideas he said 
 "it's about saving time" and "time is money". How can you 
 argue with that? ;)
I do agree, but C++ people may be less open to buy the whole package at once... The other speakers (Rust, Haskell) will talk about specific things that they regard as nicer in their languages compared to C++ (safe memory access,
safe
 concurrency in Rust;
std.concurrency Funny story: the first ever (and really, only) program I wrote in Rust had a deadlock in it. I never did figure out why, I just stopped using threads to get rid of the problem. I know it's only anecdata, but "fearless concurrency" does not gel with my experience. I don't even remember the last time I wrote a deadlock in C++, if ever. Not once in D, that's for sure. It's hard to deadlock when you hardly ever lock. :) I have fearless concurrency now, in D. Message passing FTW.
 side effect safety in Haskell).
pure
 C++ users can more easily  agree to these individual points and 
 later become interested in the other languages.
Well, let's show them the same points then ;)
 It's true that D's paradigm is less different from C++ and it's 
 more about being better designed and safer as a whole. It's 
 like, sure you can write 80% of D programs in C++ with only 
 twice the typing at most,
In my experience, _at least_ twice the typing, and 3 times as many bugs. And I'm talking about C++14 here. The other day I was reminded that in C++ land one has to manually write `operator<<` to print things out and `operator==` to compare things. Atila
Apr 28 2017
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/28/2017 04:26 PM, Atila Neves wrote:
 The other day I was reminded that in
 C++ land one has to manually write `operator<<` to print things out and
 `operator==` to compare things.
What, seriously?!? That's the thing about C++: The right way is the obscure way, and the straightforward way is the wrong way. And yesterday's right way is today's wrong way. And apparently (it would seem), the only way NOT to completely fuck *everything* up is to become an expert on every corner of the language, and STAY an expert on all the latest changes. In the immortal words (and voice) of Duke Nukem: "What a mess!" Seriously, I don't care about the political incorrectness of bashing or comparing to other languages, this right here is and always was D's killer feature, the whole reason I got into it in the first place and have stayed: D takes all the current (and former!) application domains of C/C++, and brings to it basic programmer sanity. 'Nuff said.
Apr 28 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce wrote:
 On 04/28/2017 04:26 PM, Atila Neves wrote:
 The other day I was reminded that in C++ land one has to manually
 write `operator<<` to print things out and `operator==` to compare
 things.
Not to mention you have to overload operator<, operator!=, operator==, operator>, operator<=, *and* operator>= in order to get the right results in all cases. In D, you have to overload opEquals and opCmp. Hmm, I wonder why I enjoy programming in D more than C++...
 What, seriously?!?
 
 That's the thing about C++: The right way is the obscure way, and the
 straightforward way is the wrong way. And yesterday's right way is
 today's wrong way. And apparently (it would seem), the only way NOT to
 completely fuck *everything* up is to become an expert on every corner
 of the language, and STAY an expert on all the latest changes. In the
 immortal words (and voice) of Duke Nukem: "What a mess!"
Yep, this always reminds me of: https://bartoszmilewski.com/2013/09/19/edward-chands/
 Seriously, I don't care about the political incorrectness of bashing
 or comparing to other languages, this right here is and always was D's
 killer feature, the whole reason I got into it in the first place and
 have stayed: D takes all the current (and former!) application domains
 of C/C++, and brings to it basic programmer sanity. 'Nuff said.
D is not without its own flaws and WAT-worthy dark corners, mind you, but in spite it its warts, I still prefer D any day over the masochistic labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way -- until next year) that is C++. The latest WAT I found in D is this one, see if you can figure it out: char ch; wchar wch; dchar dch; pragma(msg, typeof(true ? ch : ch)); // char - OK pragma(msg, typeof(true ? ch : wch)); // int - WAT? pragma(msg, typeof(true ? wch : wch)); // wchar - OK pragma(msg, typeof(true ? wch : dch)); // uint - WAT? pragma(msg, typeof(true ? dch : dch)); // dchar - OK How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint. See: https://issues.dlang.org/show_bug.cgi?id=17141 Unfortunately, my dmd-fu isn't up to snuff so my hamfisted PR to fix this problem didn't get very far: it broke a ton of stuff, which is a big no-no, oh noes, we cannot afford to break code, even though basically every dmd release breaks code! Oh well. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Apr 28 2017
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote:
 On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky 
 (Abscissa) via Digitalmars-d-announce wrote:
 On 04/28/2017 04:26 PM, Atila Neves wrote:
 The other day I was reminded that in C++ land one has to 
 manually write `operator<<` to print things out and 
 `operator==` to compare things.
Not to mention you have to overload operator<, operator!=, operator==, operator>, operator<=, *and* operator>= in order to get the right results in all cases. In D, you have to overload opEquals and opCmp. Hmm, I wonder why I enjoy programming in D more than C++...
Comparison is better in C++. This is a weak spot in D. You could do the same in C++ as D if you wanted to. You can detect the presence of operator< in overload templates, but being explicit is not much work and more flexible. Just cut'n'paste the set you want...
Apr 28 2017
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote:
 That's the thing about C++: The right way is the obscure way, and the
 straightforward way is the wrong way. And yesterday's right way is
 today's wrong way. And apparently (it would seem), the only way NOT to
 completely fuck *everything* up is to become an expert on every corner
 of the language, and STAY an expert on all the latest changes. In the
 immortal words (and voice) of Duke Nukem: "What a mess!"
Yep, this always reminds me of: https://bartoszmilewski.com/2013/09/19/edward-chands/
That is *awesome*! Although, I always saw Eddie Scissors as more of a retelling of Frankenstein.
 D is not without its own flaws and WAT-worthy dark corners, mind you,
 but in spite it its warts, I still prefer D any day over the masochistic
 labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way
 -- until next year) that is C++.
Yea, I really think it's more important than many of us realize to heed Herb Sutter's warning and not allow too much worrying about backwards compatibility thus leading D down the same path. When I see people here fret over "Yea, but it may cause breakage", on one hand I understand that can be the responsible stance, but OTOH it also makes me cringe because it's one more "cat" nibbling us to death - I don't want to see it follow in C++'s footsteps and allow these unfixed mistakes build up and damage what made D great in the first place. Especially since "small things that add up to more than the sum of their parts" is a big part of what makes D good in the first place.
 The latest WAT I found in D is this one, see if you can figure it out:
 How an alternation between two character types ends up being int is
 beyond me, but even more inscrutible is why ch : wch produces int but
 wch : dch produces uint.
Ouch. Although yea, guess that's another good reason to just decide Unicode == UTF-8 and be done with it ;) (I don't even care about UTF-8's supposed bloat in eastern alphabets - it's freaking *text* either way. Tale of Genji would be what, some tens of MB in UTF-8? Bah, trim down a few images and overengineered file formats and multimedia clutter if you need a shave a few measly MB so badly. If UTF-32'd won out, the complete works of Shakespeare would in the same boat, some tens of MB in the "wrong" format and we *still* wouldn't have the ASCII-simplicity of code points being equal to graphemes anyway. It's *text*. If your software's footprint or bandwidth is dominated by the size of a bloated text format, then *congratulations*, you officially have one of the smallest, most succinct software footprints in the world, so smile and be happy!)
Apr 28 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 03:44:50 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce 
 wrote:
 	https://bartoszmilewski.com/2013/09/19/edward-chands/
That is *awesome*! Although, I always saw Eddie Scissors as more of a retelling of Frankenstein.
It is rather inaccurate. E.g.: «Imperative languages offer no protection against data races — maybe with the exception of D.» Sounds mostly like a sales pitch for Haskell over C++, glossing over the main reason for why the highest performance parallell algorithms are risky: the actual hardware design. If you don't want that highest speed then you most certainly can protect against data races for many problems in other languages, including C++. This won't change until the hardware changes. Oh well, it kinda has, with GPU programming.
Apr 29 2017
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote:
 The latest WAT I found in D is this one, see if you can figure 
 it out:

 	char ch;
 	wchar wch;
 	dchar dch;

 	pragma(msg, typeof(true ? ch : ch));	// char - OK
 	pragma(msg, typeof(true ? ch : wch));	// int - WAT?
 	pragma(msg, typeof(true ? wch : wch));	// wchar - OK
 	pragma(msg, typeof(true ? wch : dch));	// uint - WAT?
 	pragma(msg, typeof(true ? dch : dch));	// dchar - OK

 How an alternation between two character types ends up being 
 int is beyond me, but even more inscrutible is why ch : wch 
 produces int but wch : dch produces uint.
That's the C integer promotion rule, nothing suprising here. C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Maybe the documentation should cite more prominently from the C standard on that point. While it is quite obvious, I noticed that a lot of people do not know how it works.
Apr 29 2017
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter 
wrote:
 C99 says "if an int can represent all values of the original 
 type, the value is converted to an int; otherwise, it is 
 converted to an unsigned int."
Well, C is making the simple assumption that registers are int-sized... This is no longer true of course, as "registers" are "SIMD sized". So I am pretty sure it will lead to suboptimal code in some instances.
 While quite often surprising for people coming from other 
 languages, I think that Walter's persistence in following the 
 basic C rule is a good thing.
Why is it a good thing?
Apr 29 2017
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 29 April 2017 at 11:48:46 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter 
 wrote:
 C99 says "if an int can represent all values of the original 
 type, the value is converted to an int; otherwise, it is 
 converted to an unsigned int."
Well, C is making the simple assumption that registers are int-sized...
That's not a simple assumption, it's acknowledgment that a C program runs on real
 This is no longer true of course, as "registers" are "SIMD 
 sized".
SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case.
 So I am pretty sure it will lead to suboptimal code in some 
 instances.
Can also be said if it had another semantic.
 While quite often surprising for people coming from other 
 languages, I think that Walter's persistence in following the 
 basic C rule is a good thing.
Why is it a good thing?
For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against.
Apr 29 2017
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter 
wrote:
 That's not a simple assumption, it's acknowledgment that a C 
 program runs on real

Modern X86s are basically virtual machines... The instruction set is decoded and executed on a completely different machine than the original X86.
 This is no longer true of course, as "registers" are "SIMD 
 sized".
SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case.
Huh? No, at least on X86 the register is only bits. You can mask floats with ints.
 So I am pretty sure it will lead to suboptimal code in some 
 instances.
Can also be said if it had another semantic.
Not sure what you mean here. If every byte is recast to 32bit then you have to prove that it ends up with the same result when computed as 8bit. In C it is cast to the register size (16bit, 32bit or 64bit), because C was designed for 40 years old CPUs where you had a fixed word size (register size). D has locked int to 32 bit, so the register argument no longer makes sense.
 For the same reason it is in C. If the ambition for D is to be 
 a system language then it should avoid introducing artificial 
 abstractions and work with the machine it runs on, not against.
But the C environment no longer works well with the machine it runs on. It is archaic and doesn't really reflect the underlying hardware well. It may seem like it does, but that's only because hardware vendors target C-generated code...
Apr 29 2017
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter 
wrote:
 For the same reason it is in C. If the ambition for D is to be 
 a system language then it should avoid introducing artificial 
 abstractions and work with the machine it runs on, not against.
The C model isn't much like x86 at all. You can do operations on 8 bit and 16 bit registers on x86, but C doesn't reflect that reality. I usually defend D's behavior of "blame C". Compatibility is useful for us and conservative programmers like familiarity, but I can't defend C's rules on the merits. They aren't like the processor and they aren't even that useful.
Apr 29 2017
prev sibling parent "H. S. Teoh via Digitalmars-d-announce" writes:
On Sat, Apr 29, 2017 at 11:24:36AM +0000, Patrick Schluter via
Digitalmars-d-announce wrote:
 On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote:
 The latest WAT I found in D is this one, see if you can figure it
 out:
 
 	char ch;
 	wchar wch;
 	dchar dch;
 
 	pragma(msg, typeof(true ? ch : ch));	// char - OK
 	pragma(msg, typeof(true ? ch : wch));	// int - WAT?
 	pragma(msg, typeof(true ? wch : wch));	// wchar - OK
 	pragma(msg, typeof(true ? wch : dch));	// uint - WAT?
 	pragma(msg, typeof(true ? dch : dch));	// dchar - OK
 
 How an alternation between two character types ends up being int is
 beyond me, but even more inscrutible is why ch : wch produces int
 but wch : dch produces uint.
That's the C integer promotion rule, nothing suprising here. C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Maybe the documentation should cite more prominently from the C standard on that point. While it is quite obvious, I noticed that a lot of people do not know how it works.
The problem is that while C integer promotion works well for C, it doesn't for D so much. Perhaps it worked well in the beginning days of D, when D was much closer to C, but today's D has significantly diverged from C in many respects, including making a clear(?) distinction between character types vs. integer types (e.g., char != ubyte). There has been a regression (at least) caused by the above adherence to C integer promotion rules: https://issues.dlang.org/show_bug.cgi?id=17358 There has also been bugs / problems related to overloading between int and char types of the same width (the wrong overload gets chosen). The problem is that because D makes it a point that char and ubyte are different (ditto for wchar / ushort, dchar / uint), people have come to expect that they should be consistently treated differently. But then we run into anachronisms like C integer promotion rules that basically disregard the distinction between integer and character types. So now you have this schizophrenic situation where part of the language (a good chunk of Phobos, for example, and some parts of the compiler/language -- e.g., char.init != ubyte.init) considers them as two different things, but other parts of the language (e.g. here) disregard their distinction. That this inconsistency should lead to bugs should be no surprise. The question now is, are we going to *fix* this situation at its root, or are we going to merely patch over it half-heartedly in the name of not OMG potentially breaking wrong codez! -- and thereby perpetuate this bug-prone situation? I sure hope it's not the latter. T -- The richest man is not he who has the most, but he who needs the least.
Apr 29 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/28/2017 02:11 PM, Nick Sabalausky (Abscissa) wrote:

 D takes all the current (and former!) application domains
 of C/C++, and brings to it basic programmer sanity.
When I had asked Luís Marques what the title of the talk should be, he had said import sanity; :) Ali
Apr 28 2017
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/28/2017 08:04 PM, Ali Çehreli wrote:
 On 04/28/2017 02:11 PM, Nick Sabalausky (Abscissa) wrote:

  > D takes all the current (and former!) application domains
  > of C/C++, and brings to it basic programmer sanity.

 When I had asked Luís Marques what the title of the talk should be, he
 had said

    import sanity;

 :)
Ok, now I seriously want to create a lib with that name, but the trick is to come up with something *worthy* of it :)
Apr 28 2017