"Ken" <tyl### [at] pacbellnet> wrote in message
news:38CA2519.7A4AFCB5@pacbell.net...
>
> That is a dangerous assumption. I am painfully aware of the problems
> I had learning the scripting language in POV-Ray. I think you would
> be surprised to learn I had more problems thinking in terms of 3D than
> I did learning POV's scripting language. Sure it took some time to
> learn what sequence and order items should be placed in the scene file
> but it took me much longer to learn position, object control, and
> CSG operations than it did the syntax peculiarities. I also think
> that the difficulties of learning any new proceedure or scripting
> language will be unique for each user of the program. It's like the
> guy with a 6th grade education who can do a valve job on a newer
> Mercedes and the guy with a college education who can't figure out
> how to change the windshield wiper blades.

All this nonewithstanding, I still think that POV-Script could be
defined in a way that it makes it even easier to learn.
The fact that *you* had more problems with the 3D than with the syntax
doesn't mean that there may be others for which it is the other way
round.
And the fact that *you* didn't have too many problems with the syntax at
all doesn't mean, that maybe even *you* might have had even fewer
problems with a different POV-Script.

It all comes back to my second post: This is not a black or white issue,
but one where the best middleground should be found.

Johannes.

Post a reply to this message

Johannes Hubert wrote:

> It all comes back to my second post: This is not a black or white issue,
> but one where the best middleground should be found.

It is good that we warriors from different tribes can come together
on the battle field and let the other know what it is that we are
fighting for. Without discussion there can be no truce.

<g>

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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.

I don't remember having much trouble learning Basic or Fortran,
or the pov language : none of them was simple, mostly because of the
keywords to learn and remember, but nothing seemed outlandish.
But, after many years, I *still* have difficulty using something as simple
as MS Access Basic and I'm *still* confusing methods with properties,
for instance. Possibly, somebody with absolutely no programming background
would have no trouble at all, (because of the absence of old programming
habits) but frankly I doubt it.

So, yes, as you  say, a middleground should be found, and it should take
into account the fact that a pov user (according to my own conception
of pov of course) shouldn't have a PhD, or at least be a professional
programmer, to use it.

G.

Post a reply to this message

In article <38c9e8bc@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.

That was one case, out out of how many switch and if-then-else 
statements? The goto statment is very rarely needed, I don't think we 
are likely to run across one of those cases in something like POV.
And like Jon Cruz said, "Only for the advanced.". Since I don't consider 
myself advanced, I just avoid it like the plague. I have yet to run 
across a situation I need it...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38c9e8bc@news.povray.org>, "Mark Wagner"
> <mar### [at] gtenet> wrote:
> 
> > In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> > algorithms, simplifying things greatly.
> 
> That was one case, out out of how many switch and if-then-else
> statements? The goto statment is very rarely needed, I don't think we
> are likely to run across one of those cases in something like POV.
> And like Jon Cruz said, "Only for the advanced.". Since I don't consider
> myself advanced, I just avoid it like the plague. I have yet to run
> across a situation I need it...

Strangely the GOTO command is one of the few in Qbasic I ever understood
how to use successfully... Imagine that !

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA4E30.DAF9FB3E@pacbell.net>, lin### [at] povrayorg 
wrote:

> Strangely the GOTO command is one of the few in Qbasic I ever understood
> how to use successfully... Imagine that !

It isn't difficult to understand, it just usually leads to poorly 
designed and hard to read "spaghetti code". It can be used to do 
anything the #while loop and some of what #macro's can do, but the code 
becomes almost impossible to understand. There are cases where it can 
make a chunk of code(in C/C++/Java and probably the newer BASIC's) 
easier to understand, but those are quite rare.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA2128.BD294B07@pacbell.net>, lin### [at] povrayorg 
wrote:

> Here I will definitely agree with you. I would like to see procedural
> features added that ease the creation of scene building without having
> to resort to adding difficulty to the language itself. If you look at
> the wealth of plug-ins available for 3DS Max you will see that they
> offer some powerful features, that are easy to use, and the functions
> that make them work are transparent to the user. The question that
> needs to be asked is if the program exists for programmers or if it
> exists for users who don't care how it works so long as it does.

I am not sure if some of these things, like cloud objects, fur, trees, 
etc, would be a good language feature. It would be faster parsing, but 
that is about it. It would be more difficult to modify, if you want to 
customize it you would have to become a patch programmer. These seem 
like things best taken care of by include files and macros.
Now, something like an L-system object would be a different matter...it 
would still be quite flexible but would also parse much faster and 
probably consume less memory. The syntax would be a little hard to 
define, but the results would be worth it. And maybe a couple 
specialized patterns for making types of clouds and smoke with 
media...and maybe a partice system object.


> Good point(s). What I also fear is that if the programming language
> is extended in POV-Ray to include OO programming, for () loops, and
> all of the other programming suggestions that have been addressed
> in this thread, is what is going to happen when some non programming
> literate POV-User comes to the news groups seeking help and some
> programmer type gives them an example in the form of these new
> features ? The programmer types (and there a lot of them here in the
> groups that answer questions on a regular basis) will quickly adopt
> the attitude that everyone thinks like them and give examples in
> their language style of choice, while the real truth of the matter
> is that they could express themselves in a way that the people
> seeking help will not understand a word they are saying.

Do you really think the #for() loop would be harder to understand than a 
#while() loop? I think it would be easier to understand, at least, I 
found it easiest to understand and use when I was learning programming. 
(in Tandy and Commodore BASIC, yuck)
And why all the paranoia about object-oriented features? What does a POV 
script do? It manipulates *objects*. The object oriented features would 
only make this simpler. 500 pages? Try 5 pages, for the in depth 
description including examples. I'm not talking about inheritance, that 
wouldn't be necessary. I'm talking about the ability to have objects 
have accessible data(like MyCamera.location) and to attach variables and 
macros to objects.


> I would probably not use the new version if it became to hard to
> learn. This would restrict me to using the older versions of the
> program and I would miss out on new features.

Few of the feature requests I have seen would cause problems with 
backward compatability...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA2519.7A4AFCB5@pacbell.net>, lin### [at] povrayorg 
wrote:

> I think you would be surprised to learn I had more problems thinking 
> in terms of 3D than I did learning POV's scripting language.

Hmm, my biggest problem was remembering all the keywords. :-)
I still can't remember off hand whether no_shadow or shadowless is used 
for an object...the thinking in 3D was actually the easiest part for me.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38ca2675@news.povray.org>, "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> I had to wonder about your viewpoint on this for a moment but my 
> sentiments lean toward the hashmark (#) as being one of the things 
> that shows the person, not the parser alone (however that works), 
> where each of those special keywords are.

On the other hand, newbies might be scared away by a file full of 
mysterious commands with hash marks in front of them. :-)
Remember that the reason you use them as visual cues is that you are 
familiar with the language.


> But what may be getting overlooked is how POV has a programmer 
> language of sorts simply by being what it is: textual interface.  The 
> continuance of that into more features isn't the issue I'm sure, it's 
> the syntax that is the hub of this discussion.  By that reasoning it 
> should not ever be a hard-core programming language, instead it 
> should always be a common vocabulary most of all.

Well, it definitely shouldn't become a "hard-core programming language", 
since it's purpose is to describe scenes. But some of the features of 
more advanced languages would make the description of complex scenes 
including trees, plants, particle effects(like the Liquid Spray include) 
much easier. You wouldn't even have to understand them, you could just 
use include files written by others.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA3F4E.54F5C535@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> 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.

I think you are getting scared off by the "inheritance" features of most 
object-oriented languages. They are the main source of complexity in 
programming languages, and I don't think they would be necessary or 
useful in POV. What I am talking about(and what I think most other 
people who want OO features are talking about) is adding the ability to 
bind macros and variables to objects, and access the attributes of the 
object. Which seems more intuitive:
#declare MyObject = object {MyObject translate y*3}
or
MyObject.Move(y*3);

You could have a separate Move() macro for a specific object which would 
do things like change the color depending on the distance moved. (like 
in steam dispersing or fire turning into smoke) The code would be much 
less complex, and easier to understand. Copies of the object would have 
the same macros and copies of the variables, but that would be the only 
inheritance-like feature, and is not difficult to understand.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message