-MPRHB- Development proceeds...

On Jan 28, 8:02 pm, Martin Read <mpr....RemoveThis@chiark.greenend.org.uk> wrote:
> >Just to satisfy my curiosity - during the current refactoring, did the
> >code base grow or shrink?
> Grow a modest amount.
>
> wc ~/src/dungeonbash-1.99.1/*.[ch] says 12231 lines (including copyright
> boilerplate at 25 lines/file) and 320282 bytes.
>
> wc ~/src/hellbash-0.51.1/*.{cc,h} ~/include/libmrl/*.h says 13278 lines
> and 356412 bytes.

I don't know the particulars of MPRHB, and an 11% increase isn't that
much- but generally speaking I would be wary of "improvements" that
increase the size of a program without adding functionality. Size is
the mind killer - http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

-Ido.
 >> Stay informed about: -MPRHB- Development proceeds... 

Ido Yehieli <Ido.Yehieli.TakeThisOut@gmail.com> wrote:
>On Jan 28, 2:00 am, Martin Read <mpr....TakeThisOut@chiark.greenend.org.uk> wrote:
>> So far, Martin's Hell Bash hasn't really moved forward very far. It's
>> effectively the same game as Martin's Dungeon Bash 1.99.1. However, I've
>> been doing a lot of work "under the hood" to turn it into a solid-ish
>> basis for adding actual features.
>
>So in other words you're only doing refactoring?

So far, I have only been doing refactoring, yes. There's still some more
left to do - most notably, bmagic.cc needs refactoring, and
radiance.{h,cc} ideally want to be refactored into a component of libmrl
(since the beam and AOE mechanisms were designed in such a way that they
don't have to know anything about the other data structures in the
game).

>Just to satisfy my curiosity - during the current refactoring, did the
>code base grow or shrink?

Grow a modest amount.

wc ~/src/dungeonbash-1.99.1/*.[ch] says 12231 lines (including copyright
boilerplate at 25 lines/file) and 320282 bytes.

wc ~/src/hellbash-0.51.1/*.{cc,h} ~/include/libmrl/*.h says 13278 lines
and 356412 bytes.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
 >> Stay informed about: -MPRHB- Development proceeds... 

On 2008-01-28 20:18:39, Ido Yehieli <Ido.Yehieli.TakeThisOut@gmail.com> wrote:

> On Jan 28, 8:02 pm, Martin Read wrote:
> > >Just to satisfy my curiosity - during the current refactoring, did the
> > >code base grow or shrink?
> > Grow a modest amount.
> >
> > wc ~/src/dungeonbash-1.99.1/*.[ch] says 12231 lines (including copyright
> > boilerplate at 25 lines/file) and 320282 bytes.
> >
> > wc ~/src/hellbash-0.51.1/*.{cc,h} ~/include/libmrl/*.h says 13278 lines
> > and 356412 bytes.
>
> I don't know the particulars of MPRHB, and an 11% increase isn't that
> much- but generally speaking I would be wary of "improvements" that
> increase the size of a program without adding functionality. Size is
> the mind killer - http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

[scans MPRHB]
I'm certain that propagating libmrl::Coord properly will end up shrinking the
codebase, even with the STL compatibility glue on the extracted classes and the
copyright boilerplate.

I agree with Mr. Yegge regarding code size, and the rather awful marketing
errors behind Extreme Programming. However, I'm pretty certain Mr. Yegge does
*not* understand refactoring, as he completely omits that one of the checkpoints
for committing to refactoring is that it *must* do one of the following:
* directly reduce code size after comments are deducted (which is the case
here)
* eliminate/prevent definition redundancy

That is, refactoring is the most direct way of reducing that 500,000 line count
to something more reasonable (or at least the total file size of the project).
 >> Stay informed about: -MPRHB- Development proceeds... 

Ido Yehieli <Ido.Yehieli RemoveThis @gmail.com> wrote:
>On Jan 28, 8:02 pm, Martin Read <mpr... RemoveThis @chiark.greenend.org.uk> wrote:
>> Grow a modest amount.
>>
>> wc ~/src/dungeonbash-1.99.1/*.[ch] says 12231 lines (including copyright
>> boilerplate at 25 lines/file) and 320282 bytes.
>>
>> wc ~/src/hellbash-0.51.1/*.{cc,h} ~/include/libmrl/*.h says 13278 lines
>> and 356412 bytes.
>
>I don't know the particulars of MPRHB, and an 11% increase isn't that
>much- but generally speaking I would be wary of "improvements" that
>increase the size of a program without adding functionality.

Except that I *have* added functionality, by removing the previous
arbitrary limitations on the number of monsters and items I can have in
memory, and making it feasible to have every monster and item created
have a unique ID.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
 >> Stay informed about: -MPRHB- Development proceeds... 

On 2008-01-28 02:00:36, Martin Read <mpread DeleteThis @chiark.greenend.org.uk> wrote:

> . .. to a point.
>
> So far, Martin's Hell Bash hasn't really moved forward very far. It's
> effectively the same game as Martin's Dungeon Bash 1.99.1. However, I've
> been doing a lot of work "under the hood" to turn it into a solid-ish
> basis for adding actual features.

It looks like you're on the right track.

C++ Standards Committee, take note

#include <algorithm>

is so bloated that some high compiler-performance projects intentionally
reimplement std::min, std::max, and so on rather than use <algorithm> . MPRHB
is merely the latest to implement this.

> The major reason I'm posting this right now is to ask for help
> diagnosing a problem with the curses-based display code. Basically, the
> display of the status window is completely buggered, and I can't work out
> *why* it's buggered.

I don't see it either; I'd have to build it to have a clue.
 >> Stay informed about: -MPRHB- Development proceeds... 

Kenneth 'Bessarion' Boyd <zaimoni.DeleteThis@zaimoni.com> wrote:
>On 2008-01-28 02:00:36, Martin Read <mpread.DeleteThis@chiark.greenend.org.uk> wrote:
>> The major reason I'm posting this right now is to ask for help
>> diagnosing a problem with the curses-based display code. Basically, the
>> display of the status window is completely buggered, and I can't work out
>> *why* it's buggered.
>
>I don't see it either; I'd have to build it to have a clue.

I found it in the end. It was a case of not knowing what my own code was
doing...
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
 >> Stay informed about: -MPRHB- Development proceeds... 

On Jan 28, 2:18 pm, Ido Yehieli <Ido.Yehi... DeleteThis @gmail.com> wrote:
>
> I don't know the particulars of MPRHB, and an 11% increase isn't that
> much- but generally speaking I would be wary of "improvements" that
> increase the size of a program without adding functionality. Size is
> the mind killer -http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

A nice link, thank you for it. I do agree 100% that size is the worst
feature of code. However, I think the author is still counting LOC
incorrectly. Unit tests, for example. don't contribute to the "LOC"
of a project. They are, by definition, stand-along forks of code
dependency that don't interact with the rest of the code base.

The real size of a program is the size of the tightly coupled
spaghetti mess at the center. This is the complexity that can kill.
One problem is that projects, out of fear of making such a ball of
spaghetti, instead cut and paste to avoid dependency. My personal
scar from cut & paste is a text adventure I wrote in Pascal. My IDE,
Alice Pascal, has a nifty "Collapse block" function. So, I wrote the
code for a room:
case 143: // Room 143
if command == north
writeln("You walk north");
room = 132;
if command == south
writeln("You walk north");
room = 123;
if command == look
writeln("You see a room here.");
etc

This could then be collapsed into a single line. And then cut & paste
for each room in the text adventure game, with the suitable changes
for what each verb did. My first clue I was doing something wrong was
when I ran out of memory on my 1Mb ST. :>

And people wonder why I shuddered when MSVC 2003 added the block-
collapsing function. Like the author points out: some IDE features
*create* problems rather than solve them. If you make it easy to
manage 500kLOC, people will write 500kLOC.

So, I'd identify two antagonistic problems:
1) Complex code kills. It is too difficult to debug, understand,
change, etc.
2) Simple code kills. It is too big. 500kLOC of inertia means that
fundamental changes become extraordinarily expensive. Adding another
verb to my text adventure was unthinkable.

From the sounds of it, his game hit #2. I roll for disbelief that
this is a result of some fundamental problem with Java. 500kLOC is
suspiciously huge for any video game. Usually when I look into such
stats it turns out disparate, disconnected, and often suspicously
similar, systems are counted. My random guess is a "class SHIRT :
ARMOUR" type implementation. This would hopelessly bloat a Java game
and is something easily fixable in the languages the author holds out
for salvation. The problem isn't with Java, but how it was used. In
defense of the author, a lot of people will try and tell you to use
Java in just that way.

If you find you are writing lots of boiler plate you are using your
language wrong :>
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: -MPRHB- Development proceeds... 

On Jan 30, 2:16 am, Jeff Lait <torespondisfut... DeleteThis @hotmail.com> wrote:
> From the sounds of it, his game hit #2... 500kLOC is
> suspiciously huge for any video game.

I'm not sure, have you tried wyvern? It actually does quite a lot.
500k is not that unusual for projects that have been actively
developed for years, although it is unusual for 1 person to write it
all by himself.

Wrt java not being the problem - you are probably right.
I'm betting that even if his ruby rewrite will be exceptionally
successful it wouldn't be less than 1/3-1/2 the size and that
difference isn't big enough to make wyvern maintainable by one person
for long.

-Ido.
 >> Stay informed about: -MPRHB- Development proceeds... 

On Jan 30, 3:31 am, Ido Yehieli <Ido.Yehi....TakeThisOut@gmail.com> wrote:
> On Jan 30, 2:16 am, Jeff Lait <torespondisfut....TakeThisOut@hotmail.com> wrote:
>
> > From the sounds of it, his game hit #2... 500kLOC is
> > suspiciously huge for any video game.
>
> I'm not sure, have you tried wyvern? It actually does quite a lot.

His original article didn't mention the game, so I wasn't sure exactly
what he was referring to. Now, with the name, I can take a look at
what it is.

I'm sure it does a lot. But Nethack does quite a lot too. And it
does it in 134k.

> 500k is not that unusual for projects that have been actively
> developed for years

That is precisely the author's point, however. 500k should be
unusual! Few things require that amount of complexity.

I'll amend my earlier two causes of large code sizes with a third...
1) A truly complex problem. Very rare.
2) Too simplistic an implementation. Too many problems solved by
brute force rather than subtlety - you are in a maze of twistly little
functions, all different.
3) Confusing data with code. A sort of subset of #2, since this is
"simple" code. The original Neverwinter Nights gave me a painful
insight into this when I could see the "scripts" for the main
campaigns. A huge number of slightly different scripts that could
have been subsumed into a simple data field if the conversation engine
weren't so eager to demand any if statement have a full script
attached. Ironically, the "solution" was to make conversation wizards
that autogenerated these scripts - similar to using an IDE to better
manage your 500k of code.

POWDER demonstrates #3 rather effectively. You could say there are
140k in .cpp and .c files. However, that counts the 80k or so of auto-
generated files - everything from structured data tables to bitmaps.
So a more realistic size is 60k.

> although it is unusual for 1 person to write it
> all by himself.

As the author himself asserts, this is no accident! You can't change
500k lines of code!

> Wrt java not being the problem - you are probably right.
> I'm betting that even if his ruby rewrite will be exceptionally
> successful it wouldn't be less than 1/3-1/2 the size and that
> difference isn't big enough to make wyvern maintainable by one person
> for long.

I'd posit it could be made 1/2 the size without leaving Java. But,
I'll freely admit I'm just speaking without support there.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: -MPRHB- Development proceeds... 

On Jan 30, 5:23 pm, Jeff Lait <torespondisfut... RemoveThis @hotmail.com> wrote:
> POWDER demonstrates #3 rather effectively. You could say there are
> 140k in .cpp and .c files. However, that counts the 80k or so of auto-
> generated files - everything from structured data tables to bitmaps.

May I ask why are you putting these in .c and .cpp files instead of
just reading the text/bitmap files directly?
Is it because of performance?

-Ido.
 >> Stay informed about: -MPRHB- Development proceeds... 

On 30 tammi, 18:23, Jeff Lait <torespondisfut....DeleteThis@hotmail.com> wrote:
> So a more realistic size is 60k.

Kaduria is 30k, but I guess it will be about 50k when it's
ready. Actually I think Kaduria's source code is quite
hopeless bloat at the moment..
 >> Stay informed about: -MPRHB- Development proceeds... 

On 2008-01-30 02:16:29, Jeff Lait <torespondisfutile DeleteThis @hotmail.com> wrote:

> On Jan 28, 2:18 pm, Ido Yehieli wrote:
> >
> > I don't know the particulars of MPRHB, and an 11% increase isn't that
> > much- but generally speaking I would be wary of "improvements" that
> > increase the size of a program without adding functionality. Size is
> > the mind killer -http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
>
> A nice link, thank you for it. I do agree 100% that size is the worst
> feature of code. However, I think the author is still counting LOC
> incorrectly. Unit tests, for example. don't contribute to the "LOC"
> of a project. They are, by definition, stand-along forks of code
> dependency that don't interact with the rest of the code base.

The definition of LOC is floppy -- GCC, for instance, considers the unit tests
part of the deliverable. And certainly the unit tests *do* have to be
maintained as much as design by contract.
 >> Stay informed about: -MPRHB- Development proceeds... 

On Jan 31, 4:52 am, Ido Yehieli <Ido.Yehi....RemoveThis@gmail.com> wrote:
> On Jan 30, 5:23 pm, Jeff Lait <torespondisfut....RemoveThis@hotmail.com> wrote:
>
> > POWDER demonstrates #3 rather effectively. You could say there are
> > 140k in .cpp and .c files. However, that counts the 80k or so of auto-
> > generated files - everything from structured data tables to bitmaps.
>
> May I ask why are you putting these in .c and .cpp files instead of
> just reading the text/bitmap files directly?
> Is it because of performance?

Most certainly not performance.

A few players have commented positively on the lack of support files,
but I think there are better ways to achieve that.

The number one reason is because I target the Gameboy Advance. Not
much of a filesystem in that platform. :> I guess I could have gone
to PhysFS, but POWDER grew organically from a system that just
converted to .c, so I stayed with that path.

One type of data that I convert to .cpp is different, however. I
convert all of my monster/item/etc data from a .txt file into .cpp
file. This isn't for performance, but is for ease of coding. The
converter automatically generates the enums to refer to the monsters,
creates the structure that defines the monsters, etc. If I want to
access a monster definition variable "foobar", I can just do

foo = mob->defn().foobar;

A mistyped foobar becomes a compile time error rather than a run time
error, which I appreciate. The traditional data file approach would
make something like

foo = mob->defn("foobar");

which is prone to failure. Equally annoying, you'd have to specify
the type likely:

foo = mob->getI("foobar"); // integer
str = mob->getS("name"); // String

Of course, you can then write a lot of boiler plate like
const char *MOB::getName() { return getS("name"); }

but that is a lot of boiler plate. See our earlier discussion of the
danger of boiler plate :>

This is why You Only Live Once and my other 7drls all use .txt files
that are compiled into .cpp files rather than just reading the .txt
file themselves.

I think there is a lot of good to be said of having your secondary
"languages" compile into your primary language. It certainly makes
the whole question of setting up bindings rather trivial :>
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: -MPRHB- Development proceeds...