Kirby writes - 

> But then, programming with variables, the type of which may not
> be readily known to the reader, is not the same thing as raw
> entry of numbers into a calculator.  Just looking at raw numbers
> is to all together miss the point of adding a // key to this
> calculator (and saving / from doing double-duty depending on
> the type of inputs we feed it).

I guess I do communicate poorly.  My point was totally something
else:

What a end-user understands themselves to be working with 
determines their experience wth it.  If they aren't clear that they 
are in an environment where something other than calculator 
numerics is at work, the fact that they are getting results inconsistent 
with normal calculator numerics seems broken.  If their expectations 
are put properly in line with what they are going to experience,
the experience is changed.

By ultimate point is that I think that there has been an implicit assumption 
that 
lessons learned from environments like VPython in a college physics
class are somehow relevent or meaningful when speaking of,
let's say, a beginning programming class.

I contend that they are not different shades of gray.  They are just 
different, period. Design decisions that might well be good for
one constituency, could be directly counter-productive as to 
the other. 

It would be better if things were simpler. Its not my fault that they may not
be.

I happen to have a deeper interest in one constituenecy than the other.
So I have been struggling to get this simple distinction on some map.

Very badly.

ART 

 





_______________________________________________
Edu-sig mailing list
Edu-sig@[...].org
http://mail.python.org/mailman/listinfo/edu-sig