Gilles Tran wrote:
> 
> Johannes Hubert wrote:
> 
> > And the "non-programmers" would get a language for which the manual
> > would actually be *thinner* than it is now, a language that is more
> > approachable and easier to learn (because frankly I think, that many of
> > you here who advocate POV-Script as an easy language to learn have lost
> > perspective a bit, since you alreay *know* POV-Script: sure, newbies
> > *can* learn POV-Script, but the language is far from being easy to learn
> > and could be much more so in my opinion).
> 
> It's obvious that there's a general consensus about the fact that the pov
> syntax,
> having evolved from a simple scene description language to a "programming"
> language has now problems of its own. And you're right, it was never easy to
> learn, and I know of people who downloaded pov and were scared right away.
> However, I think that the original construct "primitive transform texture",
> written in such a way, is very intuitive. I know of teachers who use it at
> school
> to teach maths to kids. I guess it's intuitive because it's close to actual
> language :
> "the sphere is big and blue".
> 
> My own ventures in OO programming and other advanced programming indicate
> that, though there's no discussion on the necessity of it when it comes to
> programming efficiency, it also requires a *much higher* level of abstract
> thinking.
> This may be natural to full-time programmers, but for many people
> (including me) these ways of thinking are extraordinary hard, if not
> impossible, to grasp. Many of the concepts discussed in this thread
> (or in the programmers' wish lists) are simply out of my intellectual reach.

Time to add my own two cents, I suppose.

The POV scene language is a bit of an engineering nightmare, since its
usefulness is more or less inversely proportional to its ease of use.
(As is usually the case with such things.) Fortunately for us, you're
not required to access *all* of the complexity to use the language; you
can define very simple scenes very easily without having to mess with
any of that "weird programming stuff".

I don't think we need to add a zillion ways of doing the same thing;
this is almost certainly the idea of some well-meaning but foolish
programmer who thinks that POV should look more like a "real language"..
as if he has the authority to decide what that is. What we DO need is
some polish. This is a raytracer meant for end users, not a
correspondence course in computer science. Either the package should
include a comprehensive set of tutorials (particularly on things like
isosurfaces, realistic skies and water, media, lighting techniques and
complicated crap like that), or it should be provided as a separate download.

And it would be nice if POV-Ray had some sort of plugin architecture so
that if someone wanted to hard-code a tree-generator or fur-generator to
save parsing time, rendering time, and/or memory, they could do it.
Patches could use the same architecture, since they would basically work
the same way (extension to the parser and some custom code to do the
actual work). It wouldn't prevent you from using #includes, and since no
casual user is going to be able to figure out how those things work
anyway, if it's that important to be able to modify the plugins, the
creators could always provide source code.

Finally, it's my opinion that the POV language is *already* OO. I would
love for anyone who disagrees to explain to me how

object
	{
	dimensions { foo }
	transformation { foo }
	texture { pigment { foo } }
	texture { pigment { foo } normal { foo } }
	whatever { foo }
	}

...is in *any* way fundamentally different from something like

object.dimensions = foo
object.transformation = foo
object.texture[0].pigment = foo
object.texture[1].pigment = foo
object.texture[1].normal = foo
object.whatever = foo

-- 
Xplo Eristotle
http://start.at/xplosion/

Post a reply to this message