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

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

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...

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 :)

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!)

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.

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.

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?

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
hardware not a virtual machine like Java or C#.
>
> 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.

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
> hardware not a virtual machine like Java or C#.

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...