antoine <map### [at] orangefr> wrote:

> Hello,
> (I apologize in advance for the possible bad english)

No worries.  Some of the people who speak the worst English are the ones born in
English-speaking countries.  ;)

> I remember some years ago, Christoph Lipka was evocating/evoking the
> Json script language as a replacement of POVRay's Scene description
> language.

("advocating"?)

https://news.povray.org/povray.pov4.discussion.general/thread/%3C566c3270%40news.povray.org%3E/

I was involved in a very large-scale project, and the way it was organized, was
that those who wanted their "camp" to be considered would submit a "cover
letter" explaining their position, and supported by a "spreadsheet" covering all
of the pros and cons, deficiencies and benefits of their way of going about
things.
People signed up to be part of the team, with the understanding that when a
critical mass was achieved (the development team), they would then do what was
necessary to become an active developer.

In order to "best" determine the will of the active user base / developers, the
Condorcet method was used to select which "camp" would drive the development.
https://en.wikipedia.org/wiki/Minimax_Condorcet_method

I think it would be productive and educational if a list of programming
styles/paradigms was made, with representative specific languages, and then
people with specialized knowledge of each of those languages would fill in the
details, and explain how things are the same, different, beneficial,
detrimental, etc.  Then we could have something to read over and really KNOW
what we want for a "new SDL", and there would historical documentation for the
users to understand WHY - which seems to fill up a lot of recurring newsgroup
threads.

Then we could move on to organizing the complexities of the hierarchies of CSG,
pigments, textures, normals, finishes, uv_mapping, cutaway_textures, etc.

Specifically highlighting good programming practices, and exposing the pitfalls
of certain ways of doing things that lead to ambiguity, unintended results,
scope leakage, etc. (with specific coding examples and results) would minimize
covering the same ground repeatedly, and focus efforts on continual progress,
rather than getting bogged down in rehashing old issues with new contributors.

Once again, I'll point out that a lot of folks here that have been around a long
time, simply don't have the time, energy, focus, round-tuits, programming
experience, writing parsers and lexers, etc to take on something like re-writing
all of SDL from scratch and getting something functioning at the end of it.

So soliciting outside expertise in these areas seems to be less of a suggestion
and more of a critical need.

- BW

Post a reply to this message