Re: Variable Ponderance
Re: Variable Ponderance
- Subject: Re: Variable Ponderance
- From: has <email@hidden>
- Date: Fri, 1 Oct 2004 23:19:05 +0100
Courtney Schwartz wrote:
I can understand your distaste for pointers, pass-by-reference and
heaps, but that doesn't mean it's never helpful to understand them
when trying to understand certain puzzling behavior of AppleScript.
They're important and certainly have their place - just not in a
high-level language like AppleScript. AppleScript's problem here is
not that it doesn't expose low-level implementation details, it's
that it's not 100% successful at hiding them: its abstractions
sometimes'leak'.
Certain AppleScript behavior really doesn't make sense unless you're
familiar with basis tenets of computer logic like pointers. Just the
other day I had to set up a routine de-referencing an AppleScript
object. I would have had to abandon the whole project if I hadn't
understood that my problem was an issue of pointing a reference to
another reference, instead of passing-by-value.
Your problem there is with AppleScript's reference type, which is
somewhat flawed in design and behaviour. The correct solution is for
the language to be fixed, not for the user to learn pointer theory.
The whole point of creating languages like AppleScript is so users
_don't_ have to deal with such crud. For example, the Boxer language
[1], a semi-graphical teaching language designed at Berkeley, has a
structure called a portal which allows you to observe one part of a
program from another - and requires absolutely no knowledge of
'pointers' in order to use. [2]
My personal opinion? I love that AppleScript has reduced objects,
methods and parameters to the equivalent typical English syntax of
subject-verb-object.
Making code readable to non-programmers this way is a brilliant idea,
yes, though the way it's actually implemented is often problematic. I
also think it was a mistake for AppleScript to completely ditch
dialects: while the various human language syntaxes were a
non-starter, a 'real programming language'-like syntax could have
been very useful for educating users about the basic structure of the
code they write. 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.
I hate the obscure dictionaries and lack of information on data
types that go with it... one of the reasons I provide kudos to the
Adobe documentation team for providing separate docs on expected
child elements and input/output data types for their methods. Makes
debugging much easier!
That's not a flaw with AppleScript, but shortcomings in the design of
the Mac OS's application scripting system, to which AppleScript is
merely one of several clients. Buggy and inadequate dictionaries and
documentation are just as big a problem if using UserTalk or Python.;)
Now if only I could find a good inheritance tree diagram...
Script Debugger has a nifty doodad for visually displaying
inheritance trees. I keep meaning to write one for Python - I've
already written a suitable aete parser for rendering application
dictionaries to HTML - but haven't had the time to look into any
drawing/graphing libraries (it's not an area I've any experience in).
Mind you, if somebody else wanted to do it then I'd be more than
happy to point them in the right direction.
Cheers,
has
[1] http://www.soe.berkeley.edu/boxer.html/
[2] IMO, a modern Boxer would also make a far better "AppleScript"
than AppleScript does. Perhaps AppleScript should've nicked all its
best ideas from Logo instead...;)
--
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