Re: Python Programming: An Introduction to Computer
I wasn't doing that though. I realize there are lots of worthwhile languages out there and it pays to move on from Python. But it also pays to come back to it later, and if all the Python you ever get is in CS1, then you might not realize some of its power.
This is equally true for some other languages.
Which begs the question: why Python instead of these other languages? Given the choice between teaching CS students more Python or teaching a new language (such as Prolog, Scheme, ML, or Haskell), I would decide to teach a new language. Anyways, I think that many students who continue to program will simply continue to use Python when it makes sense. That's been my experience so far.
How is this different from discussing "neat features"? That you can use such simple syntax to do file I/O, or don't need a lot of type declarations, are *features* which lead to higher productivity.
I guess that's true. When I think about it, for me the question is "How do I convince my department to change CS1 from Java to Python?", and listing language features isn't the answer. Neat language features are a dime a dozen in CS. By the way, I am in "Zelle's camp": http://tonka.iat.sfu.ca/toby/pythoned/pp4e. I don't think Perl, Ruby, or Scheme (or VB, PHP, JavaScript, Tcl/Tk, ActionScript, etc.) have any hope of becoming popular CS1 languages the way Python does. Toby -- Dr. Toby Donaldson Assistant Professor School of Interactive Arts and Technology Simon Fraser University
This is equally true for some other languages.
Which begs the question: why Python instead of these other languages? Given the choice between teaching CS students more Python or teaching a new language (such as Prolog, Scheme, ML, or Haskell), I would decide to teach a new language.
Yes, and I said I understood why CS2 was about Java and not more Python. I said the reasoning for this was solid. My frustration/worry was that if Python always gets beginner treatment, that people might never get to appreciate some of its deeper structure. For example, I think the reason it's often compared to LISP is you have all these hooks into the syntax itself, such that you can program at the meta level. Changing the meaning of the arithmetic operators is just the beginning. One thing I like to do when introducing Python is:
dir(1)
And then talk about what the output is telling us (basically, this is about type/class unification, which recent versions of Python have worked hard to achieve). But I didn't argue that the solution was to abandon other languages and just go with Python. On the contrary, my position, consistently, has been that any real computer science curriculum needs to include exposure to multiple languages.
Anyways, I think that many students who continue to program will simply continue to use Python when it makes sense. That's been my experience so far.
I've been somewhat reassured by a number of posts to this effect. Let's hope that it's true.
By the way, I am in "Zelle's camp": http://tonka.iat.sfu.ca/toby/pythoned/pp4e. I don't think Perl, Ruby, or Scheme (or VB, PHP, JavaScript, Tcl/Tk, ActionScript, etc.) have any hope of becoming popular CS1 languages the way Python does.
Toby
Me too (in Zelle's camp). Kirby
For example, I think the reason it's often compared to LISP is you have all these hooks into the syntax itself, such that you can program at the meta level. Changing the meaning of the arithmetic operators is just the beginning.
Um, this is not a "hook into the syntax", and operator overloading isn't very Lispish; I think the concept actually came from Algol-68 and was popularized by C++. Lisp's hooks into the syntax are a lot more direct: its syntax actually translates to a data structure that is directly manipulable from inside the program, which is not how Python works. The available "representations" of program code are either trivial (strings), immutable (code objects) or extremely hard to handle (parse trees). And there is no way to change the *syntax*. About the main topic of this weekend's thread, I am happy to hear Python's role in the CS curriculum clarified (thanks to John Zelle's book as a conversation-starter), and I am seeing some posts from Arthur that I can actually understand. --Guido van Rossum (home page: http://www.python.org/~guido/)
Kirby:
For example, I think the reason it's often compared to LISP is you have all these hooks into the syntax itself, such that you can program at the meta level. Changing the meaning of the arithmetic operators is just the beginning.
Guido:
Um, this is not a "hook into the syntax", and operator overloading isn't very Lispish; I think the concept actually came from Algol-68 and was popularized by C++.
By "hook into the syntax" I meant the ability to change the behavior of obj() via __call__, or obj.a via __getattr__ or __getattribute__. Or we might change the behavior of obj[a] (__getitem__). I see overloading of arithmetic operators as just the beginning.
Lisp's hooks into the syntax are a lot more direct: its syntax actually translates to a data structure that is directly manipulable from inside the program, which is not how Python works. The available "representations" of program code are either trivial (strings), immutable (code objects) or extremely hard to handle (parse trees). And there is no way to change the *syntax*.
This is a sort of perverse example, but is what I was trying to get at re "syntax overloading":
class P: def __init__(self,value): self.value = value
def __getitem__(self,other): return P(self.value + other.value) def __repr__(self): return "P: value = %s" % self.value
p1 = P(3) p2 = P(5) p1[p2] P: value = 8 p1[p2][p1][p2][p1][p1][p1] P: value = 25
Many other languages wouldn't let you mess with the behavior of square brackets like this. Not that we'd want to in just this way of course. True, the syntax is still legal Python. What's changing is behavior.
About the main topic of this weekend's thread, I am happy to hear Python's role in the CS curriculum clarified (thanks to John Zelle's book as a conversation-starter), and I am seeing some posts from Arthur that I can actually understand.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Kirby
participants (3)
-
Guido van Rossum -
Kirby Urner -
Toby Donaldson