Thoughts on screed about HC and Applescript
Jim Witte
jswitte at bloomington.in.us
Sun Apr 11 01:58:01 EDT 2004
Hi,
A couple days ago, I submitted a long screed to Apple's Bugreporter
(probably not the best place) as a feature request for Applescript.
Then I posted it to the "Applescript Users" mailing list. The
reactions were not exactly pretty. I'm wondering what people here
think, since Rev is closer to HC (IMO) than AS is, especially my point
at (1) about Cocoa and AS Studio being more 'intimidating' that HC, and
my general idea of "desktop programming"?
BTW, could Rev be used to do such "Desktop programming" - i.e. have a
stack that would have a "clear" card (not opqaue) such that clicks to
the card (but not objects on it which had scripts) would be passed to
applications "underneath" the stack?
You'd have to be able to make a "clear" card, and either have Rev sit
on the very bottom of the windowing stack or the very top - probably
the bottom, as to really integrate nicely, it would be desireably to
have the ability to, say, you could put a Finder icon (MacOS) right
next to a button in the Rev app, even if the Rev app had a field across
from the button, like this:
[Rev button] [Finder icon] [Rev field]
The button and field would be part of the application, but the icon
would have to sit between them. The only way I can see this happening
is if the Rev stack were at the bottom of the windowing stack. And it
*might* have to stay there, even when it's controls were activated.
This might be an interesting idea for the Windows/Mac/Linux? GUIs of
Rev to be able to do in the future..
-- "The Screed" --
It would be SO nice if in Applescript I could simply write:
put 5 into tVar
put "set x to" && quote & tVar & quote && "+10" into tCommand
[...]
than the rather cumbersome (and much less Englishlike)
set tVar to 5 -- or equivalently 'copy 5 to tVar'
set tCommand to "set x to \"" & tVar & "\"+10"
[...]
First of all, the word 'quote' is just easier on the eye than the
escape-double-quote, except perhaps for people who are used to reading
Perl for a living - which I don't think AS's audience is.
The && operator for concatenation with a space is not as intuitive, but
it is simple, and accomplishes a function that one often wants to do
when composing text. It is both easier (some would say more concise)
than using the 'space' keyword, and is easier on the eyes than writing
"this string " & "has a space in it" with the space at the END of the
first string literal - the eye can VERY easily miss that space, or
worse, delete it by mistake.
As for the 'put' command - I have never liked AS's 'set' command - it
makes sense to *set* properties such as the height of an object. It
does not however make as much sense to "set" a variable. It makes
sense, but it's not what people generally say when they are referring
to real world containers, which after all, are what variables are -
containers. One never says "I set water into the bucket". HC
succeeded because the programming language metaphors matched the
real-world metaphors they were trying to emulate. AS doesn't do this
as much (and I have written quite a lot of HC in my time, and a fair
amount of AS too)
The 'copy' command is closer to the English language usage, but
again, not quote. To copy implies that the destination already exists,
and that the source will continue to exist after the execution. This
is true with variables, but it is also (assummed) true with 'put' and
'set' as well (that's where the metaphorical relation between
computer-variables and real-world-objects breaks - the contents of
variables are almost ALWAYS copied, whereas real-world objects cannot
be generally)
'Set' also brings to mind to possibility that it is performing a
refernce-copy instead of a value - like a 'clone' command (from
NewtonScript). Which of course it doesn't either.
When AS came out, I had hoped that I would either be able to type in
HC scripts I had been writing for years *exactly* as they had been, and
have them work (as far as they would - as HC had no application-object
model), or that they would with very minor changes. Alas, that didn't
happen, and it *continues* to frustrate me to this day, because I write
something that would have worked in HC, and it doesn't in AS, and I
can't figure out why.
Most often this has to do with coercian of variables that didn't seem
to be a problem in HC (having to write kludgy-looking things as
"display dialog (tFile as string)" instead of having the AS compiler
know enough to do the coercian of a file refernce to a string
automatically. But that's another bug report - I'll have to come up
with specific examples.
Generally, I would hope that Apple would resurect the entire HC
language syntax, and re-create it as an AS dialect (if those still
exist in the current codebase - I know they did at one point). This
would be of great benefit if there are still a bunch of HyperCard
veterans like me out there (I don't know), especially if Applescript
Studio were reworked into an interface as easy to use as HC (instead of
requiring one to use xCode and IB, which while much more powerful, is
also somewhat intimidating than just having a little palette with 15 or
18 buttons on it, creating little buttons, and editing their scripts
all in one place..
Hypercard was one of the most innovative, possibly THE most
innovative application or technology on the Mac ever, aside from the
Mac itself. In my opinion, it should have been integrated directly
into the system and Finder (buttons and fields on the desktop, in
folders, etc), and made into a system scripting lanuage, combining what
later was to be AppleEvents and AppleScript functionality, as well as
UI scripting like QuicKeys. Network support should have been added,
and more robust data transfer capabilities. If that had been done, HC
would have been a platform for user-level programming (which it already
was), and more so, for "user GUI design" - a concept which does not
currently exist in ready form on either MacOSX OR Windows. SmallTalk
and Squeak may have parts of it (I haven't played with thse much).
This kind of technology, coupled with easily-accessible
application-control and UI-scripting (comparable in part to VBA on
Windows and a number of disparate pieces on MacOS including QuicKeys,
iKey, AppleScript Studio, and MetaCard) YEARS before Windows did. With
network ability, scripting ability (equivalent to JavaScript), and
multimedia capabilities, HC could have formed the basis for the World
Wide Web, taking the place of, or combining with the current protocols
of HTML, XML, DHTML, JavaScript, Java, and all sorts of CGI platforms,
as well as WebObjects. [some may recognize that last line..]
Apple could still put together this "user GUI design" paradigm on the
desktop end - and work toward integrating it more closely with Java,
JavaScript, DHTML and the DOM, and WebObjects on the enterprise size -
even now. It would undoubtedly be harder (technically and
logistically), and the payoff would be much more uncertain, but if done
correctly, it could possibly create the next interface revolution for
the 21st century, after the desktop-metaphore pioneered at Xerox-PARC.
It already exists in small forms in Squeak and some Java environments,
but it has yet to reach the mainstream, and I believe will never reach
the mainstream unless a large company commits to it. MS is probably
not going to do so, or it likely already would have.
Plus, for users, the "Steve Jobs keynote selling-point demonstration"
is obvious: how would you like to be able to create a customizable list
of stock quotes that would always be on your desktop, yet roll away at
the click of a mouse, in only 6 lines of code? And it would take you
less than 5 minutes to do." and it could be done, eith HC and SOAP
queries..
-- (my further commentary from later on in the discussion on the
Applescript list) --
Actually, either live SuperCard or Runtime Revolution. Supercard I
think is a bit (or a lot - I haven't used it since v3) more polished,
but Revolution has a lot of potential.
And I didn't mean by the comment that "Hypercard was one of the most
inovative (blah)" and the bit about the system integration that it
can't be done - it certainly can, and faster. I wouldn't even want to
*think* about writing a web browser in HC - but I might using
Revolution or Applescript Studio . Nor did I mean that HC should be
resurrected as it - God no. HC was the beginning, but it *is* dead
now, and has been for a while (no color, very little or no multi-window
support, little real menu support, etc - I never looked much at the 2.2
version).
All these things *can* be done, and quite quickly given the tools -
which are now freely available in xCode. I'm saying that if the
functionality of AppleScript Studio were available on the desktop
(rather than as a separate app), it might get a bigger a bigger
user-base. How much bigger, I don't know.
(1)
I just have a feeling that Cocoa programming, and perhaps even
Applescript studio programming, is seen as more intimidating that HC
was, because of the design interface. I'm very possibly wrong on that,
but I remember seeing a *lot* of stuff relating to HC (the DevStack
collections, other external collections, reams of educational software)
and I'm not sure if that is happening with Applescript Studio, although
AS Studio still is relatively new.
-- (another response, to a (non-favourable) comment someone made about
my distinction between 'set' and 'put') --
Subject of this email: Re: "Putting minutes into timers..." (this
becomes clear quite soon)
>>> (I had written)
>>> As for the 'put' command - I have never liked AS's 'set' command
>>> - it
>>> makes sense to *set* properties such as the height of an object. It
>>> does not however make as much sense to "set" a variable.
>> (The complainer [John. C] had written)
>> It's quite natural. Do you put five minutes into a timer? Of course
>> not, you
>> set the timer for 5 minutes. That's the real way you set values.
> (The 'peace maker' had written)
> Well, that's the way _you_ think of it; and Jim thinks of it a
> different
> way. And don't get Howard Gardner started, or we'll be here all night.
Interesting here, that John C. exactly makes my point: a timer is an
object, not a container. According to my human-language/real-world
metaphorical model, you use set with objects and put with containers,
so you would *not* "put 5 minutes into a timer".
This is starting to look like an interesting programming-psychology
experiment..
And I'm starting to feel like a fool. I just wish Apple hadn't let
HC sit for so long...
Jim
More information about the use-livecode
mailing list