RE: Managing "Designers disgust". RE: cheating

[Jakob Ilves <illvilja at yahoo dot com>]

Hello again!

(Xconq mailing list folks, if we are getting to chatty here, just tell us to slow down...  The
volume of traffic here has, well, peaked...)

 --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > From: Jakob Ilves
[mailto:illvilja@yahoo.com]
> >
> > So, as a hobby hacker, by strongly handling future concerns
> > one gets a win ONLY if one has strong
> > immunity against the "designers disgust".  That is, being
> > very (extremely?) patient and persistent.
> 
> I had 9 months' worth.  Then I broke.  At least the code I wrote is
> solid - overengineered really.  It'll be there for me when I resume a
> year from now.  But man, what a lousy way to handle one's morale.

Um, I don't consider your case to be viable for a "designers disgust" discussion.  You've not run
into this on as a hobbyist programmer.  You've run into issues out on the disgusting battlefield
known as "commercial game programming" and that's a completely different story.  You did not take
the risk of just getting a morale break or getting tired of your project.  You took a major
economical risk in an environment full of competitors and scavengers and bumped in a wall!

I know people making (or trying to make) a living as artists, by making comics, by programming
games, by making music etc.  All that kind of creative stuff which is fun as a hobby but which I
think is a mere nightmare as a life.  All stories about scrupolous bastards ripping these people
off, competitors stealing ideas. Imagine never knowing if the next months rent can be paid or not
(yeah, income can be SCARCE).  I'm impressed by you people (yes, you are included Brandon) because
of the economical risk you CONSCIUSLY expose yourselves to.  As long as I've got my two kids to
think of, I would never do such a thing.  (Who knows in 10 years though, Carl Barks was 40 when he
started to draw his classical Donald Duck comics ;-)

I just want to make it very clear that I never intended to compare the "designers disgust" of a
hobbyist with the economical disasters professional artists, comic drawers, game programmers etc
risk to experience.

> > But what levels of patience is appropriate for a
> > project is pretty much dependant on
> > the people working on it, at least in the hobby programming
> > area.
> 
> I think you have to provide exceedingly quick rewards to developers in
> any arena where they're not getting paid.

Well, it depends.  Sometimes volunteers appears who don't want to get quick rewards, they are just
impressed of a project and have decided to contribute to it, sometimes taking on quite difficult
tasks which DO take time to solve, especially in a hobby based open source project.

But your right, if people have the patos in themselves, they NEED to be rewarded to work for free.
 Or, to get a rather quick "payback" by managing to add fairly quickly a feature to an open source
product they need in their work.

> > Some folks prefer to invest in
> > managing multiple future concerns simply because they can
> > afford it without running into
> > "designers disgust".  They're patient enough.  In such
> > environment, it's tough to make them change
> > their minds to shift more of their focus on today's fetures
> > because their current allocation of
> > work on between current and future concerns are working for _them_.
> 
> "Masters of DOOM" by David Kushner is illustrative in this regard.  John
> Carmack put his developers through *hell* as he was perfecting his
> engine.  It was working for John's technological needs, it wasn't
> working for other people's game design needs, and it tore the company
> apart.

The open source ImageMagick was resently divided into two projects: ImageMagick and
GraphicsMagick.  I don't know if any situation with similarities with "hell" caused that split but
there were different ideas in the group about where the project should lead so...

A good example that open source project isn't immune in any way against some of the issues
commercial projects/companies are facing from time to time.

> > If one isn't that patience an extreme solution for a hobby
> > hacker can be to ignore future concerns
> > alltogether in order to speed up short term development.
> > That can lead to a horrible product
> > implementation which is rewritten over and over again but it
> > might on the other hand be written by
> > a very amused developer.
> >
> > For that "pentahexahepta" thing I've lately been considered
> > to do the latter.  Take all virtues
> > like structured programmed, OO design, security and _LOCK
> > THEM IN SOMEWHERE IN A CLOSET AWAY FROM
> > ME_.
> 
> Yeah, if you *can* succeed in barfing out code in this way, it's a good
> idea to do so.  Any working scaffold, however heinous, is better than
> sitting around methodically planning without really cutting code.  The
> risk of course is when the project does in fact require highly
> structural discipline to pull off.  Some neato technologies, you can
> just pull out of your ass by shoveling them.  Others, you really do have

Good news, that I know how to do! ;-)

> to sit down and be an Architect / Disciplinarian.

Argh.  Why do I always end up with such tasks, why do I always want to do complex things?  Or
maybe I'm too stupid to even manage "shovel tasks" without architecture and discipline :-q.

(Nothing is so easy that it cannot be darn impossible if being stupid enough ;-)

> I think Python is the right language for people who want to barf.  It's
> a dynamically typed language, you don't get any more flexible than that!
> In contrast, people who do C++ tend to "wax architectural" and get
> sucked into optimizing their code.  They end up missing the forest for
> the sake of the trees.  It's a disease I've had as a 3D graphics
> optimization jock, and I've learned the very $$$$$ hard way to get away
> from it.

I know.  I really enjoy being a pathological perfectionist.  Bad news is that time never permits,
I constantly have to do trade offs.  The only good thing is that I'm usually aware of which
corners I cut and what stuff it is that will get back to me later and bite me (and the latter
happens...).

> I can't even fathom people willingly using plain C in 2003 without pay.
> That mentality is utterly alien to me, there are far better and more
> interesting programming tools available out there for free.  Python is
> merely a common one that has nascent market momentum behind it.  I think
> library, tools, community support, and proven real world use are all
> valuable, so that's why I champion it.

Why use C anno 2003 for an open source project?  That's an intresting question.  A few reasons
might make it a reasonable choice:

Quick answer: performance and portability between platforms (C has been around for three decades
so it's solid in that respect).  Also, there are apperently some developers (including good ones
writing good products) that don't consider OO to be that much valuable.  (Don't ask me how they
come to that conclusion, I am a OO fan).

More elaborate answer:

* Performance.  By profiling a highlevel program in Python, Perl or Tcl and realizing a small
chunk is doing 99% of the CPU usage, you can speed up things considerably by writing that chunk in
C instead.

This is how the open source Perl program MRTG (Multi Router Traffic Grapher) was speeded up by a
factor 20.  MRTG was initially 100% Perl but then a user submitted a small special purpose C
program (called "rateup") to be included in the MRTG package.  That program was used to replace
the Perl code pieces responsible for writing and reading graph data on disk as well as generating
the graph GIF images.  By running those tasks by calling that external C program the performance
boosted.  The Perl code handling the polling of statistics and web page generations were left
intact.

* Stringent portability demands.  The above mentioned "rateup" executable (being a part of MRTG)
were later on spun into a stand alone product called RRDtool, usable for MRTG as a replacement for
"rateup".  RRDtool could of course be used in other statistics frameworks, not only MRTG (it can
be used in Xconq to display statistical graphs for the game as it proceeds).  That software is
written in C for performance and I think one reason C were preferred over C++ was that the author
wanted to make the program run on as many platforms as possible.  C++ compiled with GNU g++ was
percieved as being slightly less portable than C compiled with gnu gcc.

I've heard that comment elsewhere as well, that some people considered C a more solid platform
than C++ and I recall I found it surprising at the time.  I was, until then, thinking everybody
ought to "prefer" C++ over C in all circumstances but maybe that's a bit naive.  Over the years,
I've started to get the feeling that OO is a programming paradigm among many others, being
justified at many places but problematic at some.

For the curious, the two projects are here: http://www.mrtg.org, http://www.rrdtool.org.

/IllvilJa


=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html