"Chris B" <nom### [at] nomailcom> wrote:
> Backwards Compatibility
> There's a lot of time been invested in tutorials, interfaces, macros and
> objects.
> Much of the written information out on the Internet (including the years of
> newsgroup postings) doesn't specify which version it relates to, so if this
> material is rendered largely redundant it's probably going to be wise to
> totally change the product name. Otherwise there's a risk of years of
> confusion that may create difficult barriers to new users.

There is some point to this; however, that's why it would be "POV-Ray 4.0", and
not "POV-Ray 3.8".

I don't know anything about POV-Ray 2.0, but I bet tutorials on it would be far
from usable nowadays, too.

Backward compatibility could also be maintained by designing the new language
such that it will be compatible to POV 3.x SDL up to (and including) the
"#version" statement, at which point a legacy parser may kick in.

> Inventing New Languages
> There are a lot of mature languages about in common usage with comprehensive
> and well designed structures and support channels. It may be better to adopt
> one existing language, providing API/DOM access to the C++ core with
> official support for that language. Enthusiast for other languages could
> then add support for other languages as trends change.

This would (a) generate a major problem with POV being unusable stand-alone, (b)
require a major effort to implement a whole mature language (and all its
features, because that's what people would expect), or (c) open up the can of
worms called GPL by integrating an existing language interpreter into the POV
package.

> Maybe a solution would be to create an integration layer with native support
> for an enhanced version of the established POV-Ray SDL and, at the same time
> expose the API/DOM. As a particular programming language becomes a popular
> choice for the POV-Ray community in years to come it could become the
> defacto standard and could be added to the short list of officially
> supported languages.

In my opinion the problem with the current SDL is not only that it is showing
its age regarding the features it offers, but also the syntax: It is far from
consistent with itself (just look at #fopen vs. #fwrite: Why does one have the
parentheses, while the other has not?), and needs an overhaul even in that
respect.

I think a redesigned language would actually be of benefit for new users, as it
will be much easier to learn.

If the basic syntax is sufficiently different, but the scene stuff parameter
names are not changed, I guess there will not be much confusion: It will just
be an (obviously) different syntax to access the same properties.

Those tutorials not dealing with scene stuff properties but instead elaborating
on how to work around the shortcomings of the current SDL will be rendered
obsolete anyway by a next generation SDL, or we'd better not talk about a new
SDL at all.

Re established general-purpose language, note also that Perl is currently
undergoing a major syntax overhaul, so even going for established languages
does not save you from incompatibilities between language versions.

Plus, I'd expect API/DOM access from an established language to usually be a
good deal more cumbersome. So instead of writing something like this:

for(i = 0; i < n; i ++) {
  sphere (<0,i*2,0>, 1) {
    texture {
      ...
    }
  }
}

you would for instance need to write something like this:

for(int i = 0; i < n; i ++) {
  Sphere mySphere = new sphere(new Vector3d(0,i*2,0), 1);
  mySphere.texture  = new Texture(
    ...
  );
  pov.addToScene(mySphere);
}

So, as a scene designer, which would you prefer?

POV scene description is a highly specialized application, and therefore IMO
advocates a special language. Even if it's only for the native support of 3D
vectors and colors: They're just too commonplace to use general-purpose
languages' typically comparatively cumbersome ways of expressing custom-type
"literals".

Instead, the SDL can fairly well go without various other common features of
all-purpose languages, like event handling, exception handling, inheritance,
sophisticated regular expressions, dynamic memory handling (provided the basic
data containers are good enough), reflection (except maybe some rudimentary
stuff), template classes, interface declarations, and a good deal more, that
really make those languages complicated to implement.

To summarize: No, I don't think it would be prudent to continue extending the
existing SDL after POV 3.9999.

Post a reply to this message