[Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59

[Daniel Lord]

On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote:

>
> On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote:
>
>>
>> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote:
>>
>>> Ronald Oussoren wrote:
>>>
>>>> Totally off-topic, but if you'd move to setuptools you can keep  
>>>> several separate packages, but users could install using  
>>>> 'easy_install appscript' which would then take care of the  
>>>> dependencies for you.
>>>
>>> I think setuptools is going to be a great solution and definitely  
>>> plan to more there eventually. For now though, the mpkg-based  
>>> distribution provides a lower barrier to entry (one less thing to  
>>> install first), and it's a familiar format to all Mac users. One  
>>> of the obvious audiences for appscript is existing  
>>> AppleScripters, who aren't always overly enthusiastic about  
>>> approaching unfamiliar technology, so it keeps things simple for  
>>> them.
>>
>> this is a personal opinion so I don't expect consensus. I _like_  
>> appscript. A lot. HAS did a great job with it. And while I like  
>> the power of Apple Events, I do not like Applescript--the syntax  
>> is not standard by design--it varies from application to  
>> application which in theory means flexibility but in practice  
>> means entropy and chaos. And some application developers cannot  
>> even get the AETE right and so their scripting is broken or at  
>> least crippled. Applescript does not have decent control  
>> structures nor regular expression support. Its file system syntax  
>> is horrific. I applaud the idea and the 'dream'--it just fell far  
>> short in practice. So using Python or Perl, whose syntax and  
>> language elements don't vary much from application to application  
>> is much better. The objects can vary--just not how to address  
>> them. I have used Mac::Glue with Perl, appscript with Python  
>> satisfactorily though I wish Apple would build in Apple Event  
>> support for those languages.
>
> That's irrelevant to appscript.  If you're disappointed with the  
> inconsistency of a given application's scripting dictionary then  
> complain to the developer.  Apple can't do a damn thing about it  
> (unless of course they're the developer of the given app).  Apple  
> can't "build in support" for Python that would really be any  
> different than what current solutions offer.  What they could do is  
> offer better tools for creating scripting dictionaries, and more  
> documentation on the topic, but that's about it.
>
> -bob
>

Ah but it is, I disagree. Apple is the OS and platform vendor. It is  
their decisions on frameworks, tools, and languages that constrain  
us. And with Applescript they boxed us in with a poorly-thought-out  
and insufficiently-defined concept for a language and platform that  
allows dabbling but little else in practice. It is a failure--even on  
a low-market share platform it has little penetration and for a good  
reason--it is 'crap shoot' to use. Poorly and inconsistently  
supported. Sure blame the docs.  In the end, the documentation for a  
tool is as important or even _more_ important than the tool even when  
its structure is flawed. So fine. Let's agree to disagree. I'll let  
Applescript's adoption number speak for my side of the argument. When  
is it going to be ported to Linux or WIndows like Python and Perl  
have? Applescript could work with COM and .Net Why hasn't anyone done  
it if its so great? Res ipsa loquitur.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/f4dae10e/attachment.html