• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: a date is not a date? Or: Why I sometimes hate AppleScript...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: a date is not a date? Or: Why I sometimes hate AppleScript...
      • From: "Gary (Lists)" <email@hidden>
References: 
 >a date is not a date? Or: Why I sometimes hate AppleScript... (From: Skeeve <email@hidden>)
 >Re: a date is not a date? Or: Why I sometimes hate AppleScript... (From: deivy petrescu <email@hidden>)
 >Re: a date is not a date? Or: Why I sometimes hate AppleScript... (From: has <email@hidden>)
 >Re: a date is not a date? Or: Why I sometimes hate AppleScript... (From: deivy petrescu <email@hidden>)

  • Prev by Date: Re: A date IS a date
  • Next by Date: Re: A date IS a date
  • Previous by thread: Re: a date is not a date? Or: Why I sometimes hate AppleScript...
  • Next by thread: Re: a date is not a date? Or: Why I sometimes hate AppleScript...
  • Index(es):
    • Date
    • Thread