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