Why is D unpopular? (page 76)

On Monday, 23 May 2022 at 13:55:34 UTC, wjoe wrote: > On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote: >> [...] >> Asserts are removed in release mode unless it is assert(0). Its idiotic. > > Isn't that C behavior though? C asserts are included or not based on various defines.

On Monday, 23 May 2022 at 14:07:32 UTC, deadalnix wrote: > On Monday, 23 May 2022 at 13:55:34 UTC, wjoe wrote: >> On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote: >>> [...] >>> Asserts are removed in release mode unless it is assert(0). Its idiotic. >> >> Isn't that C behavior though? > > C asserts are included or not based on various defines. It's rather odd, that it's so much easier in C. // uncomment to disable assert() // #define NDEBUG (whereas) .. So much mucking around in D. It's ridiculous.

On Monday, 23 May 2022 at 22:05:23 UTC, forkit wrote: > On Monday, 23 May 2022 at 14:07:32 UTC, deadalnix wrote: >> On Monday, 23 May 2022 at 13:55:34 UTC, wjoe wrote: >>> On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote: >>>> [...] >>>> Asserts are removed in release mode unless it is assert(0). Its idiotic. >>> >>> Isn't that C behavior though? >> >> C asserts are included or not based on various defines. > > It's rather odd, that it's so much easier in C. > > // uncomment to disable assert() > // #define NDEBUG > > (whereas) .. So much mucking around in D. It's ridiculous. It's a command line option versus a macro (likely supplies on the command line). It's just fuss over nothing.

On 5/23/2022 7:07 AM, deadalnix wrote: > C asserts are included or not based on various defines. Building them in offers some semantic advantages, 1. being able to get them to do things line insert a HLT instruction 2. format an error message based on stringizing the expression 3. people won't be motivated to create their own

On 5/23/2022 4:54 AM, bauss wrote: > On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote:> >> >> Sometimes it feels like D is intent on finding the most ways to reuse the same keyword to mean different things in different contexts. > > alias says hi static was already taken

On Tuesday, 24 May 2022 at 02:05:39 UTC, Walter Bright wrote: > On 5/23/2022 7:07 AM, deadalnix wrote: >> C asserts are included or not based on various defines. > > Building them in offers some semantic advantages, > > 1. being able to get them to do things line insert a HLT instruction > 2. format an error message based on stringizing the expression > 3. people won't be motivated to create their own Another reason is that forcing people down a blessed road means that the means you provide for fiddling with behaviour can be composed together much more easily (whether this be some runtime hook or merely all Assertions throwing the same Error).

On Monday, 23 May 2022 at 22:42:52 UTC, max haughton wrote: > On Monday, 23 May 2022 at 22:05:23 UTC, forkit wrote: >> On Monday, 23 May 2022 at 14:07:32 UTC, deadalnix wrote: >>> On Monday, 23 May 2022 at 13:55:34 UTC, wjoe wrote: >>>> On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote: >>>>> [...] >>>>> Asserts are removed in release mode unless it is assert(0). Its idiotic. >>>> >>>> Isn't that C behavior though? >>> >>> C asserts are included or not based on various defines. >> >> It's rather odd, that it's so much easier in C. >> >> // uncomment to disable assert() >> // #define NDEBUG >> >> (whereas) .. So much mucking around in D. It's ridiculous. > > It's a command line option versus a macro (likely supplies on the command line). It's just fuss over nothing. I don't fuss over 'nothing'. First, I have to 'remember' that assert is removed in -release, but that depends on how you've actually used it. Then, in order to leave my assert's in production code, I need to 'remember' not to compile with -release, but rather -someothercrap I can't remember at the moment. So while it's not the end of the world, it's also not 'nothing'.

On Tuesday, 24 May 2022 at 06:12:40 UTC, forkit wrote: > On Monday, 23 May 2022 at 22:42:52 UTC, max haughton wrote: >> On Monday, 23 May 2022 at 22:05:23 UTC, forkit wrote: >>> On Monday, 23 May 2022 at 14:07:32 UTC, deadalnix wrote: >>>> On Monday, 23 May 2022 at 13:55:34 UTC, wjoe wrote: >>>>> On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote: >>>>>> [...] >>>>>> Asserts are removed in release mode unless it is assert(0). Its idiotic. >>>>> >>>>> Isn't that C behavior though? >>>> >>>> C asserts are included or not based on various defines. >>> >>> It's rather odd, that it's so much easier in C. >>> >>> // uncomment to disable assert() >>> // #define NDEBUG >>> >>> (whereas) .. So much mucking around in D. It's ridiculous. >> >> It's a command line option versus a macro (likely supplies on the command line). It's just fuss over nothing. > > I don't fuss over 'nothing'. > > First, I have to 'remember' that assert is removed in -release, but that depends on how you've actually used it. > > Then, in order to leave my assert's in production code, I need to 'remember' not to compile with -release, but rather -someothercrap I can't remember at the moment. > > So while it's not the end of the world, it's also not 'nothing'. This is very close to nothing when it comes to actually shipping code. By the time you have something in "production" you will have bigger things to worry about than implementing your policy for assertions i.e. reading the manual. The idea of a release build is something of a mistake anyway, it's usually not exactly right for a given purpose so you're better off specifying exactly what you want instead anyway. I use the flag more often on compiler explorer than anything else.

May 24, 2022

Re: Why is D unpopular?

Posted by Siarhei Siamashka
in reply to max haughton

Permalink

Siarhei Siamashka

Posted in reply to max haughton

Permalink

On Tuesday, 24 May 2022 at 07:02:29 UTC, max haughton wrote:

The idea of a release build is something of a mistake anyway, it's usually not exactly right for a given purpose so you're better off specifying exactly what you want instead anyway.

I strongly disagree with this opinion. When shipping a product as a source code, end users may use various wild combinations of compiler options to build it. This may result in sub-optimal performance if some of the important options are forgotten. Or this may result in program misbehavior if it gets miscompiled by some super duper experimental options. It's also difficult to test all possible permutations of the available build options.

So having the '-release' option, which provides reasonable and mostly optimal defaults is very useful. In reality https://en.wikipedia.org/wiki/Safety_in_numbers is also a thing. If the majority of users use the same build options, then they are likely to encounter the same bugs and/or performance problems in the compiler, report these problems and have these problems resolved. Autovectorization and LTO are somewhat immature and controversial, but if they were rock solid and never regressed anything, then I would like to see them included as a part of the default '-release' options bundle too (that's of course a big IF).

When developing free open source software in C/C++, I had to deal with the end users or distro maintainers picking bad compilation options on more than one occasion. In my experience, fine grained individual optimization options to enable or disable something are mostly useful for troubleshooting compiler bugs.

Considering what I said above, it's not surprising that D is also often misconfigured on various programming competition websites (which is probably not a very important use case, but it still shows the language in a bad light):

Forums