Unification of Methods and Functions

[David MacQuigg]

On Thu, 06 May 2004 11:39:01 -0700, Donn Cave <donn at u.washington.edu>
wrote:

>In article <qp5k905u0uomcp7o4lnuome7ke5f7emn2h at 4ax.com>,
> David MacQuigg <dmq at gain.com> wrote:
>...
>> How did you know to add self in Mammal.talk(self)?  This is a perfect
>> example of an experienced Python programmer sailing right past a
>> problem that trips up less proficient users, and not even being aware
>> that the problem exists.  What surprises me is that even after
>> pointing out a problem like this, I will get someone telling me --
>> It's real simple, dummy.  Mammal is a class.  When you call a method
>> from a class, you get an unbound method, which requires an explicit
>> 'self'.
>> 
>> Yes, I know that.  I remember it because I use Python almost every
>> day.  My students and clients, three months after learning it, will
>> not remember.
>
>Maybe they won't, I don't know.  But if it's difficult, it's
>a benign sort of difficulty.  You CAN understand how it works,
>you can't use it WITHOUT understanding how it works, and the
>more you use it, the more obvious it becomes (sail right past.)

My point is that you don't *have to* deal with these difficulties,
even if they are "benign". There is nothing fundamentally missing if
we use a syntax that makes all function/method calls the same.  Taking
out unnecessary complexity is a good thing, even something as benign
as the confusion over dividing two integers, and not getting a
fractional result.

Currently, I'm not including OOP in my lesson plan.  For most design
engineers, it will be sufficient that they understand functions.
Mostly they will be modifying scripts to run the design tools, and we
can avoid using classes in any code the user is likely to be working
with.

Still, it would be nice if I could include OOP with just four more
hours total ( lecture, reading, and working exercises ).  I believe
that is possible with simpler syntax.  See the first ten pages of the
Prototypes chapter at http://ece.arizona.edu/~edatools/Python/  With
the current syntax there is no way I can get students to the level
they can "sail past" the problems in my Animals.py example.

>This is what Python is all about - a consistent, explicit
>system.  If you're searching for unbearable difficulties, I'd
>look for things you can use without understanding, like the
>object/reference storage model, and its interactions with
>mutable default parameters, +=, etc.

I agree Python is better than other languages in consistency and
simplicity, just not perfect.

I'm not aware of a simpler model for object references, but then I
wasn't aware that all functions/methods could be unified until I
looked at Prothon.  Do you have an idea for simplification of the
object/reference model?

>But at any rate, from my perspective, this is your problem,
>not your students and clients problems.  

I guess you know them better than I do.  :>(

>I've been hearing
>for years from sophisticated users who think they know how
>to speak for the unsophisticated users, and after a couple
>decades I have come to be highly skeptical.

I don't consider myself a sophisticated user at all.  I *have*
encountered many sophisticated users, not just Python, but programming
in general, who have not a clue as to what is easy or hard for users.
I suspect that there is a bit of elitism in the attitudes I have seen.
Now that they have learned their "stock-in-trade" they really don't
want to make it easier on others.  In general, Python and its
community is far more open than others I have seen.

>I've dealt with
>scientists myself, and I think I have an idea of what you're
>talking about, the principles make sense, but the connection
>between the general principles and the specific details ...
>a black art.  You're not unique here because you represent
>non-programmers, you have a unique idea of how that relates to
>the language.  As would anyone.

Whenever I hear that program usability is a "black art" I think of all
the really excellent programs I have used, and the straight-forward
things they do to improve usability, or I pick up a book like The Art
of Unix Programming, and get a refreshing discussion showing how
principles relate to specific examples.  Or I look at what Linus
Torvalds has done with Linux, or GvR with Python.  Sometimes you have
to swim against a flood of ignorance and apathy.

At the same time I'm acutely aware of my own limitations in designing
the perfect interface.  I try to always keep an open mind to a better
idea coming from the most unexpected place.  And I try to keep my
interfaces separable, so we can tear it all up and start over after
the first real user points out some obvious mistakes.

I've come up with an idea which simplifies Python's function/method
syntax.  Actually, it wasn't my idea.  It was Prothon (and they got it
from Ruby, Self, whatever).  I am ruthlessly stealing Prothon's good
ideas, and I hope ignoring the bad.  They are ruthlessly ripping off
Python.  Long live open source!!

>My own perspective is, present
>the core language and leave them to solve problems in that model,
>"bad programming" or not.  

This could be an argument for Perl. :>)

>The static method, for example, is
>not really a core concept - not just the implementation, but
>the basic principle.  So don't go there.  You'll be surprised
>at how little pain they feel over software engineering issues.

I can accept this argument for metaclasses, and other advanced tricks
that the basic user really doesn't need.  But I would include in the
core, most of what is in Learning Python by Mark Lutz.  Static methods
are necessary because it is a very natural thing to write a method in
a class that needs to work without being bound to any particular
instance.  

Yes, you can re-structure your program to avoid the need, but that is
like re-writing variable names to avoid the letter q.  It's a pain,
and the resulting program is not as clear as the original.  But worst
of all, it adds to the "benign" difficulties faced by the users I care
most about, those who are too busy to learn Python, but could benefit
enormously from it.

Again, thanks for all your help.

-- Dave