> Working with, rather than against, others' misaligned intuitions is > the anti-thesis of the scientific spirit. >
Which is maybe why I'm working against your misaligned intuitions. ;-D > You don't propose that there is no meaningful distinction between > methods and attributes. > > You might be able to con me into believeing *that*, at least. ;) > > Instead you acknowledge the distinction but are consciously > using the power to shuffle appearances to appease and re-enforce > intuitions that happen to be wrong. > No, the knowledge domain isn't "wrong" when it thinks of angles A,B,C as *attributes* of a triangle, or myaccount.balance as an *attribute* of my bank account -- even if there're SQL lookups or cosine calculations going on behind the scenes. How a particular programming language needs to work to satisfy a use case needn't trump the basic intuitions of the user. You want to "educate" your user about what you had to do in Python. I say the user shouldn't have to care about that. Python is a servant, a tool, not a dictator. I don't give a rats ass what hoops you needed to jump through to make 'weight' an attribute of my heart object, not a method. As the client cardiologist, I'm telling you what I want the API to look like -- or I'll get a more competent programmer. You don't want to acknowledge that verb-sense and noun-sense are prior to any programming language (part of ordinary thinking). The whole idea of OO is we're modeling object-worlds [1], trying to make our code meet the expectations of users who may *already have* a refined understanding of their own discipline (gasp!). We're here to learn from clients, and do our best to mirror their expectations, not second-guess them at every turn. You seem temperamentally incapable of adopting this attitude. > I have to suppose that a intepretation of computer science that > seems to support that approach is a misreading of the science. > > I am a great believer in the proposition that in the end, Reality wins. Python isn't "reality". It's a modeling tool. Programmers and programming languages are about helping scientists and others get work done, not educating them about what a Python callable is, vs. an attribute. How your objection sounds to me: "how can you in good faith make humans look *that big* on a movie screen? -- humans really aren't that huge, nor are they flat." You seem to deny that it's OK to model, to represent, to use any special effects. Artists use perspective to give the illusion of depth on a flat surface -- is that somehow anti-scientific in your book? Properties are an "illusion" in the same sense. They're about mirroring expectations -- *legitimate* expectations. Likewise with the whole OO apparatus of classes and objects -- the cues come from reality, but the implementation (in the form of a computer language) is merely a representation (we hope a nuanced and expressive one). > Put properties away in your use case, and you have no choice but to > transcend the users' misaligned intuitions, and align with reality. > I don't for a moment believe that can be harmful to your > scientists/users. > I do. You're arrogantly putting Python front and center, thinking it defines "reality" in some sense, over and above what your client learned in medical school, banking school or whatever. *Ask* them what's a verb and what's a noun, don't *tell* them. Python shouldn't get in their way. > All of which is besides the point. > > Please stop implying that you have some insight that Python is > encouraging you toward this approach. > > It's slander - as far as I am concerned. > > Art You were the one suggesting Python was (inadvertently?) encouraging the use of attribute syntax to trigger methods. I'm agreeing with you, it does, and it should -- and it's not inadvertent. Bottom line: We're trying to paint it as *they* see it. This is not pandering. It's working with professionals who know their own jobs -- yet may know nothing much about programming. Kirby [1] for more re 'object worlds', see 'Designing Engineers (Inside Technology) by Louis L. Bucciarelli (MIT Press, 1996). http://www.amazon.com/exec/obidos/tg/detail/-/0262522128/ _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
