February 26, 2013
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
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
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
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
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
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
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
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
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
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.