|
 |
Ger <No.### [at] Thank You> wrote:
> I guess you would call me one of "those people".
> Don't get me wrong, I'm not against a new language perse but I am against "a
> new language for the sake of a new language". If at the end of the
> discussion it turns out that the current SDL cannot be cleaned up/extended
> to do what we all want it to do, then off course we need a new language.
> But implementing a new language has major cons.
> 1) All current and older projects are useless because of loss of backwards
> compatibility.
> 2) We'll upset/drive away a good portion of the current userbase because of
> the new syntax.
>
> --
> Ger
That's not so obvious to me. AFAIK, compatibility problems already happened
in POV's life when the syntax evolved and new features were added. The
#version clause was added for that. If the new syntax inherits enough from
the current one, we can imagine either that the new is a subset of the old
and the new parser will understand old syntax, or converters can be
developped (which is not far from the first case). I can't imagine that the
new syntax makes less features than the old, so I dont't see why there would
be an impossibility.
However, the arrival of a new syntax is a major change, thus we can't hope
making a significant step without some eventual concessions.
Even if lots of nice stuff was produced with pov 3.6 & megapov 1.2.1 syntax,
it appears that many people feel limited and want something new. That's the
reason of this discussion and justifies we think seriously about it and try
to determine the WHAT, the WHY, and the HOW.
Bruno
Post a reply to this message
|
|
|
|
In article <470313c2@news.povray.org>,
nic### [at] gmailisthebestcom says...
> > In article <47024d79$1@news.povray.org>,
> > nic### [at] gmailisthebestcom says...
> >> Umm... Isn't that how things work on *any* loosely-typed language?
> >>
> >> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3
)];
> >>
> >> A valid Javascript array containing a number, another array, a string,
a
> >> regular expression, and a Sphere (provided that the Sphere object was
> >> defined).
> >>
> > Well, all I know is that it wasn't, for what ever reason, possible with
> > the client. That *may* be due to the fact that Java is *not* normally
> > that loosely typed, or that some serious problem existed in ActiveScrip
t
> > which seriously fracked it (since it relies a lot of that for every
> > language except Lua. Though, mind you, half the ActiveScript languages
> > seem to not follow spec anyway and suffer from bloody silly
> > inconsistencies even in how you instance them, never mind get them to d
o
> > anything after they are linked.)
> >
>
> You're mixing up Java and Javascript (they have nothing to do, name
> similarity is apparently because of marketing reasons). Java is
> strongly-typed, Javascript is loosely-typed. Java is compiled into
> bytecode, Javascript is interpreted. Java has classes, Javascript has
> prototype-based OOP instead.
>
I realize there are differences between them, didn't know that was one
of them though. I still don't like the syntax that well. My point was
though that you get the same issues trying to use something like Python.
It didn't link the same way, even though it should have, and worse,
there actually seems to be some sort of insane memory leak in it,
triggered when you drop in some temp code to run, then try to remove it
again. We are not sure if its garbage collection not handling the
deleted code correctly or what, but its frustrating.
Oh, and using Java may not be useful precisely *because* it relies on
compiled Bytecode. Why? Because I am not sure how well it can handle
shifting code in/out on the fly, and while I am not sure how/if that
would be useful in POVRay, since it kind of assumes you are going to
render one frame, then exit, it is a nice things to have some times.
Like say you have a flag to turn off a certain feature, while testing
colors, because it slows things down. So, you figure, "Ok, color is
good, so lets just type in "myflag = 1", so the next frame will render
"with" the feature turned on, so I can see it that is working too,
without having to restart the entire render." Sure, its not the sort of
thing you "expect" to be doing in a program like this, but it can be
useful some times to have immediate execution of a comment "into" the
code that is already running, in some cases. You can't do that with
compiled code.
Now, whether there is a legitimate reason to allow such a thing in
POVRay is another question entirely, as well as how that would effect
speed. But it is something that might be considered. Its also used in
the client I use to do things like reacting to some event, then
inserting code to do some specific task "at that event". Probably not
useful or necessary for POVRay, since coding that in directly, then re-
running the script, is probable just as easy, but again, its something
that could be done real time, even as processing is being done, in the
client I use, while a compiled language simply wouldn't support it.
Useful for something like POVRay or completely useless? Not sure myself.
I am sure I could think of uses for it "if" I had the option, but
thinking of them now is a bit harder.
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
