Sorry, I'm a coder. I can't do anything about it... ;)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ken wrote:
> 
> Gilles Tran wrote:
> 
> 
> 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 ? 

How many times have you seen someone ask 
"I have nested #while loops and the inner one doesn't work" ?
This is a problem that would go away with for() loops.

I fully agree that programming features are just a part of POV-Ray, but
who doesn't appreciate the efforts of people like Chris Colefax.  How
much more productive would such #include writers be with better tools?

I also don't think anyone is advocating that the POV-team drop
development of the render engine in favour of the programming interface,
we all want faster, more realistic  renders with more features ;^)

Cheers, PoD.

Post a reply to this message

Spend a minute thinking about the requirements for a POV-Ray L-system
(but make sure you're sitting down first)

PoD.

Post a reply to this message

PoD wrote:
> 
> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)
> 
> PoD.

Oops,
That should have been requirements for the syntax of POV-Ray L-system.

PoD.

Post a reply to this message

In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)

What about them?
I think it would be hard to understand unless you have experience with 
L-System scripts, but the POV syntax would be pretty simple. And a 
couple predefined objects and some macros for controlling l_system 
objects should probably be included...

Writing the actual l_system object would be much more difficult than 
deciding on a syntax.

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

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> 
> > Spend a minute thinking about the requirements for a POV-Ray L-system
> > (but make sure you're sitting down first)
> 
> What about them?
> I think it would be hard to understand unless you have experience with
> L-System scripts, but the POV syntax would be pretty simple. And a
> couple predefined objects and some macros for controlling l_system
> objects should probably be included...
> 
> Writing the actual l_system object would be much more difficult than
> deciding on a syntax.
> 

Show me a simple syntax that lets you create a tree with different
textures for trunk, branches, twigs, leaves, fruit, flowers.
And has declarations of objects to use for the above.

I think that if the syntax was invented, then implementing it would be
simple.

PoD.

Post a reply to this message

Tor Olav Kristensen wrote:

> People can press whatever keys they like.
>
> So if you preferred not to hit that function key, then the computer
> wouldn't modify your work...

Okay, but what about 1, 2 and 3a? :-p

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message

Johannes Hubert wrote:

> >
> > Of those, only case 3 looks like possibly decent use.  Case 1 and 2
> look very
> > problematic.
>
> Java handles case 1 with a labeled break, doesn't it?
>
> Johannes.

Yes. Which is a bit different. Personally I try to avoid that also.
Among other things you might get a problem of buried meaning. Usually I
code first for correctness and clarity. Then if I get a performance
bottleneck, I go in, but only after measuring actual performance.

But also I usually don't do intense mathematical algorithms, so that may
be another factor.

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

Chris Huff wrote:

> In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
> wrote:

> >       So what is the difference other than a different syntax? The 123
> > ways to create a loop? They all do the same thing in the end.
> > Even step = 3 with I=I+3.

> >       Introducing additional syntaxes raises more problems than it
> > solves. With one elementary syntax that can do everything there
> > isn't nearly as much to read and a hundred fewer places for
> > parser differences to creep in.

> The only difference is syntax. But that is a meaningful difference.
> Although a for loop could also be implemented as a while loop, it can
> sometimes be easier to write and understand if written as a for loop. 

	Actually I would say it is usually more famliar which makes it
appear easier to understand. 
 
> And what do you mean by "a hundred fewer places for parser differences
> to creep in"? I don't think the modifications would be very extensive,
> and there is only one parser.

	I mean implementation differences. On an i++ while you can get a
debate started among purists as to while i < 5 should bail out or
4 or 5 in that should the < be checked before or after evaluating
and changing the variables in the loop. 

	You can get another debate on permitting i to be both integer
and float. 

	This stuff may be OBE since the late 70s when was being paid to
look into it perhaps due to the dominance of C or the later
developments of Wirth after Pascal. 

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

	Without GOTO all branches are conditional to another routine.
Permitting GOTOs to exist after falling out of a routine simply
because it is sequencial is what we called spaghetti code. If you
have GOTO you have unconditional GOTOs. 

	They are nasty little buggers when they show up in late night
sessions. Never want to meet on in the dark. 

-- 
A free internet for free minds.

Post a reply to this message

Mark Wagner wrote:

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

	Does he use it in TWO algorithms? or just one? 

	And what is his overall opinion of it? 

	BTW: I think I went through that once and don't remember it.

	I do remember going through someone's Atari BASIC code once
trying to make sense of it. It was good. I even approached the
author with money for markeing if he could clean it up. 

	He said he could not clean up his own code as the GOTOs were
workarounds of things "too hard" to correct rigorously. And the
problem with that the possibility of added functionality was as
dependent upon his memory as his ability. 

	If his mind were off of it for a month, it was frozen code.

-- 
A free internet for free minds.

Post a reply to this message