Return to XSI 2005-05-27 - By mark wilson
Back
I agree with the C/C++ points. Come on Kim, yield to the power! :-P
m
-- --Original Message-- --
From: owner-xsi@(protected) [mailto:owner-xsi@(protected)] On Behalf
Of Guy Rabiller
Sent: 27 May 2005 17:10
To: XSI@(protected)
Subject: Re: Return to XSI
[Raffaele]
> > - Programming. Avoid VBscript. JScript is perfect as it is
> > close to C syntax.
[Kim]
> Vbscript simply isn 't structured enough to allow you to deal with
large
> code libraries in any kind of sensible fashion
According to the KISS rule, those statements are paradoxal.
For any script beginner I would say dont avoid VBScript, because of the
very
reason that VBScript is simple and stupid.
1) Beginners will learn it fast, wont fall into some of the JScript
and/or
Python traps, will type code faster than in JSript or any other language
available in XSI.
VBScript is far sufficient for people who write scripts to help them in
automating laborious tasks or creating basic tools.
2) For 'advanced' scripters/td/dev I'm still amazed by the argument
"because
JScript is close to C syntax".
If you like to type semi-colon every line just for the sake of using
some
"serious looking" scripting language, its your choice.
Admit however that this is totaly useless in the context of a scripting
language. What a waste of time.
3) There is a trap. The "prototyping" argument, believing in the fact
that
once you have prototyped you tool in JScript you will easily "port" it
to
C/C++.
This is wrong. Sure, you can copy/paste a lot of code lines, but at the
expense of a poor design.
You wont design a tool in C/C++ as you will in any scripting language,
including JScript.
Dont believe this fairytale.
4) Creating libraries of OO reusable tools is a good thing.
But dealing with large code libraries in Script ?!
At the end people are wondering why it takes so long to accomplish some
tasks.
When it comes to large, robust, efficient code libraries, better do it
in
C/C++.
If you need to move a scripted plugin you'll have to make your large
code
libraries available.
In C/C++ you can just link to it, you'll have self contained files.
Having proper C/C++ libraries, then creating compiled plugin using the
CPP
API is nearly as simple and fast than doing it in script, and at the
end, it
will be far more efficient.
Just my 2 euros.
--
guy rabiller | 3d technical director @ LaMaison
-- -- Original Message -- --
From: "kim aldis" <kim@(protected)>
To: <XSI@(protected)>
Sent: Friday, May 27, 2005 2:43 PM
Subject: RE: Return to XSI
> I've a few comments, below:
>
> > -- --Original Message-- --
> > From: owner-xsi@(protected)
> > [mailto:owner-xsi@(protected)] On Behalf Of Raffaele
Scaduto-Medola
> > Sent: 27 May 2005 10:20
> > To: XSI@(protected)
> > Subject: Re: Return to XSI
> >
> >
> > - Programming. Avoid VBscript. JScript is perfect as it is
> > close to C syntax.
> >
>
> Jscript is good and I very much agree with you on the vbscript thing.
> Vbscript simply isn 't structured enough to allow you to deal with
large
> code libraries in any kind of sensible fashion. But if you're building
> pipelines you need for xsi to talk to the outside world and Jscript,
being
> made with security in mind, isn't good at that. Perl and Python are -
see
> note on sql below. I'd advise Python, Perl is a tad rambling where
Python
is
> very tight but still has a good module set. Mysql, XML, sockets and
good
> file handling are some of the things that Python will do for you where
> jscript won't.
>
>
>
> > The other benefit, which I would encourage
> > is using Mel like syntax ($ signs in front of variables,
> > commands like syntax passing unique single variables at the
> > top of your scripts).
>
> This puzzles me; I'm not sure why you advise this but I would
personally
shy
> away from trying to make any tool behave like another one. I also
think
> that's one of the biggest mistakes you can make with Xsi. I've spent a
good
> deal of time scripting Unix shells and Perl and I'm quite thankful not
to
> have to prefix variables in this way. And there are more important
things
to
> be careful of when developing variable naming conventions. If it's for
the
> purpose of highlighting variables then a good text editor or IDE will
do
> that for you much more constructively. I'm genuinely curious, though.
>
> What does 'commands like syntax passing unique single variables at the
top
> of your scripts mean?
>
> > XSI can uses many of MicroSoft engines,
> > and JScript can be programmed with objects very efficiently.
> > But the practical issue of finding high level Object oriented
> > programmers is difficult, Keep it Simple. At Omation, I was
> > able to hire people with Mel experience and let them workout
> > and learn XSI guts through the SDK (first using commands,
> > then more and more using the object model).
> > interested in scripting.
>
> Obviously this would be because there's a shortage of good xsi people,
not
> because hiring Mel people is preferable ;-) You *will* need to
consider OO
> if you're building pipelines. Getting the best people you can, though,
is
> critical, I can't emphasise this enough.
>
>
> >
> > -mySQL rules. Unfortunately I'm not sure how you can do this
> > on Linux, but in Windows world you can create a "sql" object
> > which is acessible within XSI. IE you can setup the
> > automation tools to check-in/check-
>
> Python will do this on both Linux and Windows (as will Perl if that's
your
> bag).
>
> > out assets,renders
> > automatically between XSI and mySQL (or I believe any SQL
> > flavor). This makes larger project manageable, and automated.
> > If your in management side, you need to understand that
> > tracking assets trhough production is important (something
> > SQL engines can do really well).
>
>
>
>
> >
> > -build an command autoloader. XSI as pre-built tools to
> > auto-install addons, plugins, etc... I would recommend you
> > figure out some scheme to auto register scripts directly,
> > without having to package them, that way you can make the
> > connection between your scripts and the users at your
> > facility "live". I've build a couple over the years in both
> > Maya and XSI.
> > The main benefit, is that everyone can automatically get the
> > latest greatest version of scripts available. And tied to a
> > consistent syntax format that everyone adheres to, it will
> > make your script development, sharing knowledge and encourage
> > people working in teams to solve complex problem. With system
> > I devellop, I could actually spread out the work of rigging a
> > single character to several people at the same time
> > (chaining, deformation, facial targets...).
>
> This is what plugins and workgroups are for. There are performance
issues
> here ( Graham ;-) ) but there are ways of being selective about what
loads
> for what class of user.
>
> >
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in
body:
> unsubscribe xsi
>
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
