On 7/30/02 10:59 AM, "Hal E. Fulton" <hal9000 / hypermetrics.com> wrote:

> ----- Original Message -----
> From: "Chris Gehlker" <gehlker / fastq.com>
> To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> Sent: Tuesday, July 30, 2002 12:46 PM
> Subject: ActiveRubyScript and RubyAEOSA
> 
> 
>> I just discovered ActiveRubyScript (sometimes written as two words) by
>> following up on a  reference here. I haven't had a chance to play with it
>> yet but I'm installing a Windows emulator in the background so I can play
>> with it.
> 
> Isn't it actually called ActiveScriptRuby? I'm
> going from memory here...

ActiveScriptRuby is more common. I was just copying the translation from the
last page I googled up.

>> How important is it? How much is it like Ruby.
> 
> I'd say it *is* Ruby -- an embeddable version of the
> interpreter (embeddable in the sense of Windows Script
> Host, etc.). For example, using ASR, your Internet
> Explorer can run Ruby scripts just as (out of the box)
> it runs Javascript code.
> 
> Having said that it "is" Ruby, there may be differences
> I'm not aware of.
> 
> How important? Only if 1) you're using Windows and 2) you
> want to use an embedded Ruby interpreter. And then there
> might be other ways.
> 
>> It doesn't appear to be much like RubyAEOSA. Is this important?
> 
> I don't know about that. Can you elaborate?
> 

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.

>> I'm sort of a *nix newbie but thumbing through "Unix in a Nutshell" there
>> don't appear to be *any* 'scripting languages' in the Visual
>> Basic/JavaScript/AppleScript sense or for that matter any scriptable
>> applications.[1] I don't doubt that this is related to the linear nature
> of
>> many Unix apps that has been mentioned here before. But that raises the
>> question of will there ever be scriptable Unix apps, and if the answer is
>> yes, shouldn't there be a single Ruby syntax for addressing them.
> 
> Interesting viewpoint. Personally I would say that
> the Unix world *invented* the scriptable app and
> perhaps the concept of a scripting language (as
> opposed to the old job control languages). Flames
> to /dev/null, please. :)
> 
> 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.

> Well, I have often wished for a COM equivalent in
> the Unix world. It would only be useful if there
> were one universal standard, I think. My knowledge
> of this particular area is limited, though, so I
> can't address it much.

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.

> 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.

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.
-- 
We are all born originals - why is it so many of us die copies? -Edward
Young, poet (1683-1765)