A java hobbyist programmer learning python

[Scott David Daniels]

Tim Rowe wrote:
> ... I like the second style because it makes it leaves the 2-d
> implementation hidden, which is the whole point of encapsulation.
I like the second as well, in that it it allows the parent to update any
related data structures (for example, updating a display).  However, I
am a bit nervous about changing the signature of the move message, and
would be more tempted to add a move3d, for multiple inheritance reasons.

>> But then I am a fan of Hungarian notation, which many
>> programmers can't stand.
> 
> Is it that programmers can't stand it, or is it that they can't stand
> it when it's imposed when not needed? ....
Well, I tend to be one who hates Hungarian.  I spent a long time being
a fan of strong typing.  Then, I felt the compiler would enforce the
typing, and the Hungarian muddied the readability of the expressions.
I felt that you should define a type for distance_in_yards, and not have
that confusable with distance_in_meters (though you might provide an
automatic conversion.

Now, I feel strong-typing systems cannot express the type relationships
that I want as a programmer in the face of sub-typing, and I hold
no hope that (A) such a language will appear, or (B) that the strong
majority of the bugs I produce in Python will be caught by a statically
typed system.  I do however, still find the neddling little text
annotations in the variable naming to be irritating noise that distracts
from the readability of the expressions.

The kinds of type systems that I want(ed) is most closely expressed by
F-Bounded polymorphism, and that doesn't manage to be both expressive
enough and computationally feasible to use as a production type system.
For example, I'd like to type a sort function or a project function,
and all I've seen looks like its fit will feel more like a suit of armor
than a shirt.

--Scott David Daniels
Scott.Daniels at Acm.Org