"Carlo C." <nomail@nomail> wrote:
> If it can be useful the point of view of a non-programmer and a beginner in
> POV-ray...

.... which is well appreciated and actually of high valuable in this context, as
it is virtually *impossible* for any programmer to assess a programming
language's "approachability" (or absense thereof) to beginners.

Maybe it's the most important point of view we need to take into account. After
all, POV-Ray is a raytracer first, and although it is obviously primarily aimed
at people who can get along quite well without a "wysiwyg" type of 3D modelling
tool, and one of its *strenths* is its integrated programming language, still
it aims for a much broader audience than just full-fledged software developers.

> POV language is simple and intuitive, and there are not hateful things, like:
>
> - *<>* or *</>* for each line...

I bet (and hope and pray!) POV's SDL will *not* go XML ;)

> - long word, filled with *__*, etc.

Doesn't remind me of a particular language. But I guess what you're saying is
that a POV language should use short (yet clear) words.



Like in that language occasionally referred to as "the duct-tape of the
Internet"? Yeah, with duct tape you can do just about anything quite fast, but
the result always looks ugly, and you better have the job re-visited soon in a
more professional fashion ;) (Well, after all, "perl" is not a "pearl" ;))

(Then again, I'm not perfectly sure whether that is the kind of stuff you are
referring to.)

> - billion of brackets of all types that disorientate...

Yes, the typical POV script has those omnipresent curly braces for nesting
objects and their properties, some parentheses for some mathematical formulae,
and an occasional square bracket for array indices, and that's it, basically.

Which is possibly why I'm still irritated at the square brackets used for maps.

> Here, would it be possible to make the POV-language more powerful while
> preserving the characteristics of simplicity?

You definitely have a point here.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > > for(int i=0;i++<10;)vec[i]=i*i;
>
> > Well, that's (1) not plain C but C++
>
>   That has been valid C for 10 years now.

There are still environments where the original C89 ANSI-C is *the* C standard.
Not only because of compiler availablility.

For instance, high-reliability systems written in C are often required to be
MISRA-C compliant - which as of today still demands use of plain vanilla C90
ANSI-C (if I'm not mistaken; it may be even C89).

The least common denominator today is still C89 ANSI-C (and actually only a
subset thereof, namely that which is not specified as leading to
compiler-specific or undefined behavior).

Post a reply to this message

clipka <nomail@nomail> wrote:
> [-- text/plain, encoding 8bit, charset: iso-8859-1, 21 lines --]

> Warp <war### [at] tagpovrayorg> wrote:
> > clipka <nomail@nomail> wrote:
> > > > for(int i=0;i++<10;)vec[i]=i*i;
> >
> > > Well, that's (1) not plain C but C++
> >
> >   That has been valid C for 10 years now.

> There are still environments where the original C89 ANSI-C is *the* C standard.

  I don't see how that's relevant in this specific context. It's a bit
like saying "we should support Windows 3.1 because some old computers
might still be using it". May be *technically* true, but in practice
mostly irrelevant in this context.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > > > > for(int i=0;i++<10;)vec[i]=i*i;
> > >
> > > > Well, that's (1) not plain C but C++
> > >
> > >   That has been valid C for 10 years now.
>
> > There are still environments where the original C89 ANSI-C is *the* C standard.
>
>   I don't see how that's relevant in this specific context. It's a bit
> like saying "we should support Windows 3.1 because some old computers
> might still be using it". May be *technically* true, but in practice
> mostly irrelevant in this context.

That was also the case for my statement "that's (1) not plain C but C++", and
therefore also for your statement "That has been valid C for 10 years now." As
a matter of fact, this branch of the thread has left "the specific context"
quite a while already ;)

Bottom line: Looks like I have scored a point in this nitpicking contest, by my
opponent - after having jumped in on the game at first - now backing off into
pointing out that I'm nitpicking :P

(Yeah, I love having the last word in an argument, as silly as it may ever be
;))

Post a reply to this message

Chris B wrote:
> When you say "all over the place" you may be able to access a few sites,
> but
> when newbies do a Google and discover thousands of sites containing
> materials most of which just inexplicably don't work and can't readily be
> made to work then it's likely to have a very negative effect on their
> impression of the software.

	One possibility is to have POV-Ray detect somewhat that the syntax
being used may be the old one, and have it fail with an explicit
explanation so that they can go to the official docs.

	Frankly, though, I have difficult imagining that someone who's never
used POV-Ray before wouldn't at least take a glance at the official
docs. There _are_ some great tutorials out there, but I'm not sure I saw
more than a few that are accessible to complete newbies.

> Well yes. Hope springs eternal :-) But reality depends upon people who hope
> that they will show an aptitude for developing a fantastic new computer
> language (when they've probably never done that before) realising their

	Well, if they've never coded POV-Ray, then they'll be learning a new
language regardless. And frankly, the current SDL sucks as a language.

	I guess your concern is more the people who _do_ know POV-Ray from before.

> Also, this misses the point a bit in that you can create up-to-date
> tutorials
> but they'll be competing for prominance in Google with a greater number of
> better established, but out of date tutorials that don't contain any
> indication
> that they may be out of date.

	Actually, I'd suspect the opposite. Not sure how Google page rank
works, but if there are only a few pages out there about POV-Ray 4, then
they'll each get more hits and are more likely to show up on top on Google.

	I know your concerns, but I think it's a fallacy _never_ to change the
SDL. Maintaining backward compatibility will always be a limiting factor
in development. It'll be a pain to add drastically new features (such as
a custom shading language), while trying to make those new features
compatible with the old SDL. And has been pointed out elsewhere,
backward compatibility has been broken in the past as well.

-- 
If you try to fail, and succeed, which have you done?


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

How about also get rid of #declare. Is it really needed.  Why not just have
direct assignment without the need of a directive:

// Declare an object but don't create it
ball = sphere
{
    ...
}

// Create an object
object
{
    ball // reference to previously declared object
    ....
}

Post a reply to this message

"Allen" <bri### [at] yahoocom> wrote:
> How about also get rid of #declare. Is it really needed.  Why not just have
> direct assignment without the need of a directive:
>
> // Declare an object but don't create it
> ball = sphere
> {
>     ...
> }

This would require some alternative way of indicating whether the variable is to
have global or inc/macro scope (#declare vs. #local); I guess we wouldn't want
to ditch the #declare but keep the #local.

Post a reply to this message

Another feature I'd suggest for the new SDL: "pattern" being fully
interchangeable with 3-parameter function.

Always having to wrap the one inside the other is cumbersome without need (in my
eyes).

Post a reply to this message

On 3/30/2009 7:41 PM, clipka wrote:
> Another feature I'd suggest for the new SDL: "pattern" being fully
> interchangeable with 3-parameter function.

Why not go one further, and remove one of them?

Everything could be represented as functions of the form
<vB1,...> pattern my_func(<vA1,..>)

That is, everything could be called a pattern, could take a vector with 
Na components as an argument, and return a vector with Nb components.

Anywhere you would expect either a pattern or a vector, the new style 
pattern could be used.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

On 3/27/2009 9:52 AM, clipka wrote:
> "Kenneth"<kdw### [at] earthlinknet>  wrote:
>> My main concern is actually with 'semantics' (if that's the right word.) I.e.,
>> the term #while seems to be quite logical and understandable in its meaning:
>
> Actually, I remember that when I started programming, I was multiple times
> fooled by the while-loop, about when the condition is checked. The most
> intuitive loop, for me, was:
>
> REPEAT
>    ...
> UNTIL (condition);

That's usually represented as
do {
stuff
} while (condition);


-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message