Re: Scripting in Gnome

[Sean Middleditch <elanthis awesomeplay com>]

On Mon, 2004-02-02 at 16:08, jamie wrote:
> > Which Python/Perl/TCL/Ruby/etc all excel at.  Again, we have the script
> > side of the solution solved.  It's pointless to waste time reinventing
> > that wheel.
> > 
> Yes but at a price because integrated scripting would therefore depend
> on every possible interpreter being installed on your system.

You have a library.  This library offers a generic script interface. 
All any app ever depends on is this library.

One could make it so the library needs recompilation for new languages. 
I.e., user A might only have Perl installed, so when she compiles the
library, it only has Perl support.  All of her apps that use this
library however get automatic Perl support with no need to understand
Perl.  A second user has no Perl, but does have Python, TCL, Mono, and
Lisp.  she compiles the library, and it has support for all four of
those.  All applications that use the library get free and automatic
support of those languages without ever needing to know about them
specifically.

An extension of this idea (and a much better solution, imo) is for the
library to support dynamically loading glue modules, so that you don't
even have to recompile/reinstall the library.  Install a new language,
install the glue module, and boom, all apps automatically get support of
this new language, even if the apps were developed/compiled before this
language was ever conceived.

One of these languages could also be some kind of VB knock off, if you
are offering to develop one for us.

> > But what do we actually need the XML for?  You've repeatedly stated how
> > we need XML to solve this problem without actually stating why.  XML is
> > just a syntax for heirarchial data.  What does that have to do with
> > connecting a script language VM/interpreter to an application?
> 
> XML is just a good way to define the syntax for a particular script
> language in a generic script engine. It could be done using an ini file
> but XML is more standard nowadays.

But what do we need a syntax definition for?  What's wrong with the
compilers and interpreters we already have?

Do you perhaps mean, instead of syntax, the API?  As in, the author of
an application describes the objects/methods in their application with
XML, and that is used by the script layer to generate bindings for the
script language(s)?  That's quite possible (I do it myself in AweMUD). 
Not sure how necessary it would be, tho.

> 
> 
> 
> > > No the XML will make use of Bonobo/Orbit not replace it. Again Im
> > > talking about mini scripts here - its nothing that competes with Perl or
> > > Python. All it is is a generic script engine which enables scripts to be
> > > used in any language whoose syntax is defined using an xml definition. 
> > 
> > Um, for what purpose?  what do you need this fictional languages for
> > that you acn't already do with real life languages that already have
> > perfectly working Bonobo/ORBit bindings?
> 
> Let me give you an example:
> 
> Suppose we have a script engine as a bonobo component which is used by
> Gnumeric to enable users to write macros. SUppose johnny writes his
> macros in Gnumeric using python and chris writes his macros in Ruby.
> What happens when chris sends his gnumeric spreadsheet file with
> embedded Ruby macros to johnny, who does not have a Ruby interpreter
> installed? 

Then Johny needs to install Ruby.  Chris obviously chose to write them
in Ruby for a reason, tho.  Perhaps those macros needed a library
functionality that only exists in Ruby.  Perhaps Chris is only
experienced with Ruby, and the many many hours it would take to learn a
new hacked up macro language just isn't worth the effort loss of
productivity on his part.

Chances are, most users would only be using the handful of mainstream
languages anyhow.  Anyone running GNOME probably has Python installed
(especially given how popular Python/pygtk are for writing full-scale
applications).  Etc.

Yes, it wouldn't be a bad idea to have some kind of lite-weight
"guaranteed to be there" language, perhaps JavaScript (using
Spidermonkey) or whatever, so that users wishing to make their macros
universally usable could do so.  That would be just one of the many
languages available, however.  If your script framework takes away my
choice to use a language I've already dedicated many hours to in order
to become highly proficient with, your framework won't be very well
received.

> 
> Of course he cant execute those macros if he does not have the Ruby
> interpreter installed. This problem is therefore magnified many times if
> you consider what happens with a generic script interface - you would
> need every possible interpreter installed on your system to guarantee
> you could execute any macro.   

Pity.  Life goes on.  He installs the interpreter he needs, he gets his
work done, the person writing the macros in their language of choice
gets their work done, all is happy.  Ya, it's a minor inconvenience, but
not nearly so bad as if everyone were to be forced to learn an use a new
language, one which might not even be capable of doing what they need.

> 
> Enter my proposed integrated generic script interface and that problem
> goes away. There would be no dependancy on any other libs or
> interpreters. Its the same case with Microsoft's activex scripting
> control. You get language independance and minial dependancy on other
> packages.

ActiveX doesn't solve this.  I can write ActiveX controls in many
languages.  If you download a file that needs a control you don't havem,
or a control without the proper dependencies it needs, you're just as
screwed. 

Additionally, many apps have need beyond simple macros.  Gnumeric
probably has simple needs if we're talking about macros to do
calculations.  Abiword however has a plugin system allowing large
massive functionalities to be added to the application.  These would be
impossible to write in a stripped down "macro language."

With your proposal, we'd need *two* script engine.  One to bind for
macros, one for plugins/extensions.  Developers need to learn two APIs. 
Exported interfaces need to be duplicated, perhaps even maintained
separately due to divergence between the two script systems'
interfaces.  Etc.  A universal generic layer will work in both cases,
and likely others than neither you, I, nor anyone else here has yet
foreseen.  (Which, as a side note, is one of the greatest joys to
experience; someone using something you wrote in ways you didn't even
imagine before.)

> 
> Remember I am not proposing to replace perl and python - I'm just
> proposing an integrated script engine. The languages to be used need not
> be more powerful than shell script.

Shell script is quite powerful.  I've written several large applications
entirely in POSIX shell... ;-)

Again, tho, using exclusively JavaScript or any other language doesn't
offer anything to the user.  Most users probably already have Python or
Perl, for example.  Most users have one or the other already in memory,
due to one of dozens of applications that link to them or are fully
written in them.  Adding another "small" language doesn't *decrease*
memory usage, as now it means the user needs both Python *and* the other
language in memory.  Joy.

> 
> 
> > 
> > > 
> > > VBA is needed anyhow for things like Gnumeric if they want to achieve
> > > compatibility with Excel
> > 
> > This much is true.  That is a separate problem, however.  That's the
> > need for yet another interpreter which would just use the same entrance
> > points that Python/Perl/etc. would use in a scripted application.
> Yes, but its no more effort than to write a generic script engine.

Perhaps.

-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.