[Edu-sig] re: Types and true division (was Re: strange output)

[Kirby Urner]

Oh, OK, twist my arm, one more...

At 03:42 PM 10/10/2002 -0400, Art wrote:

>The old "/" operator is a gotcha if one choses to see it that way.  I had
>told you in a private note some time ago, that I found it a particulary
>nasty gotcha when raising to a fractional power. From an experiential point
>of view, that tended to be the only time I would *actually* get caught with
>my pants down.

But how much time have you spent trying to read code as elaborate
and math-invested as Pygeo's, yet not written by yourself?

>But I have the ability to foresee where Bruce's and Michael's students are
>most likely to get caught with *their* pants down, under the new operator.
>Which are ways even more subtle, IMO, but just as likely to arise as with my
>raised to a power issue.  So, on the gotcha score - at best a wash, IMO.

(You don't spell out the gotchas with the new behavior -- examples
might have been nice.)

Again, your model is the of lone coder, trying to get results,
wrestling with his or her own confusions and overcoming them.

But what about teams of coders writing stuff that future maintainers
will need to wrap their heads around?

The change in the div operator is what'll make Pygeo easier to grasp
when you're no longer around to explain how it works.  Commenting helps
of course, but a function like

   def op(a,b,c):
     return (a/b)+c

buried on line 10000, is just going to puzzle a reader (including a
pro), if they don't know immediately all the places op is invoked (and
why should they), and whether op expects floats, or integers -- and
given no explicit declarations, this'll be hard to determine (like,
maybe a,b,c are read from some raw data file -- this isn't Kansas
a.k.a. the C language, where you'd have int a; int b; float c declared
elsewhere, along with the return type of the function itself).

>With no generalizations to be made beyond that observation.
>
>Art
>

It's an observation based on an overly-narrow appreciation for what
programming involves, which is *not* just person X overcoming some
initial confusions and producing an elaborate, functional program.
You need one of those jobs where someone hands you 10000 lines of
Python code, with some subtle math-related bugs in it, and asks you
to track them down (by tomorrow, latest).

These days, I'm struggling with some Visual FoxPro thing (Xbase)
written by an amateur coder with a day job as a plumber.  He's since
moved to Colorado (I'm changing some of the facts, to protect the
guilty).  My client uses this program all day for mission critical
stuff.  There's no time to start over, so I have to gradually puzzle
through all this stuff, a lot of which is written in quirky ways
because he didn't really know Xbase all that well.

A test of Xbase's power and long term viability is how well it holds
up (in terms of readability, comprehensibility) in circumstances
like these.  If I have doubts about APL and J (REBOL?), it's in
this area also:  are these "write once, read never" languages? --
I haven't learned J well enough to know if easy fluency around
*other peoples code* (not just mine) is trully attainable
(presumably it is, but it takes more than a year to get there).

Kirby