Autocoding project proposal.

[Kragen Sitaker]

Jonathan Hogg <jonathan at onegoodidea.com> writes:

> On 28/1/2002 3:56, in article 83sn8rgmc7.fsf at panacea.canonical.org, "Kragen
> Sitaker" <kragen at pobox.com> wrote:
> 
> > The Python of this is len(open('foo.txt').readlines()) --- not as
> > Englishy, and therefore not as easy to learn to read, but not any
> > harder to learn to write, I think.
> 
> This missed my point pretty completely I'm afraid. You've introduced a few
> new hard-to-grasp concepts such as objects, members, argument-less function
> application, sequences, length as a function.

I don't think you need to understand most of these things to learn to
write code like the above, although it will help at the point that you
start defining your own functions.  You need to know the following:

open('foo.txt') names the opened file "foo.txt".
x.readlines() gives us a list of the lines in a text file x.
len(x) gives us the length of the list x.

That's the same amount of memorization you need for AppleScript.

> My point was not that this sort of stuff is hard to learn, but that it has
> to be learnt. It doesn't match the terms and concepts people use in their
> normal lives.

People can't simply use the terms they use in their everyday lives to
write AppleScript.  They can use them to *read* AppleScript, but
writing it is a different matter.  Consider the following variations:

    give me the count of the lines of file 'foo.txt'
    get the count of lines of file foo.txt
    get the number of lines of file foo.txt
    get the count of the lines of file 'foo.txt'
    get the number of lines of document foo.txt
    get the number of lines of foo.txt
    get the number of foo.txt's lines
    get how many lines of file foo.txt
    get the number of lines in file foo.txt

AppleScript still requires ridiculous amounts of rote memorization,
and while its terms may match the terms people use in their everyday
lives, it only uses some of those terms, and they don't mean exactly
what they mean in everyday life.

> To take a single part of your implementation: 'len(<sequence>)'. Consider
> this for a second. 'len' is clearly an abbreviation of 'length'. Why? What
> was wrong with 'length'? Now, we're applying 'length' to a sequence to get
> the number of items in it. How does this make sense?

These are problems, but they are not problems AppleScript solves.

> 'length' isn't something that you do, it's an attribute that
> something has. 'count' is something that you do. Since when did
> someone 'length the items in a sequence'?

Not to put too fine a point on it, but most people don't read f(x) as
"do f to x".  They read it as "<intimidating mathematical formula>" or
"f of x".  "sin" isn't something you do, either --- it's an attribute
that an angle has.

Python does have the problem that it has three different ways to ask
for an attribute of an object:
    len(x)
    x.len
    x.len()

> > The real point you make above is that functional programs are simpler
> > than procedural ones, but that shouldn't be news to anyone.  The only
> > debates over functional programming are (a) can functional programs
> > run fast enough? and (b) can people understand functional programs
> > dealing with abstract concepts?
> 
> No. That's not the point I was making.

That may not have been the point you intended to make, but you did
succeed in making it quite clearly.

> AppleScript is not a functional language,

Your AppleScript example was a functional expression, and that was the
major difference between it and your Python sample.

> and I think functional languages are even more flawed than
> imperative languages in this respect. Functions make a sort of
> perfect mathematical sense to me, but to a non-programmer (or even a
> non-functional-programmer), they don't make any kind of sense at
> all.  Sequence makes sense to normal people: I do A, then I do B. If
> I have some kind of intermediate result then I put it somewhere. Mix
> ingredients in bowl, empty bowl into tin, put tin in oven, bake at
> 200C for 1 hour.

As I pointed out above, while functional programs are simpler, they
are often argued to be harder to understand.  This is why.

> What is it about us that hates verbosity in programming? Why 'len' over
> 'length'? Do the extra three letters really feel that hard to type?

I don't really like ubiquitous abbreviation myself (although I'm not
as averse to using invented words like "grep" or "cadr", where I'm not
likely to read them as abbreviations).

My hypothesis is that brevity increases the amount of time to read one
line of code, but up to a point, decreases the amount of time to read
one function point.