Chris Huff wrote in message ...
>In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
>wrote:
>> Next, complex conditional if then else statements. Can GOTO be
>> far behind?
>
>Umm, we have if-then-else statements. And switch statements. And goto is
>a bad idea for many reasons.


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

Mark

Post a reply to this message

Mark Wagner wrote:

> Chris Huff wrote in message ...
> >In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
> >wrote:
> >> Next, complex conditional if then else statements. Can GOTO be
> >> far behind?
> >
> >Umm, we have if-then-else statements. And switch statements. And goto is
> >a bad idea for many reasons.
>
> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.
>
> Mark

And that was one out of how many? And by a 'Master' also. Only for the
advanced.   :-)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DC47.1BEAFE1C@neuro.informatik.uni-ulm.de...
>
> Johannes Hubert wrote:
> >
> >
> > For example:
> >
> > for (I = 1; I <= something; ) {
> >     // loop body here
> >     I += non_deterministic_increment;
> > }
>
> From the viewpoint of a computer scientist (I'm one) this is a not a
> syntactically correct defiend for-loop.

Since we seem to look at details now (not to say beginning to split
hairs), I have to point out, that you are wrong: The "for" loop is
syntactically absolutely correct (in the languages C, C++, Java at
least) - on the *syntax* level there is nothing wrong with it.

However:

> Sorry for flaming, but this are the programming styles, which make
> software packages difficult to maintain, debug, readable and
> understandable by other programmers.

With this I may agree. I have never (as far as I can remember) actually
used a loop like this. I would rather use a while-loop for stuff like
that.
The point was to shows that a C/C++/Java style for-loop *can* change its
looping index.

Johannes.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DAB2.3BE14CC3@neuro.informatik.uni-ulm.de...
>
> No, I don't think so. In most programming languages the state of the
> variables used in a for-loop are undefined outside the loop, but most
> programmers ignores this and use the mostly undocomented feature, that
> after the for-loop the variable has the value of the variable in the
> last loop incremented by the specified step.

Not really correct either. You are probably thinking of C++, where the
ISO/ANSI standard says that a variable declared (and initialized) inside
of the for-statement is defined only in the statement and the block that
belongs to it. A fact that is still ignored by most compilers (the
standard is still kind of fresh).

But:

This is true only for for-loops like this one:

    for (int i = start; i != end; i++) {
    }

If you rewrite the loop like this:

    int i;
    for (i = start; i != end; i++) {
    }

then there is no ambiguity about if or if not "i" is defined after the
loop and which value it has. It *is* defined and *has* the value
assigned to it during the last executed operation that modified it.

Johannes.

Post a reply to this message

"Jim Kress" <jim### [at] kressworkscom> wrote in message
news:38c9cb32@news.povray.org...
> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like
this
> but I think the rest of us casual users would be driven away.

I must agree with Jon (see his post). Your message shows a "fear" of the
conecept of "object oriented" that is totally unfounded.
I guess it is porbably mostly fueled by the fact that OO is such a
buzzword, and by (not very good) programmers that have learned
procedural programming and or now too afraid, too lazy or too snobbish
to learn something else, and thus give OO a stigma of "new and complex
and difficult to learn, with no real advantages" just to justify the
fact that they don't even want to look at it.

I am convinced that learning OO programming is in many cases easier than
learning procedural programming (if you are not already "spoiled" by a
procedural language) - and for POV OO would be perfect - easy to
understand and learn and very powerful.

I'm very interested how Mikael's work will turn out. Maybe POV-Ray will
go the way of C++? (meaning *not* that the language becomes like C++,
but that it will be an object oriented language that contains backwards
compatibility to the old language, like C++ contains good old C).

Greetings,
Johannes.

Post a reply to this message

Gilles Tran wrote:

> Of course I don't want to be conservative : POV can (should) evolve.
> But my personal wish list is made of features that would make the
> user's life easier in terms of creation (like a really

> support of some popular mesh formats, or a simple way to make
> patina and cracks, or built-in "fur" and "tree" engines etc.).

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 have to recognize that some programming features (like arrays
> or macros) that seemed complex at the beginning (yes, for a
> non-programmer, even arrays are complex !) proved themselves
> very useful. My current concern, which I seem to share with
> Ken Tyler, is that many of features I've seen on programmers'
> "wish lists" looked like they would surely improve the lives
> of programmers and possibly make pov faster, or more flexible,
> but that they would also make a few non-programmers cringe.
> For instance, some people may have fun browsing a 500-page
> long manual on OO programming, some others don't.

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.

> To answer Ken's questions, I surely would experience trouble if
> the language changed completely.

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.

> I've got my own legacy of scenes
> (which already hard to maintain due to version changes and
> immoderate patch use), and I'm able to work fast because I
> know my way in POV (provided the help file is open !).
> So having a new language format would be like using a
> new software : I would take the trouble to learn it only if
> it was clearly "competitive", in terms of user-friendliness
> and features, over the current POV implementation.

I agree here too. I have more .pov files that you can shake a stick
at and I am comfortable now, after hundreds of hours of using the
program, with it's current language structure.

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

I understand your arguments and can see how many of them may be true.

However, I am not really convinced. It *may* be true that creating a
more stringent and defined "language" may scare away users. However, I
don't know if this has to be so. If the language is designed carefully,
with "non-programmer" users in mind, it may become more accessible.
This doesn't necessarily have to mean that the new language resembles
any given programming language. It could be defined in its very own way
instead.

I have the impression, that the POV-Script has (in places) grown from
some ad-hoc decisions, and is therefore (in places) bloated and not very
logical.
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.
Note: I am not saying that POVs parser is bad, since it has had a long
time to evolve. I am only pointing out the "#" as a thing that has
probably been introduced ad-hoc in one of the very first versions, and
has since been carried with the language, without having much effect
besides making the script harder to read. An example for the "bloat" I
mentioned.

I agree with Ken's assessment that it is nice to have so many different
ways to achieve the same thing. I like that too. However, to have this,
there is no need for a bloated language. Take Java for example: Newly
designed and relatively "lean" it still offers many ways to do the same
thing (and I am *not* advocating to make the POV-Script like Java! this
is just an example...).

I think that "cleaning out the undergrowth" in the language (and adding
some OO features on the way) can have positive effects both for the
"programmer" and "non-programmer" users,
_if_done_in_a_carefully_thought_through_way_!
The "programmers" will find themselves more at home in the POV-language,
and the old problem of the difficulty to parse POV-Script (no program
besides POV really can) would also be solved.
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).

The key is: Such a redesign of the language must be very well thought
through. A quick-shot solution (with focus only on making POV more like
a "standard" programming language) is not a good solution. And also
backwards compatibility to the old script needs to be maintained, so
that the old scenes are not lost in limbo.

So far,

Johannes.

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

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] mailacom> 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