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