Darren New wrote:

> Warp wrote:
>>   People have suggested not inventing the wheel once again but to use
>> an existing scripting language which is fast and efficient. This is not
>> a good solution because the scripting language of POV-Ray needs to be
>> specific to POV-Ray. It must be easy to create primitives, textures, etc
>> with the language. This task becomes harder if they must be created with
>> a generic scripting language not designed specifically for POV-Ray.
> 
Well, I am the strong opinion that Warp is right here. A new language for 
POVRay needs to be designed for POVRay, there is IMO no much use in 
trying to use some existing language because one would run into trouble 
quite quickly. 

> Not necessarily. The increased difficulty can be offset by not having to
> implement all the "normal" stuff like conditionals, procedures, etc.
> 
And, BTW, implementing a programming language using lexer and parser 
generators like flex and bison (lexical analysis and syntax analysis) 
is not that difficult as it may seem. It's surprisingly simple. 

Wolfgang

Post a reply to this message

in news:4173fcc5$1@news.povray.org Darren New wrote:

> Essentially, a good embedded language should be embedded first, then 
> stand-alone second.

Just for me to get an idea, could that be something like the "Parrot 
virtual machine" with an SDL parser on top of it?


Ingo

Post a reply to this message

>   What would be the point of having tons of people throwing random thoughts
> and usually just creating endless flamewars about tiny details of the new
> design?

...how about "virtually nothing"?

>   There's a saying at least in Finnish (which I don't know if exists in
> English) about several cooks cooking the same soup.

"Too many cooks spoil the broth."

Indeed, I'm told that in commercial software development, when a project 
gets really behind, sometimes they fix it by taking programmers OFF the 
team... (The idea - I guess - is fewer people to argue = more time coding.)

But anyway...

Andrew @ home.

Post a reply to this message

>   Exactly as the current POV-Ray source code is a bunch of hacks over hacks
> and patches over patches, making it an unmaintainable chaotic mess, the
> SDL is pretty similar. The original SDL was never meant to be a programming
> language, just a data container format. However, over the years many
> programmatical features were added (read: kludged) over the old SDL.
> The result is a bloated, mostly ugly, limited and specially inefficient
> language.

Indeed - I recently started a project to make my own SDL, with my own 
interpreter, which would run the executable parts of the code, and 
finally spit out "normal" POV-Ray SDL at the end.

Naturally, since I magorly suck at building parsers, this little project 
did not progress far...

(I would like to say that - IMHO - as hacks go, POV-Ray [and it's SDL] 
turned out not too bad at all, really! :-) Respect...)

Andrew @ home.

Post a reply to this message

Christoph Hormann wrote:
> Andrew Clinton wrote:
>> So, when discussions begin for POV-Ray 4.0, will the Team provide an open
>> forum for user suggestions?  My vote is for "povray.wishlist".  As a
>> programmer, I'm also wondering how you really keep "requirements" and
>> "design" seperate.  A discussion of requirements necessitates some degree
>> of discussion of feasibility,
> 
> No.  As an engineer i can tell you that when planning a new design you
> start with the requirements alone.  Limiting the requirements from the
> beginning to only require what is feasible will result in no innovation
> at all (and i am quite sure this applies for program design as well).
> So what you write here to me indicates that you have no idea what
> formulating the requirements actually means.
> 
I completely agree with you that this approach ultimatively yields to 
the best solution. First one should just think _what_ one would like to 
be able to do with it - and not _how_. 

The only problem is that this way it tends to take ages until the product 
is in production state. And then the problem is also to not loose interest 
in it in between. 

Wolfgang

Post a reply to this message

On Mon, 18 Oct 2004 16:40:08 +0200, Christoph Hormann wrote:

> Andrew Clinton wrote:
>> So, when discussions begin for POV-Ray 4.0, will the Team provide an
>> open forum for user suggestions?  My vote is for "povray.wishlist".  As
>> a programmer, I'm also wondering how you really keep "requirements" and
>> "design" seperate.  A discussion of requirements necessitates some
>> degree of discussion of feasibility,
> 
> No.  As an engineer i can tell you that when planning a new design you
> start with the requirements alone.  Limiting the requirements from the
> beginning to only require what is feasible will result in no innovation
> at all (and i am quite sure this applies for program design as well). So
> what you write here to me indicates that you have no idea what
> formulating the requirements actually means.
> 
> 
I never said to limit the requirements to what is feasible.  What I
believe is that there is a progression of discussions that might happen as
interesting suggestions are brought to the table (requirements), where
they are first discovered and discussed from the user's standpoint, then
considered in a more technical context by the programmers (feasibility and
design).  I don't see any reason that should necessitate a full
requirements gathering and accounting (up front) and then a design phase.
As an engineer, you should recognize this as a waterfall model.  From my
experience (which so far isn't too much, only ~2 years programming in
field, but this is what I've been accustomed to), a much better method is
to design things in a more flexible way, in which the process can loop
back to revisit and integrate changing requirements, and improving
knowledge of the target that you are aiming to achieve.

I've been able to do design up front (waterfall) for only extremely small
projects.  The types of projects that I am thinking of, are those where
you can fit the entire design into your head, because either you have a
vast background in the technical area that you are designing for, or you
have "done it all before". If the POV-Team has this level of knowledge of
what they intend for the next version of POV-Ray, the foresight to plan
for future needs, and the technical knowledge to put it all together
(within reasonable timeframe), this is probably the best method to use and
I would agree with you.

> So again my suggestion: if you want to start some discussion helpful for
>   future POV-Ray design start with talking about requirements.  The most
> useful discussions usually arise from users talking about something they
> would like to do but that seems difficult/impossible with current
> POV-Ray.  The majority of such postings can of course be answered with
> an already existing and well working solution but from time to time you
> see things that really hit a weak point.  If you then really try to
> formulate what you actually want to do - as concrete as necessary but as
> general as possible - you are already half way finished.
> 
> A povray.wishlist newsgroup will only result in a lot of feature
> suggestions and i have already explained why there is not much use in
> proposing features at the beginning.  Everyone who likes to make an 'i
> would like feature xxx in POV' should ask himself what he wants feature
> xxx for and voila - you are again talking about requirements.  A
> separate newsgroup for discussing requirements would only make sense IMO
> if the discipline to keep the discussions on-topic is maintained there.
> 
> 
While I agree that there may be some superfluous discussion in such a
group, I don't agree that this is necessarily harmful.  The other
newsgroups here seem to have been well moderated to encourage users to
post on-topic responses, so why not for a requirements group?  As for
stating general requirements, there will be some users who can bring their
statements to the quality level that you are looking for.  The others,
although less refined, can still be interpreted and understood with a
small amount of effort from the moderators, like is done in any reasonable
company with good customer support.  You just need to have the ability to
abstract a multitude of requests into a few core features that could
support the vast majority of items people are requesting (which I believe
is one of the first things should be done in coming up with a good design).

Post a reply to this message

On Mon, 18 Oct 2004 16:39:53 +0200, Thorsten Froehlich wrote:

>>>>
> Every discussion about design ideas is just ignored,
> regardless of what is being discussed.  As such, there is simply no judgment
> at all made on any idea discussed in public.
> <<<
> 
> How to misinterpret that statement to "ignoring [..] ideas that are not to
> the 'Team's liking." is beyond me, and probably anybody else reading this as
> well.
> 

I am sorry that I may have expressed myself poorly in the previous post. 
My intention was to point out that I do not think it is productive to
ignore these discussions, for whatever reason, if they may raise issues
that might help the POV-Team in formulating a design for a future version
of the software.

Post a reply to this message

Wolfgang Wieser <wwi### [at] nospamgmxde> wrote:
> But for me "outside here" is just feels like everyone (including the team)
> is merely dreaming of version 4 and actually not putting much effort into
> design or development. I'm not sure if that is really the case or if I have
> to blame the closed development model for that.

I'd bet my money on the latter, even as yesterday's input from the Team
clearly shows that the developement model is not either as closed as 'we'
may think, or 'they' would have us think :-)

--
jussi.kantola

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I'd think something OO would be good, since POV deals with 
> objects in a very real sense

  The problem with that is that you will get an extremely strong opposition
from conservatives who think object-oriented programming is only very
slightly easier than rocket science or neurosurgery.

  While the scripting language should preferably contain strong OO
capabilities, it should be implemented so that you don't need to
necessarily even see nor know about it in order to write a simple scene.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Andrew Clinton" <ajc### [at] uwaterlooca> wrote in message
news:pan### [at] uwaterlooca...
[deletions]
: My intention was to point out that I do not think it is productive to
: ignore these discussions, for whatever reason,  [deletions]

It seems to me that no one is ignoring any discussion. But that
the developers are not going to be drawn into open debate. We
(the users) propose changes. If those changes are useful, others
will see it too. The developers can read...
=Bob=

Post a reply to this message