Re: on scalability (was Re: on neophytes vs perfectionists)
Re: on scalability (was Re: on neophytes vs perfectionists)
- Subject: Re: on scalability (was Re: on neophytes vs perfectionists)
- From: has <email@hidden>
- Date: Sat, 20 Dec 2008 15:42:33 +0000
On Dec 17, 2008, at 10:32 PM, Chris Page wrote:
Myself and many like me use AppleScript all the time, because it's
the best solution for some jobs, but we need it to scale better.
When I think of scalability and AppleScript, I think of improvements
that will immediately improve the lives of ordinary AppleScripters,
such as decent text handling and lists that can be iterated in O(n)
time, not O(n*n), so that scripts don't take a pile of hand-rolled
code or half a day to perform what are basically menial tasks. And
that's really it.
Most of the fancy stuff that professional programmers expect, such as
thread-based concurrency, class-based OOP and introspection/
reflection, have no place in AppleScript, and adding them would lose
the one advantage that AppleScript does have over other languages such
as C++ and Java: the smallness, simplicity and coherency of the core
language. (Much of which admittedly gets lost under all the ill-
organised crap that scriptable applications slop on top, but that's a
separate issue and the principle otherwise stands.) Adding anything
like that to AppleScript would be a disaster: professional programmers
would still hate it, and non-programmers would no longer find it
appealing. Their wants and needs are far too different ever to be
properly catered for in a single language.
However, there are still a couple potential ways that the needs of
both non- and professional programmer audiences could be better met:
1. Send non-programmers and programmers along completely separate
development paths. Non-programmers need an end-user language that
caters specifically to their own particular needs. AppleScript has a
lot of shortcomings as an end-user language, but it's what we've
currently got to work with so we'll stick with that for the non-
programmers until a better option comes along. Programmers should
stick with their existing 'pro' languages, and the technical features
that make AppleScript what it is - Apple event support, attachability
support [1] - should be brought to those languages [2].
2. Send non-programmers and programmers along separate development
paths, but allow those paths to cross. Once again, this means having a
separate language for non-programmers, but instead of making it
completely isolated from other languages as the current AppleScript
interpreter is, follow the approach taken by (e.g.) Microsoft with
their Common Language Runtime, and build a new AppleScript (or
whatever) front-end on top of an existing VM (virtual machine - the
bit that does all the hard work of actually running program code) that
other 'pro' languages can also be built on. You still have separate
languages, but moving between them becomes much easier as the shared
VM foundation makes a lot easier to share code written on one of those
languages with all the others.
3. You could also reimplement AppleScript directly on top of another
language, creating a hierarchical layered structure instead of the
peer-to-peer arrangement described in #2.
For example, if you built it on top of another scripting language such
as MacRuby, you would get three levels - the AppleScript layer, the
Ruby layer, and the ObjC layer - that users could climb down when
they're ready to advance their skills or need access more
sophisticated or low-level features, without having to throw away and
redo all their previous work.
Similarly, new functionality (i.e. modules and frameworks) created at
a lower level may be more easily wrapped to make it accessible to the
next level above. i.e. Just as MacRuby's HotCocoa add-on is in the
process of creating easy-to-use, Ruby-style wrappers around ObjC's
Cocoa APIs, easy-to-use, AppleScript-style wrappers could be created
around existing Ruby APIs. [3]
Regards,
has
[1] In principle, 'attachability support' means packaging the language
as an OSA component, but the OSA component architecture we have today
is a pile of crap that really needs to be completely rethought,
redesigned and rewritten before its original promise of true language-
agnosticism will ever be delivered on.
[2] Indeed, Apple already has introduced their own Apple event support
to ObjC in 10.5 - and, as usually happens with their AppleScript-
related technologies, managed to flub it. But at least it shows
there's some interest in popularising application scripting amongst
other languages, even if the delivery falls frustratingly short.
[3] This is not entirely unlike the approach I took when creating
TextCommands, which is just a thin AppleScript-accessible wrapper
around a chunk of Python's built-in string methods and regular
expression module. Quick and easy to implement (certainly moreso than
creating an equivalent C-based extension), and provides a native
scripting interface that AppleScript users will find familiar and
friendly. The benefit of the HotCocoa approach is that all the
wrapping can be done within the existing set-up, instead of being
implemented as a bridge between two different runtimes, with all the
extra code and runtime overheads that entails.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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