| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 49:45:09 |
| Calls: | 422 |
| Files: | 1,024 |
| Messages: | 90,463 |
In article <vsh5m5$3is6e$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
Wow. That's a lot smaller than I had expected.
On 4/1/2025 1:42 PM, Dan Cross wrote:
In article <vsh5m5$3is6e$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
Wow. That's a lot smaller than I had expected.
It must be some of the bigger ones.
409/15 * 1.9 MLOC would be over 50 MLOC, which is way too
high, so "representative of identifiable components of
the system" must have skewed selection towards
bigger ones.
On Tue, 1 Apr 2025 13:52:56 -0400, Arne Vajhøj wrote:
409/15 * 1.9 MLOC would be over 50 MLOC, which is way too
high, so "representative of identifiable components of
the system" must have skewed selection towards
bigger ones.
That must be including a bunch of userland components, not just the OS kernel.
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
409/15 * 1.9 MLOC would be over 50 MLOC, which is way too
high, so "representative of identifiable components of
the system" must have skewed selection towards
bigger ones.
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
On 2025-04-01, Arne Vajhøj <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
How the hell does DCL have 30,000+ lines of code ? :-)
(Even allowing for the fact most of it is in Macro-32)
Also, regarding those BLISS/Macro-32 figures across the various modules
in general, I wonder how much smaller the code would have been if it had
been written in C ?
On 4/3/2025 2:15 PM, Simon Clubley wrote:
On 2025-04-01, Arne Vajh°j <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
How the hell does DCL have 30,000+ lines of code ? :-)
(Even allowing for the fact most of it is in Macro-32)
Just for fun I downloaded bash and counted. 117 KLOC.
Also, regarding those BLISS/Macro-32 figures across the various modules
in general, I wonder how much smaller the code would have been if it had
been written in C ?
C is a relative high LOC/FP language.
Most LOC/FP tables have C in the 100-125 range and macro-assembler
in the 200-250 range.
If we adjust for VAX instructions being more powerful/complex
than average ISA, add a random number and subtract wind speed I
will estimate the Macro-32 / C ratio to be around 1.5-1.75.
If you buy that then the DCL 33 KLOC would be 19-22 KLOC in C
to be compared with bash 117 KLOC.
On 2025-04-03, Arne Vajh°j <arne@vajhoej.dk> wrote:
On 4/3/2025 2:15 PM, Simon Clubley wrote:
On 2025-04-01, Arne Vajh°j <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
How the hell does DCL have 30,000+ lines of code ? :-)
(Even allowing for the fact most of it is in Macro-32)
Just for fun I downloaded bash and counted. 117 KLOC.
Wow. I had no idea it was now that big. OTOH, bash has got a _lot_ more functionality in it than DCL does.
Also, regarding those BLISS/Macro-32 figures across the various modules
in general, I wonder how much smaller the code would have been if it had >>> been written in C ?
C is a relative high LOC/FP language.
Most LOC/FP tables have C in the 100-125 range and macro-assembler
in the 200-250 range.
If we adjust for VAX instructions being more powerful/complex
than average ISA, add a random number and subtract wind speed I
will estimate the Macro-32 / C ratio to be around 1.5-1.75.
If you buy that then the DCL 33 KLOC would be 19-22 KLOC in C
to be compared with bash 117 KLOC.
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given.
That is something which can be implemented a lot more easily and concisely
in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
On 2025-04-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/3/2025 2:15 PM, Simon Clubley wrote:
On 2025-04-01, Arne Vajhøj <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
How the hell does DCL have 30,000+ lines of code ? :-)
(Even allowing for the fact most of it is in Macro-32)
Just for fun I downloaded bash and counted. 117 KLOC.
Wow. I had no idea it was now that big. OTOH, bash has got a _lot_ more functionality in it than DCL does.
Also, regarding those BLISS/Macro-32 figures across the various modules
in general, I wonder how much smaller the code would have been if it had >>> been written in C ?
C is a relative high LOC/FP language.
Most LOC/FP tables have C in the 100-125 range and macro-assembler
in the 200-250 range.
If we adjust for VAX instructions being more powerful/complex
than average ISA, add a random number and subtract wind speed I
will estimate the Macro-32 / C ratio to be around 1.5-1.75.
If you buy that then the DCL 33 KLOC would be 19-22 KLOC in C
to be compared with bash 117 KLOC.
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given.
That is something which can be implemented a lot more easily and concisely
in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
On 4/4/2025 2:00 PM, Simon Clubley wrote:
It basically parses, validates, and executes commands it has been given.
That is something which can be implemented a lot more easily and
concisely
in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
It is not obvious to me that:
(LOC/FP for Macro-32) / (LOC/FP for C)
is a lot higher for a shell than for the average application - data structures are not anything special for shells.
But maybe.
On Sun, 6 Apr 2025 20:34:54 -0400, Arne Vajhøj wrote:
... bash has got a _lot_ more functionality in it than DCL does.
6 times more?
ldo@theon:~> man bash | wc -w
52159
I think that’s considered about novel-length.
How many words are there in the DCL reference?
... bash has got a _lot_ more functionality in it than DCL does.
6 times more?
On Mon, 7 Apr 2025 07:40:16 -0000 (UTC), I wrote:
On Sun, 6 Apr 2025 20:34:54 -0400, Arne Vajhøj wrote:
... bash has got a _lot_ more functionality in it than DCL does.
6 times more?
ldo@theon:~> man bash | wc -w
52159
I think that’s considered about novel-length.
How many words are there in the DCL reference?
I suppose the reference is the “DCL Dictionary”. And that is a lot longer.
But then, it includes docs for a lot of commands that are not built into
DCL itself. You’d have to take those out for a fair comparison.
On 2025-04-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/4/2025 2:00 PM, Simon Clubley wrote:
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given. >>> That is something which can be implemented a lot more easily and concisely >>> in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
It is not obvious to me that:
(LOC/FP for Macro-32) / (LOC/FP for C)
is a lot higher for a shell than for the average application - data
structures are not anything special for shells.
But maybe.
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 ?
On 4/4/2025 2:00 PM, Simon Clubley wrote:
Wow. I had no idea it was now that big. OTOH, bash has got a _lot_ more
functionality in it than DCL does.
6 times more?
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given.
That is something which can be implemented a lot more easily and concisely >> in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
It is not obvious to me that:
(LOC/FP for Macro-32) / (LOC/FP for C)
is a lot higher for a shell than for the average application - data structures are not anything special for shells.
But maybe.
On 4/8/2025 8:20 AM, Simon Clubley wrote:
On 2025-04-06, Arne Vajh°j <arne@vajhoej.dk> wrote:
On 4/4/2025 2:00 PM, Simon Clubley wrote:
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given. >>>> That is something which can be implemented a lot more easily and concisely >>>> in a HLL with abstracted data structure capabilities (which includes
even C) than an assembly language with no such capabilities.
It is not obvious to me that:
(LOC/FP for Macro-32) / (LOC/FP for C)
is a lot higher for a shell than for the average application - data
structures are not anything special for shells.
But maybe.
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.
Effort is a different issue. If someone said:
x1.6 LOC
x16 hours for initial write of code
x160 hours for maintenance of code
then I would consider it likely.
It has been hinted a few time that the DCL code is not easy to
understand and modify.
On 2025-04-01, Arne Vajhøj <arne@vajhoej.dk> wrote:
He looks at size 6.2 -> 7.2 -> 8.2 -> 9.2 and .mar vs .c 6.2 -> 9.2.
https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
How the hell does DCL have 30,000+ lines of code ? :-)
(Even allowing for the fact most of it is in Macro-32)
Also, regarding those BLISS/Macro-32 figures across the various modules
in general, I wonder how much smaller the code would have been if it had
been written in C ?
Simon.
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.
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.
On 4/8/2025 1:27 PM, Simon Clubley wrote:
As I mentioned above, this is no longer about DCL. I picked the above
standalone example, a LL(1) RD parser, because it's a really good example
of the different scale of effort involved in writing it in Macro-32
instead of in C.
I have not made any claim about effort either.
Are you sure that you have understood the topic??
The classic assumptions are:
LOC = a * FP
effort = b * LOC**c = a * b * FP**c
where a, b and c are language specific and c > 1.
The topic is whether the first one is true (strictly speaking
it does not need to be linear for my original claim to be
true - it would be true for any LOC = a * f(FP) where f
does not depend on language).
Whether a[Macro-32] * b[Macro-32] * FP**c[Macro-32] is at a different
scale than a[C] * b[C] * FP**c[C] does not say anything about that.
On 2025-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/8/2025 8:20 AM, Simon Clubley wrote:
On 2025-04-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/4/2025 2:00 PM, Simon Clubley wrote:
The problem with that analysis is what DCL does.
It basically parses, validates, and executes commands it has been given. >>>>> That is something which can be implemented a lot more easily and concisely
in a HLL with abstracted data structure capabilities (which includes >>>>> even C) than an assembly language with no such capabilities.
It is not obvious to me that:
(LOC/FP for Macro-32) / (LOC/FP for C)
is a lot higher for a shell than for the average application - data
structures are not anything special for shells.
But maybe.
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. :-)
Effort is a different issue. If someone said:
x1.6 LOC
x16 hours for initial write of code
x160 hours for maintenance of code
then I would consider it likely.
It has been hinted a few time that the DCL code is not easy to
understand and modify.
As I mentioned above, this is no longer about DCL. I picked the above standalone example, a LL(1) RD parser, because it's a really good example
of the different scale of effort involved in writing it in Macro-32
instead of in C.
On 4/8/2025 1:27 PM, Simon Clubley wrote:
On 2025-04-08, Arne Vajh°j <arne@vajhoej.dk> 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.
Effort is a different issue. If someone said:
x1.6 LOC
x16 hours for initial write of code
x160 hours for maintenance of code
then I would consider it likely.
It has been hinted a few time that the DCL code is not easy to
understand and modify.
As I mentioned above, this is no longer about DCL. I picked the above
standalone example, a LL(1) RD parser, because it's a really good example
of the different scale of effort involved in writing it in Macro-32
instead of in C.
I have not made any claim about effort either.
Are you sure that you have understood the topic??
On 2025-04-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/8/2025 1:27 PM, Simon Clubley wrote:
On 2025-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/8/2025 8:20 AM, Simon Clubley wrote:
Still not obvious to me that it would not follow normal LOC/FP
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 ? >>>>
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.
The amount of Macro-32 code required for something higher-level such
as a RD parser that can be concisely expressed in C compared to assembly language is clearly greater than, say a device driver, where the device access and programming sequence is the same regardless of whether it
is done in C or assembly language.
You cannot even optimise the register access sequence in a C device driver
to reduce the amount of code, (and you even have to use volatile variables
so the compiler doesn't do it for you behind your back.)
Effort is a different issue. If someone said:
x1.6 LOC
x16 hours for initial write of code
x160 hours for maintenance of code
then I would consider it likely.
It has been hinted a few time that the DCL code is not easy to
understand and modify.
As I mentioned above, this is no longer about DCL. I picked the above
standalone example, a LL(1) RD parser, because it's a really good example >>> of the different scale of effort involved in writing it in Macro-32
instead of in C.
I have not made any claim about effort either.
Are you sure that you have understood the topic??
Yes, but it's not clear if you have Arne.
Simon.
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?
On 4/14/2025 8:45 AM, Simon Clubley wrote:
On 2025-04-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/8/2025 1:27 PM, Simon Clubley wrote:
On 2025-04-08, Arne Vajhøj <arne@vajhoej.dk> 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?
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
On 2025-04-14, Dave Froble <davef@tsoft-inc.com> wrote:
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?
Exactly one line of code.
Simon.
On 4/14/2025 1:06 PM, Simon Clubley wrote:
On 2025-04-14, Dave Froble <davef@tsoft-inc.com> wrote:
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?
Exactly one line of code.
Indeed! However, some utilities used to count lines of code might count more >than one. So, the entire exercise should be considered subject to errors.
Perhaps looking at the size of object files, or executables, might be a better >measure?
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 <arne@vajhoej.dk> wrote:
On 4/8/2025 1:27 PM, Simon Clubley wrote:
On 2025-04-08, Arne Vajhøj <arne@vajhoej.dk> 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.
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware. WhetherI wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/14/2025 9:34 AM, Dave Froble wrote:
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/16/2025 9:29 PM, Dan Cross wrote:
I wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
On 4/16/2025 9:29 PM, Dan Cross wrote:
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/14/2025 9:34 AM, Dave Froble wrote:
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.
It is very fine if people simply don't read posts from
and replies to whomever they don't consider worth reading.
But if such people replies then it means that other people
start to see duplicate questions/comments.
On 2025-04-17, bill <bill.gunshannon@gmail.com> wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware. WhetherI wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
3 lines of code.
On 4/16/2025 9:29 PM, Dan Cross wrote:
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
Their language awareness consist of recognizing comments.
They are examples of some of those tools that simply count
non-blank non-comment lines.
(SCC also know some keywords but that is used for complexity
calculation not for line counting)
C:\Work>type demo.c
// C demo
#include <stdio.h>
int main()
{
int a[] = {
1,
2,
3
};
printf("%d %d %d\n",
a[0],
a[1],
a[2]);
return 0;
}
C:\Work>cloc-1.96 demo.c
1 text file.
1 unique file.
0 files ignored.
github.com/AlDanial/cloc v 1.96 T=0.01 s (67.5 files/s, 1147.0 lines/s) >-------------------------------------------------------------------------------
Language files blank comment
code
-------------------------------------------------------------------------------
C 1 2 1
14
-------------------------------------------------------------------------------
C:\Work>scc demo.c >───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code >Complexity >───────────────────────────────────────────────────────────────────────────────
C 1 17 2 1 14
0
───────────────────────────────────────────────────────────────────────────────
Total 1 17 2 1 14
0
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $305
Estimated Schedule Effort (organic) 0.63 months
Estimated People Required (organic) 0.04 >───────────────────────────────────────────────────────────────────────────────
Processed 200 bytes, 0.000 megabytes (SI) >───────────────────────────────────────────────────────────────────────────────
C:\Work>tokei-x86_64-pc-windows-msvc demo.c >===============================================================================
Language Files Lines Code Comments
Blanks >===============================================================================
C 1 17 14 1
2
===============================================================================
Total 1 17 14 1
2
===============================================================================
On 4/17/2025 8:38 AM, Arne Vajhøj wrote:
On 4/17/2025 8:21 AM, bill wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware. WhetherI wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
Given that they count non-blank non-comment lines then ...
Yes, but which is it?
Would it be three in one case and one in the other even though it is the exact same snippet?
There are lies, damn lies and statistics.
On 4/17/2025 8:56 AM, Arne Vajhøj wrote:
On 4/17/2025 8:50 AM, Simon Clubley wrote:
On 2025-04-17, bill <bill.gunshannon@gmail.com> wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware. WhetherI wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
3 lines of code.
Other replies cover what the tools actually does.
If we discuss what is the "right" answer, then I would
actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do
begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
And unless Basic next has some subtle functionality I am not
aware of then I would say 2 for Basic as well.
Interesting concept. But the NEXT is a requirement of the
language, does take time to type and if it is left out does
require debugging to fix the problem. So, if we are counting
lines in some attempt to determine the cost of writing and
maintaining the program it seems it would have to count as
a line.
On 4/17/2025 1:48 PM, Simon Clubley wrote:
Number of statements, not number of lines. That makes it 3 statements
following my reasoning or 2 with Arne's reasoning. Either way, it's
still the exact same number of statements in both cases.
But I thought we were talking LoC - Lines of Code and the ability of
a machine to make that determination in order to provide accurate
statistical information.
On 4/17/2025 8:38 AM, Arne Vajh°j wrote:
On 4/17/2025 8:21 AM, bill wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware.á WhetherI wonder how they would handle BASIC?á :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
Given that they count non-blank non-comment lines then ...
Yes, but which is it?
Would it be three in one case and one in the other even though it is the exact same snippet?
On 4/17/2025 1:04 PM, Arne Vajhøj wrote:
On 4/17/2025 10:08 AM, bill wrote:
On 4/17/2025 8:56 AM, Arne Vajhøj wrote:
On 4/17/2025 8:50 AM, Simon Clubley wrote:
On 2025-04-17, bill <bill.gunshannon@gmail.com> wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
Most modern code-counting tools _are_ language aware. WhetherI wonder how they would handle BASIC? :-)
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.
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
10 FOR X = 1 TO 10:PRINT X:NEXT X
Is the snippet above one line of code or three?
3 lines of code.
Other replies cover what the tools actually does.
If we discuss what is the "right" answer, then I would
actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do
begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
And unless Basic next has some subtle functionality I am not
aware of then I would say 2 for Basic as well.
Interesting concept. But the NEXT is a requirement of the
language, does take time to type and if it is left out does
require debugging to fix the problem. So, if we are counting
lines in some attempt to determine the cost of writing and
maintaining the program it seems it would have to count as
a line.
Programming is more about thinking than about typing.
The thinking part is about adding two constructs:
- having i iterate from 1 to 10 => Basic FOR loop
- printing a line with i => Basic PRINT statement
The specific language syntax requirement and the developers
formatting preference is not a thinking problem (unless
the developer does not know the language well, but
that is a more general problem).
Which is why I consider it two.
But all this goes back to my original point. Counting
non-blank and non-comment lines is simple while trying to
count "right" end up in having to make dozens maybe
hundreds of decisions on how to count various constructs
in various languages. Several posts back I brought up
fluent style - not an easy one to count in my opinion.
If we instead of those few lines you provided took an entire
application and asked everybody here to count, then I would not
be surprised if everybody came up with a different number.
Which is why I have been talking about "right" answer and not
right answer.
Once again, Arne, it seems in the end we actually agree.
LoC is probably not easily extracted accurately. And
the actual value of that information is minimal if of any
value at all.
All that really matters is:
Does the program work?
Does it do what it was intended to do?
Does it do it without errors?
On Thu, 17 Apr 2025 08:56:17 -0400, Arne Vajhøj wrote:
If we discuss what is the "right" answer, then I would actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
How much difference would such distinctions make in real-world code,
anyway? I suspect not much. Longer compound statements would dominate
shorter ones in the line count.
If we discuss what is the "right" answer, then I would actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
In article <vtqslm$j0ll$1@dont-email.me>,¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓ
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 4/16/2025 9:29 PM, Dan Cross wrote:
In article <67fee5b8$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
Their language awareness consist of recognizing comments.
They are examples of some of those tools that simply count
non-blank non-comment lines.
(SCC also know some keywords but that is used for complexity
calculation not for line counting)
C:\Work>type demo.c
// C demo
#include <stdio.h>
int main()
{
int a[] = {
1,
2,
3
};
printf("%d %d %d\n",
a[0],
a[1],
a[2]);
return 0;
}
C:\Work>cloc-1.96 demo.c
1 text file.
1 unique file.
0 files ignored.
github.com/AlDanial/cloc v 1.96 T=0.01 s (67.5 files/s, 1147.0 lines/s)
-------------------------------------------------------------------------------
Language files blank comment
code
-------------------------------------------------------------------------------
C 1 2 1
14
-------------------------------------------------------------------------------
C:\Work>scc demo.c
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓLanguage Files Lines Blanks Comments Code
Complexity
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓC 1 17 2 1 14
0
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓTotal 1 17 2 1 14
0
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓEstimated Cost to Develop (organic) $305
Estimated Schedule Effort (organic) 0.63 months
Estimated People Required (organic) 0.04
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓProcessed 200 bytes, 0.000 megabytes (SI)
├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ¥Γé¼├óΓÇ
C:\Work>tokei-x86_64-pc-windows-msvc demo.c
===============================================================================
Language Files Lines Code Comments
Blanks
===============================================================================
C 1 17 14 1
2
===============================================================================
Total 1 17 14 1
2
===============================================================================
You are aware that there are other tools, correct? These are
just examples of a handful that have _some_ language awareness.
- Dan C.
[snip] These are
just examples of a handful that have _some_ language awareness.
I don't know compilers, but, I'd think a compiler might have the best idea of >the statements, output code, and such. Perhaps they just aren't set up to tell us?
Relative deviation decreases when the size increases.
On Thu, 17 Apr 2025 08:56:17 -0400, Arne Vajhøj wrote:
If we discuss what is the "right" answer, then I would actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
How much difference would such distinctions make in real-world code,
anyway? I suspect not much. Longer compound statements would dominate
shorter ones in the line count.
On 4/17/2025 7:26 PM, Lawrence D'Oliveiro wrote:
On Thu, 17 Apr 2025 08:56:17 -0400, Arne Vajhøj wrote:
If we discuss what is the "right" answer, then I would actually say 2.
for i := 1 to 10 do writeln(i)
for i := 1 to 10 do
writeln(i)
for i := 1 to 10 do begin
writeln(i)
end;
for i := 1 to 10 do begin
writeln(i)
end;
for(i = 1; i <= 10; i++) printf("%d\n", i);
for(i = 1; i <= 10; i++)
printf("%d\n", i);
for(i = 1; i <= 10; i++) {
printf("%d\n", i);
}
for(i = 1; i <= 10; i++)
{
printf("%d\n", i);
}
I would say 2 for all.
How much difference would such distinctions make in real-world code,
anyway? I suspect not much. Longer compound statements would dominate
shorter ones in the line count.
It is all based on averages.
If person X write a tiny program and person Y write a the
same tiny program, then the non-blank and non-comment line
count may vary a lot.
But if a team of a 100 developers write an application close to
one million lines of code and another team of another 100 developers
write the same application, then then the non-blank and
non-comment line count will be relative close.