Disqus - Latest Comments for dorismith

Re: It's still not the language's fault.

jcwelch — Sat, 19 Sep 2009 00:17:30 -0000

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.

Re: It's still not the language's fault.

dorismith — Fri, 18 Sep 2009 21:07:39 -0000

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];

[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.

Re: It's still not the language's fault.

jcwelch — Fri, 18 Sep 2009 19:18:18 -0000

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.

Re: It's still not the language's fault.

dorismith — Fri, 18 Sep 2009 17:40:38 -0000

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!

Re: And the answer to the question is….

dorismith — Fri, 06 Feb 2009 18:48:05 -0000

Congrats, and best of luck! If you need any freelancers, you know where to find me... ;-)

Re: @grossberg Two off the top of …

Dori — Sat, 04 Oct 2008 01:42:14 -0000

Hey, just saw this, and wanted to say thank you for thinking of me in this context. For a gig like The Ajax Experience, I would *definitely* be available. All they have to do is ask--which they've never done.

Dori