Re: solutions to scripting addition terminology confilicts [going OT a bit]
Re: solutions to scripting addition terminology confilicts [going OT a bit]
- Subject: Re: solutions to scripting addition terminology confilicts [going OT a bit]
- From: has <email@hidden>
- Date: Sun, 27 Jan 2002 17:19:01 +0000
Shane Stanley wrote:
>
>
> But, seriously, say you take a look at the current community support for
>
>- and
>
> use of - AS-based mods/libraries by way of comparison.
>
>
>
> "What support?" I hear you cry. Well, exactly. AS must have the poorest mod
>
> support of any commonly-used scripting language. Why?
>
>
>
My guess: probably because, like these scripting additions plans, you're
>
talking about solutions to problems that the great majority of scripters
>
simply don't run into -- and in this case, probably never will.
Writing modular code is simply good programming practice. TID-based find
and replaces, file read/write routines; these sorts of things can be spun
off - not just into separate handlers, but even into reusable modules that
can be called on an as-needed basis. Less duplication = smaller code =
easier development and maintenance. These are Good Things, whether your
script is ten lines or a thousand. Abstract those small, common details
away wherever and whenever you can; your code will be the better for it.
Date-formatting, url/html/cgi encoding and decoding, math operations, list
manipulations... the list goes on. When some newbie comes on the list and
asks "How do I do... [something common]?", it ought to be a simple case of
replying "use doSomething() from library so-and-so".
[Note: this is not weakness or laziness as some might think; this is good
programming. Anyone from novice to expert can benefit from it. That they
frequently don't can be mostly put down to lack of education, IMHO. Any old
AppleScript tutorial will tell you what a handler is and what it does, but
I've yet to see one that really gets into WHY you should use one. I'm
certainly not advocating every ASer should do a full-blown 3 year course in
CompSci, but a summary of good programming principles that is accessible to
even non-programming AppleScript newbies doesn't seem to be an unreasonable
thing to hope for.]
In the meantime, look at the huge quantity of modules you can get for
languages such as Perl and Python, and compare that to AppleScript. If you
can measure the health and success of an OS by its application support, I'd
say that you can tell a few things about a scripting language by its
third-party mod support. One of these days OSA-compliant versions of those
languages could well eat AppleScript's lunch if it isn't careful. And
hand-wringing and wailing that "the osax authors should've tried harder"
won't deserve to cut much ice.
--
But this is getting rather OT as I'm spinning off on a different rant
entirely. My original point was to counter any ideas that folk might be
having about trying to start up an "official" unofficial hack as a solution
to a problem that is Apple's job to fix - by pointing out how difficult it
is to get even a *non-hack* solution to a *real* problem successfully off
the ground (though I take my hat off to folks like Greg S who are trying
hard to do so). My apologies if that provided an inadvertent distraction to
the topic at hand.
Anyway, my first post to this thread was to suggest that the best solution
is for osax/app designers not to go running with scissors in the first
place. I still believe that to be the preferred solution, and quite
achievable if folks put their mind to it (though I daresay the thought of
being chased by a big-stick-wielding Jon P. should be more than enough to
keep any reckless hedonists well in line;).
Cheers,
has
(hon. member of the Anti-Wheel Reinvention Society)