On 7/30/02 3:22 PM, "JamesBritt" <james / jamesbritt.com> wrote:

>>> 
>>> 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.
> 
> What is the distinction for people who have not (sufficiently) used both?
Hmm. Maybe it's a continuum by now. So let me make up an example comparing a
couple of implementations at the extremes, AppleScript and perl on FreeBSD.
Let say I have a bunch of digital photos in jpeg format and I want to touch
them up to make me look handsome. The perl way would be to look on CPAN for
a jpeg library use it to program the code that beautifies me. It would
probably just step though every file in a given directory. The program would
know a lot about jpegs and, with the addition of the library, would actually
embody a model of a jpeg.

Now look at the same project in AppleScript. I'd just write some glue to
tell iPhoto to pass every picture on the current roll to Canvas and to tell
Canvas to clean up my visage. AppleScript doesn't have any model of a jpeg
but that doesn't matter because iPhoto and Canvas do. It doesn't matter that
iPhoto's model is very different from Canvas's either.

Of course one could actually build a model of a jpeg in AppleScript because
its Turing Complete but it would be very hard.

> I don't know about emacs, but with Excel you can have an application create
> an instance of Excel, and manipulate it, or you have Excel load a script and
> execute it internally. Or both.

Yep.

> 
> 
>> 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.
> 
> Well, I'm inclined to say that Ruby (and maybe Perl) is concerned with
> object manipulation.  Sometimes the object need be defined in Ruby.  Other
> times the object can be an external thing with a suitable API.

I buy this on Windows and Mac. On general *nix there isn't a good method for
discovering the APIs of external objects, AFAICT.

>> 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.
> 
> I've written a fair amount of VBA code for Word, and would love to be able
> to use Ruby instead of a Visual Basic variant.

You actually can do this now in Mac Word.
-- 

Those who write clearly have readers, those who write obscurely have
commentators. -Albert Camus, writer and philosopher (1913-1960)