7drl beginning announcement

In article <87ve4zlztn.fsf.DeleteThis@plap.localdomain>, paul-
donnelly.DeleteThis@sbcglobal.net says...

> That's a 100% increase due to braces right there. Obviously that makes
> it a little difficult to compare my LOC (currently < 1k, hopefully I can
> unwrite some of that) to, say, a C programmer's.

What is the roguelike?

- Gerry Quinn
 >> Stay informed about: 7drl beginning announcement 

Gerry Quinn <gerryq.TakeThisOut@indigo.ie> writes:

> In article <87ve4zlztn.fsf.TakeThisOut@plap.localdomain>, paul-
> donnelly.TakeThisOut@sbcglobal.net says...
>
>> That's a 100% increase due to braces right there. Obviously that makes
>> it a little difficult to compare my LOC (currently < 1k, hopefully I can
>> unwrite some of that) to, say, a C programmer's.
>
> What is the roguelike?

It's a stealth game, nominally styled after the Thief games, but I don't
suppose I'll actually import the mythology or anything from them. The
plan is to implement stealth in terms of shadow, learning guards' patrol
routes, and guard FOV+direction. At present, lighting is the only one of
those components that is implemented, although I've got guards that
wander around and a combat stub. My aim is to keep the game as simple as
possible. It will probably damage replayability, but this project is
largely intended as a way to come to grips with all the aspects of
writing a RL engine. I'll save the task of balancing a complicated game
world for the next one.
 >> Stay informed about: 7drl beginning announcement 

Norbert Melzer <norbert.melzer.DeleteThis@gmx.net> writes:

> Am Sat, 09 Feb 2008 00:48:04 GMT schrieb Paul Donnelly:
>
>> my programs don't have extra lines for opening or
>> closing braces, e.g.:
>>
>> (loop
>> (simulate-a-*WORLD*))
>>
>> rather than
>>
>> while(1)
>> {
>> simulate_a_WORLD();
>> }
>
> even in C and C++ the following is possible:
>
> while ( 1 ) {
> simulate_a_world(); }
>
> Would be the same with your LISP-Code in LOC.

Exactly. While the number of lines that actually "do something" may not
vary between Lisp and C, the actual number of lines in the program is
inflated by traditional C indentation, and deflated by Lisp style. My
idea is that there is some average ratio by which putting a C program's
braces on their own lines increases code size, and once this ratio is
discovered, it would be possible to calculate the number of "do
something" lines in a C program. In a Lisp program, any non-empty,
non-comment line can be assumed to be a "do something"
line. Actually, I suspect that if you were to adopt C-like style
for Lisp code, the ratio of brace only lines to "do something" lines
would be even larger than for C code (which is probably why Lispers
*don't* put braces alone on lines).

It's really a moot point. You can't compare LOC between Lisp and C (or
whatever) in any meaningful way in any case. I just think it would be fun to
figure out a collapsed brace conversion factor.
 >> Stay informed about: 7drl beginning announcement 

Am Sat, 09 Feb 2008 00:48:04 GMT schrieb Paul Donnelly:

> my programs don't have extra lines for opening or
> closing braces, e.g.:
>
> (loop
> (simulate-a-*WORLD*))
>
> rather than
>
> while(1)
> {
> simulate_a_WORLD();
> }

even in C and C++ the following is possible:

while ( 1 ) {
simulate_a_world(); }

Would be the same with your LISP-Code in LOC. BUT! We have to put an main
around that... Thats at least 1 more LOC:

void main () {
while ( 1 ) {
simulate_a_world(); }}

But hey... I can write that as one line:

void main () { while ( 1 ) { simulate_a_world(); }}

But thats going to get OCC
 >> Stay informed about: 7drl beginning announcement 

Gerry Quinn <gerryq.DeleteThis@indigo.ie> writes:

> In article <87fxw1myja.fsf.DeleteThis@plap.localdomain>, paul-
> donnelly.DeleteThis@sbcglobal.net says...
>
>> It's really a moot point. You can't compare LOC between Lisp and C (or
>> whatever) in any meaningful way in any case. I just think it would be fun to
>> figure out a collapsed brace conversion factor.
>
> Well, a common metric for C/C++ is the number of terminal semi-colons,
> plus the number of terminal curly braces.
>
> Maybe an equivalent metric for Lisp would be some sort of appropriate
> statement count, plus the number of closing brackets? (Since in Lisp
> the brackets seem to fulfil approximately the same functions as block
> delimiters in C.)

Hmm, perhaps. I'm not sure how you'd come up with a statement count for
Lisp. The number of close parens might give you something like it, but
it wouldn't really be counting "statements" in the way that LoC in a C
program does. Compare:

x = y * z + a / b % c ^ d; // All one "statement".

(setf x (+ (* y z) (/ a (mod b (expt c d))))) // Six "statement"s?

That's why I figured I'd stick with lines as a metric, with the
assumption that one line does "one code thing" in both Lisp and
C. Modulo lines that only contain a brace, I figured a LoC comparison
would be a direct comparison of "lines that do things" to "lines that do
things". Not much of a comparison in any real-world way, of course. It's
just one of those things where my brain starts problem solving a silly
"problem" on its own.
 >> Stay informed about: 7drl beginning announcement 

In article <87fxw1myja.fsf.RemoveThis@plap.localdomain>, paul-
donnelly.RemoveThis@sbcglobal.net says...
> Norbert Melzer <norbert.melzer.RemoveThis@gmx.net> writes:
>
> > Am Sat, 09 Feb 2008 00:48:04 GMT schrieb Paul Donnelly:
> >
> >> my programs don't have extra lines for opening or
> >> closing braces, e.g.:
> >>
> >> (loop
> >> (simulate-a-*WORLD*))
> >>
> >> rather than
> >>
> >> while(1)
> >> {
> >> simulate_a_WORLD();
> >> }
> >
> > even in C and C++ the following is possible:
> >
> > while ( 1 ) {
> > simulate_a_world(); }
> >
> > Would be the same with your LISP-Code in LOC.
>
> Exactly. While the number of lines that actually "do something" may not
> vary between Lisp and C, the actual number of lines in the program is
> inflated by traditional C indentation, and deflated by Lisp style. My
> idea is that there is some average ratio by which putting a C program's
> braces on their own lines increases code size, and once this ratio is
> discovered, it would be possible to calculate the number of "do
> something" lines in a C program. In a Lisp program, any non-empty,
> non-comment line can be assumed to be a "do something"
> line. Actually, I suspect that if you were to adopt C-like style
> for Lisp code, the ratio of brace only lines to "do something" lines
> would be even larger than for C code (which is probably why Lispers
> *don't* put braces alone on lines).
>
> It's really a moot point. You can't compare LOC between Lisp and C (or
> whatever) in any meaningful way in any case. I just think it would be fun to
> figure out a collapsed brace conversion factor.

Well, a common metric for C/C++ is the number of terminal semi-colons,
plus the number of terminal curly braces.

Maybe an equivalent metric for Lisp would be some sort of appropriate
statement count, plus the number of closing brackets? (Since in Lisp
the brackets seem to fulfil approximately the same functions as block
delimiters in C.)

- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
 >> Stay informed about: 7drl beginning announcement 

On Tue, 12 Feb 2008 13:57:10 -0000, Gerry Quinn <gerryq.TakeThisOut@indigo.ie> tried to
confuse everyone with this message:

>In article <87fxw1myja.fsf.TakeThisOut@plap.localdomain>, paul-
>donnelly@sbcglobal.net says...
>> Norbert Melzer <norbert.melzer.TakeThisOut@gmx.net> writes:
>>
>> > Am Sat, 09 Feb 2008 00:48:04 GMT schrieb Paul Donnelly:
>> >
>> >> my programs don't have extra lines for opening or
>> >> closing braces, e.g.:
>> >>
>> >> (loop
>> >> (simulate-a-*WORLD*))
>> >>
>> >> rather than
>> >>
>> >> while(1)
>> >> {
>> >> simulate_a_WORLD();
>> >> }
>> >
>> > even in C and C++ the following is possible:
>> >
>> > while ( 1 ) {
>> > simulate_a_world(); }
>> >
>> > Would be the same with your LISP-Code in LOC.
>>
>> Exactly. While the number of lines that actually "do something" may not
>> vary between Lisp and C, the actual number of lines in the program is
>> inflated by traditional C indentation, and deflated by Lisp style. My
>> idea is that there is some average ratio by which putting a C program's
>> braces on their own lines increases code size, and once this ratio is
>> discovered, it would be possible to calculate the number of "do
>> something" lines in a C program. In a Lisp program, any non-empty,
>> non-comment line can be assumed to be a "do something"
>> line. Actually, I suspect that if you were to adopt C-like style
>> for Lisp code, the ratio of brace only lines to "do something" lines
>> would be even larger than for C code (which is probably why Lispers
>> *don't* put braces alone on lines).
>>
>> It's really a moot point. You can't compare LOC between Lisp and C (or
>> whatever) in any meaningful way in any case. I just think it would be fun to
>> figure out a collapsed brace conversion factor.
>
>Well, a common metric for C/C++ is the number of terminal semi-colons,
>plus the number of terminal curly braces.

function1(function2(x,y),function3(x,y));

1 statement under your metric.

>Maybe an equivalent metric for Lisp would be some sort of appropriate
>statement count, plus the number of closing brackets?

(function1 (function2 x y) (function3 x y))

Well, there are 3 closing parens, and I'm not really sure what do you
count as statements, but it seems to me that these metrics are not even
remotely equivalent.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
 >> Stay informed about: 7drl beginning announcement