Autocoding project proposal.

[Jonathan Hogg]

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.

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.

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

> 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. AppleScript is not a functional
language, 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.

> COBOL has the same advantage, really.  Not that I'd want to use or
> learn COBOL, but if I had to write a program to do some kind of simple
> calculation and it needed to be readable by nontechnical people, COBOL
> would be the tool for the job!

Yes, someone else already mentioned COBOL. I was mulling over this the other
day and I began wondering if the mismatch between programming languages and
natural languages is in the number of terms. As programmers we tend to
strive to keep things simple with as few abstract terms as possible. Yet if
you look at human languages, they do the exact opposite - adding concrete
terms all the time. The complete Oxford English Dictionary runs to some 20
volumes. Humans clearly have no problem learning vast numbers of different
terms.

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?

Jonathan [once-an-Ada-programmer'ly-yrs ;-)]