From: Chris Gehlker Date: 2002-07-31T06:31:06+09:00 Subject: Re: ActiveRubyScript and RubyAEOSA On 7/30/02 10:59 AM, "Hal E. Fulton" wrote: > ----- Original Message ----- > From: "Chris Gehlker" > To: "ruby-talk ML" > 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)