> > > Maybe we should advertise this more. One of the pedagogical issues in > > > question (hence cc:ing to sage-edu) is that we *do* eventually want > > > students to get more sophisticated, and so I have been careful *not* > > > to use this. Especially math and science majors are almost guaranteed > > > to need to know how to program if they do not go into education, and > > > it's a boon to them if they do, so knowing the OO paradigm (even if > > > they don't call it that) can be useful. > > As a CS --> math convert, I'm sympathetic to this perspective; my
Hmm, as a math --> programming pseudo-convert, this is why I'm starting to feel like my students should really be dealing with this - because it was difficult for me, not having been exposed to it early, and they're going to have to know it anyway eventually. I'm discovering, for instance, that they really take to LaTeX, even though I would have been petrified by it as an undergrad; now I wish I had known it then! Then again, in my intro courses, I don't have them directly using Sage commands in any case - it's all about the interacts. That's how I get around this issue (and I would argue this is the "correct" way to do so, in some sense). > differential equations courses effectively convert to Python / Sage > courses for a week or two each semester. But there is a large block > of potential "consumers" out there that struggle with getting anything > useful out of Sage due to language issues that have become automatic > for the rest of us. Making life easier with method calls (without > clobbering the whole language) seems like it could greatly increase > the accessibility of Sage to new users. Yes, of course. The question is how to do this in a coherent way. We'd almost need to have two separate sets of documentation, and there is the "clobbering" issue you raise, not to mention the problem we currently don't have (as often) of people trying to do the wrong thing to the wrong object. People learn to LOVE tab-completion after the dot; it just makes more sense than searching through documentation for functions that might or might not apply to mathematical object X. And then there's the whole problem that the GUI is still not really point- and-click or dragging math stuff (though presumably this could be built on top of Sage easily enough by some dedicated team who really wanted to do so and had enough time to do it?). That said, I don't want to be a naysayer; despite these barriers or quasi-objections, if a good set of introductory documents were available which showed how to use this, that would be all we really need. Well, that plus the "clobbering" issue fixed, I guess. You may want to ask Fernando and/or the IPython list about the details of the last pieces of your implementation, they seemed to be interested in the potential at the time. > You could also make the case that aliasing f(A) to A.f doesn't mean > abandoning the OO paradigm; we could read "f(A, ...)" as "pass the > message f to A with parameters ..." This is consistent with the Sure, fair enough. Insofar as I understand OO programming, which is not very much. But I think your point makes sense even to me. Any other thoughts by sage-edu folks about the "dot notation" being a hazard? -- You received this message because you are subscribed to the Google Groups "sage-edu" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sage-edu?hl=en.
