Autocoding project proposal.

[Jonathan Hogg]

On 27/1/2002 17:37, in article slrna58en4.4cd.philh at comuno.freeserve.co.uk,
"phil hunt" <philh at comuno.freeserve.co.uk> wrote:

> Of course, this is partly a matter of definition. If you define who writes
> an Applescript or a macro as a "programmer" (they are certainly writing
> a program), then by definition there can be no programming systems for
> non-programmers.

Definitions are tricky things, that's why I explicitly gave one in my first
post on this thread:

[Side note: I don't mean to be derogatory with the term "non-programmers". I
just mean people that are more comfortable communicating with natural
language than the highly artificial and low-level computer languages that
programmers typically use.]

When I've taught programming to students, I usually try to make the point
that we are all programmers in the sense of being able to explain to someone
else how to do something. The main difference is simply in the language we
use. [Is this another argument for Tim's nine commands? ;-)]

> But there *are* open source projects that aim to
> make programming easier for casual programmers. Examples:
> 
> (1) In another post on this thread, someone points out that GNOME as
> a system of application directories similar to the Applescript system.

I suppose I was overly harsh with my criticism of Open Source software on
this front. But I would still say that these interfaces are thin on the
ground, and where they exist they are designed for programmers (using my
definition above).

> (2) The python language is explicitly designed to be easy to program in.
> It's creator, Guido van Rossum takes a big interest in making programming
> easy -- consider thar Python was based on his earlier ABC language, which
> was designed for ease-of-use by non-professionals. Then there's his
> "Computer Programming For Everybody" project.

Don't get me wrong here, I love Python, but it's still designed for computer
programmers. It takes a certain mental leap to understand the concepts
involved. These concepts are so ingrained into our psyche now that we don't
question how they map to a non-programmers view. Take:

    def count( file ):
        i = 0
        for line in file:
            i = i + 1
        return i

    count( open('foo.txt') )

The earlier example on counting lines in a file, expressed as simply as I
can think to do it in Python (using the new 2.2 iterators magic). There are
a number basic concepts here we take for granted: functions, arguments,
variables, loops, function return, function calling, nesting...

Surely what would make more sense to a non-programmer is something like
(using pseudo-AppleScript):

    get the count of the lines of file 'foo.txt'

I don't want to come across as some mad AppleScript zealot. My point is not
that AppleScript is fantastic, but that it's the closest I've seen to
something that a non-computer-geek friend might be able to read and make
some sense of. It still falls down on a lot of things - some computing
concepts don't map very well to natural terms.

[Side note: this is why I think PythonCard has gone off half-cocked. The
great thing about HyperCard was HyperTalk - the language that clearly
influenced the design of AppleScript. HyperCard was an incredibly powerful
tool for non-programmers, many HyperCard authors had never read a
programming book in their life; PythonCard looks set to be a useful tool for
teaching people to program.]

> It's good that you were able to do that. Evidently Applescript is a
> useful system for that sort of problem.

I can't decide a) if that's damning with faint praise, and b) if so, is it
damning me or AppleScript ;-)

I just picked a real-world example that I thought would make sense to people
(note to Tim). AppleScript can, and does, do a lot more than this. Most of
the applications I use on my Mac are scriptable - including the emailer I'm
using to type this.

> Until someoner builds a system for doing useful stuff with the "side
> doors", no-one will build any in. To some extent this is chicken-and-egg.
> I see two solutions (i) built a progresamming system that interpretes
> "side doors"b and also allows useful stuff to be done interacting with
> systems that don't have them, (ii) build some apps that do have "side
> doors" -- or modify existing apps to have them.

Perhaps the answer is to look at the GNOME stuff and consider how the CORBA
interfaces might be made available at a user level. I'd love to see someone
come up with something really natural.

> Tim's problem is that he is very good at (probably inadvertently) rubbing
> people up the wrong way. He also is a poor communicator -- it is often hard
> to get at what he is driving at. He also has a strange attitude towards
> others -- he wants them to do things for him, and at the same time
> castigates them for being elitist and/or stupid.

Yes, I don't mean to feed the kooks, but I am genuinely interested in the
kernel of truth in his rantings. The problem with programming languages is
that, no matter how simple and easy to learn, they require the user to learn
to program. You have to adapt to the computer, instead of the computer
adapting to you.

We've managed to make writing letters, sending emails, and surfing the web
easy enough for Grandma to use, but programming a computer is fundamentally
no easier than it was when we toggled switches or punched cards.

Jonathan