As a math teacher, I always fear that I am teaching my students a particular piece of technology rather than the concept that I am trying to teach. As a small example, I am confident that my students can find the point of intersection between two lines with a TI-83, but less confident that they can find it with a TI-92 or a Casio-whatever; and I often fear that they don't recognize that they would get the same answer by solving each equation for y, setting the y's equal to each other, and then solving for x.
Geometry packages give an even clearer, more appropriate example. The two leading commercial products (one of these days I'll take a look at pyGeo and see what it does) are Gemoter's Sketchpad (GSP) and Cabri. Most high schools seem to use GSP, where I've heard that several universities use Cabri. The programs are opposite in orientation; GSP is more object oriented (click a pair of points, then choose the command to draw a line through them) where Cabri is more procedural (at least for the old version, you would say that you are in line-drawing mode, and then choose two points). I often fear that I am teaching GSP rather than geometry, and I know that (of those who use GSP) most of my colleagues within my own building are afraid of Cabri because they have only used GSP. It is fine and good to learn a single language, but this is not computer science. A single language is just a tool. It is necessary to learn several languages in order to have an idea of what computer science actually means. Different languages have different orientations, different tools, and different fundamental assumptions. I would want my students (indeed, myself) to be able to solve a problem/write a program satisfying particular criteria in ANY appropriate language, and also to recognize which languages are inappropriate for a given task. Prerequisite to this is knowledge and use of more than one language. Not a good language? Depends. What's the task? On 5/26/05, Arthur <[EMAIL PROTECTED]> wrote: > > > Got through the first few chapters of "Practical Common Lisp". > > Whether I end up liking Lisp remains to be seen, but I have seen enough > already to begin to appreciate Lisp. > > And have more confidence that my instincts where sensible - taking this > detour as a way of getting to the next stage as a Python programmer. > > And the experience, so far, also reinforces my instincts about Python - as a > learning language. With little other than some Python under my belt, I can > make my way through the Lisp presentation feeling prepared and competent. > > So in my case, Python has been foundation for exploring first Java - and > getting far enough into it that I felt I understood its fundamentals, and > that I could become competent in it should I choose (and chose not to) - > and now Lisp. > > I would think that the fact that Python has provided a foundation that could > take me in each of these directions says a lot its utility as a learning > language. > > I just wish, as always, we could disassociate "learning language" from the > notion of "easy". I wouldn't expect an effort that provides the foundation > for learning of approaches to programming as diverse as Java and Lisp to be > easy. My sense is that in some important senses learning Java is easier > than learning Python. But at the end of it I also suspect that one is a > Java programmer - and little else. Which is why it is not a particularly > good learning language. > > Art > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig