[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Interfacing to AppleEvents (fwd)



According to Tom Pollard:
> 
> On Mon, 16 Jun 1997, Paul J. Schinder wrote:
> > In fact, I'd love for someone to define "scripting language".  The
> > definition would have to be pretty convoluted to exclude MacPerl, IMHO.
> 
> Not at all.  To me, a scripting language is a language in which you can
> naturally specify a sequence of actions, that you would ordinarily execute
> 'by hand', in a 'script'.  All Unix shells, more or less, constitute
> scripting languages in this sense.  Tcl, when it's embedded in an
> application, is a scripting language in this sense.  Because the Mac has
> no standard command-line interface (it's graphically oriented), these
> models have to be modified for the Mac.  There, AppleScript and Frontier
> are real scripting languages for the Macintosh because they let you
> control AppleScriptable applications in a way that's very closely tied to
> their standard gui interfaces.  
> 
> Under this definition, MacPerl is no more a scripting language than C is. 

This is (to me) really weird.

AppleScript is nothing more than a programming language which calls AppleEvents.
MacPerl is nothing more than a programming language which calls AppleEvents.
C is nothing more than a programming language which calls AppleEvents.
Frontier is nothing more than a programming language which calls AppleEvents.
MacFortran(FORTRAN77) is nothing more than a programming language which calls AppleEvents.
MacCobol is nothing more than a programming language which calls AppleEvents.

I really don't see the difference.  AppleEvents are
something separate from any of the programming languages
you can name.  Now, AppleScript was created specifically to
handle AppleEvents and to make the handling of them easier
- but it's still just a programming language.

The problem we are running into is that ANY language you
can name is a "programmable" language.  A script, by
definition, is more of a general guideline to go by.  Not
the actual code.  Once you've written the actual code - a
script becomes a program.  Even AI languages, when you type
commands in for - say - a robot to pick up something.  If
you can put the commands into a file and store them
somewhere - then those commands become a program.

So you can try to delineate what is a script and what is a
program.  But (presently) in computer terminology - they
are they same thing.  Thus, Apple-SCRIPT is just a buzz
word.  A media spin that was used to make people go "WOW!
A _DIFFERENT_ kind of programming language!"  And -
obviously - it's worked!  :-)  Now we have "It's a script!"
wars in addition to the "My computer's better than yours"
wars, "My language is better than your language" wars, and
all of the other dopey "horse with blinders on" wars on the
net.  Heh.  Always interesting to watch - but a bit
draining on the energy.

I'll shut-up now with this last thing:

When a play is going to be put on they use a SCRIPT to go
by.  But when the play is put on - you are given a paper
with what is on the PROGRAM for that night.  The same is
true in the computer world.  :-)  The closest thing we have
to a scripting language is pseudo code or flowcharts.  All
the rest - are programming languages.  Plain and simple.

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch