In article <n8ag309hemfhpmj8jnt5j5s3k8gr66rm62@4ax.com>,
 Andreas Kaiser <aka### [at] nurfuerspamde> wrote:

> This might be a 'learning' problem if you aren't aware of the
> operators 'hidden' complexity. 

Only if the code is poorly designed. You shouldn't have to care about 
the hidden complexity. It doesn't matter one bit how the = operator 
copies a string, only that it does so.


> >So do functions.
> 
> Yes, same problem here. There's no correlation between length of
> function name and complexity. 

It's not a problem. It's a feature. Code written without functions is 
called spaghetti code, it ain't pretty and it is very inefficient and 
unmaintainable. Or should functions that do more have longer names? How 
long should POV-Ray's main() function be?


> If you call a Trace() function you should know why.
> May be to write a trace record to a log file, may be to start a render
> that will be finished some months later.

And when it's in a raytracer, and when you're giving it ray information 
and receiving a color from it, which do you think it is? This is an 
English language issue, not a programming language one.


> The macros required to do trivial colour/vector arithmetic are
> 'information hiding' in the worst sense. They blow up source code and
> add visual noise which makes it sometimes almost impossible to see
> what's going on.

Agreed. They hide what the code is really doing by bloating up each 
little operation.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message