From: "Hal E. Fulton" Date: 2002-07-31T07:47:04+09:00 Subject: Re: ActiveRubyScript and RubyAEOSA ----- Original Message ----- From: "Chris Gehlker" To: "ruby-talk ML" 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