On Fri, Feb 11, 2022 at 04:47:46PM +0000, user1234 via Digitalmars-d wrote:
> On Friday, 11 February 2022 at 16:41:33 UTC, user1234 wrote:
> > On Friday, 11 February 2022 at 15:17:16 UTC, rempas wrote:
> > > On Friday, 11 February 2022 at 14:52:09 UTC, max haughton wrote:
> > > > 
> > > > The object emission code in the backend is quite inefficient, it needs to be rewritten (it's horrible old code anyway)
> > > 
> > > I would love if they would do it but I can't complain that they don't. Openhub reports that [DMD] consists of 961K LoC!!
> > 
> > Openhub and their metrics are old trash. It's more 170K according to D-Scanner.
> 
> wait... it's 175K. I had not pulled since 8 monthes or so. There's much new code that was commited since, with importC notably.

I pulled just this week, and running `wc` on *.d *.c *.h says there are 365K lines.  I'm not sure what the *.h files are for, since DMD is now bootstrapping. Excluding *.h yields 347K lines.  But a lot of those are actually blank lines and comments; excluding // comments, /**/ and /++/ block comments, and blank lines yields 175K.

The 961K probably comes from the myriad test cases in the testsuite, where more lines is actually a *good* thing.

But really, LoC is an unreliable measure of code complexity. Token count would be more reflective of the actual complexity of the code, though even that is questionable. Writing `enum x = 1 + 1;` would be 7 tokens vs. `enum x = 2;` which is 5 tokens, for example, but the former may actually make code easier to read in certain cases (e.g., if the longer expression makes intent clearer that the shorter one).

Compressed size may be an even better approximation, because a high degree of complexity approaches Kolgomorov complexity in the limit, which is a measure of the information content of the data. Stripping comments and compressing (with the best compression algorithm you can find), for example, would give a good approximation to the actual complexity in the code.  Though of course, even that fails to measure the inherent level of complexity in language constructs. So you couldn't meaningfully compare compressed sizes across different languages, for example.


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On Friday, 11 February 2022 at 17:36:37 UTC, H. S. Teoh wrote:

> I pulled just this week, and running `wc` on *.d *.c *.h says...

https://github.com/AlDanial/cloc would yield a more practical metric, at least as far as "practical metric" in terms of LoC goes.

On Friday, 11 February 2022 at 17:44:45 UTC, Stanislav Blinov wrote:
> On Friday, 11 February 2022 at 17:36:37 UTC, H. S. Teoh wrote:
>
>> I pulled just this week, and running `wc` on *.d *.c *.h says...
>
> https://github.com/AlDanial/cloc would yield a more practical metric, at least as far as "practical metric" in terms of LoC goes.

```
---------------------------------------------------------------------------------------
Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
D                                     3867          75824          88426         431299
HTML                                   114          11405            967          61083
C/C++ Header                            57           2729            992          23332
C                                       93            830            797           3346
C++                                     19            532            139           2249
```
this includes the test suite and other stuff that isn't technically the compiler-proper.

On Fri, Feb 11, 2022 at 05:44:45PM +0000, Stanislav Blinov via Digitalmars-d wrote:
> On Friday, 11 February 2022 at 17:36:37 UTC, H. S. Teoh wrote:
> 
> > I pulled just this week, and running `wc` on *.d *.c *.h says...
> 
> https://github.com/AlDanial/cloc would yield a more practical metric, at least as far as "practical metric" in terms of LoC goes.

I'm skeptical of any LoC metric.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??

On Friday, 11 February 2022 at 17:36:37 UTC, H. S. Teoh wrote:
> On Fri, Feb 11, 2022 at 04:47:46PM +0000, user1234 via Digitalmars-d wrote:
>> On Friday, 11 February 2022 at 16:41:33 UTC, user1234 wrote:
>> > On Friday, 11 February 2022 at 15:17:16 UTC, rempas wrote:
>> > > [...]
>> > 
>> > Openhub and their metrics are old trash. It's more 170K according to D-Scanner.
>> 
>> wait... it's 175K. I had not pulled since 8 monthes or so. There's much new code that was commited since, with importC notably.
>
> I pulled just this week, and running `wc` on *.d *.c *.h says there are 365K lines.  I'm not sure what the *.h files are for,

Ah yes, the h files... D-Scanner does not take them in account.
They are still used by GDC I believe.

On Friday, 11 February 2022 at 16:47:46 UTC, user1234 wrote:
>> Openhub and their metrics are old trash. It's more 170K according to D-Scanner.
>
> wait... it's 175K. I had not pulled since 8 monthes or so. There's much new code that was commited since, with importC notably.

Thank you for the information! It seems pretty impressive to me that DMD only has 175K LoC in it's code base given the fact of how huge D is! Even without the recent commits (which how much could they be?), this seems to little to me. In that case, we can talk about re-writing it but again, that's up to the developers to decide.

On Friday, 11 February 2022 at 18:02:21 UTC, max haughton wrote:
> On Friday, 11 February 2022 at 17:44:45 UTC, Stanislav Blinov wrote:
>> On Friday, 11 February 2022 at 17:36:37 UTC, H. S. Teoh wrote:
>>
>>> I pulled just this week, and running `wc` on *.d *.c *.h says...
>>
>> https://github.com/AlDanial/cloc would yield a more practical metric, at least as far as "practical metric" in terms of LoC goes.
>
> ```
> ---------------------------------------------------------------------------------------
> Language                             files          blank        comment           code
> ---------------------------------------------------------------------------------------
> D                                     3867          75824          88426         431299
> HTML                                   114          11405            967          61083
> C/C++ Header                            57           2729            992          23332
> C                                       93            830            797           3346
> C++                                     19            532            139           2249
> ```
> this includes the test suite and other stuff that isn't technically the compiler-proper.

Interesting! We could remove the "test-suit" directory and we could tell it to only parse "D" language files which will give us more "clean" results. "cloc" is actually what I use and for DragonFlyBSD, it gave me the same number "OpenHub" gave so I really wonder how other source code or languages have different results...