In article <38CE3356.F0445117@nigels.com>, nig### [at] eisanetau wrote:

> > >       Yes, but once in POV script, you can't do anything else
> > >       with it.
> > 
> > I really don't know what you mean by that...
> 
> 	I mean that once data is stored in POV format,
> 	it is trapped there. 

I understand what you were trying to say now, but I still don't see why 
it is a problem. If the program already has the data, why does it need 
to read it back?
And besides, you can always use a plain comma delimited text file to 
store the data, and use macros or an include written in POV-Script to 
read it. I have used this approach for my particle simulator, outputting 
a bunch of calls to a macro to make particles, and it is quite flexible 
and powerful.(and makes smaller files)


> Worse than that, it may not 	even be compatible with the next version 
> of POV.

One of the biggest nice things about POV is that it is backward 
compatable to a high degree. Recently there have been changes, and there 
will probably be bigger changes in the future, but the basic object 
syntax hasn't changed much.


> > >       Programmers are quite familiar with the strengths and
> > >       weaknesses of using flat text.  
> > But is it actually limiting? I don't feel very limited...
> 
> 	Yes it is.  I spent all afternoon staring at C++ code
> 	wondering why there is no facility to have graphical
> 	documentation embedded in the source code.  I do
> 	graphics programming, and the geometric result of
> 	code is not always obvious from the C++ code.  Why
> 	can't I extend the C++ file format to stick anything
> 	in there that is relevant?  Why can't I rename the
> 	member "A::doXYZ()" without doing a search and replace?

Maybe you should have spent that afternoon figuring out the code 
instead. (just kidding!) :-)
Honestly, I haven't had much trouble with that. And graphical 
documentation embedded in the source code? The source would no longer be 
ASCII, would it?
I really don't think many people "program" in ASCII, but in structural 
concepts and operations which they translate into a language format. 
Some concepts and operations translate better to a visual format, at 
least for some people. I tend to visualize things as a bunch of 
interlinked structures, not code, but I don't think I would be able to 
make much sense from a non-code representation of that on the screen.


> 	Why can't I get an instant list of all everywhere that
> 	a certain variable is modified, or a function called?
> 	The compiler figures out all this information but 
> 	doesn't use it for useful things.  C++ programmers
> 	are trapped all day in this klunky ASCII view of
> 	their problem.  

Why would you need to? If it is for writing/modifying code, that belongs 
as an editor feature.(CodeWarrior can automatically find definitions of 
variables and types for me, and also supports fairly advanced 
search/replace features)


> 	I'm sure that some punch-card users didn't feel
> 	very limited either.  I used to think Commodore
> 	Basic was pretty cool.  Then machine language,
> 	then C, then C++.  You don't really see the 	
> 	limitations until you are freed from them.

But you can try to explain the limitations to the people who don't see 
or feel them...(hint)


> > >       Pascal and C are nearly equivalent languages. 
> > But they are separate languages. 
> 
> 	They are referred to as separate language, but
> 	they are actually so similar that it may be better
> 	to refer to them as "dialects of procedural programming".

You mean like Chinese and Australian Aborigine are different "dialects 
of human language"?
They are both a certain type of computer language, but they are 
certainly separate languages. By my definition, anyway.


> > The problem is that it is too generic, it can't be hand-edited easily.
> > Special tools are required.
> 
> 	Special tools are required for editing text too.
> 	You need a computer, monitor, keyboard and
> 	text editing program.  Are you taking all this
> 	technology for granted?  It must be working well!

Yes, it works quite well. :-)
My point was that text editors are practically universal, and everyone 
knows how to use them. XML editors are not as universal, and many people 
don't know anything about them.(like me)
If people are using POV, it is a very safe assumption that they have and 
know how to use a text editor(and a computer, monitor, keyboard, etc). 
The same does not apply for XML.


> > I don't understand this "flexibility" argument, at some point it has to
> > be converted into data structures in RAM. The only thing that would make
> > adding features easier would be the universal syntax, and that could be
> > done in other ways just as well.
> 
> 	Why would you do it in "other ways"?   You think
> 	you know better?  Do you think XML is some gimmick
> 	that Microsoft cooked up to make you upgrade all
> 	of your software?  Find out more about XML,
> 	at the very least it will improve your ability
> 	to argue against it. :-)

Huh? Did I mention Microsoft?
I don't think XML is a "gimmick", I just don't think it is the right 
thing for POV-Ray. If you can demonstrate how it would be the "right 
thing" for scene description with POV-Ray and how it would be noticeably 
more flexible and useable than the alternatives(redoing the language to 
be more clean and consistant, for example), and I will believe you. 
Right now, all you have shown me is some extremely ugly and difficult to 
read syntax, which you apparently want to use as a file format for 
specialized editors instead of a description language.

And you still haven't explained how this gets the data into RAM in an 
easier way than making modifications to a well-written parser would.

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

Post a reply to this message