February 24, 2013
On 02/24/2013 09:57 PM, Andrej Mitrovic wrote:
> On 2/24/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> Yeah, which just adds the confusion, because all it does is enable debug
>> bocks.
>
> The feature almost doesn't pay its weight. I mean technically you can
> use -version=Debug and then use version(Debug) blocks. All `debug`
> does is saves a little bit of typing.
>

debug blocks also disable purity checking.
February 24, 2013
On 2/24/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> debug blocks also disable purity checking.

Ah good point.
February 24, 2013
On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
> On 2/24/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> Yeah, which just adds the confusion, because all it does is enable debug
>> bocks.
>
> The feature almost doesn't pay its weight. I mean technically you can
> use -version=Debug and then use version(Debug) blocks. All `debug`
> does is saves a little bit of typing.

I should explain the reasoning for this.

I've talked to many C/C++ programming managers. They lament that every C/C++ coding group feels compelled to reinvent their own debug macro scheme. This makes it pointlessly difficult to share code between groups.

It's not that unlike how pre-C++98 code bases all had their own "string" class.

By baking one scheme into the language, people will rarely feel a need to reinvent the wheel, and will go on to more productive uses of their time.

February 24, 2013
On Sunday, February 24, 2013 14:28:42 Walter Bright wrote:
> On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
> > On 2/24/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> >> Yeah, which just adds the confusion, because all it does is enable debug bocks.
> > 
> > The feature almost doesn't pay its weight. I mean technically you can use -version=Debug and then use version(Debug) blocks. All `debug` does is saves a little bit of typing.
> 
> I should explain the reasoning for this.
> 
> I've talked to many C/C++ programming managers. They lament that every C/C++ coding group feels compelled to reinvent their own debug macro scheme. This makes it pointlessly difficult to share code between groups.
> 
> It's not that unlike how pre-C++98 code bases all had their own "string" class.
> 
> By baking one scheme into the language, people will rarely feel a need to reinvent the wheel, and will go on to more productive uses of their time.

I don't disagree with any of this. It's just that the name of the flag (-debug) is unfortunate due to the confusion it helps engender with regards to the difference between "release" and "debug" builds. I don't know what else the flag could have reasonably been called though. Alternatively, version(Debug) could have been used instead (complete with whatever special capabilities debug statements currently grant - e.g. skipping purity checks), but that also might make the feature just enough more obscure that it wouldn't be used as much.

So, I don't know that we have a good solution to the problem or that there's anything obvious that we could have done differently were we to have known better when the feature was first introduced, but there _are_ some downsides to the current scheme.

- Jonathan M Davis
February 25, 2013
On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
> On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
>> On 2/24/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>>> Yeah, which just adds the confusion, because all it does is enable debug
>>> bocks.
>>
>> The feature almost doesn't pay its weight. I mean technically you can
>> use -version=Debug and then use version(Debug) blocks. All `debug`
>> does is saves a little bit of typing.
>
> I should explain the reasoning for this.
>
> I've talked to many C/C++ programming managers. They lament that every C/C++ coding group feels compelled to reinvent their own debug macro scheme. This makes it pointlessly difficult to share code between groups.
>
> It's not that unlike how pre-C++98 code bases all had their own "string" class.
>
> By baking one scheme into the language, people will rarely feel a need to reinvent the wheel, and will go on to more productive uses of their time.

This is a fallacy caused by the "culture" of c++ programmers - there is exactly *zero* benefit in baking this into the language.
Yes, I agree with the sentiment that there should be a standard way to save programmers the hassle and all that. The correct solution to that is a culture of cultivating standard conventions and "convention over configuration". E.g. Java has many such convections followed to a level of religious zeal, such as using camelCase everywhere and using PascalCase for types, etc, etc. None of which is _enforced by the language_.
On the other hand, many major c++ libraries re-invent "string" even though there exists already std::string and there are even libraries that advocate _avoiding_ the use of stl entirely, all for the perceived benefit of efficiency which is a prime example of premature optimization. Even if there is efficiency gain in a specific implementation, ideally it should have been used to improve the standard stl::string but trying to change anything in the c++ standard is futile - you can't just send a pull request, you need to pass boat loads of red tape and wait a decade or two for the next version, thus causeing this major NIH attitude.
All of this is to say, that instead of trying to "fix" the c++ culture in D, we should try to create a *better* D culture. When you're buying an airplane ticket, what do you say to the travel agent? The human reflex of "I don't want to go to ___" doesn't get you a ticket anywhere. This feature is analogous - it's designed to not allow c++ misbehavior, instead of actually thinking what we do want and how best to achieve that. In fact there are many such "not c++" features in D and which is why I find other languages such as rust a *much* better design and it evolves much faster because it is designed in terms of - what we want to achieve, how best to implement that.
February 25, 2013
On 2/25/2013 2:00 PM, foobar wrote:
> On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
>> By baking one scheme into the language, people will rarely feel a need to
>> reinvent the wheel, and will go on to more productive uses of their time.
> This is a fallacy caused by the "culture" of c++ programmers - there is exactly
> *zero* benefit in baking this into the language.

On the contrary, I think it has turned out rather well. Another success story of baking certain things into the language is Ddoc. Unittest is a third. They've been big wins for D.

None of those strictly has to be in the language - they can be done by convention and 3rd party tools. Nevertheless, convenience, standardization and mechanical enforcement of a convention seem to work better than applying religious zeal to enforce a convention.


> All of this is to say, that instead of trying to "fix" the c++ culture in D, we
> should try to create a *better* D culture.

We do have a significantly better D culture than the C++ one. For example, C++ relies heavily and unapologetically on convention for writing correct, robust code. D eschews that, and instead is very biased towards mechanical verification.


>  In fact there are many such "not c++"
> features in D and which is why I find other languages such as rust a *much*
> better design and it evolves much faster because it is designed in terms of -
> what we want to achieve, how best to implement that.

How does rust handle this particular issue?
February 26, 2013
On Monday, 25 February 2013 at 22:26:33 UTC, Walter Bright wrote:
> On 2/25/2013 2:00 PM, foobar wrote:
>> On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
>>> By baking one scheme into the language, people will rarely feel a need to
>>> reinvent the wheel, and will go on to more productive uses of their time.
>> This is a fallacy caused by the "culture" of c++ programmers - there is exactly
>> *zero* benefit in baking this into the language.
>
> On the contrary, I think it has turned out rather well. Another success story of baking certain things into the language is Ddoc. Unittest is a third. They've been big wins for D.
>
> None of those strictly has to be in the language - they can be done by convention and 3rd party tools. Nevertheless, convenience, standardization and mechanical enforcement of a convention seem to work better than applying religious zeal to enforce a convention.
>

DDoc isn't part of the language but rather part of the compiler, nevertheless it has its downsides. Being part of the compiler means that the compiler needs to be changed to address those and it isn't even written in D! The end result is all sort of additional auxiliary D utilities to post-process this in order to address some of those issues. Hence, A prime example of the failure that I'm talking about.

unittest is worse, it is indeed part of the language so now the _language grammar_ needs to be changed to fix the problems with it, such as not having test names. A far better solution practiced in all other major languages is to use annotations and in fact, there probably already are similar D frameworks, thus exhibiting the same problem of multiple conflicting implementations you wished to avoid.

Additional such problems - the AA issue which has been going own for years now. The endless discussions regarding tuples.
It seems that D strives to bloat the language with needless features that really should have been standardized in the library and on the other hand tries to put in the library things that really ought to be built into the language to benefit from proper integration and syntax.

The latest case was the huge properties debate and its offshoots regarding ref semantics which I didn't even bother participate in. Bartosz developed an ownership system for D to address all the safety issues raised by ref *years ago* and it was rejected due to complexity. Now, Andrei tries to achieve similar safety guaranties by giving ref the semantics of borrowed pointers. It all seems to me like trying to build an airplane without wings cause they are too complex. Rust on the other hand already integrated an ownership system and is already far ahead of D's design. D had talked about macros *years ago* and rust already implemented them.

>
>> All of this is to say, that instead of trying to "fix" the c++ culture in D, we
>> should try to create a *better* D culture.
>
> We do have a significantly better D culture than the C++ one. For example, C++ relies heavily and unapologetically on convention for writing correct, robust code. D eschews that, and instead is very biased towards mechanical verification.
>

I call bullshit. This is an half hearted intention at best.
@safe has holes in it, integers has no overflow checks, ref also has holes, Not only D has null pointer bugs but they also cause segfaults.

>
>> In fact there are many such "not c++"
>> features in D and which is why I find other languages such as rust a *much*
>> better design and it evolves much faster because it is designed in terms of -
>> what we want to achieve, how best to implement that.
>
> How does rust handle this particular issue?

February 26, 2013
On Tuesday, 26 February 2013 at 07:56:05 UTC, foobar wrote:
> The latest case was the huge properties debate and its offshoots regarding ref semantics which I didn't even bother participate in. Bartosz developed an ownership system for D to address all the safety issues raised by ref *years ago* and it was rejected due to complexity. Now, Andrei tries to achieve similar safety guaranties by giving ref the semantics of borrowed pointers. It all seems to me like trying to build an airplane without wings cause they are too complex. Rust on the other hand already integrated an ownership system and is already far ahead of D's design. D had talked about macros *years ago* and rust already implemented them.
>

Do you have a link to that ? I know that he did, but never could find the proposal itself.
February 26, 2013
On 2013-02-26 08:56, foobar wrote:

> DDoc isn't part of the language but rather part of the compiler,
> nevertheless it has its downsides. Being part of the compiler means that
> the compiler needs to be changed to address those and it isn't even
> written in D! The end result is all sort of additional auxiliary D
> utilities to post-process this in order to address some of those issues.
> Hence, A prime example of the failure that I'm talking about.

Having to use the JSON output to generate documentation just shows that DDoc is lacking.

> unittest is worse, it is indeed part of the language so now the
> _language grammar_ needs to be changed to fix the problems with it, such
> as not having test names. A far better solution practiced in all other
> major languages is to use annotations and in fact, there probably
> already are similar D frameworks, thus exhibiting the same problem of
> multiple conflicting implementations you wished to avoid.

There are already several testing frameworks for D. The only thing I think the "unittest" keyword is useful for, is creating a block where to put the code. The rest will my framework handle.

> Additional such problems - the AA issue which has been going own for
> years now. The endless discussions regarding tuples.
> It seems that D strives to bloat the language with needless features
> that really should have been standardized in the library and on the
> other hand tries to put in the library things that really ought to be
> built into the language to benefit from proper integration and syntax.
>
> The latest case was the huge properties debate and its offshoots
> regarding ref semantics which I didn't even bother participate in.
> Bartosz developed an ownership system for D to address all the safety
> issues raised by ref *years ago* and it was rejected due to complexity.
> Now, Andrei tries to achieve similar safety guaranties by giving ref the
> semantics of borrowed pointers. It all seems to me like trying to build
> an airplane without wings cause they are too complex. Rust on the other
> hand already integrated an ownership system and is already far ahead of
> D's design. D had talked about macros *years ago* and rust already
> implemented them.

I agree in general.

-- 
/Jacob Carlborg
February 26, 2013
I agree with all but small comment on unit tests : current approach makes it really easy to start adding tests for projects that do not have them and this is huge. So having "unittest" blocks themselves is really a success feature. Tightly coupling handling of this blocks to compiler is an issue though.