Re: [kidsgames] Generic adventure game engine

[Steve Baker <sjbaker1@airmail.net>]

Manuel Gutierrez Algaba wrote:

> I don't know.

So, you are condemning the opensource community for not doing
great things - when you don't know/understand ~80% of the great
things that are out there.
 
> > Woah! Gnome and Emacs are both OpenSource. If you are going to remove
> > from the catagory of 'OpenSource' everything that you find to be
> > 'CleverSource' then of course what's left is junk.
> 
> That's part of my point. There's a lot of junk, only the "recent"
> superb libs like Mesa, SDL and others make a junk look like
> art work.

Mesa is ancient.  Possibly older than Linux.  It was written for
the Amiga.

Sure there is a lot of junk - so there is in any human endeavor.
The difference is that in the "Open" world, we don't eliminate
the junk by (for example) having book or record publishers who
refuse to publish things they don't like.

That is unfortunate - it allows junk through into the world - but
it also prevents jewels that aren't understood by the commercial
world from making it into the light of day.

> > If you do, it's generally a waste of
> > effort.  If I want (say) a routine to draw a dodecahedron - it's
> > much easier to write a new one than it is to trawl through the
> > entire web looking for one - only to find that it doesn't work
> > *exactly* how I want it to.
> 
> You're saying that reinventing the wheel is better that get some
> ways of organizing libraries of algorithms and libraries. Very
> clever! Very geek-ly!

Yes - that's *exactly* what I'm saying.

It doesn't matter how well organized your libraries are.  If I
want (to use my example) to draw a dodecahedron, I *could* spend
10 minutes in some hypothetically perfect library - and find
ten apparently suitable routines - then spend another 10 minutes
downloading them - only to discover that:

Routine A:  Only draws dodecahedrons that are 1 unit in diameter so
            they have to be scaled afterwards.
Routine B:  Can only draw dodecahedrons at the origin.
Routine C:  Is 100Mb long because it can draw ANY regular solid.
Routine D:  Doesn't generate surface normals for illumination.
Routine E:  Uses a "non-commercial use only" license.
Routine F:  Is perfect - but relies on an obscure linear math
            library that I don't wish to depend on.
...etc...

I can write a routine to draw a dodecahedron in maybe 50 lines -
taking me about 10 minutes to write and another 10 to debug.
That's MUCH faster than re-using anything.

Unless I need to grab at least a couple of thousand lines of
code - it's never worth the effort to re-use - no matter how
convenient you make it for me.
 
> > Code re-use in the context of such a wide-spread community is
> > at the level of entire code libraries.  Hence, GIMP gave us
> > GTK, TuxAQFH/TuxKart gave us PLIB.
> 
> OOP --> reusable objects, otherwise we're not programming in OO.

Who cares about "reusable objects" and all that theoretical bull.

I want to get a program written in a reasonably short period of
time - and have it work efficiently and reliably.

For small modules - a complete rewrite is often MUCH faster than
re-use.
 
For larger modules - the OpenSource community is VERY good at
re-use.

> > I'll talk about my software as an example - only because I
> > happen to know it well:
> >
> >   However, of those 44,000 lines of code, 40,000 are in the
> >   PLIB library suite - which is written in classical OOP
> >   style (albeit in C++) and which is now in use in over 100
> >   OpenSource projects.
> 
> Very good for PLIB library!

So - you like this!

What I'm telling you is that MOST OpenSource software is organized
along those lines.  If it isn't PLIB, it's CrystalSpace or GTK or
FLTK or ... the list is a LONG one.
 
> > Code re-use is alive and well - it just doesn't operate
> > at the microscopic level because it simply isn't all that
> > USEFUL at that level.
> 
> Good

So we agree on that ... but...

> > I want to re-use modules of tens
> > of thousands of lines of code - not silly little 20 line
> > classes from some tiny Java program.
> 
> You're wrong about this.

You don't agree about this?

Well, I've been a practical programmer since about 1973 and
I can tell you for sure that re-use on the micro scale is
a pointless activity.

Hmmm - your '.sig' file is particularly apropos to this:
 
>   Fried's 1st Rule: Increased automation of clerical function
> invariably results in increased operational costs.

Baker's corollary: Increased automation of small-function
software library re-use invariably results in increased development costs.

...unless of course us Geeks have the common sense to ignore
the stoopid library and get on with some real work.

-- 
Steve Baker   HomeEmail: <sjbaker1@airmail.net>
              WorkEmail: <sjbaker@link.com>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net


-
kidsgames@smluc.org  -- To get off this list send "unsubscribe kidsgames"
in the body of a message to majordomo@smluc.org