[Edu-sig] quantum instance

[Kirby Urner]

> 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/