On 4/2/13 6:04 AM, bearophile wrote:
> Jonas Drewsen:
>> Article about the expressiveness of languages with D included as one
>> of the contestants.
>>
>> http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
>>
>
> I think D is quite expressive:
> http://forum.dlang.org/thread/zdhfpftodxnvbpwvklcv@forum.dlang.org
>
> Bye,
> bearophile

I meant to comment on this - it's a terrific walkthrough. I think bearophile should convert it into a blog post/article. I think reddit would love it.

The suggestions included (such as enumerate()) are also very worth looking into.


Andrei

On 4/2/2013 1:59 PM, Andrei Alexandrescu wrote:
> On 4/2/13 6:04 AM, bearophile wrote:
>> Jonas Drewsen:
>>> Article about the expressiveness of languages with D included as one
>>> of the contestants.
>>>
>>> http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
>>>
>>>
>>
>> I think D is quite expressive:
>> http://forum.dlang.org/thread/zdhfpftodxnvbpwvklcv@forum.dlang.org
>>
>> Bye,
>> bearophile
>
> I meant to comment on this - it's a terrific walkthrough. I think bearophile
> should convert it into a blog post/article. I think reddit would love it.
>
> The suggestions included (such as enumerate()) are also very worth looking into.

I agree, it's terrific. But perhaps we can just submit it to reddit as is?

On Tuesday, 2 April 2013 at 17:33:13 UTC, Walter Bright wrote:
> On 4/2/2013 2:53 AM, Joseph Rushton Wakeling wrote:
>> I also have a strong feeling that LOC per commit reflects too many different
>> factors to be really reliable as a comparison, e.g. it probably depends quite
>> strongly on the age/maturity of a project, the rate of development, and other
>> factors.
>
> Consider also that this LOC numbers are not lines of code - they're also lines of comments! D's ddoc encourages writing considerably more lines of comments than C does.

While I don't know what this specific report used, but comments are generally factored out of LOC and have their own count.

I usually find the build in unittests to cause more skew since those are counted as LOC.

On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> I usually find the build in unittests to cause more skew since those are counted
> as LOC.

Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.

I'm inordinately pleased with how well unittests have become embedded in our D culture.

On Tue, Apr 02, 2013 at 05:01:32PM -0700, Walter Bright wrote:
> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> >I usually find the build in unittests to cause more skew since those are counted as LOC.
> 
> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
> 
> I'm inordinately pleased with how well unittests have become embedded in our D culture.

And I'm inordinately pleased with how many careless mistakes have been caught by unittests in my D code while coding, as opposed to afterwards when I'm actually using the program for something and bugs show up.


T

-- 
Тише едешь, дальше будешь.

On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> > I usually find the build in unittests to cause more skew since those are counted as LOC.
> 
> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
> 
> I'm inordinately pleased with how well unittests have become embedded in our D culture.

Yes, though I've had complaints before about a pull being too much code where the unit tests were considered part of the code, and the reviewer thought that number of lines was too great to be worth adding, even if the number of lines of normal code was relatively small. And that sort of attitude would just lead to not properly unit testing stuff. And while we do some great unit testing (the built in unit test feature is a _huge_ success in that regard), there are at least some areas where we really need to step up our game on that (with ranges in particular given all of the variations of them there are and how many static if branches many range-based functions have).

So, what we've got is great, but we can do better.

- Jonathan M Davis

On 4/2/13 10:13 PM, Jonathan M Davis wrote:
> On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
>> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
>>> I usually find the build in unittests to cause more skew since those are
>>> counted as LOC.
>>
>> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
>>
>> I'm inordinately pleased with how well unittests have become embedded in our
>> D culture.
>
> Yes, though I've had complaints before about a pull being too much code where
> the unit tests were considered part of the code, and the reviewer thought that
> number of lines was too great to be worth adding, even if the number of lines
> of normal code was relatively small. And that sort of attitude would just lead
> to not properly unit testing stuff.

I think it leads to writing less repetitive unittests.

If we did datetime all over again, I'd give a budget of 2000 lines for all functionality. I bet the solution would be better.


Andrei

On Tuesday, April 02, 2013 22:44:15 Andrei Alexandrescu wrote:
> On 4/2/13 10:13 PM, Jonathan M Davis wrote:
> > On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
> >> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> >>> I usually find the build in unittests to cause more skew since those are counted as LOC.
> >> 
> >> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
> >> 
> >> I'm inordinately pleased with how well unittests have become embedded in our D culture.
> > 
> > Yes, though I've had complaints before about a pull being too much code where the unit tests were considered part of the code, and the reviewer thought that number of lines was too great to be worth adding, even if the number of lines of normal code was relatively small. And that sort of attitude would just lead to not properly unit testing stuff.
> 
> I think it leads to writing less repetitive unittests.
> 
> If we did datetime all over again, I'd give a budget of 2000 lines for all functionality. I bet the solution would be better.

I very much doubt that you could do that unless you specifically formatted the code to take up as few lines as possible and didn't count the unit tests or documentation in that line count. Otherwise, you couldn't do anything even close to what std.datetime does in that few lines. Sure, some functionality could be stripped, but you'd end up with something that did a lot less if it were that small. The unit tests and documentation do make it seem like a lot more code than it is, since they take up well over half the file (probably 3/4), but you'd definitely lose functionality with that few lines of code, and you'd end up with something very poor IMHO if those 2000 lines included the documentation and unit tests. You'd either end up with something that was very bare-bones and/or something which was poorly tested, and given how easy it is to screw up some of those date/time calculations, having only a few tests would be a very bad idea.

std.datetime's unit tests do need some refactoring (some of which I've done, but there's still a fair bit of work to do there), which will definitely reduce the number of LOC that they take up, but I don't agree at all with considering the unit tests as part of the LOC of file when discussing keeping LOC to a minimum. And while it's good to avoid repetitive unit tests, I'd much rather have repetitive unit tests which are thorough than short ones which aren't. I find your focus on trying to keep unit tests to a minimum to be disturbing and likely to lead to poorly tested code.

If anything, we need to be more thorough, not less. That doesn't mean that the tests need to look like what std.datetime has (particularly since I purposefully avoided loops and other more complicated constructs when I wrote them originally in order to make them as simple and as far from error-prone as possible), but unit tests need to be thorough, and while we're getting better, Phobos' unit tests frequently aren't thorough enough (particularly in std.range and std.algorithm when it comes to testing a variety of range types). Too many of them just test a few cases to make sure that the most obvious stuff works rather than making sure they test corner cases and whatnot.

- Jonathan M Davis

On 4/2/2013 8:03 PM, Jonathan M Davis wrote:
> Too many of them just test a few cases to make sure that the most
> obvious stuff works rather than making sure they test corner cases and whatnot.

Currently, the datetime unittest coverage is 95%. Some of the 0 cases suggest low hanging fruit.

Despite what I just said, datetime has one of the highest unittest coverages of any phobos module. Pretty much all of the phobos module unittest coverage testing indicates more work is needed.

Minor perf improvement: the order of the tests in yearIsLeapYear() should be reversed, especially since signed divide is a very slow operation, and it is called 20 million times by the unittests!!!

On 2013-04-03 04:13, Jonathan M Davis wrote:

> Yes, though I've had complaints before about a pull being too much code where
> the unit tests were considered part of the code, and the reviewer thought that
> number of lines was too great to be worth adding, even if the number of lines
> of normal code was relatively small. And that sort of attitude would just lead
> to not properly unit testing stuff. And while we do some great unit testing
> (the built in unit test feature is a _huge_ success in that regard), there are
> at least some areas where we really need to step up our game on that (with
> ranges in particular given all of the variations of them there are and how
> many static if branches many range-based functions have).

The problem is having the unit tests in the same file. Yes, I know, most of you love it, I don't.

-- 
/Jacob Carlborg