----- Original Message -----
> From:Andrei Alexandrescu <andrei at erdani.com>
> On 2/10/11 9:50 AM, Steve Schveighoffer wrote:
> > ----- Original Message -----
> >> From:Andrei Alexandrescu<andrei at erdani.com>
> >> std.datetime has 34219 lines, which accounts for over 26% of the entire
> Phobos
> >> size. If Jonathan will (as he promised, I didn't forget :o)) fix
> line sizes
> >> to conform to 80 columns, then std.datetime will become 40961 lines, or
> straight
> >> 30% of Phobos.
> >> 
> >> (This might have to do with the increase of "hello, world"
> that was
> >> noted by some people on the compiler list.)
> > 
> > I don't think so, but I cannot be sure. I'd say a full 75-90% of std.datetime is unit tests or documentation.  That shouldn't increase the size of the lib, and certainly not by as much as it does.
> 
> It increases the size of the source that someone looking at the library must navigate and absorb.
> 
> In case I wasn't clear: my concern is source size. I am now sorry I mentioned library size, and twice so because I didn't verify the hypothesis.

OK, source size.  But still, the "relevant" source size is small.  The unit test source size is large, but who's reading all the unit tests?  Won't people skip over those?

> It is difficult to believe that a library needs that much unittests in terms of sheer size. The more I browse through std.datetime, the more firmly my hair is standing up on my head. It's most all large hand-unrolled loops. I am now sorry I voted for the library without having raised a flag at this very serious problem. I didn't realize its size back then.

I guess I just don't see it as a problem.  Source *size* doesn't concern me, quality does.

As for the amount of unittests, I feel like it's up to the developer to provide unit tests, and if he/she prefers to provide extra unit tests, that's fine.  I think the number of unit tests should be greater than 0, no upper limit.  And my unit tests are usually not looped because unit test failures usually give you a line that failed.  If you loop them, then you're not sure what loop iteration failed.

> >> I understand there are factors that contribute to that: date and time manipulation is a bulky endeavor, there's a ton of unittests, and there's a lot of documentation. But at a level I find it difficult
> to digest
> >> the fact that in sheer numbers date and time manipulation accounts for
> 30% of
> >> Phobos. As a comparison point, std.algorithm does arguably a lot of
> work, has
> >> adequate documentation, and has unittest coverage at 95%, yet does all
> that in a
> >> "measly" 8027 lines.
> 
> > Lines of file does not mean % of a library, especially when a large portion of it is not compiled.  I think we need to stop this prejudice against uncompiled LOC.  I fully support having unit tests next to the code being tested, it's the whole point of the builtin unit test system in D.
> 
> I am sorry, I disagree with discounting LOC. LOC is LOC. Compiled or uncompiled it is intellectual overhead. We need to write good code, code that we provide as living examples on how to write quality programs. Good code is not unrolled loops. Well, except sometimes :o).

Sorry to also disagree :)  Veritcal space isn't code, documentation is not code, unit tests are code, but only relevant if you are reviewing unit tests.  LOC to me is the code that you have to read to understand how the library works.  unit tests don't qualify.  Most editors have folding ability or an ability to skip to the matching bracket.  This makes it irrelevant how many lines a unit tests occupies if you are skipping over it.

And if you aren't reviewing the library, you just want the API, you should be using the generated docs, which have nothing to do with LOC.

-Steve

On 02/11/2011 12:00 AM, Steve Schveighoffer wrote:
> Sorry to also disagree :)  Veritcal space isn't code, documentation is not code, unit tests are code, but only relevant if you are reviewing unit tests.  LOC to me is the code that you have to read to understand how the library works.  unit tests don't qualify.  Most editors have folding ability or an ability to skip to the matching bracket.  This makes it irrelevant how many lines a unit tests occupies if you are skipping over it.
>
> And if you aren't reviewing the library, you just want the API, you should be using the generated docs, which have nothing to do with LOC.

I agree with this point of view.

<grumbling>
On the practical side, I'm much more annoyed by ddoc requiring doc to be placed
outside what it documents, thus artificially and uselessly doubling the
vertical space used, /in the best case/ where one's favorite editor properly
folds multiline D comments (which mine only very recently learnt to do).
</grumbling>

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Feb 11, 2011, at 12:00 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

>
>
>
>
> ----- Original Message -----
>> From:Andrei Alexandrescu <andrei at erdani.com>
>> On 2/10/11 9:50 AM, Steve Schveighoffer wrote:
>>> ----- Original Message -----
>>>> From:Andrei Alexandrescu<andrei at erdani.com>
>>>> std.datetime has 34219 lines, which accounts for over 26% of the
>>>> entire
>> Phobos
>>>> size. If Jonathan will (as he promised, I didn't forget :o)) fix
>> line sizes
>>>> to conform to 80 columns, then std.datetime will become 40961 lines, or
>> straight
>>>> 30% of Phobos.
>>>>
>>>> (This might have to do with the increase of "hello, world"
>> that was
>>>> noted by some people on the compiler list.)
>>>
>>> I don't think so, but I cannot be sure. I'd say a full 75-90% of
>>> std.datetime is unit tests or documentation.  That shouldn't
>>> increase
>>> the size of the lib, and certainly not by as much as it does.
>>
>> It increases the size of the source that someone looking at the
>> library must
>> navigate and absorb.
>>
>> In case I wasn't clear: my concern is source size. I am now sorry I mentioned library size, and twice so because I didn't verify the hypothesis.
>
> OK, source size.  But still, the "relevant" source size is small.

All code is relevant.

> The unit test source size is large, but who's reading all the unit tests?

People who look at the file.

> Won't people skip over those?

Skipping is overhead, particularly when relevant content is drowned in a sea of chaff.


>
>> It is difficult to believe that a library needs that much unittests
>> in terms of
>> sheer size. The more I browse through std.datetime, the more firmly
>> my hair is
>> standing up on my head. It's most all large hand-unrolled loops. I
>> am now
>> sorry I voted for the library without having raised a flag at this
>> very serious
>> problem. I didn't realize its size back then.
>
> I guess I just don't see it as a problem.  Source *size* doesn't concern me, quality does.
>

This goes without saying.

> As for the amount of unittests, I feel like it's up to the developer to provide unit tests, and if he/she prefers to provide extra unit tests, that's fine.

Honest, I felt the same but datetime proved me exaggeration is harmful.

> I think the number of unit tests should be greater than 0, no upper limit.

Again I used to think the same. I've since recanted.

> And my unit tests are usually not looped because unit test failures usually give you a line that failed.  If you loop them, then you're not sure what loop iteration failed.
>
>>>> I understand there are factors that contribute to that: date and
>>>> time
>>>> manipulation is a bulky endeavor, there's a ton of unittests, and
>>>> there's a lot of documentation. But at a level I find it difficult
>> to digest
>>>> the fact that in sheer numbers date and time manipulation accounts for
>> 30% of
>>>> Phobos. As a comparison point, std.algorithm does arguably a lot of
>> work, has
>>>> adequate documentation, and has unittest coverage at 95%, yet does all
>> that in a
>>>> "measly" 8027 lines.
>>
>>> Lines of file does not mean % of a library, especially when a large portion of it is not compiled.  I think we need to stop this prejudice against uncompiled LOC.  I fully support having unit tests next to the code being tested, it's the whole point of the builtin unit test system in D.
>>
>> I am sorry, I disagree with discounting LOC. LOC is LOC. Compiled
>> or uncompiled
>> it is intellectual overhead. We need to write good code, code that
>> we provide as
>> living examples on how to write quality programs. Good code is not
>> unrolled
>> loops. Well, except sometimes :o).
>
> Sorry to also disagree :)  Veritcal space isn't code, documentation is not code, unit tests are code, but only relevant if you are reviewing unit tests.

Vertical space is informational real estate.

> LOC to me is the code that you have to read to understand how the library works.

LOC is loc, period.

> unit tests don't qualify.
> Most editors have folding ability or an ability to skip to the
> matching bracket.

Structured editors are definitely helpful. I don't want to /require/ one for viewing phobos.

>  This makes it irrelevant how many lines a unit tests occupies if
> you are skipping over it.

It is relevant to anyone not using an editor especially designed for d.

>
> And if you aren't reviewing the library, you just want the API, you should be using the generated docs, which have nothing to do with LOC

Agreed. Again, Phobos sources will be studied and emulated by many. I don't want d to earn the reputation of a language requiring ten unittest lines per payload line.



> -Steve
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos