----- Original Message -----
From: "Chris Gehlker" <gehlker / fastq.com>
To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
Sent: Tuesday, July 30, 2002 4:31 PM
Subject: Re: ActiveRubyScript and RubyAEOSA


> I was trying to get a sense of whether the community was happy with the
way
> that the Mac and Windows versions of Ruby as a 'scripting language' was
> evolving separately. Personally I'm not because it seems to me that a
> program that, for example, tells MS Word to grab some data from a named
> range in Excel and insert it in a document should not have to know what OS
> the apps are running on. But I don't want to speak too strongly about
other
> peoples projects.

Offhand I'd say that it's different because each app
takes advantage of its OS features. As I see it, COM
is a Windoze thing, not an Apple thing; so even though
you have Windows apps on a Mac, they will expose
different kinds of interfaces because the OSes are
different (and Micro$oft simply hasn't created COM for
the Mac, which might well be difficult to impossible
even if they wanted to). Is this assessment accurate?

> > But I think I see what you are saying. You want
> > apps to expose an interface the way Windows apps
> > expose a COM interface, or something, right? Or
> > am I misunderstanding?
>
> Exactly! I wasn't trying to start a flame war but 'scripting language'
means
> very different things in different contexts. I think of Ruby as a
'scripting
> language' and Visual Basic for Applications as a 'macro' language. I think
> of Excel as a 'scriptable app' and emacs as a 'programmable app'. I think
> the distinction is clear enough to anyone who has used both. Languages
like
> Ruby and Perl are concerned more with data manipulation. The other group
> strive to be more of a JCL. There competitors are bash, tcsh, etc more
than
> Ruby.
>
> Having said that, the JavaScript folks were on to something. There is no
> reason for the user to have to learn more than one syntax.

I'm not sure I follow *all* your reasoning, but we'll
let it go. I know little about COM and VBA, and nothing
about the Mac.

> The Mac OS X one is just XML. They have a DTD for an application to use to
> describe the objects it knows about, the gettable instances, the
> gettable/settable instances and the methods and their parameters and
return
> messages. The DTD associates more or less arbitrary 32 bit codes with all
of
> these human readable strings. It's up to the language implementer to parse
> the XML and present the user with a human readable 'dictionary' and to
turn
> the dictionary words back into the codes. Alternatively, if you build the
> language as a plug-in to ScriptEditor.app, you get the parsing and
> translation 'for free'. The actual messaging infrastructure is just BSD
IAC.
>
> There are advantages to this approach. It's easy to understand, very easy
> to localize, and it's not too hard to make tools that automate some of the
> XML generation. It's portable to any OS that has some method of piping
> messages between applications.
>
> Of course it means the apps have to have an additional UI in addition to
the
> command line or GUI or whatever.

"Another UI" is no biggie. The benefits outweigh the hardship
of coding, I think.

I find it hard to understand the XML concept, given that it's
hard to represent control structures and such in XML. Do they
use tags to mark the parts of a loop and the branches of an
if-then and that kind of thing?

But if it works, and it's semi-elegant, I'm impressed.

> > But please, let's generate some discussion on this.
> >
>
> What fuels my enthusiasm is seeing (non-Geek) graphic artists at my wife's
> office doing useful work with AppleScript, the COBOL of scripting
languages.

Really? AppleScript is that bad? I'm not a Macoid.

> The language itself has some disfeatures but they find it easy to work
with
> because it presents an object hierarchy that's already familiar to them.
> WorkBooks contain sheets contain ranges contain cells... They don't have
to
> create the objects, they already understand them from messing around with
> spreadsheets. So if they get assigned to get some numbers from a corporate
> database and manipulate them in Excel and present the results in a Word
> document, they will do it by hand three of for times and then just script
> the whole process.
>
> Think about how much easier that would be with Ruby.

Yes, definitely! My dream for many months now has been to
control a bunch of Linux (or Unix) apps with Ruby.

Of course, I was thinking of DRb (Distributed Ruby) for
that purpose. It would be easier if the app itself were
written in Ruby -- but I daresay the average C/C++ app
*could* be given an embedded Ruby interpreter that could
run a DRb server.

Either way, that would require an investment in the
application writer's time. But learning Ruby is time
well spent.


Hal