Re: Migrating scripting additions to Mac OS X
Re: Migrating scripting additions to Mac OS X
- Subject: Re: Migrating scripting additions to Mac OS X
- From: Ric Phillips <email@hidden>
- Date: Wed, 27 Jun 2001 11:01:31 +1000
On 27/6/01 3:11 AM, "Anthony Adachi" <email@hidden> wrote:
>
On Tue, Jun 26, 2001 8:41 AM, Shane Stanley <email@hidden>
>
wrote:
>
> And my point is that making some scripting additions into apps is a
>
> ridiculous way of making AppleScript more tortuous to learn and use than
>
it
>
> is already.
>
>
I would have to disagree on that point. I think scripting additions make
>
AppleScript harder to learn. They are extensions to the AppleScript
>
language and as such make the base syntax more complicated.
>
>
When I was learning AppleScript I found it's large syntax daunting. Trying
>
to figure out what syntax was the most important to learn from what's not
>
was very difficult for me as I had no programming background. I basically
>
had to comprehend a huge amount of syntax before I was able to even begin
>
to understand how to write my own scripts from scratch (as opposed to
>
copying examples from others and modifying them slightly).
>
.....
>
I've also made attempts at trying to learn Python and Java but their syntax
>
complexities bogged me down.
>
Fascinating point (and thread). My 2c...
Additions vs apps is a bit of a non-starter as a factor in complexity.
(Stability is a different issue...) Solutions that take over the wheel (so
to speak) and have to manage the multiple app / process / in a complex
environment are always going to be prone to high levels of practical
complexity.
Mark Twain went broke because he couldn't recognize that some processes are
just too complicated to be automated profitably with the resources
available.
Having said that.....
A certain amount of 'complexity' arises in AS through the now ubiquitous
conflation of procedural and object-oriented elements of programming
language implementation.
As a procedural language AS is remarkably concise with a flexible but
basically simple syntax.
As an object-oriented language, - one that interacts procedurally with
classes and object provided by the OS and by target applications, AND one
that allows the construction of new classes and object, AS is seriously
complicated by having to deal with collections (apps, system
implementations, and OSAXEN) of objects that have little overall
consistency, are often half-baked in their implementation, and are nearly
always under-documented.)
All praise and kudos to the developers of those widgets and do-dads that
help the production scripter boldy go... Where would we be without their
efforts? With a far less complex tool, but one that wouldn't be worth much
in a production environment.
The AS environment does not enforce a consistent and therefore fully
inter-operable system of class definitions on the developer. Nor for that
matter does the operating system. So those busy and generous little bees
churning out their own solutions are going to add a level of complexity to
the AS world every time they add a new function.
Trying to work out which object or property you can access, when, and under
what conditions, and through which commands - is without a doubt the most
complicated aspect of AS.
There are days when I've just thrown another mark-twian-project in the
too-hard bin when I am sure all OOP has done is replace the verb-noun bloat
of old procedural languages like ADA and Fortran with the object-bloat of
modern OS's and Applications. SOS - new name.
Ric Phillips
Computer Laboratory Support Officer
Faculty of Humanities and Social Sciences
La Trobe University
9479 2792