Autocoding project proposal.

[Jonathan Hogg]

On 26/1/2002 20:03, in article 5203.791T524T9503446threeseas at earthlink.net,
"Timothy Rue" <threeseas at earthlink.net> wrote:

> Applescript does seem to be somewhat closed system oriented. That is
> Limited within the language included in it and other applications
> vocabulary. But then that is to be expected of a scripting language, even
> with it's flexable natural language like use.

Actually I simplified the situation slightly. AppleScript is in fact one
language that conforms to the Open Scripting Architecture (OSA) designed by
Apple. This is a set of APIs that embody the mechanisms for communicating
with applications (the "side door"). Any language can be plugged into this,
and a number of alternative OSA scripting languages exist.

I personally think AppleScript is the closest to something that allows
people to express what they want to do in terms they are most familiar with.
I'd love to see something even more natural, but natural language
communication with computers has stalled somewhat since the early enthusiasm
for AI.

> The VIC is different in that it is not a scripting language but rather
> more like a physical mechanical device with gears to shift, cycles to
> complete and patterns to match in determing what output it will produce
> given the input it receives.

I can understand what you mean about the 9 basic commands. The concepts you
describe seem very similar (to me at least) to the idea of the Turing
machine - a simple set of commands that can be mathematically proven to be
able to express all computable problems.

But the devil is in the details. To be useful, the basic commands must be
able to operate on a very high level. The Turing machine commands operate at
a very low level (move tape left, write one character, etc.).

AppleScript (to continue my example) has a few basic commands (OK, it also
has a lot that aren't basic, but run with me...). For instance (not tested,
don't bother ratting on me if I get them wrong):

    * Selecting an application:

        tell application "Finder" to ...

    * Getting a thing from an application:

        ... get the startup disk

    * Identifying a thing in terms of a container:

        ... get the folder "Documents" of the startup disk

    * Sending a command:

        ... move the folder "Documents" of the startup disk to the trash

These are simple concepts that most people can quickly grasp, but the devil
is in the details. The hard thing is mapping the things that the application
works with into terms that the user can understand. Things such as "folder",
"trash", etc.

Apple manage this by asking programmers to write a dictionary for their
application and to document it. The dictionary and the documentation are
built into the application itself, and any user can point the Script Editor
(an application that comes with every Mac) at an application and ask for
this documentation. The Script Editor application uses the application
supplied dictionary to check that the commands entered by the user are
legal.

> I don't expect anyone to understand anymore. I've pretty much come to the
> conclusion that I'm not going to get any help with this, no matter what I
> do.

Don't give up yet. Sometimes describing the problem to someone else makes it
more clear in your own head, even if the listener has no idea what you're
talking about. If you work too much on your own then you risk not being able
to see the wood for the trees.

> Think about it. IS the idea of applescript or the side door port to
> applications and other functionality that new?

No. Not particularly. The new thing, from a Mac point of view anyway, was
building enough programmer "critical mass" in terms of support for Apple's
view of the side door to be able to make it useful to users.

> the fact is Programmers have had this sort of interface for a long time in
> vaious form such as APIs. There can only be one reason why this side door
> concept hasn't been made more generally available to the typical end user.
> 
> If you don't let the user do it then you can do it and sell it to the
> user.
> 
> It really is that simple!

I'm not sure it is. I'm always more willing to attribute an unwillingness to
open up the APIs of an application to laziness than maliciousness or greed.
Most Macintosh application developers find they are able to sell more copies
of a scriptable application than one that isn't. It was Apple demonstrating
this that turned the tide.

In another article in this thread, Phil Hunt wrote:

> In that case, please explain why many of the most talented programmers
> are developing open source software, which they are giving away to
> anyone who wants it, and that many open source projects are explicitly
> aimed at making things easier for end-users?

I think that's a bogus argument. I've not seen any Open Source software that
makes any particular effort to open up the internal functionality to
non-programmers. Having access to the source doesn't make it more "open" in
this respect, since the learning curve to be able to use the source is too
high.

The problem with the primary user interface to a program is that it is based
on what the programmer thought would be useful to the user - the menus,
buttons, windows, etc. that they have defined. It is limited by their
imagination instead of the user's imagination.

I wrote a bunch of small AppleScripts in the past that would send commands
to a larger script running on a computer across the room that would
interrogate the Finder to get a list of mp3 files on the harddrive, choose
one at random, then ask the QuickTime player to open and play it. I drew
icons for the small scripts and put them into a toolbar utility that would
execute them when clicked. By sending commands to the toolbar utility I was
able to get it to display different icons indicating the
stopped/playing/paused status.

None of the applications I scripted to do this were designed to be a
jukebox. In fact none of them on their own could have done it. But since all
of the programmers had provided me with the hooks necessary to use their
functionality directly, I was able to make one.

I honestly do agree with you Timothy, but the problem is that unless you can
persuade programmers to make these "side doors", to convince them of the
freedom they provide to the user, then your machine is going to grind away
with nothing to talk to.

Unfortunately, programmers are a prickly bunch and you won't get far by
accusing them of being elitist or ignorant (even if they might be).

Jonathan