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

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: dev tools [was: Re: What makes AppleScript COOL!]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dev tools [was: Re: What makes AppleScript COOL!]


  • Subject: Re: dev tools [was: Re: What makes AppleScript COOL!]
  • From: has <email@hidden>
  • Date: Mon, 10 Dec 2007 17:43:06 +0000

John C. Welch wrote:

Every application API is different. It's unrealistic to expect
knowledge of one third-party API to be directly transferable to another
third-party API.


I don't think that's the case at all with AppleScript. I think the more
applications you script, the easier it is to master scripting new
applications.


Gotta agree with Ed here. There are some differences between applications,
but by and large, the more you script applications, the easier scripting
other applications get, unless an application just does something really
bizarre.

Again, knowledge of one *API* is not *directly transferable* to another *API*. Emphasis on "API" and "directly transferable". e.g. Knowing the classes and commands found in Finder does not make it any easier to learn the classes and commands in iTunes.


Now, what *is* transferable is general knowledge of how the Apple Event Object Model operates. I realise a lot of AppleScripters kinda sorta pick up that knowledge informally as a by-product of learning their way around applications' object models and eventually noticing that there are some underlying similarities. But the reason that knowledge is transferable is that it's completely general and application-independent; i.e. you could just as easily learn it from reading a book. (Actually, learning them from a book would be much better than trying to figure them out solely from trial-and-error observation, since it greatly reduces the forming of initial hypotheses that eventually turn out to be incorrect.)

In other words, learning general Apple event IPC principles and learning specific application APIs are two different things. General concepts are transferable, specific details aren't [1].


Anyway, apologies that my original statement wasn't clear. One of the perennial problems in the AppleScript world is that a lot of AppleScripters have great difficulty in distinguishing between the different technologies and concepts involved, in no small part thanks to AppleScript's deliberate smooshing together of all these disparate elements into one big, fuzzy, ill-defined and often confusing ball of mud.


I really should take more care when diving into it, but I was just trying to protect AppleScript against unrealistic expectations. It's frustrating the number of folk that roll in expecting AppleScript, Apple event IPC, scripting interfaces, etc. to be some sort of magic bullet that automatically works and doesn't require any effort to learn, and then start complaining as soon as it becomes obvious that it isn't. Yet other technologies are no different. It'd be like complaining that knowing NSString doesn't help in learning RegexKit. Of course it doesn't: they're two different APIs with two different purposes. (Although if they both follow standard ObjC/Cocoa design practices and patterns, existing knowledge of ObjC design practices and patterns can be carried over, of course.)



The problem is getting up to speed on new  APIs when they are almost
invariably grossly under-documented.

Of course, that's exactly where Scripter's command builder helped so much.


As does Script Debugger's live object model. API documentation really helps,
but it still falls short of being able to see, with real data, exactly what
every property and element looks like in real-world use.

Yep, being able to browse live objects interactively is a terrific feature, as (e.g.) Smalltalk users can tell you. It's a real shame the original Script Editor authors never stole the concept, as it's definitely a feature of significant benefit to novices and experts alike.


(Incidentally, I have absolutely no qualms about stealing good ideas, and both Python and Ruby appscript offer live object browsing as a command-line feature via their build-in help systems, along with quick lookup of class and command terminology, and inheritance and relationship graphs.)


Non-technical users are blessed with the unawareness that they are
 being sold short.


Is it possible to be any more condescending? Does that really help?

If it¹s getting the job done for them, then they, by definition, are not
being sold short.


You can dig coal with a spoon, and by definition that's "getting the job done" too. Or you could use an industrial coal cutter and do it a million times quicker and better and not have to work yourself to death, but only if you're aware that such a thing exists.

Education is everything, and a big advantage that professional Cocoa developers have is that they already have lots of it. If a Cocoa developer can be educated in AppleScript as well, they can become a powerful ally in improving application scripting technologies for everyone, not just because it'll enable them to improve their own application, but also because they can talk to other Cocoa programmers in their own language and thus spread that knowledge amongst application developers far more efficiently and effectively than someone who only knows AppleScript. The AppleScript community may be good at many things, but communicating with non-AppleScripters isn't one of them. If AppleScripters are serious about changing things for the better, rather than just talking about it all the time, they need to break down the walls that surround this all-too insular community and start building bridges.

has

[1] Okay, if you want to be really nit-picking, there are a few technical details that are transferable between some applications - specifically the default classes defined in Cocoa Scripting's Standard Suite and Text Suite. But these make up such a trivial portion of any decently scriptable application's interface that they're hardly worth counting in practice.
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org


_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
  • Follow-Ups:
    • Re: dev tools [was: Re: What makes AppleScript COOL!]
      • From: "John C. Welch" <email@hidden>
  • Prev by Date: Re: Changing the name of a file in the temporary items folder
  • Next by Date: Re: Changing the name of a file in the temporary items folder
  • Previous by thread: Re: dev tools [was: Re: What makes AppleScript COOL!]
  • Next by thread: Re: dev tools [was: Re: What makes AppleScript COOL!]
  • Index(es):
    • Date
    • Thread