Re: a date is not a date? Or: Why I sometimes hate AppleScript...
Re: a date is not a date? Or: Why I sometimes hate AppleScript...
- Subject: Re: a date is not a date? Or: Why I sometimes hate AppleScript...
- From: has <email@hidden>
- Date: Tue, 12 Feb 2008 14:02:21 +0000
On 11 Feb 2008, at 05:17, Christopher Nebel wrote:
Nope, its AppleScript's fault. Terminology conflicts are an
inevitable consequence of its design...
Yes, I'll agree with that, more or less. The Apple Event Manager
doesn't help, but there are ways around that.
...and an object lesson in why it's a bad idea to combine
arbitrarily extensible grammar with dumb character-based source code.
I don't think so. What it is is an object lesson in why duplicating
information is a bad idea. Whenever you store what's supposed to be
the same information in more than one place, you run the risk of
some of them getting out of sync.
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
_______________________________________________
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