From: cross@spitfire.i.gajendra.net
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj wrote:
>On 4/14/2025 9:34 AM, Dave Froble wrote:
>> On 4/14/2025 8:45 AM, Simon Clubley wrote:
>>> On 2025-04-11, Arne Vajhøj wrote:
>>>> On 4/8/2025 1:27 PM, Simon Clubley wrote:
>>>>> On 2025-04-08, Arne Vajhøj wrote:
>>>>>> On 4/8/2025 8:20 AM, Simon Clubley wrote:
>>>>>>> It's a lot more complicated than that.
>>>>>>>
>>>>>>> For example, take a LL(1) RD parser. Even ignoring the processing
>>>>>>> of the results from the parser, how much code (and how much effort)
>>>>>>> do you think it would take to implement it in Macro-32 compared to
>>>>>>> C ?
>>>>>>
>>>>>> Still not obvious to me that it would not follow normal LOC/FP
>>>>>> ratios.
>>>>>
>>>>> Try implementing one, especially with a reasonably sized grammar, and
>>>>> you will very rapidly understand that it is not as simple as you seem
>>>>> to think it is. :-)
>>>>
>>>> I have not made any claim about it being simple.
>>>>
>>>> I have made a claim that the ratio for LOC/FP for Macro-32
>>>> and LOC/FP for C for such a problem would not be significantly
>>>> different from other application types.
>>>>
>>>
>>> That claim is clearly incorrect.
>
>> I'd argue that such comparisons can be misleading. As a simple example,
>> specifying some arguments and invoking some routine. In either case,
>> the arguments must be specified, then invoking the routine. Is each
>> PUSH of an argument in assembler a separate instruction, or, just
>> specification of an argument? One must still specify the arguments in
>> either case.
>>
>> An example of a style I favor:
>>
>>        Stat% = SYS$QIOW(      ,      Â
              ! Event flag &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ListenCh%
By Value,    ! VMS channel &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â IO$_SETCHAR
By Value,  ! Operation &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
IOSB::Stat%,           ! I/O status block &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
,                      ! AST routine &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
,                      ! AST parameter &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
ListenOpt::Protocol%,  ! P1 &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
,                      ! P2 &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
ServerItemLst::Len%,   ! P3 - local socket na^
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BackLog% By
Value,     ! P4 - connection back^
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
SockOptItemList::Len%, ! P5 - socket options &
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
)                      ! P6
>>
>> Ok, how many lines of code?
>
>The question about line counting has already been raised
>by Lawrence.
Lawrence is a troll, and most of us have plonked him.
>On 4/11/2025 3:05 PM, Arne Vajhøj wrote:
> > On 4/9/2025 5:10 PM, Lawrence D'Oliveiro wrote:
> >> On Wed, 9 Apr 2025 16:01:02 -0400, John Reagan wrote:
> >>> I just looked at the largest MAR file in DCL. It has 10,000 lines but
> >>> many are comments and many are macro definitions. Not actual VAX
> >>> instructions.
> >>
> >> I would count macro definition bodies in full, and each macro
> >> expansion as
> >> one line. After all, macros are code written once and used multiple
> >> times,
> >> just like function calls as far as source code is concerned.
> >
> > That definitely makes sense.
> >
> > But there are still multiple possible counts:
> > - lines in files
> > - non-comment and non-blank lines in files
> > - non-comment and non-blank and non-continued lines in files
>
> > ; Macro-32 demo
> >
> > .title loc
> > $SSDEF
> > .psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
> > fmt: .ascid "!SL !SL !SL"
> > .psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
> > buf: .ascid " "
> > .psect $CODE quad,pic,con,lcl,shr,exe,nowrt
> > .entry loc,^m<>
> > pushl #20
> > pushl #22
> > pushl #24
> > pushab buf
> > pushl #0
> > pushab fmt
> > calls #6, -
> > G^LIB$SYS_FAO
> > pushab buf
> > calls #1, -
> > G^LIB$PUT_OUTPUT
> > movl #SS$_NORMAL, r0
> > ret
> > .end loc
>
>
>But then maybe you did not like my Macro-32.
>
>:-)
>
>There is no question that it is most accurate to only
>count the continued line as one in your example.
>
>But I suspect that a lot of LOC counters just count
>non-blank and non-comment.
>
>Anything else requires language knowledge.
>
>And while it for Fortran, Basic, Macro-32 may be relative
>simple, then for other languages it can become more tricky.
>
>Let us take 4 times Pascal:
>
>if a = 1 then b := 2 else b := 3;
>
>if a = 1 then
> b := 2
>else
> b := 3;
>
>if a = 1 then begin
> b := 2;
>end else begin
> b := 3;
>end;
>
>if a = 1 then
>begin
> b := 2;
>end
>else
>begin
> b := 3;
>end;
>
>How many lines? I would say that the most correct is 3 in
>all 4 cases. But coding the line counter to return that
>would require it to have Pascal knowledge.
>
>And what about the fluent style that are so modern?
>
>o = f.create();
>o.add(1);
>o.add(2);
>o.add(3);
>
>o = f.create()
> .add(1)
> .add(2)
> .add(3);
>
>o = f.create().add(1).add(2).add(3);
>
>1 1 1 or 4 1 1 or 4 4 1 or 4 4 4??
>
>So I think counters go for the simple approach and assume
>that for large code bases with many developers then total
>converge towards an "average" style.
Most modern code-counting tools _are_ language aware. Whether
they do a better or worse job for each given language may be a
matter of debate, but most at least recognize different
languages and have some knowledge of their semantics.
Cf, https://github.com/XAMPPRocky/tokei?tab=readme-ov-file
https://github.com/AlDanial/cloc?tab=readme-ov-file#recognized-languages-
https://github.com/boyter/scc/blob/master/LANGUAGES.md
etc.
- Dan C.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
