I've found AppleScript to be confusing and cumbersome to write especially when switching gears from writing traditional code.
"tell application "iChat" to set status message to "not that hard after all"" _is_ cumbersome. When coding I read my code like a sentence, and fill in the blanks naturally. AppleScript is too verbose and requires someone to actually write out the words a coder would naturally just say in their head.
I'm not saying this is a failing of AppleScript, just the opposite its a feature, but I can see why someone who spends time working on a image editing program in Objective-C would find AppleScript cumbersome.
John C. Welch
· 3 months ago
you're not who high-level languages are designed for. in fact, you're the exact opposite of who they're designed for. high-level languages are not for people who write applications and drivers and operating systems. if they were, only you folks would use them, and the rest of us would demand you add in an infinite set of features, because we'd have no way to do things beyond what you allow us to do in the code.
(also, considering that C and dot syntax are newcomers to programming, the idea of them being traditional code is funny shit. you want tradition, read COBOL code.)
The point of a high-level language is to make it so that someone can create some minor solution that uses two applications they use all the time, to do something neither application does. i write scripts for iWork to talk to E'rage, because apple won't ever give me that functionality for any application other than mail, and i'll use webmail before I use Mail, i fucking hate that stallsconstantly code.
thanks to Apple not deciding that because AppleScript isn't Obj-C, i don't have to be pissed off that I can't do what I want, and instead wrote a few short scripts that let me get shit done MY way. Now, if you'd rather not let users come up with their own solutions, and force them to bother you with shit forever and ever, because they can't be inventive unless they learn a language YOU approve of, be my guest. But i'd hope you have better things to do with your life than try to add every feature every user thinks of.
oh, and FYI:
tell application "iChat" to set status message to "not that hard after all" has 75 characters [[SBApplication application:"iChat"] setStatusMessage:"not that hard after all"]; has 81 characters
so if you're trying to argue that the Obj-C version is less verbose, you're not doing a good job, when it requires more typing to do the precise same thing. It's that you like Obj-C better, and will put up with some of the truly archaic shit it forces on you, because you're so used to it, you don't even think about it anymore. (seriously, it's 200-fucking-9, and compilers are still to fucking stupid to be able to tell the end of a line without a fucking semi-colon?)
let's not even get into the stuff that a higher level language gets for free over a lower level one. As a scientist i worked with said: "Sure, C will do my compute runs 3-5x faster than Fortran, no doubt. But, i'll spend almost all of that saved time dealing with bounds checking and other things that I get in Fortran for free, because it's designed to do what I need it to do. if the run takes longer, i don't care, because while it's running, i can do other shit. like write more code. if i'm writing code, all i can do is write code. So there's not a lot of advantage to C in my case"
AKA life is too short to allocate memory manually.
Coleman Nitroy
· 3 months ago
I think you _completely_ _completely_ missed what I said and your rant about compiled languages is completely off base.
"I'm not saying this is a failing of AppleScript, just the opposite its a feature, but I can see why someone who spends time working on a image editing program in Objective-C would find AppleScript cumbersome."
I agree with you that I am not who these languages are designed for, but that is why implementing or even just working with AppleScript is difficult and cumbersome for the ones making the applications.
John C. Welch
· 3 months ago
not to be blunt, but i'm not paying for software to make me into a programmer. i'm using software to get work done. if your software won't play nice, or easily with others, then why the hell should i buy another sandbox?
do objective-c coders like applescript? i don't care. i don't like a lot of things, but i see the value in them for others. if a dev can't do the same, why do i want to give them money or time.
Coleman Nitroy
· 3 months ago
You yourself even say "life is too short to allocate memory manually". From many devs eyes we see "life is too short to deal with implementing AppleScript."
You are going to script the apps, but a thousand other users will use the application as is. Why should I spend time dealing with something awkward and unrewarding to me for the sake of a few?
John C. Welch
· 3 months ago
using that logic when the Acorn dev IMPLEMENTED HIS OWN SCRIPTING IMPLEMENTATION JUST BECAUSE HE DIDN'T WANT TO DO IT THE WAY APPLE RECOMMENDED THAT STILL WOULD HAVE GIVEN HIS USERS ACCESS TO FUCKING JAVASCRIPT AND PYTHON, ALONG WITH RUBY AND APPLESCRIPT FOR THE SAME AMOUNT OF WORK is kind of, no, way, really FUCKING STUPID.
because at some point, everyone wants their application to sell more, and to sell more, you have to start breaking out of the individual user into business use. even small businesses have workflows, and at some point workflow means YOUR application has to work well with OTHERS. the way the USER, you know, the people who PAY YOU expect it to. It's a little hypocritical for you to rag on creating an OS-Standard scripting implementation when you'd be one of the first people bitching if the standard keyboard shortcuts didn't do what you expect them too. Same thing, different label.
Especially with image editing applications, if you work with them in a business setting, or even at home, you start to realize there's a lot of fucking repetition there. sure, as long as you never, ever, ever do anything outside of the application, you can implement automation however you want. But as soon as someone wants to dump a lot of images into Acorn, and then zip them up and mail them out, well, they're kind of fucked. they have to hope there's an automator action to do it, or they have to write their own automator actions, because that's the only even vaguely easy way to connect Acorn to the rest of the OS, and while Automator is indeed nice, it's also quite limited. When you give an application a proper, standard, scripting implementation, you allow others to do things with it you'll never think of, because you aren't them.
But hey, why should you want anyone to use your app in any manner than what you allow them to? fuck scripting, point and click was good enough for you, it's good enough for everyone else.
Also, you do realize there's a HUGE difference between setting up a scripting implementation that works well with rest of the OS and applications, and writing Applescript right? You DO know that you can script applications with other languages along with AppleScript, right? because you know, if you didn't know that this had been going on for years, and Apple had done a lot of work to make it happen, you'd look pretty goddamned silly.
Wait, are you one of those people who think that to write Cocoa applications, you HAVE to use Objective-C?
Coleman Nitroy
· 3 months ago
Sorry to have made you so mad, and yes I know there is a difference between writing and implementing, and no I'm not one of the pure Obj-C people, but thanks for making a bunch of assumptions.
John C. Welch
· 3 months ago
What, i have to read your mind too? You don't want me to think that you're thinking blah, then don't write things that way.
The difference between the pro devs and the guys who just make you pay for their stuff is that the pro devs put in stuff for the minority the way they should. I know for a fact that Wil Shipley has his issues with the way Apple wants you to do scripting implementations, because i've been in the room when he rightfully excoriated the core AppleScript team over those issues.
But if everyone starts writing their own scripting *implementation*, even if they use the same languages...shit you think it's bad now?
ccgus
· 3 months ago
I probably should have clarified in my blog post- but what I meant was that I found implementing AppleScript support in my apps to be cumbersome. Ever tried it?
John C. Welch
· 3 months ago
i've been working with mac devs on AppleScript issues since Cocoa only came in little paper packets. you ever try to implement AppleScript in OS 9? If you want to play that game, i spent a few years implementing database and IVR systems for F500 and larger companies in a 4GL that makes Xcode look like a toy from a getting work done POV. i've been in this game a long damned time, i know that it's not always easy.
However, that's what people spend money on Acorn for. you doing the hard programming work, so they can do equally hard work that happens to be different.
I'm well aware of the fact that implementing an automation framework isn't easy, but there's no way in hell i'm going to spend not inconsiderable time dealing with throwing ropes over an unecessary sandbox when there are a gob of image editing applications that play well with others. Some are more expensive than Acorn, some are not.
As well, again, did you ever actually try to get some help with the implementation, or ask for help on examples? someone wants help with a dictionary, i'm MORE than happy to do so, because in the end, it benefits me, and a lot of other people.
I have no doubt that i can do anything i would want to do in AppleScript in JSTalk. the problem occurs when i try to merge that code into workflows with other applications, which, as you state, is not easy at all once you get beyond simple statements, and if i'm reading what you wrote correctly, it requires:
javascript in Acorn AppleScript in the other applications Objective-C to bridge the two together
i'm glad JSTalk makes your life easier, but it stops being less cumbersome two seconds after you get outside of Acorn. That's part of what you're missing. By trying to avoid the "cumbersome" nature of a single language, you've created a completely different set of cumbersome issues, but because they're in languages you approve of, you don't see them. You've also created a lot of work for yourself, at least potentially. What happens when enough people want to script Acorn in Ruby? Well, if you implement your scripting the way Apple suggests, you don't really have to do anything, there's support for that in the OS. Ruby, Python, AppleScript, Objective-C, even Javascript, (to a lesser extent), are all supported in the OS now.
By rolling your own to avoid one issue, (and there's a lot of help with this stuff at all levels), you end up causing yourself as many problems as you think you're avoiding.
MarkKeith
· 3 months ago
i spent a few years implementing database and IVR systems for F500 and larger companies in a 4GL that makes Xcode look like a toy from a getting work done POV
uh... did I miss something on your resume? To date what I have seen you write about fall into the bucket of productivity enhancers and IT maintenance automation. Please enlighten on these big development projects? Did you have opportunity to do the requirements elaboration, architecture, detail design documentation, and formal qualification testing for major projects?
John C. Welch
· 3 months ago
From 1995 until 1997, I worked for a company that was an outsourcer for IVR applications built on the Edify Electronic Workforce platform, an (at the time) OS/2-based system that used a fully-graphical, zero-code 4GL environment to build IVR, and later web applications that tied Phone, Web, and various database systems together.
Our most common application was open enrollment, but we also did some benefits selection applications, an online job application system, and some rather extensive internal applications for a few insurance company.
The largest single client was probably Blue Cross/Blue Shield, but other companies I did work for were Allmerica, The New England, Exquifax and some others. (It's been over a decade, and I used that time to realize I hate full-time programming, so the details are a little musty).
I was directly involved in all stages of implementation and planning, since I was one of two programmers, and the sole systems integration person. Fun shit, like DB2, DBase, Oracle, lots of 3270 screen scraping, a little 5250 work, almost no Unix, (shame too, but we never had a client that used it in the areas we set our systems up in), lots of Novell networks, some NT4 and TCP/IP.
anything else?
MarkKeith
· 3 months ago
Hmmm.. applications that controlled enrollment data huh... what was that saying about helicopters "I used to be afraid to fly in helicopters.. now that I know how they work I am afraid when they fly overhead..". Yeah that is the feeling. Open enrollment is in January.... Be afraid.
John C. Welch
· 3 months ago
oh those sucked so bad. same application with only voice prompt changes, and every.damned.client had some way to deal with alpha entry that was SO much better than the pre-built way I had set up that took zero time to implement. headdesk.
and for what were really nothing applications, dear lord, the amount of crap you had to put up with, as though the entire free world was depending on this application, and if the voice prompts weren't PERFECT no one would ever have insurance coverage EVER AGAIN!!!!
that more than anything showed me that as a programmer, i'm a kick-ass sysadmin. i can be patient, but not THAT patient.
MarkKeith
· 3 months ago
I thank God for my sysadmins every day (okay some days). In the places where the free world really does depend on the work of programmers management almost always tends to hire programmers and layoff all the sysadmins... any good programmer can be a sysadmin right? we all know how well THAT works.
J.C.Burns
· 3 months ago
I'm definitely the guy who high-level languages were designed for and I migrated from HyperTalk to Apple Events to AppleScript and hung in there with it and actually have done some 'sophisticated' (?) things with it...but what's cumbersome about AppleScript to me is the UNCERTAINTY. Is it 'set status message to' or is it 'set text of status message to' or is it 'set property:status of window 1 to"...jeez o petes. There is, it seems, only one or two "right answers", and a bunch of wrong ones. The closer you get to the object model Cocoa apps are written in, the balance seems to reverse—there are a lot of right ways and fewer infuriations (give or take a bracket.)
That's why I've been trying to learn more and more about purer manifestations of Cocoa, and because I come at it from a webdev/HyperCard stack/geezer standpoint, the tools that are opening doors for me are Philippe Mougin's F-Script and Gus's JSTalk, incorporating Patrick Geiller's JSCocoa stuff.
These are bright lights shining into the innards of AppKit and the Obj-C runtime for me.
And Acorn (again, me coming from Quantel Paintboxes through Photoshop 1.0 to here) is really elegant, and built to build on not just with JSTalk but Python and Javascript and so on. And it launches in the blink of an eye. So, me, I want to encourage development like that. How about you, John?
John C. Welch
· 3 months ago
an application that launches fast is nice. but honestly, launch time rates up there with scroll speed tests. who cares.
an application that launches slower, but lets me use it better, in ways the dev might not have thought about, in the way i want to? I can live with a slower launch time for that. Entourage always launches slower than Mail, but its scripting dictionary and scriptable feature set is SO much better than Mail's that it's not even close. That's a HUGE reason why i use E'rage. Because the devs did that extra work, (and this is a CARBON application. you think setting up AS in cocoa is hard? shit, you don't know hard), i can use E'rage in all kinds of neat ways that i can't use Mail.
Oh, and it's not like a proper scripting implementation forces you into AppleScript, not any more. you can also use Ruby, Python, and even JavaSCript too. the difference is, you have to do it the right way.
the advantages to this are going to be even cooler with AppleScriptObjC, which finally does what ASS was supposed to, and make AppleScript a true peer with Python, Ruby and even Objective-C in cocoa.
So no, as it stands, Acorn's of no use to me, regardless of launch time and feature set.
philipregan
· 3 months ago
John, you are absolutely spot on here. I work in prepress and book publishing, and I live on fully scripted workflows. I'm currently in the market for a Photoshop replacement for home use (my needs are humble at home and I loathe Adobe), but Acorn just took themselves out of the running with this nonsense. My Applescript workflows usually combine other applications (both commerical and home-grown), and Acorn has completely isolated itself here. (Just as a point of disclosure, I also do work in Objective-C and REALbasic. Use the right tool for the job, as they say).
elgallorojo
· 3 months ago
John is so fucking correct. I'm in prepress and magazine database publishing, and Applescript is the only thing non-computer scientists can use to implement simple but effective custom workflows.
sdfisher
· 3 months ago
I might have used AppleScript support, but I can't imagine ever using JSTalk. Too bad.
Watts Martin
· 3 months ago
Certainly, Acorn should have an OSAScript dictionary and be done with it. (Wasn't the point of "OSA" to theoretically allow other scripting languages to be peers to AppleScript so anybody could script with anything they wanted? Whatever happened to that?) But AppleScript *isn't* a particularly good programming language even for "casual programmers." Sure, if you're comparing it to something like Frontier, AppleScript is a godsend, but Frontier makes sane people want to jam fondue forks up their noses to relieve the pain.
It's not AppleScript's verbosity that chaps me, it's the arcane maze of twisty little phrases, like "name of selected member of first chat room panel." And how many casual programmers, when faced with the error "expected end of line but found class name" (what Colloquy gives you with the construct above) are going to deduce that what AppleScript is really telling you is "Colloquy didn't bother to implement 'selected' in its OSA dictionary, so suck it?" AppleScript provides a great *illusion* of cuddly user friendliness, but it's got more sharp edges than a cutlery store.
John C. Welch
· 3 months ago
that's because AppleScript is still programming and all programming has sharp edges. However, a lot of AppleScript's verbosity comes from people who don't learn the language well, and so don't learn the myriad tricks to trim the verbosity down, or you get badly implemented dictionaries done by people who don't know a property from an element and won't bother to bloody ask.
Dean Shavit
· 3 months ago
AppleScript will never be on the same level playing field as Cocoa - it's not even directly supported by ADC - it's a product of a small group within Apple, but a group with a huge footprint and lots of influence and fantastic communities behind it. I've done a lot with AppleScript and Studio and I am currently on the fence about whether I should move to AppleScriptObjC or just skip it and use Cocoa directly - and not for any technical reason, but for support. I am not happy that my ADC membership doesn't cover anything AppleScript - related. Now if that were the reason Gus eschewed AppleScript in favor of JSTalk, I'd understand, but it seems he's made a business decision that the attention from this "AppleScript SUX" kerfuffle far outweighs the actual usefulness OSA scriptability would bring. Not only that, I'm unsure of where I'd get support for a JSTalk implementation as it seems far less proven that AppleScript, and where's the JSTalk community? When it's one *one thousandth* the size of MacScripter.net, I might take it seriously. Which tells me a couple of things:
1) Some Indie developers some call "Webkitties" are apparently trying to badmouth AppleScript to try and topple it from its favored niche of being the programming language for "the rest of us". It seems that they've been targeting mindshare of other programmers rather than $$ from real users. The prepress world? They're not interested - not until HTML and JavaScript replace PostScript and AppleScript - 'cause that's what they know - and they don't acknowledge what they don't know, apparently.
2) It follows that Acorn doesn't have many users who use it to do billable work, or possibly those that use it are using it to make a point and support their friend Gus. I have GraphicConverter, GIMP, SeaShore, Fireworks, etc. and they do the job. I got Pixelmator with a bundle and I hardly ever open it. I downloaded and launched Acorn a few times, but I don't have the free time to learn/evaluate a tool I use once or twice a month.
3) Maybe Acorn is affiliated with the other Acorn - declaring itself to be one thing, but with an ulterior motive. I hope Gus stays out of trouble. He gave me a T-shirt once, and I really like it.
Dori
· 3 months ago
Ummm... my 2¢, from an entirely different angle:
- I hate AppleScript. I hated AS long before JavaScript was invented. After way too much effort, I came to the conclusion that no one ever really learns AS; instead, you learn AS for a single application. And then you have to learn it again for another app. And then again for a third. And then when you go back to the first code you wrote, you can't remember which of the various dialects it uses, so you have to start all over again.
- I like JavaScript. Over the last dozen-plus years, it's been very good to me. Some days, I even feel like it likes me back.
- I've never learned Cocoa, 'cause I don't do that kind of programming. I'm sure I could learn it, but I'd need to either have someone paying me to do it or give me a promise of paying work at the end of it [1]—as it is, life is too short to learn everything I'd like to learn.
Which gets me to:
- JSTalk, from the little I've looked at it, ain't JavaScript. Or at least the examples I'm seeing ain't JavaScript.
For instance:
AppleScript: tell application "iChat" to set status message to "not that hard after all" JSTalk: [[SBApplication application:"iChat"] setStatusMessage:"not that hard after all"]; JavaScript: iChat.status = "not that hard after all";
[of course, that would be assuming that iChat (or any of Apple's apps, for that matter) actually understood JavaScript.]
Looking further at those JSTalk examples, I'm pretty confident in saying that this might be the way a Cocoa programmer sees JavaScript, but no one who works primarily with JavaScript would be able to make heads or tails of it without a lot of Cocoa background (in which case, why are they working primarily with JavaScript?).
FWIW, I wrote the JavaScript code for "The Designer's Apprentice: Automating Photoshop, Illustrator, and InDesign in Adobe Creative Suite 3" by Rick Ralston. He wrote the book around AppleScript, but marketing wanted the examples to also be supplied in JavaScript (because unlike AS, it's cross-platform).
Yay for JS: I found I was pretty much always able to write the same code in considerably fewer lines. Plus, cross-platform! Yay for AS: I couldn't do most of the application to application (or any of the OS to application) code in JS, because the support just isn't there (yes, I do understand that this is the workflow issue in a nutshell).
But in terms of comparing apples to apples: when I had two code snippets that did the same thing, I always found the JS one to be both more understandable and more maintainable. JSTalk, though, appears to be neither.
[1]: If you know of anyone making this kind of offer, please put me in touch with them!
John C. Welch
· 3 months ago
I hate AppleScript. I hated AS long before JavaScript was invented. After way too much effort, I came to the conclusion that no one ever really learns AS; instead, you learn AS for a single application. And then you have to learn it again for another app. And then again for a third. And then when you go back to the first code you wrote, you can't remember which of the various dialects it uses, so you have to start all over again.
that's application-specific scripting period. Javascript will no more avoid that than AppleScript. you can't use the exact same terms for word that you would for illustrator that you would for keynote. they're different things. Once you do it for a while, you realize that the better implementations try to not go too far into neverland, but if you're automating a function that doesn't exist anywhere else, you're creating application specific terms, period. thus far, other than Adobe, i'd say 99% of all Javascript revolves around the same application: the web browser, and even then, you can't trust firefox, safari or IE to do things exactly the same with the same code. the odds are better, because their base functions are identical, but they still manage to push you into situations where you have to create custom code for this or that browser.
Yay for JS: I found I was pretty much always able to write the same code in considerably fewer lines. Plus, cross-platform!
considering the obsessive way I comment, lines of code is a bad measurement for me:-), but dot languages are more efficient if properly implemented. the problem for me is that they never do the order the same way between languages, and to me, all dot languages are pretty much the same.
i think 99% of the language wars are people who don't want to admit that functionality being equal, language choice is like input device choice: very personal and highly subjective.
Yay for AS: I couldn't do most of the application to application (or any of the OS to application) code in JS, because the support just isn't there (yes, I do understand that this is the workflow issue in a nutshell).
Apple's been getting better in the last couple of OS releases about making scripting implementations language neutral. the real issue is that as far as I know, the only person making an OSA implementation for JavaScript is Late Night Software, and while it is a Universal binary, i don't know if it's been updated for snow, but i think it's been somewhat dormant since the 2.0.2 release. Still, you might want to take a look at it.
But in terms of comparing apples to apples: when I had two code snippets that did the same thing, I always found the JS one to be both more understandable and more maintainable. JSTalk, though, appears to be neither.
jstalk is like a javascript version of AppleScriptObjC, at least from what I can see. it's designed more to let you build cocoa applications with JS than to let you use JS instead of AppleScript for OSA-type stuff.
Dori
· 3 months ago
that's application-specific scripting period. Javascript will no more avoid that than AppleScript.
Keep in mind that "application-specific scripting" is what most first-time scripters are trying to do. That's why they get frustrated so quickly, because what they learned from trying to script app a doesn't apply when they try to learn to script app b.
JavaScript, unlike AppleScript, does have some ways to avoid that. One way is what Adobe's got buried under the hood of the CS suite: a full JavaScript IDE and debugger. Another is that few people are trying to JavaScript applications as their first project; instead, they get comfortable using it inside the browser sandbox, and only then do they want to do more with it. Lastly, there are plenty of solid free frameworks out there, and they make doing things cross-browser much simpler than it was just a few years ago. I suspect that if more apps were JavaScript-able, at least a few of the frameworks would be extended to cover apps darn quickly (I recommend jQuery, btw).
the only person making an OSA implementation for JavaScript is Late Night Software, and while it is a Universal binary, i don't know if it's been updated for snow, but i think it's been somewhat dormant since the 2.0.2 release. Still, you might want to take a look at it.
Oh, I've been keeping an eye on JavaScript OSA for... yowza... nearly a decade. The last release I can find was 2.0.1, which came out in November 2006. The last time Mark answered a question on the JSOSA list was August 2007. If it's not dead, it's doing a darn good impression of it (sadly!).
jstalk is like a javascript version of AppleScriptObjC, at least from what I can see. it's designed more to let you build cocoa applications with JS than to let you use JS instead of AppleScript for OSA-type stuff.
No—this is exactly what I'm saying is not true. JSTalk is like a version of AppleScriptObjC done by someone who, once, back in the 90s, may have seen some JavaScript code. Or maybe they just heard a year or so ago that JavaScript was hot again, so they claimed what they were doing was somehow related to JavaScript (why, that sounds just like what happened to LiveScript...).
But whatever it is, it is not JavaScript. The syntax is different, the style is different... Oh hell, here's another example:
AppleScript: set o to make new box with properties {height:100, width:100, xPos:100, yPos:100, stroke:10}
JSTalk example 1: var sketch = [JSTalk application:"Sketch"]; var doc = [sketch orderedDocuments][0] var rectangle = [doc makeNewBox];
JavaScript: var theCanvas = document.getElementById("myCanvas").getContext("2d"); theCanvas.lineWidth = 10; theCanvas.strokeRect(100,100,100,100);
As I said, I just don't see any similarity between the code in the JSTalk example (either version) and that in the JavaScript example.
If someone loves Cocoa, fine; they can go ahead and implement CocoaScript (or whatever they want to call it). But they shouldn't claim that it has any relationship to JavaScript when it doesn't.
John C. Welch
· 3 months ago
Keep in mind that "application-specific scripting" is what most first-time scripters are trying to do. That's why they get frustrated so quickly, because what they learned from trying to script app a doesn't apply when they try to learn to script app b.
it does more than they think. the problem is, a lot of people don't want to think that AppleScript is programming and you have to learn how the language works, whereas with a dot language It Is Clearly Programming And You Must Treat It Seriously.
JavaScript, unlike AppleScript, does have some ways to avoid that. One way is what Adobe's got buried under the hood of the CS suite: a full JavaScript IDE and debugger. Another is that few people are trying to JavaScript applications as their first project; instead, they get comfortable using it inside the browser sandbox, and only then do they want to do more with it. Lastly, there are plenty of solid free frameworks out there, and they make doing things cross-browser much simpler than it was just a few years ago. I suspect that if more apps were JavaScript-able, at least a few of the frameworks would be extended to cover apps darn quickly (I recommend jQuery, btw).
so does applescript, and if a team puts some time into the dictionary, the differences are mitigated more than you think. the problems really hit when the dictionary is poorly done, or they never fix a fucking bug, (MAIL TEAM, I AM LOOKING AT YOU). but no language will prevent that.
as far as Adobe goes, well, they're really consistent with their AppleScript too, (Except for the Acrobat team, but they're a bunch of cockwads, so fuckem), because they know what their apps are going to do, and can design accordingly. The big 3 of CS have really solid dictionaries. Comes from paying attention.
But Adobe doesn't mean that everyone else will do the same. someone writing a shit dictionary is not going to have those problems go away because the amount of dots in the language goes up. if the implementation is crap, the language isn't going to save it. If the implementation is good, the language isn't going to ruin it.
You can't hold up the "people who would use Javascript for AppleSCript tasks already know JavaScript and so you'd avoid a lot of the problems" because that's a false equivalency. Of course they're comfortable scripting browsers. What *else* do they have to do? Well, CS. that's about is. Adobe and browsers. Yes there are really nice frameworks, but at the end of the day, the difference between scripting IE, Safari, Firefox, Opera and Omniweb are a *rounding error* compared to the differences between scripting InDesign, Excel, Keynote, and OmniOutliner. If the only differences you have to deal with when you're scripting completely different applications was the IE vs. everyone else differences, it'd be friggin' cake.
Saying that because it's easy to script browsers, that scripting wildly different applications will be just as easy is going way out on a pretty shaky limb.
Also, keep in mind that for your example, you need to add the line to tell the OS what application your script is targeting. i know, i know, it's maybe one more line, but for comparison purposes it counts, and considering that you want a script targeting application A to be able to target Application B from within Application A's target block, it's important to keep that in mind. To be fair, i should have put that in the AppleScript example, and it would add between 0 and 2 lines.
to be honest, that's really kind of a setup example, in that it was done by someone who not only really doesn't understand AppleScript, but doesn't really get JavaScript either, and tries to make both into some creepy version of Objective-C.
jacek1234567889
· 1 week ago
heh, you're right. i heard gus talking in some podcasts. he sounded to me like a clueless jerk.
All Comments
"tell application "iChat" to set status message to "not that hard after all"" _is_ cumbersome. When coding I read my code like a sentence, and fill in the blanks naturally. AppleScript is too verbose and requires someone to actually write out the words a coder would naturally just say in their head.
I'm not saying this is a failing of AppleScript, just the opposite its a feature, but I can see why someone who spends time working on a image editing program in Objective-C would find AppleScript cumbersome.
(also, considering that C and dot syntax are newcomers to programming, the idea of them being traditional code is funny shit. you want tradition, read COBOL code.)
The point of a high-level language is to make it so that someone can create some minor solution that uses two applications they use all the time, to do something neither application does. i write scripts for iWork to talk to E'rage, because apple won't ever give me that functionality for any application other than mail, and i'll use webmail before I use Mail, i fucking hate that stallsconstantly code.
thanks to Apple not deciding that because AppleScript isn't Obj-C, i don't have to be pissed off that I can't do what I want, and instead wrote a few short scripts that let me get shit done MY way. Now, if you'd rather not let users come up with their own solutions, and force them to bother you with shit forever and ever, because they can't be inventive unless they learn a language YOU approve of, be my guest. But i'd hope you have better things to do with your life than try to add every feature every user thinks of.
oh, and FYI:
tell application "iChat" to set status message to "not that hard after all" has 75 characters
[[SBApplication application:"iChat"] setStatusMessage:"not that hard after all"]; has 81 characters
so if you're trying to argue that the Obj-C version is less verbose, you're not doing a good job, when it requires more typing to do the precise same thing. It's that you like Obj-C better, and will put up with some of the truly archaic shit it forces on you, because you're so used to it, you don't even think about it anymore. (seriously, it's 200-fucking-9, and compilers are still to fucking stupid to be able to tell the end of a line without a fucking semi-colon?)
let's not even get into the stuff that a higher level language gets for free over a lower level one. As a scientist i worked with said: "Sure, C will do my compute runs 3-5x faster than Fortran, no doubt. But, i'll spend almost all of that saved time dealing with bounds checking and other things that I get in Fortran for free, because it's designed to do what I need it to do. if the run takes longer, i don't care, because while it's running, i can do other shit. like write more code. if i'm writing code, all i can do is write code. So there's not a lot of advantage to C in my case"
AKA life is too short to allocate memory manually.
"I'm not saying this is a failing of AppleScript, just the opposite its a feature, but I can see why someone who spends time working on a image editing program in Objective-C would find AppleScript cumbersome."
I agree with you that I am not who these languages are designed for, but that is why implementing or even just working with AppleScript is difficult and cumbersome for the ones making the applications.
do objective-c coders like applescript? i don't care. i don't like a lot of things, but i see the value in them for others. if a dev can't do the same, why do i want to give them money or time.
You are going to script the apps, but a thousand other users will use the application as is. Why should I spend time dealing with something awkward and unrewarding to me for the sake of a few?
because at some point, everyone wants their application to sell more, and to sell more, you have to start breaking out of the individual user into business use. even small businesses have workflows, and at some point workflow means YOUR application has to work well with OTHERS. the way the USER, you know, the people who PAY YOU expect it to. It's a little hypocritical for you to rag on creating an OS-Standard scripting implementation when you'd be one of the first people bitching if the standard keyboard shortcuts didn't do what you expect them too. Same thing, different label.
Especially with image editing applications, if you work with them in a business setting, or even at home, you start to realize there's a lot of fucking repetition there. sure, as long as you never, ever, ever do anything outside of the application, you can implement automation however you want. But as soon as someone wants to dump a lot of images into Acorn, and then zip them up and mail them out, well, they're kind of fucked. they have to hope there's an automator action to do it, or they have to write their own automator actions, because that's the only even vaguely easy way to connect Acorn to the rest of the OS, and while Automator is indeed nice, it's also quite limited. When you give an application a proper, standard, scripting implementation, you allow others to do things with it you'll never think of, because you aren't them.
But hey, why should you want anyone to use your app in any manner than what you allow them to? fuck scripting, point and click was good enough for you, it's good enough for everyone else.
Also, you do realize there's a HUGE difference between setting up a scripting implementation that works well with rest of the OS and applications, and writing Applescript right? You DO know that you can script applications with other languages along with AppleScript, right? because you know, if you didn't know that this had been going on for years, and Apple had done a lot of work to make it happen, you'd look pretty goddamned silly.
Wait, are you one of those people who think that to write Cocoa applications, you HAVE to use Objective-C?
The difference between the pro devs and the guys who just make you pay for their stuff is that the pro devs put in stuff for the minority the way they should. I know for a fact that Wil Shipley has his issues with the way Apple wants you to do scripting implementations, because i've been in the room when he rightfully excoriated the core AppleScript team over those issues.
But if everyone starts writing their own scripting *implementation*, even if they use the same languages...shit you think it's bad now?
However, that's what people spend money on Acorn for. you doing the hard programming work, so they can do equally hard work that happens to be different.
I'm well aware of the fact that implementing an automation framework isn't easy, but there's no way in hell i'm going to spend not inconsiderable time dealing with throwing ropes over an unecessary sandbox when there are a gob of image editing applications that play well with others. Some are more expensive than Acorn, some are not.
As well, again, did you ever actually try to get some help with the implementation, or ask for help on examples? someone wants help with a dictionary, i'm MORE than happy to do so, because in the end, it benefits me, and a lot of other people.
I have no doubt that i can do anything i would want to do in AppleScript in JSTalk. the problem occurs when i try to merge that code into workflows with other applications, which, as you state, is not easy at all once you get beyond simple statements, and if i'm reading what you wrote correctly, it requires:
javascript in Acorn
AppleScript in the other applications
Objective-C to bridge the two together
i'm glad JSTalk makes your life easier, but it stops being less cumbersome two seconds after you get outside of Acorn. That's part of what you're missing. By trying to avoid the "cumbersome" nature of a single language, you've created a completely different set of cumbersome issues, but because they're in languages you approve of, you don't see them. You've also created a lot of work for yourself, at least potentially. What happens when enough people want to script Acorn in Ruby? Well, if you implement your scripting the way Apple suggests, you don't really have to do anything, there's support for that in the OS. Ruby, Python, AppleScript, Objective-C, even Javascript, (to a lesser extent), are all supported in the OS now.
By rolling your own to avoid one issue, (and there's a lot of help with this stuff at all levels), you end up causing yourself as many problems as you think you're avoiding.
uh... did I miss something on your resume? To date what I have seen you write about fall into the bucket of productivity enhancers and IT maintenance automation. Please enlighten on these big development projects? Did you have opportunity to do the requirements elaboration, architecture, detail design documentation, and formal qualification testing for major projects?
Our most common application was open enrollment, but we also did some benefits selection applications, an online job application system, and some rather extensive internal applications for a few insurance company.
The largest single client was probably Blue Cross/Blue Shield, but other companies I did work for were Allmerica, The New England, Exquifax and some others. (It's been over a decade, and I used that time to realize I hate full-time programming, so the details are a little musty).
I was directly involved in all stages of implementation and planning, since I was one of two programmers, and the sole systems integration person. Fun shit, like DB2, DBase, Oracle, lots of 3270 screen scraping, a little 5250 work, almost no Unix, (shame too, but we never had a client that used it in the areas we set our systems up in), lots of Novell networks, some NT4 and TCP/IP.
anything else?
what was that saying about helicopters
"I used to be afraid to fly in helicopters..
now that I know how they work
I am afraid when they fly overhead..".
Yeah that is the feeling.
Open enrollment is in January.... Be afraid.
and for what were really nothing applications, dear lord, the amount of crap you had to put up with, as though the entire free world was depending on this application, and if the voice prompts weren't PERFECT no one would ever have insurance coverage EVER AGAIN!!!!
that more than anything showed me that as a programmer, i'm a kick-ass sysadmin. i can be patient, but not THAT patient.
That's why I've been trying to learn more and more about purer manifestations of Cocoa, and because I come at it from a webdev/HyperCard stack/geezer standpoint, the tools that are opening doors for me are Philippe Mougin's F-Script and Gus's JSTalk, incorporating Patrick Geiller's JSCocoa stuff.
These are bright lights shining into the innards of AppKit and the Obj-C runtime for me.
And Acorn (again, me coming from Quantel Paintboxes through Photoshop 1.0 to here) is really elegant, and built to build on not just with JSTalk but Python and Javascript and so on. And it launches in the blink of an eye. So, me, I want to encourage development like that. How about you, John?
an application that launches slower, but lets me use it better, in ways the dev might not have thought about, in the way i want to? I can live with a slower launch time for that. Entourage always launches slower than Mail, but its scripting dictionary and scriptable feature set is SO much better than Mail's that it's not even close. That's a HUGE reason why i use E'rage. Because the devs did that extra work, (and this is a CARBON application. you think setting up AS in cocoa is hard? shit, you don't know hard), i can use E'rage in all kinds of neat ways that i can't use Mail.
Oh, and it's not like a proper scripting implementation forces you into AppleScript, not any more. you can also use Ruby, Python, and even JavaSCript too. the difference is, you have to do it the right way.
the advantages to this are going to be even cooler with AppleScriptObjC, which finally does what ASS was supposed to, and make AppleScript a true peer with Python, Ruby and even Objective-C in cocoa.
So no, as it stands, Acorn's of no use to me, regardless of launch time and feature set.
It's not AppleScript's verbosity that chaps me, it's the arcane maze of twisty little phrases, like "name of selected member of first chat room panel." And how many casual programmers, when faced with the error "expected end of line but found class name" (what Colloquy gives you with the construct above) are going to deduce that what AppleScript is really telling you is "Colloquy didn't bother to implement 'selected' in its OSA dictionary, so suck it?" AppleScript provides a great *illusion* of cuddly user friendliness, but it's got more sharp edges than a cutlery store.
1) Some Indie developers some call "Webkitties" are apparently trying to badmouth AppleScript to try and topple it from its favored niche of being the programming language for "the rest of us". It seems that they've been targeting mindshare of other programmers rather than $$ from real users. The prepress world? They're not interested - not until HTML and JavaScript replace PostScript and AppleScript - 'cause that's what they know - and they don't acknowledge what they don't know, apparently.
2) It follows that Acorn doesn't have many users who use it to do billable work, or possibly those that use it are using it to make a point and support their friend Gus. I have GraphicConverter, GIMP, SeaShore, Fireworks, etc. and they do the job. I got Pixelmator with a bundle and I hardly ever open it. I downloaded and launched Acorn a few times, but I don't have the free time to learn/evaluate a tool I use once or twice a month.
3) Maybe Acorn is affiliated with the other Acorn - declaring itself to be one thing, but with an ulterior motive. I hope Gus stays out of trouble. He gave me a T-shirt once, and I really like it.
- I hate AppleScript. I hated AS long before JavaScript was invented. After way too much effort, I came to the conclusion that no one ever really learns AS; instead, you learn AS for a single application. And then you have to learn it again for another app. And then again for a third. And then when you go back to the first code you wrote, you can't remember which of the various dialects it uses, so you have to start all over again.
- I like JavaScript. Over the last dozen-plus years, it's been very good to me. Some days, I even feel like it likes me back.
- I've never learned Cocoa, 'cause I don't do that kind of programming. I'm sure I could learn it, but I'd need to either have someone paying me to do it or give me a promise of paying work at the end of it [1]—as it is, life is too short to learn everything I'd like to learn.
Which gets me to:
- JSTalk, from the little I've looked at it, ain't JavaScript. Or at least the examples I'm seeing ain't JavaScript.
For instance:
AppleScript:
tell application "iChat" to set status message to "not that hard after all"JSTalk:
[[SBApplication application:"iChat"] setStatusMessage:"not that hard after all"];JavaScript:
iChat.status = "not that hard after all";[of course, that would be assuming that iChat (or any of Apple's apps, for that matter) actually understood JavaScript.]
Looking further at those JSTalk examples, I'm pretty confident in saying that this might be the way a Cocoa programmer sees JavaScript, but no one who works primarily with JavaScript would be able to make heads or tails of it without a lot of Cocoa background (in which case, why are they working primarily with JavaScript?).
FWIW, I wrote the JavaScript code for "The Designer's Apprentice: Automating Photoshop, Illustrator, and InDesign in Adobe Creative Suite 3" by Rick Ralston. He wrote the book around AppleScript, but marketing wanted the examples to also be supplied in JavaScript (because unlike AS, it's cross-platform).
Yay for JS: I found I was pretty much always able to write the same code in considerably fewer lines. Plus, cross-platform!
Yay for AS: I couldn't do most of the application to application (or any of the OS to application) code in JS, because the support just isn't there (yes, I do understand that this is the workflow issue in a nutshell).
But in terms of comparing apples to apples: when I had two code snippets that did the same thing, I always found the JS one to be both more understandable and more maintainable. JSTalk, though, appears to be neither.
[1]: If you know of anyone making this kind of offer, please put me in touch with them!
that's application-specific scripting period. Javascript will no more avoid that than AppleScript. you can't use the exact same terms for word that you would for illustrator that you would for keynote. they're different things. Once you do it for a while, you realize that the better implementations try to not go too far into neverland, but if you're automating a function that doesn't exist anywhere else, you're creating application specific terms, period. thus far, other than Adobe, i'd say 99% of all Javascript revolves around the same application: the web browser, and even then, you can't trust firefox, safari or IE to do things exactly the same with the same code. the odds are better, because their base functions are identical, but they still manage to push you into situations where you have to create custom code for this or that browser.
considering the obsessive way I comment, lines of code is a bad measurement for me:-), but dot languages are more efficient if properly implemented. the problem for me is that they never do the order the same way between languages, and to me, all dot languages are pretty much the same.
i think 99% of the language wars are people who don't want to admit that functionality being equal, language choice is like input device choice: very personal and highly subjective.
Apple's been getting better in the last couple of OS releases about making scripting implementations language neutral. the real issue is that as far as I know, the only person making an OSA implementation for JavaScript is Late Night Software, and while it is a Universal binary, i don't know if it's been updated for snow, but i think it's been somewhat dormant since the 2.0.2 release. Still, you might want to take a look at it.
jstalk is like a javascript version of AppleScriptObjC, at least from what I can see. it's designed more to let you build cocoa applications with JS than to let you use JS instead of AppleScript for OSA-type stuff.
Keep in mind that "application-specific scripting" is what most first-time scripters are trying to do. That's why they get frustrated so quickly, because what they learned from trying to script app a doesn't apply when they try to learn to script app b.
JavaScript, unlike AppleScript, does have some ways to avoid that. One way is what Adobe's got buried under the hood of the CS suite: a full JavaScript IDE and debugger. Another is that few people are trying to JavaScript applications as their first project; instead, they get comfortable using it inside the browser sandbox, and only then do they want to do more with it. Lastly, there are plenty of solid free frameworks out there, and they make doing things cross-browser much simpler than it was just a few years ago. I suspect that if more apps were JavaScript-able, at least a few of the frameworks would be extended to cover apps darn quickly (I recommend jQuery, btw).
Oh, I've been keeping an eye on JavaScript OSA for... yowza... nearly a decade. The last release I can find was 2.0.1, which came out in November 2006. The last time Mark answered a question on the JSOSA list was August 2007. If it's not dead, it's doing a darn good impression of it (sadly!).
No—this is exactly what I'm saying is not true. JSTalk is like a version of AppleScriptObjC done by someone who, once, back in the 90s, may have seen some JavaScript code. Or maybe they just heard a year or so ago that JavaScript was hot again, so they claimed what they were doing was somehow related to JavaScript (why, that sounds just like what happened to LiveScript...).
But whatever it is, it is not JavaScript. The syntax is different, the style is different... Oh hell, here's another example:
AppleScript:
set o to make new box with properties {height:100, width:100, xPos:100, yPos:100, stroke:10}JSTalk example 1:
var sketch = [JSTalk application:"Sketch"];
var doc = [sketch orderedDocuments][0]
var rectangle = [doc makeNewBox];
[rectangle setWidth:100];
[rectangle setHeight:100];
[rectangle setXPosition:100];
[rectangle setYPosition:100];
JSTalk example 2:
var sketch = JSTalk.application_("Sketch");
var doc = sketch.orderedDocuments()[0]
var rectangle = doc.makeNewBox();
rectangle.setWidth_(100);
rectangle.setHeight_(100);
rectangle.setXPosition_(100);
rectangle.setYPosition_(100);
JavaScript:
var theCanvas = document.getElementById("myCanvas").getContext("2d");theCanvas.lineWidth = 10;
theCanvas.strokeRect(100,100,100,100);
As I said, I just don't see any similarity between the code in the JSTalk example (either version) and that in the JavaScript example.
If someone loves Cocoa, fine; they can go ahead and implement CocoaScript (or whatever they want to call it). But they shouldn't claim that it has any relationship to JavaScript when it doesn't.
it does more than they think. the problem is, a lot of people don't want to think that AppleScript is programming and you have to learn how the language works, whereas with a dot language It Is Clearly Programming And You Must Treat It Seriously.
so does applescript, and if a team puts some time into the dictionary, the differences are mitigated more than you think. the problems really hit when the dictionary is poorly done, or they never fix a fucking bug, (MAIL TEAM, I AM LOOKING AT YOU). but no language will prevent that.
as far as Adobe goes, well, they're really consistent with their AppleScript too, (Except for the Acrobat team, but they're a bunch of cockwads, so fuckem), because they know what their apps are going to do, and can design accordingly. The big 3 of CS have really solid dictionaries. Comes from paying attention.
But Adobe doesn't mean that everyone else will do the same. someone writing a shit dictionary is not going to have those problems go away because the amount of dots in the language goes up. if the implementation is crap, the language isn't going to save it. If the implementation is good, the language isn't going to ruin it.
You can't hold up the "people who would use Javascript for AppleSCript tasks already know JavaScript and so you'd avoid a lot of the problems" because that's a false equivalency. Of course they're comfortable scripting browsers. What *else* do they have to do? Well, CS. that's about is. Adobe and browsers. Yes there are really nice frameworks, but at the end of the day, the difference between scripting IE, Safari, Firefox, Opera and Omniweb are a *rounding error* compared to the differences between scripting InDesign, Excel, Keynote, and OmniOutliner. If the only differences you have to deal with when you're scripting completely different applications was the IE vs. everyone else differences, it'd be friggin' cake.
Saying that because it's easy to script browsers, that scripting wildly different applications will be just as easy is going way out on a pretty shaky limb.
Also, keep in mind that for your example, you need to add the line to tell the OS what application your script is targeting. i know, i know, it's maybe one more line, but for comparison purposes it counts, and considering that you want a script targeting application A to be able to target Application B from within Application A's target block, it's important to keep that in mind. To be fair, i should have put that in the AppleScript example, and it would add between 0 and 2 lines.
to be honest, that's really kind of a setup example, in that it was done by someone who not only really doesn't understand AppleScript, but doesn't really get JavaScript either, and tries to make both into some creepy version of Objective-C.