So, I have an honest question, what’s the point of ApplescriptObjC? It seems like it’s basically just re-formatting ObjC commands without making them much easier to read, and doesn’t use many of the commands we were used to with Applescript Studio.
I’ve been using Applescript Studio for several years now, and I’ve really enjoyed the experience. It’s been perfect for the kinds of projects I’ve worked on, mostly coming up with custom ways to integrate other existing applications. Since they did away with ASS in 10.6, I’ve been trying to learn ApplescriptObjC, but it seems like such a better investment of time to just skip it and learn ObjC and Cocoa instead. I’m curious, has anyone found any great benefit to sticking with ApplescriptObjC, or should I just cut the lifeboat lines and go for it with ObjC? Maybe I’m missing something, but it doesn’t seem like it.
If your apps won’t be driving other apps, you may as well go straight to Objective-C – although if you know AppleScript, AppleScriptObjC can make for a much gentler introduction.
But if you are going to be writing apps that drive other apps, AppleScriptObjC makes more sense because it lets you integrate both worlds. You effectively bring Cocoa into AppleScript. So if, for a simple example, you are talking to an an app and you want to sort the results you received from some command the way the Finder sorts names, you can easily turn your list into an NSArray and do it there, without the need to cross into another language.
Going the other way and adding AppleScript to Objective-C apps is harder and generally a one-way street, and the alternative of using Scripting Bridge to script apps using Objective-C syntax looks a less than pleasurable experience.
Even if you know and prefer Objective-C, IMO hybrid AppleScriptObjC apps are the way to go for when the aim is to control other apps.
Thanks for the opinions. I feel a bit like most of what I knew is ASS is now gone, and I’m going to have to re-learn anyway so I might as well learn the real-deal. This doesn’t sound fun, and frankly, I wish they’d left ASS alone, it was a great, quick and easy tool for what I needed to do 90% of the time. I guess I’m still unclear why ApplescriptObjC is better than just using NSAppleScript within ObjC when you need to run some AS code. Is it just easier to move variables around? It seems like the speed advantages of ObjC would quickly become worthwhile despite the learning curve. Believe me, I’d much rather stick with Applescript, but it seems like what we have now is just a hacked jumble of 2 languages rather than an easier solution. You pretty much have to understand how ObjC works in order to use ApplescriptObjC, so why make your program run slower using ApplescriptObjC?
Shane, you’ve clearly embraced this platform, and you obviously know ObjC as well, can you give a couple real-world examples where ASObjC would be a better choice than ObjC, and why? I just want to understand the merits and/or shortcomings of the language before I devote the time to really learn it. Trying to learn both is proving to be too confusing, so I need to pick which path to head down in the short term. Thanks.
I’m also from those three worlds and hopefully I can clear that answer for you as well. First of all they never had to deprecate ASS because it was the perfect prototyping IDE for the mac.
The choice of a programming language is first of all, what does it has to do. You’ve asked for some examples:
¢ GUI for a bunch of shell scripts like maintenance tools (*applescriptObjC, ObjC)
¢ xmlrpc or a soap client (*applescriptObjC, Objc)
¢ library for OS X and/or iOS (ObjC)
¢tool who sends data from one application to another (*applescriptObjC, ObjC)
¢ tool to expand user options inside an application (*applescriptObjC, ObjC)
¢ game (ObjC/*C++) for performance games objc is only used for showing the results of the renderer on screen
¢ buidling a command line utility (C/*C++/ObjC)
¢ Making document based file editor like text edit (applescriptObjC/ObjC)
( is the language I prefer if there is a choice)
I preferred applescriptObjC mostly above ObjC but If you already know you’re going to subclass an NSCell (to have a source view/sidebar for example) I prefer ObjC above applescriptObjC. As long as you’re using standard cocoa objects and use cocoa bindings for data sources, applescriptObjC is a good candidate. When I want an interface like in iCal or iTunes I prefer ObjC because the handling inside a subclass is way faster and your application will stay more responsive.
ApplescriptObjC or ObjC are both easy to learn but it is the cocoa framework you’ve to understand and not the language. So when you first learn applescriptObjC you will learn in a very short time ObjC afterwards.
I’ll add my perspective: I work on Prepress. I have to make a lot of scripts and workflow applications that drive InDesign, Photoshop, FileMaker, Interarchy, Acrobat Distiller. Straight ObjC simply cannot effectively, well let me say efficiently, handle talking to all those apps. Sure I’ve used NSApplescript to do a short line of code here and there in ObjC apps. But most of my apps are mostly driving other apps, and pulling files from our network servers, opening InDesign files, outputting PDFs etc. My apps used to be be just ASStudio, but I’ve converted them to ASOC. It was hard with some, but the benefits are usually improved speed, plus I do get some more functionality with the ObjC part, in a very easy to integrate way.
As others said, it depends what you need. If you don’t need to drive other applications, if your app is “stand alone” then you don’t need Applescript so much. But I simply cannot replicate my applications (and be able to do any sort of sane debugging) without the Applescript part.
I have been following this thread with interest. Like evandau, I too was dismayed to learn that ASS had been depreciated in OS X.6. I have worked with Applescript since the OS 7 days and I have used ASS since its inception. A couple of years ago, when I still had a “desk” job, I began teaching myself ObjC. No simple task in my opinion.
For me the biggest issue with the switch to ASOC is locating the documentation that I need to complete a given task. With ASS virtually everything I needed was in the same doc. With ASOC it seems (to me) that the info I need is spread out over various docs making finding what I need a challenge.
I have just recently completed my first working application using ASOC. It still needs “idiot proofing” as I call it and I’m going to add some “bells and whistles” as a means of learning more about ASOC. I started the app. (a utility I’ll use in my job as an over-the-road truck driver) last summer and kept putting off finishing it. When I got my new computer I took up the task of finishing the app. I decided to start over, embracing ASOC. I found the process frustrating at first but as I continued it has become easier. I still have a ways to go before I’m comfortable with ASOC but I’m gaining on it.
As an aside, it could be that Apple decided to depreciate Applescript Studio because of its acronym: ASS :lol:
Well one job I did recently involved exporting an XML file describing the contents of some InDesign documents. Being able to intermingle code getting info from InDesign with code building an NSXML document, rather than either jumping from AS to Objective-C and back all the time, or more likely building some record structure in AS to hold the info and then having to unravel it again in Objective-C, was a huge time (and sanity) saver.
Even for little things. You might be doing something with an app, and you want to sort a list, or capitalize a word, or filter a record – they’re all things that are hard to do in native AS, but easy to do in Cocoa.
In fact I’ve done a few droplets lately just in AppleScriptObjC, and I’ve written them outside Xcode. They’ve been 95% straight AppleScript, with just small sections of Cocoa stuff to do the bits that either AS can’t do or takes too much effort to do.
The other point is that many of us have a lot of AS experience, which makes AppleScriptObjC more comfortable. And it definitely simplifies things: we can just deal in integers and reals, for example, without having to worry about ints, floats, doubles, longs, NSIntegers, CGFloats, NSNumbers, etc.