 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, I want to add and stress a few points:
During this discussion I have felt a strong polarization between two
main types of contributors:
Experienced "non-programming-type" POV-Ray users (like Gilles and Ken)
presenting the view that POV-Script as it is now is easy to learn and is
perfect for newbies and non-programmers.
On the other side:
Experienced "programmer-type" POV-Ray users that are not satsified with
the language style of the POV-Script and that claim that adding more
"programming-language-like" features would help.
I think this is too much black-and-white:
The truth is probably somewhere in-between: POV-Script is not easy for
newbies, no matter what the POV-Script veterans that have become
accustomed to it think. And redoing the script to a programming language
will not help either.
A "best-of-both-worlds" approach would be needed: Use the decades of
experience and "best-practices" that have accumulated in the field of
designing good programming languages, and combine them with a good
portion of usability for "non-programming-type" users and their
experiences with the POV-Script AND keep the result backwards
compatible.
(And only to have this buzzword in my post too: I think that you don't
even have to go looking for an OO-solution if you try to do this,
because it will come looking for you, since POV already *is* inherently
object oriented.)
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Johannes Hubert" <jht### [at] maila com> wrote in message
news:38ca2192@news.povray.org...
| Example: The fact that many keywords begin with a "#". This is a typical
| sign for that the person who designed the initial language and parser
| did not really know too much about parsers (I hope I am not stepping on
| too many toes here, because I am speculating...) The "#" makes the
| keywords easier to find for the parser, an approach intuitive for many
| people who are confronted with writing a parser for the first time and
| don't know better. However, parser technology has for a long time been
| very advanced, and there is really no need for such "crutches" to make
| parsing easier.
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.
In fact they tend to be of prime importance so it's very good to know where they
are located. Something you can do a search for easily too and can find all, not
just one, of the pertinent keywords.
This fact leads me to believe it might be good to have more such referencing
symbols for particular actions. At least that's one way to look at it. I think
I might get lost in a pov script having no special symbols, it can be such a
visual cue.
Anyway, I agree with Ken's remarks about the programmer/non-programmer thing a
lot. 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.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
