In article <38E2A34A.501545B8@nigels.com>, nig### [at] eisanetau wrote:

> > So you just write a simple little program that outputs POV code 
> > whenever you need objects created with programming constructs?
> 
> 	Show us a "simple little program" to parse POV code.

Who said anything about parsing? Read the part I was replying to:
"Nick Drew" 
<hyp### [at] btinternetcom> wrote:

> Forgive me my ignorance - I use POV in relative isolation from this 
> community (until now), and have never required the use of loops and 
> branches, and so I've never tried to find out if it's possible.  Of 
> course, I use flow control structures in my pov generators.

Only POV generators were mentioned...



> > So you want it to work in theory, but not in practice? :-)
> 
> 	Not at all - Works differently in practice.

How?


> > Have you ever heard of the saying, "If it works, don't fix it!"?
> 
> 	The same could have been said about MSDOS.
> 	I'm sure there were quite a few people hesitant
> 	about giving up their command line.  I heard
> 	that punch-cards were a good technology too.

So...loops, macros, and conditionals are things of the past, obsolete, 
and not needed anymore?


> > chopping out the most popular portions and making
> > the rest harder to hand code would be a big mistake in my opinion.
> 
> 	That scenario is not what is being suggested.

Yes, it is. Macros, loops, and conditionals are some of the most common 
pieces of POV code, the suggestion was to remove them and leave POV as a 
declarative language. Or did I misinterpret Nick Drew's message?


> > And if it is left in, why deprecate it?
> > Why should POV-Script be declarative and not procedural?
> 
> 	POV-Script should remain procedural, but perhaps
> 	in the XML context it would be better to leave it
> 	out.  We're talking about an alternative, not
> 	a replacement.

How would this "alternative" be useful? If it can be used with 
POV-Script, you have to use a POV parser anyway. Otherwise, you can use 
either one or the other, but not both. And you would be making more work 
for the POV Team, who would have to support a separate language.


> > This has the disadvantages of being more platform dependant
> 
> 	An ANSI C compiled library is about as portable as it
> 	gets.  A Java wrapper to this API is also pretty portable.

POV-Script is even more portable...if there is a version of POV on that 
platform, your script will run on it.(Unless your script uses certain 
features like halo and the POV application is the wrong version, of 
course.)
Not everyone who wants to use POV will want to install and learn to use 
a C compiler to make their POV scenes. For those who do, just make a 
library for outputting POV code! It isn't that hard to do, just tedious.


> > harder to distribute "scene files", 
> 
> 	Distributing scene files isn't the only goal, what about the
> 	images that come out at the end?

How would XML make the output better?


> > harder to learn to use, 
> 
> 	I find it harder to learn POV script than to use languages
> 	that I'm already confortable with.

Your point...?
It is always harder to learn a new language than to use the ones you 
know, what do you expect?
I meant that it is easier to learn POV-Script than to learn Java, C, 
C++, or others like them.


> > requiring external programs to code scenes, 
> 
> 	Entirely optional.

You have the option of staring at a screenful of tags trying to decipher 
the underlying structure or using an external program, you mean?


> > and also a lot harder to offer support for. 
> 
> 	You don't offer support for 3rd party apps anyway.  I get 
> 	support for the compilers that I've bought.

Huh?
People will ask for help. They will expect it to be given to them. If it 
is some kind of framework for use in C, C++, or Java, they will ask the 
people who make it. If it is POV-XML, they will ask the people who make 
it. Meaning the TAG and POV-Team.
And besides that, the POV-Team will have to support the actual 
programming required.
3rd party apps are irrelevant, there is still a need for language 
support.
Of course, you *could* do something like what I am going to attempt with 
POV-CSDL, and make a separate translator program to go from POV-XML to 
POV-Script. You could make the program open source, and the POV-Team 
wouldn't have to support anything.


> > If everyone is using their own language, that will break the POV 
> > community
> > into several different sections. 
> 
> 	The POV community could use some diversification. :-)

Not that kind. All that would do is add confusion.


> > Having just one POV-Script means everyone can gain from experience 
> > of others and sharing information is easier.
> 
> 	The pov scripts that I write are of zero interest to anyone
> 	else.  My goal is usually the image, not an elegant scene
> 	file.

And nobody is ever interested in sample code for solving a problem or 
showing how to use an advanced technique, right?

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/

Post a reply to this message