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: Sat, 9 Feb 2008 23:06:19 +0000
On 9 Feb 2008, at 18:33, deivy petrescu wrote:
As people have already pointed out, this is a clash in
nomenclatures.
iTunes defines year as a property of audio CD playlist.
[...]
As for you hating AS, this is your call, but mostly I feel that
problems arise because of the implementors.
Nope, its AppleScript's fault. Terminology conflicts are an
inevitable consequence of its design, and an object lesson in why
it's a bad idea to combine arbitrarily extensible grammar with dumb
character-based source code.
I completely disagree and agree with you here.
I completely disagree: it is not AppleScript's fault!
I completely agree: "Terminology conflicts are an inevitable
consequence of its [AppleScripts] design".
AppleScript is not Python, Ruby, Perl or whatever, it is AppleScript.
AS is very versatile since it allows other apps to speak its
language. This is not so with the other scripting languages above.
Say what?
In your example below, you capture a date from AS (sort of) and use
it in Python.
It is not different that what Skeeve proposed as his solution:
tell application "iTunes" to set da to date added of selected track
tell application "System Events" to get year of da
What do you think the original code was trying to do? The _only_
difference between it and Skeeve's is that the word 'year' appears
outside of the 'tell application "iTunes"' block rather than inside
it. The problem is that AppleScript cuts a lot of corners in order to
create its pseudo-English appearance, and one of those cut corners is
making decisions about what words such as 'year' mean before it has
sufficient information to actually know for sure [1]. If it guesses
right, things happen to work and the illusion holds. If it guesses
wrong, the illusion cracks, things break, and users have a devil of a
time figuring out why through all the smoke and mirrors.
One of my problems with your criticisms of AS is that you look at it
as if it is a scripting language.
It is *more* than that, it is an *inter application scripting*
language.
*Utterly* meaningless statement. Python, Ruby and Perl all do "inter
application scripting" too. There is nothing inherently magical about
Apple event IPC, and any language that can talk to C can control
scriptable applications. (Writing an application scripting bridge that
works as reliably as AppleScript's own is another matter, but that's a
separate rant for another time.) Please stop making such transparently
flimsy excuses for AppleScript's failings; it does you no favours and
hurts my eyes from all the rolling.
Because of the above it will be always plagued with the terminology
conflict, as you said.
Nonsense; as my code example showed, Python or Ruby plus appscript
manage to avoid terminology conflicts just fine. AppleScript is
plagued with terminology conflicts primarily because of its schlonky
compiler design. Allowing every Tom, Dick and Harry application and
osax to arbitrarily redefine the language's core syntax at any time
was - with benefit of hindsight - a bad decision. Even Dr Cook, one of
its original designers, acknowledges this.
You can have simple, reliable character-based source code (e.g.
Python). You can have simple, reliable natural language-like source
code (e.g. Scratch). You cannot have simple, reliable, character-based
natural language-like source code, however (AppleScript). The original
designers bent and stretched character-based source code well beyond
its capabilities in order to make it appear natural langage-like. It's
like trying to make a sports car by putting a V8 engine in a Yugo
body; the framework and transmission just can't handle the stress and
little things like wheels tend to fly off as soon as anyone puts their
foot down.
These problems simply don't exist in languages that have a stable,
unambiguous grammar, e.g. the following works perfectly in Python
with nary a peep about invalid syntax or unknown properties or any
of that other cryptic nonsense that AppleScripters have to put up
with:
Here I completely agree to disagree. I believe that you are
comparing apples and oranges. If one is interested in creating a
scripting language with the power of python (which can be used to
write compilers) with AS's syntax, one should be summarily shot! :)
Again, say what?
from appscript import *
tracks = app('iTunes').browser_windows.first.selection()
for track in tracks:
date = track.date_added()
print type(date)
print date.year
The only terminology conflicts for which application developers
might reasonably take some responsibility are those that occur
between keywords in the application's own dictionary - e.g. if a
class and a property both have the same name, - although these
sorts of limited conflicts are still largely Apple's fault for
creating the whole human-readable names versus raw Apple event
codes dichotomy in the first place.
Not really. Sometimes developers use terms which are well known
terms of the Standard Suite for instance. As for your second point,
I believe that choosing the English like, if you will, term makes it
that much easier for the uninitiated to get started.
Again, an "English-like" syntax would work just fine if it were
supplied within a framework that could handle it without the wheels
periodically flying off, i.e. a structure editor à la Scratch or
Alice. AppleScript's failings are entirely of its own manufacture. The
original design team made an honest mistake; it's just unfortunate
that Apple took them off the project before they ever had a chance to
go back and remedy it once its problems became obvious.
There are rumors of people who started with AS and now are full
fledged programmers in other languages, believe it or not... :)
Yes, I believe the undersigned is one of them... :)
has
[1] Since AppleScript is a weakly, dynamically typed language, the
only time it can know for sure what 'year' (as in 'year of
<something>') means is when it actually applies it to an object at
runtime. However, in order to create its English-like appearance, it
makes a best-guess about the user's intent for that word according to
where it appears in the script: if it appears within the 'tell app
"iTunes"' block, it gives it one meaning; if it appears outside the
block it gives it another. If it guesses wrong, the script fails at
runtime. It's like making cooking for six before you've even sent out
the dinner invitations and have no actual idea if two, five or ten
people will be coming.
--
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