Lots of interesting comments. A few responses:
1. I'm not saying that Python is infeasible as an introductory language. One of the things I really like about the idea of Python for educational purposes is that you can do complex things fairly simply, and at the end of the course, you have also learned a language that is practical for day-to-day use. However, I do feel that the drawback I pointed out is a legitimate one. It is through discussions like this that perhaps Python or a derivative language can one day be made an even better tool for educational purposes (although as I understand it, there is no longer any funding for exploring an educational-specific environment for Python). 2. My teaching experience is limited, but I did teach one programming class to a group of middle-schoolers. The most common mistake was, by far, simple misspellings of variable names (usually capitalization confusion). When a compiler catches this, it's no big deal. When a compiler reports cryptic error messages, or none at all, for such a common mistake, that can be a big problem. So I'm not making up this example out of thin air. I have seen this as a common problem (in younger children who have limited typing experience). I can imagine that a different class of errors might be more prevalent in high schoolers or college students. 3. I stated an opinion that I would be reluctant to use Python for a large-scale project. A number of people objected. It appears that the philosophy of the Python community (speaking in generalizations) can be summarized as, "We have to do runtime testing anyway, so there's no need for any compile-time checking." I disagree. I feel that every little bit helps. And in my opinion, the future of programming will rely on highly intelligent compilers which ensure that the code is as correct as its specifications. The functional programming academicians have made quite a bit of progress in this direction, and I've heard some amazing stories about the robustness of code written in a language called 001. Nevertheless, I acknowledge that _at the current time_, Python's design decision to gain flexibility at the expense of additional safety checks is a reasonable one. But I also believe that it is possible to have our cake and eat it too. An ideal educational language (and perhaps the language of the future, incorporating everything we now know about building robust code), will have both. 4. Arthur felt I was suggesting that "we need to teach the programmers early on that they are not responsible for mistakes". Well, yes and no. Let's say you designed a spaceship, and put a big red "self-destruct" button right by the pilot's knee. You told him over and over again, "Remember, when you sit in the chair, whatever you do, don't bump the button." You train him over and over again not to hit the button. But then, sure enough, one day he bumps the button by accident with his knee, and the spaceship explodes. Is that the pilot's fault, or the designer's? Surely some of the blame rests with the designer, who should design a system that takes into account the fact that to err is human. 5. We all carry a certain amount of baggage and bias to this discussion. In the interest of full disclosure, here's mine: I learned programming through a progression of Scheme followed by C++ (and of course dabbled in Basic and Logo as a kid). I have tried programming in dozens of languages, just for fun, because I love programming languages of all breeds. My favorite language is Dylan, which I think best demonstrates the "have your cake and eat it too philosophy" of providing dynamic AND static typing, object-oriented AND functional programming styles, an interpreted interactive environment AND native-compilation, and so on. (Unfortunately, the language has very little support or active development, and so it isn't a very practical choice right now). I think objects are overrated, but certainly useful. I think functional programming is extremely powerful, but I wouldn't want to have to use it for everything. I use Python as my primary programming language, because it has most of the features I want, an extremely practical set of libraries, and a syntax and primitives that I can easily remember (which is important because I program infrequently these days, and don't want to have to look everything up each time I come back to programming). If I were to teach a class to middle-schoolers or high-schoolers (which I hope to do soon), Python probably wouldn't be my first choice (although I'd be sorely tempted). I'd probably lean toward Scheme for high-schoolers (the DrScheme environment is quite impressive from an educational standpoint), and Squeak for middle-schoolers. I joined this list because I genuinely want to engage in discussion about how to make Python more suited for education. 6. I want to wrap this up with one more point that I'd love to see discussed here. It seems to me that ideally, an educational programming language should emphasize one of the dominant programming paradigms in a very "pure" fashion. But Python, as useful as it is, is anything but "pure". Although I'm not an OO expert, I suspect that there are a number of features in Python that have OO-purists shaking their heads. And I know that Python also holds several disappointments for FP-purists (lack of tail recursion, for example). Because Python is a pragmatic hybrid approach to programming, it can give you some sense for OO, and some sense for FP, but I worry that it's not really pure enough in either respect to get to the heart of either. --Mark _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
