View mode: basic / threaded / horizontal-split · Log in · Help
February 24, 2013
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
On 2/24/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> debug blocks also disable purity checking.

Ah good point.
February 24, 2013
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home