Re: Variable Ponderance
Re: Variable Ponderance
- Subject: Re: Variable Ponderance
- From: has <email@hidden>
- Date: Sun, 3 Oct 2004 22:29:06 +0100
Shane Stanley wrote:
>While it's very easy to understand what something like:
tell app "Finder" to set s to name of file 1 of home
does, it's rather harder to understand exactly how it does it,
whereas something like:
> s = app('Finder.app').home.files[1].name.get()
is harder for the casual reader to deduce the meaning of, but easier
for the student to observe the underlying structure of.
Really? I suspect your deeper knowledge of what actually happens is
coloring your view.
Well, there's a difference between what's familiar (as an
AppleScripter, dot-syntax will initially seem alien), and what's
parseable (the rules for parsing AppleScript's keyword-laden,
dictionary-dependent, context-sensitive syntax are waaay more complex
than for a context-free dot-syntax). With a [good] context-free
syntax, all meaning can be gleaned from source code alone. With
something like AppleScript, it's a lot harder to figure out what a
particular word does without cross-referencing with other sources of
knowledge first.
On second thoughts though... my original example isn't such a good
one after all. While the syntax is disambiguated, the semantics are
just as unclear as AppleScript's [1][2]. A better choice would be:
s = Application('Finder.app').get(
app.property('home').elements('files').byindex(1).property('name')
)
Anyway, the important point is that the user should be able to
identify the fundamental structures involved in any piece of code. To
give an example: because AppleScript presents application object
references using the same syntax as is used to present native object
references, users naturally assume that they are the same. Except
that they're not: application references are actually queries - with
more in common with SQL than OOP - dressed in a layer of syntactic
sugar by AppleScript to make them easier to read, whereas AppleScript
references are true OO references. Hence the confusion and annoyance
caused when a user tries to use a 'whose' clause with an AppleScript
list, or use a complex expression involving math in a 'whose' clause
to an application reference. Plus there are whole classes of
compilation errors that AppleScript is prone to that other, more
pedantically syntaxed but completely unambiguous, languages are not.
If even the AS compiler has trouble figuring out what code means,
what chance does the average user have? i.e. Where the AppleScript
syntax giveth, it also taketh away.
So while there's sometimes a benefit to be had from making different
things look the same (familiarity, readability), there's also a
penalty (confusion when certain aspects don't work as anticipated).
Being able to toggle between different presentations of the same code
could go quite some way towards helping users understand what they're
really reading: while they wouldn't want to write and write code
using some weird, lengthy, symbol-laden junk, those same symbols can
show you the meanings of individual words - e.g. is it a
partial/complete property, class, element, command or enumerator
name? - without having to constantly cross-reference each word
against application dictionaries.
Sometimes you need to know the details, and other times you don't.
And on those occasions when you [or, for that matter, the compiler]
do, the more help you have available, the better. With a 'magic
syntax toggle' button, you could have the best of all worlds. Which
is nice.
HTH
has
[1] What happens when you toss off an email with insufficient thought. ;)
[2] With the MacPython appscript package (what I took the dot-syntax
example from), I will at least have a big red "Ceci n'est pas un 'OO
reference'" warning on the front page. The advantages of syntactic
sugar do, IMHO, ultimately outweigh the disadvantages of having new
users initially leaping to the wrong assumptions. I still expect to
get a fair amount of first-timer flack for it... after all, who in
the world ever RTFMs _first_? ;p
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden