From: arne@vajhoej.dk
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.
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.
Arne
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
