Re: [kidsgames] Generic adventure game engine

[Steve Baker <sjbaker1@airmail.net>]

Manuel Gutierrez Algaba wrote:

>  How many people think yet that the main programming
> language for most problems is C/C++ ?

I do.  As an all-round general-purpose work-horse language,
it's by far the best.

There are niche areas where other languages can make life
easier on the programmer - but not one of them can address
ALL areas of programming in the way that C/C++ can.

Python - great for rapid development - too slow for graphical
         games and device drivers.
JAVA - great for network applications - also too slow for some
         things.
Pascal - good for beginners - like having your grandmother advise
         you on your sex life if you are an experienced programmer.

...the list goes on...

Rather than learn 20 different languages for 20 different tasks,
and end up being mediocre at all of them, I'd prefer to be a REALLY,
REALLY good C++ programmer and be able to write anything using it.

Maybe one day I will be.

> Come on,  with all wonderful scriptic languages we have to prototype,
> to embed, to interprete, with no freeing of memory. With all OO
> techniques: dispatcher-event,
> CORBA (?), generecity, design-on-demand (?) (Eiffel). Logic
> programming (Clips, prolog).

Hmmm "wonderful scriptic languages" - well, I *do* use them
where it's appropriate - but mostly C++ does a better job:

 * If I prototype with them - I just have to write it all
   over again in C++ later.

 * If I embed them - I have to embed them in *something* - and the
   *something* is in C or C++.

 * Interpreting code is ALWAYS slow. Python is between 5 and 50 times
   slower than C++.  TuxKart would run at 1Hz if it was in Python.

 * No freeing of memory ... is just an illusion.  All these systems
   free up memory - or else you'd run out (Duh) - they use "garbage
   collection" to do it.  This means that your program is sailing
   along just nicely when suddenly the garbage collector turns on.
   Everything stops for a second or more.  You'd just better hope
   that wasn't the moment when the pilot of your plane chose to
   lower the undercarriage!

Scripting languages just get you so far.  If Linux was written in
a scripting language, your 450MHz Pentium would be performing like
the 4MHz 68000 I had in my Amiga back in 1990.

> Just admit that 90% of geeks are not using technology that would
> be useful for them.

I don't think that's true.  We are not using technology that's NOT
all that useful to us.
 
> > 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...
> 
> Even so, it's better to evolve from a pre-made routine, and if they're
> written in decent OO it'd be pretty easy.

You keep saying that - but I've been actually doing this stuff for
enough years - and I can tell you that it's simply not true.

> > 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.
> 
> For me it's faster to reuse your routine. And it'd be easier if
> repositories of routines existed.

Then you are a slow paced programmer.  Once you are deeply familiar
with the craft of programming, these things go together quickly
and easily - and one's threshold at which it becomes 'cost-effective'
to re-use a function instead of rewriting it goes ever upwards.

A total novice might well look through lots of pre-written sort
routines - each about a dozen lines of code - because he doesn't
yet know how to write such a thing.  Once you've been programming
for a few years, you can write down a 'quick-sort' routine faster
than you can go and get one from somewhere else.
 
> > I want to get a program written in a reasonably short period of
> > time - and have it work efficiently and reliably.
> 
> I want to get a programm that looks nice structuraly and conceptually,
> if it works or not, or people doesn't like it, it's pretty secondary.
> I do this for learning , improving myself, not just for getting
> more functionality in some area of Open source software.

Well fine - if you are still at that learning stage.  However, if
we all took that approach, there would be no Internet, no Linux,
no GNU C compilers...nothing.

So you end up with pretty code - you learned something - but do
you have anything useful at the end of it?  No!   In the end
you have to produce a working program - and generally it has
to be efficient and reliable.
 
The bottom line is that you cannot point to one single Eiffel
program that's in common use.  Not one.

I can point to 10,000 C and C++ programs that are in use by
millions of people every day.

Which approach actually works?

In the end, the objective here is to produce a string of bits
that controls a computer...not to write poetry.

Demonstrably, the best way to do that is in C/C++.

> > 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.
> 
> Ok, I was born in 1972, and started programming in middle eighties,
> and you seem to do great/succesful pieces of software. Even so,
> I'm pretty sure that I can beat you down in terms of wise technology
> used and elegance in general.

Perhaps so...but it's results that count.  Show me the big successes
of your approach.  TuxAQFH has been downloaded (and presumably
enjoyed) by 150,000 people so far.  What has your approach produced
that was better?  I'm not just talking about things that you
personally have written - name ANY program with that kind of
success that was not written in a conventional procedural (or
mildly OOP) language like C/C++.  I can't think of ANY...although
I guess there surely must be one or two.

Realise that it's not helping the general Linux populace to have 
fine theoretical principals and not actually produce anything
of any real use.

> Ok, a challenge. In
> http://www.ctv.es/USERS/irmina/genaut.py there's my crossword
> generator for Crosswords for linux .
> It uses backtracking/recursion and scripting, that is, theoretical
> shit.

Backtracking and recursion are certainly not theoretical techniques,
I use both quite a bit in day-to-day work.  I still write in C++
and don't engage in re-use at the micro-scale - which is what
this is about.

Tell me, what percentage of that program came from re-use of
JAVA components from something else (and you can't count the
JAVA standard libraries)?  Show me other programs that use
those components.

(Remembering that TuxKart is at ~90% re-use right now - and
the code it re-uses is used in at least 100 other programs -
and remember that you are trying to convince me that your
way is better).

> It's written in Spanish, so you can back in this fact for
> not accepting the challenge :PPP.

I'll attempt your challenge when you can show me a complete working
3D computer game that runs at 60Hz - and do it all in 6 weeks.  That's
what TuxKart took.

Hint: You won't be able to do it using Python, Eiffel, rigorous OOP,
Java, etc, etc.

Not one single high performance game has EVER been written sucessfully
that way.  Not once in the entire history of computers.

*Simple* programs like crossword puzzle generators are not the
issue here.  We are talking serious software engineering - hundreds
of thousands of lines of code.  Things like your crossword puzzle
widget are quite cute - but they are 'toy' computer programs. I
have lots of them that I've written over the years here:

   http://web2.airmail.net/sjbaker1/toys

Even the more sophisticated things like TuxKart are toys by
comparison to serious software engineering tasks.  At work, we
have systems containing 5 and 10 MILLION lines of code.  Nobody
does that stuff in these cute theoretical ways.

> The question is that genaut.py is damn simple and damn powerful,
> and by no means an average "geek" using his average points of
> view may come to something as clear and simple as this.

But *real* programmers don't *need* it to be that clear and simple
if as a result it takes longer and runs slower.

Well, I've had enough of this thread - this is my last post to it.

My apologies to everyone else who had to listen to it.

-- 
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