ingo <ing### [at] nomailcom> wrote:

jr and I have had extensive discussions and brainstorming / planning sessions
where we have striven to address how we should go about
fixing/rewriting/developing POV-Ray and how to best manage an open-source
project.

I like to use the analogy of actually building something.
It may start with an idea, then a sketch, then an analysis of the details:
requirements, parameters, goals, features, allowing modification/extension, etc.
Detailed drawings, Geometric Dimensioning and Tolerancing, and perspective
drawings to get a preview of what it will look like when finished.

As folks have seen, I have tried to make lists of "things" in POV-Ray that I'd
like to implemented, improved, or fixed.

I've also made some doodles in SDL to sketch out what I'd like to see formally
implemented in source code.

With things like sor {}, I've gone through the source and done the research and
detective work necessary to understand what the goals, are, how they are
currently implemented, and meticulously checked all of the steps that make it
work, and compared that to expected or desired outputs.

Then I offered suggested source code edits, and critiqued the current state of
not only the sor {} object, but the related lathe, the spline code, the root
solver(s), and the bounding.


> There is a, almost natural, discrepancy between developers and users of
> a program. They have different interests, goals. Nothing wrong with
> that.

Yes, but there does need to be communication and meaningful feedback for
anything productive and substantive to happen.

Developers create the things that the users implement.
Users dream up applications of what the developers create.

There's a behind-the-scenes anecdote regarding the film's set design. When
reviewing script scenes depicting Hell, Director Adrian Lyne asked writer Bruce
Joel Rubin, "How many carpenters do I need to build the abyss?"
That really struck home to the writer the immense practical construction

but might take a herculean effort to create on a set.

"Easier said than done."

Also consider the "bullet time" scene from The Matrix.  I think it took a year
and a half and a huge pile of equipment and money just to implement an effect
for only a few seconds of a scene in an otherwise long film.

> Coders and users speak the same
> language, they all "code". That removes "friction". That can enhance the
> product.

> I'm in no way suggesting that in such a case users can suddenly be core
> POV-Ray developers. Knowing the moves of chess pieces don't make me a
> chess player.

Yes, this is why I have strongly suggested that users pick a feature and try to
implement it in SDL. (or any other language)
It serves to increase understanding of what actually goes into making a shape,
or solving some equation, and properly visualizing it on the screen.

It also helps (self)document things, incidentally discover limitations, bugs,
and other unknowns, and usually the user winds up providing the results of their
research and discoveries in the forum.

That helps everyone in the long run.

Documentation is a giant pain in the ass.
However, formal documentation need not be a stumbling block for releasing a new
version.
No one needs a 4-paragraph explanation about how to use a volume control.  Be it
a rocker-style button with +/- marking, a knob to rotate that has a wedge shaped
glyph, or a slider that has a bar-graph indicator.
Even if the label is somewhat cryptic and mysterious, you just move the control
and observe the change.  Understanding is almost instantaneous.

If we have working code that a user can implement in seconds, then they can just
fiddle with the controls to intuitively understand what might takes pages of
written documentation to convey.  Not to mention all of the renders and diagrams
that might be necessary to supplement the text.

So I'll say it again:   1 fully working code example for every keyword.

Once the code gets written, it's a lot easier to understand what may need to be
written about it, and the written part can always lag behind the development
(presuming that comments are provided in the cde, as they should be).

- BE

Post a reply to this message