Autocoding project proposal.

[phil hunt]

On Sun, 27 Jan 2002 23:40:31 +0000, Jonathan Hogg <jonathan at onegoodidea.com> wrote:
>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.]

I think that's all of us.

>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? ;-)]

Hmm. But programming computers in English is probably AI-complete.

>> 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).


There is an element of truth to this. Open source software is often written
by people wanting to "scratch their own itch". People write tools that'll
be useful to them.

Having said that, it is changing -- GNOME and KDE are part of the process 
of change, and I know non-programmers who use Linux.

>> (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...

Yes, to understand programming you have to understand the underlying 
concepts. But that's true of anything: if someone said to you that threy
wanted to drive a car without learning all that nonsense about steering
wheels, brakes, road signs, highway code, etc, you'd think they were
barmy. Well, driving a computer is the same. 

I don't know if Applescript has the concept you name above, but if it 
doesn't, it'll be severely limited in what you can do with it.

>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'

Thgis uses English-like syntax, which makes it look easy at first glance,
but is it really easier? I suspect not, and as evidence I point ot the lack
of success of languages that emulate Cobol's pseudo-English-like nature.

(I may well be wrong here, but that's my personal intuition; has anyone
done any surveys of the subject?)

Say, instead, you want to count the number of words, or lower-case letters
in foo.txt? How would you code that in your pseudo-English? or in 
Applescript? Consider: "easy things should be easy, and hard things 
should be possible".

It seems to me that a better solution might be:

   count_lines foo.txt

or as we say in Unix:

   wc -l foo.txt

If I wrote a Python-like language it'd probably be codable something like:

   len(readlines(OFile('foo.txt')))

>[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.]

I've never used Hypercard but it was clearly a significant and well-liked
program. I wonder why Apple are dropping it? That they are doing so is 
a reasonn to use open source software wherever possible, at least on data
you want to keep for some time.

I know little about pythoncard, but I get the impression they are currently
concentrating on screen-drawing functionality. Maybe they will add
a hypercard-like language layter on. Pythoncard is an intriging project
and i hope it is successful.

>> 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,

To some extent. The fact that one can write programs in a programming 
language is hardly revolutionary. I expect a Python program that does the
same thing wouldn't be much more complex. Let me see:


   mp3FilesStr = commands.getoutput('find ~ -name "*.mp3"')
   mp3Files = string.split(fileStr, "\n")
   fileToPlay = whrandom.choice(mp3Files)
   os.system('mp3player ' + fileToPlay)


This could be simplified somewhat -- e.g. a simpler find command, and the
names of the python modules / functions could maybe be a bit more 
descriptive. But it'd be hard to make it much simpler.

OTOH, to the extent that you and other people find Applescript useful, it 
*is* useful.

>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.

But how scriptable is the emailer? To take an example of something I'm 
currently working on, is it possible to run all emails through an input
filter (an arbitrary program that processes and possibly alters them), 
before they go in to the user, and do the same with output emails?
That functionality would be very useful if someone wanted to connect the
emailer to an email encryption / decryption program.

>Yes, I don't mean to feed the kooks, but I am genuinely interested in the
>kernel of truth in his rantings. 

Certsainly the way you explain it to me makes a lot more sense than what 
he is saying.

>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.

Well, yes. But I suspect that "the computer adapting to you" may well
be AI-complete.

-- 
===== Philip Hunt ===== philh at comuno.freeserve.co.uk =====
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.