In article <41dbac8c@news.povray.org>,
 Bernd Fuhrmann <Sil### [at] gmxde> wrote:

> >>What should be thought of is this: There are a lot of good programming 
> >>languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
> >>Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
> >>own programming language that is compatible to none of the existing 
> >>ones? The only thing that POVRay needs to do is this (simplified):
> > 
> > Simplicity. None of those really cut it.
> 
> If you say so. Are you quite sure of what you're talking?

Yes, I am quite sure. I have done complex simulations in POV-Ray, it's a 
pain in the ass. I have also done scenes coded directly in Java and C++, 
that's a bigger pain in the ass than writing the raytracers. As I 
mentioned before, simply the lack of a built-in vector syntax makes 
things much harder to write and read. My C++ tracer can be made to do 
Monte-carlo path tracing by simply coding the materials in a certain 
way, but building a scene of any complexity is maddening due to all the 
C++ syntax I have to work through.

Pascal, Delphi, JavaScript, and PHP would all have similar problems to 
C++ and Java related to the requirement of using an API. A Prolog SDL 
would be...very interesting, but probably not very good for general use. 
Scheme might make a useful, but idiosyncratic SDL. XML is useless for 
hand coding, and no easier for automated programs to write than a custom 
SDL would be.


> Some of those languages are very powerful, especially for large projects.

And this shows you completely miss the point. It doesn't matter how 
powerful the language is if you must be a programmer to use it. Most POV 
users aren't programmers, despite hand coding their scenes in a 
Turing-complete programming language.


> But they can't do advanced things as easy as they could if there existed 
> some default front-end for one of those programming lanugages mentioned 
> above. So there should be an alternative for those who want to do the 
> more advanced stuff.

They can't do them *now*. They could with a improved scene description 
language, more easily than they could with a general programming 
language.


> Programming languages don't change that much. Last change of C++ was in 
> 2001, I guess, and that was just a minor issue. Ok, C++ is complex. You 
> might consider the use of any other programming language. They are well 
> defined and if there are substantial changes you might stick to the old 
> version for a while. You might even use external compilers so the POVRay 
> team can concentrate on the raytracer.

...

The POV-Team, and all the people developing patches, will concentrate on 
what they want. Much of the time, that is extending the language to be 
more powerful for describing scenes. It is not just a minor subsystem 
for loading scene data.

In addition, an external language will either lose a great deal of 
versatility because it can't tie directly into the tracer, or lose 
portability due to having to dynamically load the POV-Ray renderer as a 
library. Evaluation of pigments, transformations, and ray intersections 
during scene construction are extremely important features. You just 
can't do this without adding problems with portability, dependency on 
other libraries or utilities, etc. And then you have the issues with 
ensuring security from malicious scripts, convincing users that they 
have to learn a complex programming language and scene API, etc...


> It's not learning POVRay SDL but getting complex work done with it. I 
> can tell you that it is not motivating if you are just experienced 
> enough to know that the code you are writing will not be maintainable.

You miss the point again...that can be fixed by improving the SDL, 
without losing its advantages...which would be lost by moving to a 
general programming language. Ease of learning the language and using it 
for things which are simple in terms of programming are far more 
important than you seem to realize.


> So there would be another POVRay modification. I don't have the time for 
> this. I would have to redesign half of the program. This is useless 
> since I would have to spend so much time and in the end noone would use 
> my version (except me). All the advanced features of the next version 
> and it's bugfixes would not be in my version. Therefore this is pointless.

I think this should be obvious, but if nobody finds it useful, it 
shouldn't be in the official version.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message