Re: AppleScript-Users Digest, Vol 5, Issue 102
Re: AppleScript-Users Digest, Vol 5, Issue 102
- Subject: Re: AppleScript-Users Digest, Vol 5, Issue 102
- From: Jason Bruce <email@hidden>
- Date: Tue, 12 Feb 2008 18:28:29 -0800 (PST)
has,
I may be wrong (and will certainly change my mind if
you correct me) but I disagree with your position that
AppleScript's syntax doesn't provide sufficient
semantic information to determine how a given word
should be treated. Your Ruby examples are just a
matter of how many languages refer to variables (or
symbols or whatever) within name spaces. AppleScript
uses the possessive form of the english language (e.g.
"of" of an apostrophe). It also uses other forms to
refer to particular namespaces (e.g. "my," "its,"
"continue", "using terms from", etc.).
Jb
has stated:
This is true (the keyword-vs-raw-code problem), but
it's not the only
factor. When parsing a script, the AppleScript
compiler also attaches
meta-information on what each symbol means: is it an
identifier, a
command name, a property name, an element name, a type
name or an
enumerator name.
It has to do this because AppleScript's syntax doesn't
provide
sufficient semantic information to determine how a
given word should
be treated; e.g. is a given word a variable name, a
class/enumerator
name or a property/element/command name? (The three
major food groups,
if you like.) With other languages such as Ruby, this
information can
be derived from the syntax alone, e.g.:
document = 3 # document is a variable
:document # document is a symbol
foo.document # document is a method call
This is all that Ruby needs to know in order to parse
and execute a
script; the compiler doesn't need to guess at the
'document' words
intent because the syntax makes it perfectly clear. Of
course, all
those cryptic dots and dashes are none too appealing
to the sorts of
folks that AppleScript is aimed at, which is why its
original
designers left them out. In order to make this work at
all, however,
they had to resort to various cheats. For example, in
Ruby I can write:
InDesign = app('Adobe InDesign CS3')
length = InDesign.documents[1].stories[1].length.get
The first 'length' is a variable identifier; the
second a method call.
This information can be reliably determined via Ruby's
syntax alone.
In AppleScript, if I try to write the above as:
tell application "Adobe InDesign CS3"
set length to length of story 1 of document 1
end tell
it doesn't work as intended. Because AppleScript's
syntax is just too
ambiguous for it to follow my intentions, it just
ignores me and takes
its directions from somebody else instead (the
application
dictionary). As user I'm the one who's supposed to be
in charge, but
here we have AppleScript going off and making its own
spot decisions
behind the scenes.
The AppleScript apologists will invariably point out
that the fault
here is mine for trying to use an application-defined
name for a
variable, which is the same argument they hauled out
against the
iTunes team over the 'year' keyword conflict that
started this thread.
This is the programming equivalent of slapping a
band-aid on a broken
leg and calling it healed. It's a kludge; a hack; a
clumsy workaround
that treats only the superficial symptoms while not
only failing to
rectify the underlying cause but actually exacerbating
it.
If there is a golden rule of software design, it's
that you must
constantly work at keeping your code's complexity to
an absolute
minimum. If you don't keep complexity tightly under
control, it will
quickly spiral beyond your ability to understand and
manage it, and
you'll be left with a bloated, bug-ridden disaster
that gives you
brain aneurisms just to look at, never mind work on.
By demanding that
each object/script/application/developer in the system
must know about
every other object/script/application/developer in
order to do its job
correctly, apologists are unwittingly asking for
significantly
increased complexity along with the new problems this
will create. The
only way to make things work better is to _reduce_,
not increase, the
amount of stuff that scripters and developers, not to
mention
AppleScript itself, need to know in order to do their
jobs.
Te only way to truly fix these problems is to
eliminate all the
guesswork, behind-the-scenes trickery and hackwork
that AppleScript
currently relies on, and put users back in charge of
telling the
language what _they_ want the words they use to mean.
This is already
the case with Python, Ruby, etc., but given that the
audience to which
AppleScript appeals wouldn't take kindly to their kind
of technically
reliable but visually unattractive dots-n-braces
syntax (or else
they'd already be using those other languages), that
leaves the
structure editor approach as used by MIT's Scratch and
Carnegie
Mellon's Alice as the only sensible answer. (This is
something I've
already discussed in other posts, so won't spend time
rehashing it
here.)
Regards,
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden