View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
Re: Are there any default dmd optimizations
On 2/26/13 2:56 AM, 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.
>
> 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.

I think this is unnecessarily negative because far as I can tell ddoc 
and unittest are features that people use and appreciate. BTW no need to 
change the grammar for improving unittests, only an API is sufficient - 
consider e.g.:

@"name" unittest { ... }

or simply

unittest {
   testName("name");
   ...
}

One can find negatives of most any feature.

> Additional such problems - the AA issue which has been going own for
> years now. The endless discussions regarding tuples.

There are plenty of cases in which discussions have been concluded with 
successful improvements. We can't tell people what to work on, so some 
are longer than others.

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

If I wanted to clarify how subjective that is, I couldn't have written 
it better :o).

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

That was for threads.

> 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 think Rust has gone a bit too far with with complexity of the type 
system. There's only this much karma one can spend for such. In my 
opinion we're in better shape than Rust in that particular regard.

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

Last one is different. Anyhow, it is a certainty we regard e.g. @safe 
hole as problems that need fixing, which is a significant cultural 
difference. At any rate, I agree one ought to be suspicious whenever 
someone claims "Language X's culture is better than language Y's culture."


Andrei
February 26, 2013
Re: Are there any default dmd optimizations
On 2/26/13, foobar <foo@bar.com> wrote:
> Rust on the other hand already
> integrated an ownership system and is already far ahead of D's
> design.

Far ahead? It allows things like local variables shadowing earlier declarations:

let monster_size = monster_factor * 10.0;
...
let monster_size: int = 50;

That's straight from the tutorial. When has anyone thought to
themselves "I need a new variable to store some result to, but damn, I
wish I could use an existing name but use it to store a completely
different type". That is an incentive to write unreadable code.

And then there are things like this:

"Note that, if applied to an integer value, ! flips all the bits (like ~ in C)."

So (!2 == true)?

There are plenty of complaints for both languages (it's only natural),
but saying that Rust is somehow far ahead, I don't buy that one bit.
It's all too easy to cherrypick features which are in one language and
not in the other.
February 26, 2013
Re: Are there any default dmd optimizations
On 2/25/2013 11:56 PM, foobar wrote:
> DDoc isn't part of the language but rather part of the compiler, nevertheless it
> has its downsides.  [...]
> unittest is worse,

I think you're missing something gigantic. Before D had ddoc, the documentation 
for Phobos was TERRIBLE - it was mostly missing, and the rest would describe 
something that had no resemblance to what the code did. Adding Ddoc completely 
revolutionized this. It's like night and day. Sure, you can pick at Ddoc's flaws 
all day, but without Ddoc, the Phobos documentation would have remained utter s**t.

Yes, one could use Doxygen. One could hope an up-to-date version exists on all 
the platforms D is on. One could nag people to use it. One could argue with 
people who wanted to use a different doc generator. And one could look at 
typical C and C++ projects, which use no documentation generator at all, and 
pretty much have no documentation or have documentation as bad as the pre-Ddoc 
Phobos docs.

Having Ddoc always there, always installed, always up to date, with literally 
zero effort, tips the balance. It gets used. It raised the bar on what is 
acceptable D code - it looks wrong without Ddoc documentation. By tipping the 
balance I mean it *revolutionized* D code.

The same goes for unittest. How many C/C++ projects have you run across that 
have unit tests? Again, yes, you can use 3rd party tools (of which there are a 
plethora). You can try to use multiple libraries that use different unit test 
frameworks. You can look at Phobos before unittest and see that it was pretty 
much completely untested.

Unittest in the language, always there, always installed, zero effort, 
completely changed the game. I'm very pleased at the depth and breadth of 
unittests in Phobos. I have no doubt that would not have happened without unittest.

Sure, you can pick all day at the flaws of unittest, but you'd be missing the 
point - without builtin unittest, there'd be nothing to pick at, because people 
would not have unit tests.


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

A little history is in order here. AA's were built in to the language from the 
beginning, a result of my experience with how incredibly useful they were in 
javascript. This was many years before D had templates. There was no other way 
at the time to implement them in a nice manner (try doing it in C, for example).

D's improving generics has enabled them to be redone as library features.


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

Bartosz' ownership system was intended to support multithreaded programming. It 
was and still is too complicated. I've been working on another design which 
should serve the purpose and will need nearly zero effort from the programmer 
and it won't break anything. There was some discussion last fall on the n.g. 
about it.


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

Yes, and those are bugs, and we have every intention of fixing all of them.


> integers has no overflow checks,

This has been discussed ad nauseum. To sum up, adding overflow checks everywhere 
would seriously degrade performance. Yet you can still have overflow checking 
integers if you build a library type to do it. See std.halffloat for an example 
of how to do it. It fits in with your suggestion that things that can be done in 
the library, should be done in the library.

> ref also has holes,

Yes, and we are actively working to fix them.


> Not only D has null pointer bugs but they also cause segfaults.

D now has all the features to create a library type NotNull!T, which would be a 
pointer type that is guaranteed to be not null.


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

I presume rust does not have an official answer to the debug conditional issue 
and leaves it up to the user?
February 26, 2013
Re: Are there any default dmd optimizations
On Tuesday, February 26, 2013 11:53:11 Walter Bright wrote:
> On 2/25/2013 11:56 PM, foobar wrote:
> > DDoc isn't part of the language but rather part of the compiler,
> > nevertheless it has its downsides. [...]
> > unittest is worse,
> 
> I think you're missing something gigantic.
[SNIP]

I agree with all of this. Ddoc and the built-in unit testing features may not 
be perfect, but they put us light years ahead of most everyone else. They 
actually get _used_. If it's at all difficult to generate documentation or write 
unit tests, they just don't happen in far too many cases. We are _way_ better 
off with these. It's quite possible that improvements could be made to their 
feature set, and it's quite possible that improvements could be made to how 
they're implemented in order to make improving them easier, but we are _way_ 
better off having them.

And the fact that they exist costs you _nothing_ if you want to use 3rd party 
stuff like you would in C++. You can write your own unit test framework and not 
even use -unittest. You can use doxygen if you want to. Nothing is stopping 
you.

But by having all of this built in, it actually gets used, and we have decent 
documentation and unit testing. They're features in D which have a _huge_ 
impact, even if they don't first appear like they would.

- Jonathan M Davis
February 26, 2013
Re: Are there any default dmd optimizations
On 2/26/13, Walter Bright <newshound2@digitalmars.com> wrote:
> Sure, you can pick all day at the flaws of unittest, but you'd be missing
> the
> point - without builtin unittest, there'd be nothing to pick at, because
> people
> would not have unit tests.

Also you can implement your own unittest runner function and do some
cool customizations, e.g. selecting which unittests will or will not
be run, displaying success/failure information, etc.
(Runtime.moduleUnitTester is the cutomization point).
February 26, 2013
Re: Are there any default dmd optimizations
On Tue, Feb 26, 2013 at 11:53:11AM -0800, Walter Bright wrote:
> On 2/25/2013 11:56 PM, foobar wrote:
> >DDoc isn't part of the language but rather part of the compiler,
> >nevertheless it has its downsides.  [...]
> >unittest is worse,
> 
> I think you're missing something gigantic. Before D had ddoc, the
> documentation for Phobos was TERRIBLE - it was mostly missing, and
> the rest would describe something that had no resemblance to what
> the code did. Adding Ddoc completely revolutionized this. It's like
> night and day. Sure, you can pick at Ddoc's flaws all day, but
> without Ddoc, the Phobos documentation would have remained utter
> s**t.

I have to say that even though ddoc hasn't quite grown on me yet, I did
start using it recently for one of the generic modules I was working on
for my personal projects, and, for all its warts and shortcomings, it's
incredibly handy, and actually makes you *want* to write documentation
for your code. I mean, it's right there, you just have to type it in and
you'll get the docs. YMMV, but personally I find ddoc actually very
helpful in improving the general quality of D code. My D code has
improved because having to write docs for functions actually made me
think about some corner cases I would've overlooked otherwise.


> Yes, one could use Doxygen. One could hope an up-to-date version
> exists on all the platforms D is on. One could nag people to use it.
> One could argue with people who wanted to use a different doc
> generator. And one could look at typical C and C++ projects, which use
> no documentation generator at all, and pretty much have no
> documentation or have documentation as bad as the pre-Ddoc Phobos
> docs.

I've tried to use Doxygen before. I hate it. It feels like something
patched onto a deficient language, and just doesn't integrate well with
the workflow (nobody wants to run make docs when it might potentially
lengthen the code-compile-test cycle). Whereas ddoc is done as you
compile, so you get it "for free". It assumes users actually have it
installed, which most don't, and ... the number of C/C++ projects I've
seen the source code of, that uses Doxygen, can be counted on one hand.
Maybe less. Most just have outdated comments (if at all!), haphazardly
formatted, and usually inaccurate because people have patched changes
without updating the comments (nobody wants to, because there's no
standard format, and nobody wants to edit typo-filled non-punctuated
remarks on the off-chance that it might actually be saying something
important).


> Having Ddoc always there, always installed, always up to date, with
> literally zero effort, tips the balance. It gets used. It raised the
> bar on what is acceptable D code - it looks wrong without Ddoc
> documentation. By tipping the balance I mean it *revolutionized* D
> code.

+1. Well, +0.5, 'cos I'm still not fully sold on ddoc yet... but I'm
starting to.


> The same goes for unittest. How many C/C++ projects have you run
> across that have unit tests? Again, yes, you can use 3rd party tools
> (of which there are a plethora). You can try to use multiple
> libraries that use different unit test frameworks. You can look at
> Phobos before unittest and see that it was pretty much completely
> untested.
> 
> Unittest in the language, always there, always installed, zero
> effort, completely changed the game. I'm very pleased at the depth
> and breadth of unittests in Phobos. I have no doubt that would not
> have happened without unittest.

Yeah, unittests have improved the quality of my code by leaps and
bounds. Especially in the area of regressions: sure you don't need
built-in unittests to get it right the first time, but what about when
you made the 500-line diff adding a brand new feature? Most of the time,
when I do that, I introduce tons of regressions that I'm not even aware
of until I run into them much later. Nothing is a better wakeup call
than patching the diff in, compiling with -unittest, running the
program, and oops, unittest failure left, right, and center! Better fix
all those regressions! Result: you find bugs early, before they show up
in production environments.


> Sure, you can pick all day at the flaws of unittest, but you'd be
> missing the point - without builtin unittest, there'd be nothing to
> pick at, because people would not have unit tests.

Yep, that's me. I hated unittesting, 'cos I felt it was a waste of time.
I had to put the code on hold, switch to a different language made for
unittesting (like python or Tcl/Expect or whatever), write tests in a
different directory, which then get out of sync with the latest code,
and become too troublesome to update, so you disable them then forget to
re-enable them later after things are updated, etc.. It's just lots of
needless overhead.

But D's built-in unittests, for all their warts and shortcoming, have
the benefit of being right there, ready to use, and guaranteed to be
runnable by whoever is compiling the code (don't have to worry about
people not having Expect/python/whatever installed, so contributors have
no excuse to not run them, etc.). Plus, it's in pure D syntax, so my
brain doesn't have to keep switching gears, which means I'm more likely
to actually write them. And there's no need of painstakingly building
lots of scaffolding for unittesting, which is the problem when I begin
most projects 'cos the code is too small to justify the effort of
setting up a unittesting environment, but then once the code grows, too
much code isn't unittested as they should be, and by then, it's kinda
too late to remember all the corner cases you need to check for.  As is
the case with ddocs, writing unittests while you're coding makes you
think about corner cases you may have overlooked, all while the code is
fresh in your mind, as opposed to 20 minutes later when that potentially
dangerous pointer manipulation may have been forgotten and lurks in the
code until much later.

So yeah. Complain as you may about the flaws of D's unittests, but they
sure have helped improve my code significantly.


> >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.
> 
> A little history is in order here. AA's were built in to the
> language from the beginning, a result of my experience with how
> incredibly useful they were in javascript. This was many years
> before D had templates. There was no other way at the time to
> implement them in a nice manner (try doing it in C, for example).
> 
> D's improving generics has enabled them to be redone as library
> features.
[...]

Not to mention that many of current AA issues were introduced later when
people tried to extend it in ways not originally conceived. Like
supporting ranges -- which required the schizophrenic duplication of
internal data structures in object_.d -- a horrible idea, to say the
least, but I can totally sympathize with why it would be preferable to
holding off and waiting indefinitely for the ideal solution, and thus
having zero range support for a looong time.


T

-- 
Stop staring at me like that! You'll offend... no, you'll hurt your eyes!
February 26, 2013
Re: Are there any default dmd optimizations
On 2/26/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Most just have outdated comments (if at all!)

Some projects even maintain documentation *separately* from the
codebase, which leads to a ton of outdated stuff. For example look at
the list of documentation fixes I made for wxWidgets:
http://trac.wxwidgets.org/query?reporter=drey&order=priority
February 26, 2013
Re: Are there any default dmd optimizations
On Tue, Feb 26, 2013 at 09:41:09PM +0100, Andrej Mitrovic wrote:
> On 2/26/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> > Most just have outdated comments (if at all!)
> 
> Some projects even maintain documentation *separately* from the
> codebase, which leads to a ton of outdated stuff. For example look at
> the list of documentation fixes I made for wxWidgets:
> http://trac.wxwidgets.org/query?reporter=drey&order=priority

I thought that was the norm? Especially in the realm of open source, the
problem of docs mismatching implementation is sadly very prevalent.

The thing is, when code comments are so poor, nobody would even imagine
using them as user-consumable docs. And so docs are written separately.
But coders love to code; docs are in another format in another subdir,
who cares about updating it when you just have a 1-line fix?

It's a totally different ball game when the ddoc comments are staring
you in the face, right in the source code, crying out "update me! update
me!".

I'm not pretending that it solves the mismatch problem entirely, of
course. You *can* still change the code without updating the ddocs. But
you're much more likely to update it because it's right there in front
of you, not somewhere else in some obscure subdirectory, out of sight
and out of mind. I'd even say having the ddocs embedded in the code
*shames* you into updating it, in much the same way as built-in unittest
blocks shames you into writing them (so much so, that just this past few
days, upon revisiting some of my earlier D code, I was horrified at the
huge swaths of unittest-free code -- writing unittests have become such
a habit to me now -- and now I feel too ashamed to not start writing
unittests for that code).


T

-- 
Many open minds should be closed for repairs. -- K5 user
February 26, 2013
Re: Are there any default dmd optimizations
On Tuesday, 26 February 2013 at 10:59:41 UTC, Dicebot wrote:
> 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.

Again, this is a completely superfluous feature. D already has 
annotations (took only several years to convince Walter to add 
them) which are more flexible and much better suited for this.

@unittest // <- this is a unit-test function
void mySuperDuperTestFunction(...);

There is no benefit in having all those special case features in 
the language which have all sorts of integration issues yet deny 
the usefulness of a more general solution generally accepted in 
the programming world, successfully used in many languages and 
thus also familiar to programmers coming from those languages.
February 26, 2013
Re: Are there any default dmd optimizations
On Tuesday, 26 February 2013 at 18:41:24 UTC, Andrej Mitrovic 
wrote:
> On 2/26/13, foobar <foo@bar.com> wrote:
>> Rust on the other hand already
>> integrated an ownership system and is already far ahead of D's
>> design.
>
> Far ahead? It allows things like local variables shadowing 
> earlier declarations:
>
> let monster_size = monster_factor * 10.0;
> ...
> let monster_size: int = 50;
>
> That's straight from the tutorial. When has anyone thought to
> themselves "I need a new variable to store some result to, but 
> damn, I
> wish I could use an existing name but use it to store a 
> completely
> different type". That is an incentive to write unreadable code.
>
> And then there are things like this:
>
> "Note that, if applied to an integer value, ! flips all the 
> bits (like ~ in C)."
>
> So (!2 == true)?
>
> There are plenty of complaints for both languages (it's only 
> natural),
> but saying that Rust is somehow far ahead, I don't buy that one 
> bit.
> It's all too easy to cherrypick features which are in one 
> language and
> not in the other.

I don't get what fault you find in the binary NOT operation.
Regardless, my post wasn't really about specific features, 
(Walter actually mentioned those) but rather about the general 
design philosophy of D which I find lacking. Yes, it is obviously 
true that Rust has it own share of faults, The difference is what 
*principals* they use to address those faults and evolve the 
language.
Rust is written in Rust, thus the developers themselves feel all 
the shortcomings, they also listen to their users and they strive 
to find the best way to express the semantics they want in the 
possibly simplest yet readable syntax possible. They think 
positive and build on their vision, whereas D thinks negatively 
based on C++'s vision.
D exists for more than a decade and all it provides is slightly 
less hackish C++.
At first, I dismissed Rust for having poor syntax ("ret" really? 
Are we back to assembly?) but lo and behold, in a very short time 
they considerably improved the syntax. D still argues about the 
exact same issues from several years ago, as if it's stuck in a 
time loop. This to me shows a lack of direction. I expected thing 
to improve lately with all those newly minted release process 
discussions and such, but alas the attitude hasn't shifted at all.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home