Re: Hooks

On Tue, Jun 8, 2010 at 3:33 PM, Richard Fabian <[email protected]> wrote:
> OO C++ might be nicer to look at than data oriented C++ (if it's done right)
> but it seems that as it so seldom is done right, can't we just move to a
> paradigm that newbies will be able to understand enough to not cause us
> massive grief later on when we pick up the pieces?

Why is "avoiding massive grief later" a commercial goal?  The guys
that were doing things before, they shipped, they got paid, they moved
on to something else.  The company wanted to ship, so it's not like
they cheated the company.  Just about every American company out there
plans for the next Quarter only, not some long term business cycle.
YMMV in other countries.  Game projects have to survive, and a lot of
game code is disposable from project to project.  Reuse is overrated
and shouldn't be over-engineered.  Sure you can and should keep one
eye on the future, but you've always gotta keep two eyes on the
present, or your project tanks.  I'm saying, you shouldn't approach
the software engineering from a position of prejudice where crap isn't
allowed to happen and is viewed as "wrong" development.  Crap *is*
going to happen, and programmers are going to get paid to clean up
messes later, long after the fact.  That's reality.  If you don't like
that kind of job, and are being subjected to too much of it at a given
studio, perhaps you should move on / move up?  It is much better to
make new messes for other people to clean up, rather than spend your
time head scratching and cleaning up old messes, unless you're getting
paid an absurd amount of money to do the latter.

My $0.02 is that C++ greatly exacerbates these problems.  Moving to a
garbage collected language helps somewhat.  Blind adherence to OO
still creates problems however.  Maybe in time, as programmers become
more accustomed to non-OO paradigms, code will gradually become more
maintainable.  I'm thinking particularly in terms of metaprogramming,
which seems apropos to an "I wanna hook into all of my variables"
sentiment.  Why torture yourself with trying to solve that kind of
problem in C++?

While we're waiting for the future, though, I think it's important to
recognize when our problems mainly stem from our choice of tools, or
job, or team members, or segment of industry, or other things we can't
simply code our way out of.  You can't make a silk purse out of a
sow's ear.


Cheers,
Brandon Van Every
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com