[besson3c]

What is the point of Applescript? Why should anybody learn this thing when there is a rich Unix command line environment available? Why should developers put in the time to make their app Applescript friendly rather than just write a command line Unix tool that will handle all of the things that people might want to script? What does the Applescript language offer that I could not do via the command line if the application included a command line binary as I've described here? Is Applescript little more than a holdover from the days of OS 9?

I understand that Automater makes use of Applescript, but if Applescript had been killed off sooner Automater could simply interact with these (proprietary) command line tools. I wouldn't at all be surprised if the Unix command line environment wasn't much richer than Applescript/Automater anyway, which is why Applescript seems pretty redundant to me.

[0157988944]

It's very close to natural language as languages go. That's all I got.

[larkost]

First off, Automator does not use AppleScript. There are some places where they cross (you can call Automator from AppleScript, and some Automator actions use AppleScript), but they don't actually do much with each other. I really wish that they had built Automator on top of AppleScript, but they did not.

And shell scripts and AppleScripts have very few similarities. With shell scripts you are limited in what you pass between one segment and another to just text. There are a lot of tricks to work around this limitation in some areas, but they only work for some types of problems. So if what you are working on is just text then shell scripts can work out great, stray much from that and you are going to have a problem.

A point to emphasize here is that shell scripts don't ever interact with each other except through a single stream of text. So it is difficult for a script to ask complex questions of a program it is working with, and prohibitively difficult to do interactive things.

AppleScript is actually really bad at text (comparatively). Its real strength is that you can work within other applications with a set of objects declared by that application. An example is going through a complete workflow in PhotoShop. You can programmatically check on the size of images, move them around, arrange them based on other objects, perform filter operations, change layers, etc... all through AppleScript. Those are things that you could never do through shell scripting. There are a few other languages that are used like AppleScript (lua comes to mind), but none of them have been created to be able to have a single script that can work with multiple applications like AppleScript (so you can have multi-application automated workflows).

I should note that Microsoft's PowerShell idea takes ideas that are expressed in AppleScript, Automator, and shell scripting. The interface like shell scripting (so a command shell), the power to comunicate with running applications (like AppleScript), and the ability to pass rich objects between components (Automator, but without so many limitations). I have never done more than read about PowerShell, so I am probably missing all the limitations, but do wish that Apple would come up with something conceptually like it.

[besson3c]

Originally Posted by larkost 

First off, Automator does not use AppleScript. There are some places where they cross (you can call Automator from AppleScript, and some Automator actions use AppleScript), but they don't actually do much with each other. I really wish that they had built Automator on top of AppleScript, but they did not.

And shell scripts and AppleScripts have very few similarities. With shell scripts you are limited in what you pass between one segment and another to just text. There are a lot of tricks to work around this limitation in some areas, but they only work for some types of problems. So if what you are working on is just text then shell scripts can work out great, stray much from that and you are going to have a problem.

A point to emphasize here is that shell scripts don't ever interact with each other except through a single stream of text. So it is difficult for a script to ask complex questions of a program it is working with, and prohibitively difficult to do interactive things.

AppleScript is actually really bad at text (comparatively). Its real strength is that you can work within other applications with a set of objects declared by that application. An example is going through a complete workflow in PhotoShop. You can programmatically check on the size of images, move them around, arrange them based on other objects, perform filter operations, change layers, etc... all through AppleScript. Those are things that you could never do through shell scripting. There are a few other languages that are used like AppleScript (lua comes to mind), but none of them have been created to be able to have a single script that can work with multiple applications like AppleScript (so you can have multi-application automated workflows).

I should note that Microsoft's PowerShell idea takes ideas that are expressed in AppleScript, Automator, and shell scripting. The interface like shell scripting (so a command shell), the power to comunicate with running applications (like AppleScript), and the ability to pass rich objects between components (Automator, but without so many limitations). I have never done more than read about PowerShell, so I am probably missing all the limitations, but do wish that Apple would come up with something conceptually like it.

Yes, but I'm not talking about shell scripts persay, I'm talking about command line tools for these applications. For instance, just as a for-example, say you wanted to batch process some images in Photoshop:

Code:
photoshop-cli --source=/source/folder --dest=/dest/folder --action=myaction

This may be a really bad example because I have no clue whether this is possible in Applescript and how this would be done, exactly. However, combine this with your Unix environment and there is a lot of potential. You could do this batch processing and scp the files elsewhere, PGP sign them, sort them into directories based on filename, or whatever.

So, I'm proposing replacing Applescript with a command line component to an app that works in a Unix environment, not simply shell scripts as they exist today. Any proprietary file format issues would be handled by this particular app.

Make sense?

[Hal Itosis]

Originally Posted by besson3c 

What is the point of Applescript? Why should anybody learn this thing when there is a rich Unix command line environment available? Why should developers put in the time to make their app Applescript friendly rather than just write a command line Unix tool that will handle all of the things that people might want to script?

Code:
#!/usr/bin/pseudo_bash
if [ "developers provided command line tools" ]
then
	applescript might become less important
fi

KEYWORD: "if"

Ha! No, yes i agree... but such things don't happen overnight. AppleScript was born out of need in an OS long ago. Developers needed to be inspired and motivated. TextWrangler is a GUI that includes a tool or two... so that's one [limited] example already in the wild. There are a few others perhaps, but i don't recall them now.

[larkost]

Your example is designed to conform to what a script does best. You are missing all the non-linearity that AppleScript can provide. Without creating a whole new embedded language inside PhotoShop (which PhotoShop already has incidentally) your proposal fails when you have to check anything for the image. What if you need to put two images next to each other, and want them both in lanscape mode? How do you propose doing that. I could probably accomplish that particular task with command-line scripting through ImageMagic, but that would be the most complicated workflow possible.

And you are also missing that a single AppleScript script can work with multiple applications, so you could do the work in Photoshop, then carry the resulting image and place it into a table in a Word document along with some associated text at the current insertion point (where the cursor is). At this point we are clearly beyond what is possible with command-line scripting.

Incidentally PhotoShop is actually a bad example for this, since they do have an internal system for scripting, and you can make command-line callable workflows. They can be slightly complex, but nothing like what is possible through the AppleScript bindings.

[CharlesS]

AppleScript and shell scripts serve two different, completely orthogonal purposes. AppleScript is designed to make it possible to automate and control other GUI apps, whereas traditional shell scripting is not. Sure, developers can create command-line interfaces to their applications, but you will never get anywhere near the sort of coverage that you get with AppleScript, especially when you take into account built-in functionality such as the default AppleScript functionality provided by Cocoa and its various classes, and GUI scripting.

AppleScript's syntax also appears to be easier for "average Joe" type users to understand.

[P]

Originally Posted by besson3c 

So, I'm proposing replacing Applescript with a command line component to an app that works in a Unix environment, not simply shell scripts as they exist today. Any proprietary file format issues would be handled by this particular app.

Make sense?

Sure. Only thing that doesn't make sense is where Apple fits into all that. Apple does provide command line equivalents of some of its tools - all that's missing is for app developers to do the same. They can do that irrespective of Applescript's existence of not.

Besides, you can all Applescript from the command line as well, if you want to.

[besson3c]

Originally Posted by larkost 

Your example is designed to conform to what a script does best. You are missing all the non-linearity that AppleScript can provide. Without creating a whole new embedded language inside PhotoShop (which PhotoShop already has incidentally) your proposal fails when you have to check anything for the image. What if you need to put two images next to each other, and want them both in lanscape mode? How do you propose doing that. I could probably accomplish that particular task with command-line scripting through ImageMagic, but that would be the most complicated workflow possible.

Why not anything that people typically do within a Photoshop action becomes a command line argument, i.e. --rotate, --resize, etc.?

I'm honestly not trying to jam a square peg into a round hole. Maybe there are perfectly legitimate reasons for Applescript to exist, but I would suggest that perhaps *both* ought to exist, as a command line tool would definitely have its uses. Agreed?

And you are also missing that a single AppleScript script can work with multiple applications, so you could do the work in Photoshop, then carry the resulting image and place it into a table in a Word document along with some associated text at the current insertion point (where the cursor is). At this point we are clearly beyond what is possible with command-line scripting.

I agree that there are some uses for this sort of high level GUI oriented scripting. What percentage of Applescripts are designed to do these tasks, would you guess? This isn't a leading question, I'm just not imaginative enough to think of several circumstances where this high level scripting would come into play.

I will say that I think that this sort of high level GUI application dependent scripting is pretty ugly and hacky in general. I don't know if I would put too much trust into this in a meaningful workflow.

Incidentally PhotoShop is actually a bad example for this, since they do have an internal system for scripting, and you can make command-line callable workflows. They can be slightly complex, but nothing like what is possible through the AppleScript bindings.

I just pulled Photoshop off the top of my head very quickly, I'm sure there are other, more relevant case scenarios

[besson3c]

Originally Posted by CharlesS 

AppleScript and shell scripts serve two different, completely orthogonal purposes. AppleScript is designed to make it possible to automate and control other GUI apps, whereas traditional shell scripting is not. Sure, developers can create command-line interfaces to their applications, but you will never get anywhere near the sort of coverage that you get with AppleScript, especially when you take into account built-in functionality such as the default AppleScript functionality provided by Cocoa and its various classes, and GUI scripting.

AppleScript's syntax also appears to be easier for "average Joe" type users to understand.

You're the programmer, so here's a question for you (this isn't meant to sound passive aggressive or some sort of confrontational challenge, I honestly don't know the answer to this)...

How hard would it be to simply make all of the menu commands you put into an app available as a command line option? E.g.:

Code:
--file-open
--file-save
--edit-copy
--edit-paste

I'm not suggesting that this would necessarily make sense, but could you essentially recreate Applescript this way if you added on some basic logic that might be relevant to the program (e.g. if image = x dimensions, crop to y dimensions, save, open next file)?

[besson3c]

Originally Posted by P 

Sure. Only thing that doesn't make sense is where Apple fits into all that. Apple does provide command line equivalents of some of its tools - all that's missing is for app developers to do the same. They can do that irrespective of Applescript's existence of not.

Besides, you can all Applescript from the command line as well, if you want to.

Good point. I guess it's up to us users to request this as features to the apps we use then... What got me started with this is thinking that there are probably a number of users, particularly Windows users, who would not think to look or think about a command line based solution for their scripting needs. I generally find that many Windows users and novice users in general solve problems by thinking of everything at a high level - i.e. what GUI options they can see and click on. As our understanding of computers grows we start to understand that hey, there is a protocol called IMAP that is used to fetch messages from my Inbox, and that when I click on such and such icon in such and such app, the fetching of that message is not some weird magic that goes on that is a mystery to all mankind. I can begin to trace problems a little better, understand what kinds of communications apps such as this facilitate and how this is all managed, etc.

I would hate to put together a workflow that was dependent on a daisy chain of Applescript scripting, it just seems like a very ugly and sloppy way to do things from a design perspective. Then again, I haven't actually used Applescript, so perhaps my thinking is irrational, or I'm making too many assumptions.

[CharlesS]

Originally Posted by besson3c 

You're the programmer, so here's a question for you (this isn't meant to sound passive aggressive or some sort of confrontational challenge, I honestly don't know the answer to this)...

How hard would it be to simply make all of the menu commands you put into an app available as a command line option? E.g.:

Code:
--file-open
--file-save
--edit-copy
--edit-paste

I'm not suggesting that this would necessarily make sense, but could you essentially recreate Applescript this way if you added on some basic logic that might be relevant to the program (e.g. if image = x dimensions, crop to y dimensions, save, open next file)?

Well, you certainly could do that. You'd have to set up some IPC between your command-line tool, decide on the structure of the commands, write logic for your command-line tool to encode your commands and for your app to decode them, and then write logic for your app to listen for such commands, interpret them, and execute them. You'd also probably have a plethora of security issues to work out. It wouldn't be implausible, but it would be a lot more work and would take a heck of a lot more time than simply implementing AppleScript. Doing the latter would get you a working interface much more quickly, your result would be more flexible, easier to use, and as a side bonus it'd be a lot easier to write your command-line interface, by having it use the AppleScript functionality as its back-end. I'd bet dollars to donuts that TextWrangler's 'edit' command is built on top of AppleScript or Apple Events to do its thing. So, AppleScript is a win-win for everyone.

(yes, I know I'm a hypocrite because I haven't built the AppleScript support for Pacifist yet. It's been on my to-do list for a long time; I just haven't gotten around to it. One excuse I have is that AppleScript support is easier to do for a Tiger-only app due to some new mechanisms they added in Tiger, so I've been waiting until I can dump Panther support before sitting down and doing it.)

[besson3c]

Okay, so it is clear where Applescript is useful. I do think that there are instances where a command line binary in place of or a supplement to Applescript would be handy or preferable, but I guess this isn't really Apple's call to make, unless there were things that Apple could provide that would make writing these sorts of tools easier?

[CharlesS]

Well, there is something Apple provides that makes writing these sorts of tools easier. It's called AppleScript. If your program supports AppleScript, you can make a command-line tool to control your application quite easily. It wouldn't even have to be a real program - it could be a simple shell script sending the AppleScript commands via the osascript tool.

(Yes, there's also PDO, but vending the whole object raises some extra security concerns that you don't have with AppleScript, which is a more limited environment.)

[Simon]

Besson, what the heck are you talking about?

Both serve entirely different purposes. And both can call each other. So obviously if you have a complex workflow you would do something specific in the one that is better suited and then switch over to the other when required.

Nothing has to be killed. It sounds like you just need to get a clue about AS.

[Chuckit]

Like Simon said, AppleScript and command-line programs are fairly orthogonal. Dedicated programs do things by themselves. AppleScript is an inter-process communication protocol for already-running programs. Why would you phase out one in favor of another?

[kmkkid]

A better question is why kill off something that serves a purpose, isn't broken, and has no legitimate reason to be killed off?

AS can call shell scripts, so what would be the purpose exactly?

Waste resources at Apple by having them add already existing functions, just via different code?

[davidbk1]

I think the real issue here for besson might be that he wants command line access to some of his applications, and I would love this as well. Applescript is good at pretending to be the user typing and clicking, but it's not so nice if you want to have QuickTime convert a few movies for you. My 3 gripes are, 1) I don't want to see windows for applications I don't interact with (convert those movies without a GUI) 2) If all you want to do is pause a movie from the command line, its really slow (it gets frustrating to have to wait 5 seconds before answering the phone) 3) It's not even close to English or normal communication. Just because it uses more words than symbols doesn't mean you can pick which words to use, or their order etc. It's just as hard to guess at writing properly as any other language, except for us programmers who tend to know a few languages, none of them look anything like Applescript so we're starting over. I don't see the benefit in making more complete sentences for newbies. It's still a formal language that requires effort to understand. I don't think including useless, English words will lower the barrier for newcomers, but I could be wrong.

If there were alternative command line control for applications like Finder and QuickTIme, I would never touch Applescript. I understand its usefulness, it's just not for me.

[JKT]

Originally Posted by davidbk1 

My 3 gripes are, 1) I don't want to see windows for applications I don't interact with (convert those movies without a GUI)

Wouldn't that be where Automator comes in?

[mduell]

Originally Posted by besson3c 

What is the point of Applescript? Why should anybody learn this thing when there is a rich Unix command line environment available?

*nix-like CLI is a lot of things, but rich? Not so much. They're still passing text streams between utilities instead of rich data structures.

If AppleScript disappeared tomorrow I wouldn't miss it, but I recognize that people have built difficult-to-replace workflows around it.

[Chuckit]

Originally Posted by davidbk1 

2) If all you want to do is pause a movie from the command line, its really slow (it gets frustrating to have to wait 5 seconds before answering the phone)

What?

Code:
time osascript -e 'tell app "QuickTime Player" to start document 1'

real	0m0.158s
user	0m0.088s
sys	0m0.023s

Originally Posted by davidbk1 

3) It's not even close to English or normal communication. Just because it uses more words than symbols doesn't mean you can pick which words to use, or their order etc. It's just as hard to guess at writing properly as any other language, except for us programmers who tend to know a few languages, none of them look anything like Applescript so we're starting over. I don't see the benefit in making more complete sentences for newbies. It's still a formal language that requires effort to understand. I don't think including useless, English words will lower the barrier for newcomers, but I could be wrong.

Yes, the language is terrible. Fortunately, we don't have to use it anymore. MacRuby equivalent:

Code:
framework 'ScriptingBridge'
SBApplication.applicationWithBundleIdentifier('com.apple.quicktimeplayer').documents[0].start

[davidbk1]

Originally Posted by Chuckit 

What?

Code:
time osascript -e 'tell app "QuickTime Player" to start document 1'

real	0m0.158s
user	0m0.088s
sys	0m0.023s

Yes, the language is terrible. Fortunately, we don't have to use it anymore. MacRuby equivalent:

Code:
time osascript -e 'tell application "System Events" to keystroke " "'
 
real	0m2.044s
user	0m0.109s
sys	0m0.036s

It could be one of several applications and it should toggle playing, this is the simplest way I found to do it. For applications that aren't scriptable, trying to arrow down 15 times is a disaster, not that it would be any better without Applescript. I wish keystroke commands executed faster is all I guess.

I'll have to look into MacRuby, thanks.

[davidbk1]

Originally Posted by JKT 

Wouldn't that be where Automator comes in?

The only option I see in Automator is to convert movies to iPod or AppleTV format. That's extremely limited and doesn't allow for common (to me at least) tasks like joining movies or converting to other formats. I never bother with Automator now as the few times I did open it I found the actions to be very limited. Maybe it's improved since I last tried to use it, next time I've got a scripting task I'll give it another go.

[Chuckit]

Originally Posted by davidbk1 

Code:
time osascript -e 'tell application "System Events" to keystroke " "'
 
real	0m2.044s
user	0m0.109s
sys	0m0.036s

It could be one of several applications and it should toggle playing, this is the simplest way I found to do it. For applications that aren't scriptable, trying to arrow down 15 times is a disaster, not that it would be any better without Applescript. I wish keystroke commands executed faster is all I guess.

If you have a command you have to type out a lot, you could make a shell script and/or double-clickable AppleScript to run them. My point was that execution speed doesn't seem to be a problem. Typing speed will always be an issue with a command-line interface.

Originally Posted by davidbk1 

I'll have to look into MacRuby, thanks.

There are lots of language bindings that let you do scripting. OS X includes RubyCocoa and Python bindings as of 10.5. There's also a JavaScript OSA plugin and I think a few other languages too.

[besson3c]

I agree that Applescript has its purpose and shouldn't be killed, let's leave it at that.

I would still like for command line options to be more common. There are many occasions where they would be quite useful, and more so than AS.

[Chuckit]

Only if they happened to be the options you were looking for. There are many instances (such as David with QuickTime Player) where it seems quite likely that a CLI would not offer the functionality some people want from it.

[besson3c]

Originally Posted by mduell 

*nix-like CLI is a lot of things, but rich? Not so much. They're still passing text streams between utilities instead of rich data structures.

What kinds of data structures would you like to pass around that you can't? Arrays? Hashes? You can do this already. XML?

[besson3c]

Originally Posted by Chuckit 

Only if they happened to be the options you were looking for.

True, but you have to start somewhere.

What's kind of funny is that several OS X apps already do have CLI options, they are used buried inside the package:

Code:
$ pwd
/Applications/Firefox.app/Contents/MacOS

$ ./firefox --help
Usage: ./firefox-bin [ options ... ] [URL]
       where options include:

        --g-fatal-warnings              Make all warnings fatal

Mozilla options
        -height <value>         Set height of startup window to <value>.
        -h or -help             Print this message.
        -width <value>          Set width of startup window to <value>.
        -v or -version          Print Firefox version.
        -P <profile>            Start with <profile>.
        -ProfileManager         Start with ProfileManager.
        -no-remote              Open new instance, not a new window in running instance.
        -UILocale <locale>              Start with <locale> resources as UI Locale.
        -safe-mode              Disables extensions and themes for this session.
  -jsconsole           Open the Error console.
  -browser            Open a browser window.
  -setDefaultBrowser   Set this app as the default browser.
Usage: firefox [-flags] [<url>]

I think what I might start doing is creating a directory of symbolic links to these binaries and put this directory in my shell's path. There are times when I'm working in the Terminal and I would love to be able to do stuff like:

Code:
firefox http://www.prototypejs.org/api

[besson3c]

Never mind, it looks like the Firefox command line tool is broken anyway. It wants to relaunch Firefox rather than use the instance of Firefox that is already running.

This would be nice to have working though... oh well.

[mduell]

Originally Posted by besson3c 

What kinds of data structures would you like to pass around that you can't? Arrays? Hashes? You can do this already. XML?

Objects. Whatever the fsck I want them to be.

That you even suggest serializing is sort of my point... unix-like CLIs are limited to passing text around.

[besson3c]

Originally Posted by mduell 

Objects. Whatever the fsck I want them to be.

That you even suggest serializing is sort of my point... unix-like CLIs are limited to passing text around.

So is the rest of the programming world, I don't think this is fair to single out the CLI environment this way. There are difficulties bridging between languages in general, this is where intermediary technologies such as JSON and SOAP come into play. Some of the CLI tools might be written in Perl, Ruby, Python, or C. Right now, there is no way to create a universal object that is recognizable by each of these languages without some sort of bridge, AFAIK.

[Chuckit]

Because there are so many things other than binary data that make sense to pass between programs? That doesn't seem like much of a limitation. You're generally going to need to serialize to get anything outside of your own memory space.

[CharlesS]

Originally Posted by davidbk1 

Code:
time osascript -e 'tell application "System Events" to keystroke " "'
 
real	0m2.044s
user	0m0.109s
sys	0m0.036s

It could be one of several applications and it should toggle playing, this is the simplest way I found to do it. For applications that aren't scriptable, trying to arrow down 15 times is a disaster, not that it would be any better without Applescript. I wish keystroke commands executed faster is all I guess.

I'll have to look into MacRuby, thanks.

Well, if applications aren't scriptable, that's an inherent limitation, although in this case you wouldn't be able to do it using the shell at all. Furthermore, any slowness in the GUI scripting thing is more of a problem of the Accessibility framework, which is what is doing the actual work, not AppleScript itself (which is simply relaying the message to the System Events application to tell it to go and perform the keystrokes using Accessibility).

However, if you're dealing with QuickTime Player, all you have to do is:

Code:
time osascript -e 'tell app "QuickTime Player" to stop document 1'

real	0m0.149s
user	0m0.088s
sys	0m0.023s

and it's fast.

Also, I didn't find keystroke to be as slow as what you're getting, so perhaps it's something about your setup:

Code:
time osascript -e 'tell app "System Events" to keystroke " "'

real	0m0.418s
user	0m0.092s
sys	0m0.026s

[JKT]

Originally Posted by davidbk1 

The only option I see in Automator is to convert movies to iPod or AppleTV format. That's extremely limited and doesn't allow for common (to me at least) tasks like joining movies or converting to other formats. I never bother with Automator now as the few times I did open it I found the actions to be very limited. Maybe it's improved since I last tried to use it, next time I've got a scripting task I'll give it another go.

You can create Automator workflows and apps around CLI commands as well as around AppleScripts and the Automator actions supplied by apps. As you seem comfortable writing CLI commands and scripts to do your encoding for you, I think you could create an Automator workflow that would run in the background, with no splash screen or need to launch an app, as you wanted.

[cgc]

Isn't AppleScript kind of like ARexx which I used on my Amigas...

[wadesworld]

As others have said, the problem with killing Applescript is that suddenly every application would have to implement its own scripting language, and there would be no consistency.

But, as others have also said, Applescript is fairly HORRIBLE to write. In it's quest to be "English-like" it's darn near impossible to figure how something should be described if your first guess doesn't work.

[taltos14]

According to someone close to the Applescript team:
Back around the time Quark was preparing version 4, Apple was planning to kill Applescript. Some players from the Graphic Arts industry convinced Apple that Applescript was one of the things that kept them on the Mac platform. Apple did a 180 on their decision. Quark had to scramble to put an Applescript dictionary back into their application at the last minute. That was the reason for the crappy Quark script dictionary.

Bottom-line, the prepress industry is saving tons of cash with applescript. Back in the day, there was nothing that could do what Applescript could do. Javascript is getting there. Given a choice between two applications, one scriptable and one not; I'm always going to favor the scriptable option, even if the other app is slightly better

[moonmonkey]

someone could PM Sal, he knows quite a bit about Applescript.

[Art Vandelay]

Considering he's the program manager for AppleScript at Apple, probably no one knows more than him.

[CharlesS]

Originally Posted by moonmonkey 

someone could PM Sal, he knows quite a bit about Applescript.

"Quite a bit?" Sal knows everything about AppleScript. He's in charge of the whole project.

[moonmonkey]

Yes, I was exercising a little used technique known as understatement.