Re: [Edu-sig] Explaining Classes and Objects
In a message of Sun, 12 Jun 2005 22:08:50 PDT, Kirby Urner writes: OO really is a different world. I think it still makes sense to teach the subject historically, even though we *can* start with objects at the same time. In other words, have students relive some of the trauma of moving from the procedural paradigm to the object oriented one -- not to traumatize, but to give the flavor of what paradigm even means (including that switching between them may be difficult). This may make sense for people who already know procedureal programming, but I don't think that it is a good idea for the rest of the world. I think that you need to learn about exception handling _early_ ... say right after you learn how to write a loop, and unit testing, and test driven design from the moment you get out of the 'how to play with the interpreter' stage. There isn't a lot of use in teaching people the procedural necessity of doing a huge amount of data validation, and how to deal with the 'cannot happen' of malformed data. It makes for really ugly code -- where it is close to impossible to find out what the code is supposed to do when nothing is wrong, and everything is working properly, because over 80% of it is to detect problems you hope you will never see ... just my 2 cents, Laura ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Teaching programming to physics students
At 20:24 11/06/2005, André Roberge wrote: My first suggestion would be to go through the edu-sig archives. :-) Heh, I've been trying but haven't found the search tool too helpful, with few results for 'physics'. Is there an official searchable archive (aka something with a good search index)? Thanks for the book recommendation, I've ordered it from the library. If I may suggest one additional topic (which I didn't see after a quick scan, it would be to explore simple functional programming techniques, and demonstrate the fundamental theorem of calculus, as inspired by Kirby. (http://aroberge.blogspot.com/2005/04/computing-derivatives-using-python.html) Thanks for the idea, it looks a fun idea to work in. Peter -- Maple Design - quality web design and programming http://www.mapledesign.co.uk ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Teaching programming to physics students
Hi, we have been running a computational physics course, for the third time by now. All the material given to the students can be found at http://www.comp-phys.tu-dresden.de/cp2005/ However, it is all in German. But still you might get an idea... Best, Arnd ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
In a message of Sun, 12 Jun 2005 22:08:50 PDT, Kirby Urner writes: OO really is a different world. I think it still makes sense to teach the subject historically, even though we *can* start with objects at the same time. In other words, have students relive some of the trauma of moving from the procedural paradigm to the object oriented one -- not to traumatize, but to give the flavor of what paradigm even means (including that switching between them may be difficult). This may make sense for people who already know procedureal programming, but I don't think that it is a good idea for the rest of the world. I think that you need to learn about exception handling _early_ ... say right after you learn how to write a loop, and unit testing, and test driven design from the moment you get out of the 'how to play with the interpreter' stage. The average beginner isn't going to know any programming, so why not start with class/object right from the top? Yet the procedural model requires less setup I think, less background. There's no class hierarchy to discuss. This is where the parallel experience with math, in algebra, will help, as in Python we have top-level functions, and procedural programming is mainly just organizing the flow in terms of a main procedure branching to and returning from numerous subprocedures e.g.: def main(args): vars = sub1(args) vars = sub2(vars) vars = sub3(vars) return vars Procedural code starts as simply as: def f(x): return x*x My approach is to start with a lot of a rule-based numeric sequences (the above generates square numbers): triangular numbers, Fibonacci numbers, other polyhedral numbers. This means writing a bunch of free-standing functions. But then suddenly you need one to call the other, i.e. when doing tetrahedral numbers, you need to stack consecutive triangles: def tri(n): return n*(n+1)//2 def tetra(n): sum = 0 for i in range(n): sum += tri(i) # -- function calling function return sum There was an earlier paradigm shift for the first users of procedural languages, such as FORTRAN. Formerly, it was OK to use a very convoluted flow based on GOTO -- lots of jumping around, giving us spaghetti code. The Dykstra came along and preached the gospel of structured programming (more like the above). A lot of programmers fought the idea of a right way to do flow. Having listened to more than a couple CS teachers describe their curricula, I'm seeing the procedural-first, OO-next approach is fairly widespread. The good thing about Python though is the OO model is deeply engrained, and just to begin explaining dot-notation is to enter the class/object discussion. What I come to is it's easier to think of objects as something you use, as primitives in the language, within procedural flows. Then take what you've learned about writing functions to write methods and start rolling your own classes. At that point, the full power of the OO model will start to dawn. What you say about getting into exceptions early is food for thought. I think you're probably right. Error handling is where the procedural flow gets especially ugly, what with all those case-based validations (switch statements trying to pin down all the ways a piece of data might be wrong). However, once again I think students may gain a deeper appreciation for exception handling once they've been exposed to the old way of doing it. But that doesn't mean weeks and months of coding in an obsolete style. One could go through the history in a short lecture, with projected examples. There isn't a lot of use in teaching people the procedural necessity of doing a huge amount of data validation, and how to deal with the 'cannot happen' of malformed data. It makes for really ugly code -- where it is close to impossible to find out what the code is supposed to do when nothing is wrong, and everything is working properly, because over 80% of it is to detect problems you hope you will never see ... just my 2 cents, Laura Yes, you've got a point. Validation still consumes lines of code, and we still prompt the user to try again, but the code isn't so gnarly. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
Kirby Urner wrote: Based on my working with Bernie, I think it's helpful to start early with the class/object distinction rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw() A useful note here: all programmers are _used_ to using objects: The file for I/O is an OS-defined object (without the nifty syntax in such cases). OO provides (A) a way to define abstractions that behave like the file abstraction yourself, and (B) a way to (at least sometimes) define an abstaction that is just like that other abstraction except. Until you have A, B doesn't make sense. B is hard to teach in that you need to go slowly -- the changes made by inheritance take a while to get. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
Classes are not a feasible choice to start with because they are a most complex structure in a programming language that builds on knowledge of virtually anything else. We agree on a lot of points. Because just about any decent Python script makes use of core data structures, such as the list, even if only as a range() return, dot-notation starts to be relevant right from the top. Explaining dot-notation as thing.action(inputs) identifies these things as the objects, with dot-notation being a postfix notation for calling, setting and getting. Indeed, using built-in objects is simpler than defining and using classes. Still, the concept of objects needs two underlying concepts: variables and method (function) calls. Object variables are not so trivial because object assignment is a reference assignment and therefore creates aliases. Method calls require understanding of arguments and return values. Thus, it is beneficial to study functions, variables, and controls structures for a while, before coming to built-in objects. Yes, but I still need to explain dot-notation, even in the early days of just doing simple functions. Indeed, I might argue that the simplest intro to conditional flow might be the if clause in list comprehension syntax, i.e. now that we're comfortable with generating in the form [f(x) for x in range(n)], let's now add ... if x%2] or some such. However, the idea of a list object should already be in place by this time, i.e. we've looked at [].sort() and so on. Why I'm not so concerned about the fine points of passing by reference, aliases and like that is I'm confidant that class/object thinking is already engrained, simply through exposure to Aristotelian taxonomies. Kids visit the zoo. They understand cat family inheriting mammalian characteristics, under the kingdom of animal (which excludes spinach). So there's your class hierarchy, generic blueprints vs. instances, and individual state variables. Now express that in dot-notation e.g. thetiger.yawns(). In other words, go to the roots of the metaphor and forget about the nitpicky details of computer languages. Come back to that later, but get enough of the concepts to make dot-notation comfortable very early in the game. I'm a philo major, not a CS major, which may account for my willingness to forget about ... computer languages from time to time (whenever convenient). Personally I believe that lists, dictionaries, and strings offer a great opportunity to introduce objects. There a lot of interesting methods that can be explored interactively and that can be used to write interesting programs. Introducing objects with GUIs is OK, but GUI objects seem to offer fewer opportunities for interactive exploration than lists, dictionaries, and strings. I'm inclined to agree. On the other hand, I see a need to instill in newcomers that visualization is going to be part of what's coming. They want some assurance up front that graphical content won't be ignored. So sometimes I feel pulled towards GUI-based examples ala John Zelle's graphics.py simply because I know students *want* to go there, and I'm reluctant to resist them. That being said, I don't like doing *only* GUI-based examples. Anyway, IDLE is a GUI, so if you're doing shell in IDLE, you're ipso facto using a GUI (the same could be said of an x-term window). I cover class definitions as a last theme in my CS1 with Python course. The continuation is CS2 with Java, an entirely class-oriented course. No CS2 student has ever complained that classes seem unnatural or difficult to understand. This is because, I believe, classes come at the right time - after all underlying concepts have been well understood. Atanas Radenski mailto:[EMAIL PROTECTED] http://www.chapman.edu/~radenski/ I think this is a viable and likely-to-be-popular approach. Use Python for a first year, then switch gears and get more heavily into OO at the same time, say with Java or C# or... Some will encourage Jython (which I have no problem with -- wish I had more time to play with it). My own framework is based in somewhat different assumptions: pre-college students trying to avoid learning everything twice, once *with* dot-notation and once without. My working hypothesis: the class/object metaphor is useful enough to merit inclusion of dot-notation in mainstream K-12 mathematics. For example, if you want to invert a matrix, write thematrix.invert() -- presuming its invertible. Or you can still write thematrix**(-1) too if you like (operator overloading at your service). So in my course, we're learning about matrices, vectors, polynomials, integers modulo N *as objects*. It's a programming to learn course, i.e. the use of Python is a means to an end: a stronger conceptual grasp of various core mathematical ideas, algorithms, ways of approaching a problem. We have yet to clearly differentiate between CS and traditional mathematics at this level
Re: [Edu-sig] Explaining Classes and Objects
You might try: These names don't just exist in some primordial soup. There has to be a place they get stored. There is a bit of magic: import __main__ a = 24 print a, __main__.a __main__.a = 365 print a, __main__.a And even: print a, __main__.a, __main__.__main__.a After which I might go: dir(__main__) ['__builtins__', '__doc__', '__main__', '__name__', 'a'] dir(__builtins__) That'd connect back to Laura's focus on exception handling -- clearly the Error related content in __builtins__ is significant. type(ArithmeticError) type 'classobj' dir(ArithmeticError) ['__doc__', '__getitem__', '__init__', '__module__', '__str__'] ArithmeticError.__module__ 'exceptions' EnvironmentError.__module__ 'exceptions' import exceptions dir(exceptions) Now everything is dot notation, with some of the thing. stuff assumed. Eventually you'll have to say locacal variables don't really work like that, but they are close. universe.milkyway.sun.earth.hawaii.maui is another way to introduce dot-notation. It's about progressively zooming in, or out, through a succession of progressively more, or less, encompassing domains. This gets us back to the root class/object metaphor, which allows us to appreciate the ordinary interaction of any two objects as involving encapsulation, polymorphism and message-passing i.e. the original SmallTalk paradigm. Kirby --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
whoops, sent this reply off-list by accident (apologies to Scott) Here's a thought that just jumped into my mind, I don't know if it has any value, but bear me out: I think it probably makes most sense to introduce programming to totally new people in a procedural/structured/whatever you want to call it way. My feeling is that most people who haven't done any programming think of a computer program as a big list of instructions for what to do, and this model should be pretty easy to introduce to them. Now you start to try to do more compliated things, and you have to start accumulating global state so that your many functions can do meaningful things without having to pass loads of arguments around. Pretty soon, depending on the topic, you probably want a way to group global variables together -- the first approach might be to name them similarly, like foo_bar and foo_baz for bar and baz relating to foo. But what if you have two different things of type foo? Now introduce objects as essentially structs. You have a class definition, like: class Foo: bar = someDefault baz = someDefault and just work with that for a while. Now, you are passing around Foo's as arguments to your functions, and you realize that certain functions can only work on Foo's, while others can only work on OtherThing's. Isn't it logical to group your functions in the same way as your variables? Oh, look, thats object-orientation (or the core of it), and you got there all on your own. My experience as a student has been that the best teachers are the ones who give you all but the conclusion, and let you make the final leap yourself. That, I think, makes the knowledge both more likely to stick, and the excercise (which is probably at least somewhat artificial, as most exercies tend to be) more exciting, as you feel like you're making a new contribution to how it all works. Anyway, that's roughly how I had been introduced to OO programming over the years: first BASIC, learning the, well, basics, of program organization with sub's; next, larger scale programs, maybe in C, organizing static members and functions into files; soon structs; then full-on OO with Java (which I loathe), and later Python and C++. Just my $0.02 dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
Hello Scott,
Monday, June 13, 2005, 10:16:12 AM, you wrote:
SDD Kirby Urner wrote:
Based on my working with Bernie, I think it's helpful to start early with
the class/object distinction
rectobj = Rectangle(...)
rectobj.setWidth(10)
rectobj.draw()
SDD A useful note here: all programmers are _used_ to using objects:
SDD The file for I/O is an OS-defined object (without the nifty syntax
SDD in such cases). OO provides (A) a way to define abstractions that
SDD behave like the file abstraction yourself, and (B) a way to (at
SDD least sometimes) define an abstaction that is just like that other
SDD abstraction except. Until you have A, B doesn't make sense. B
SDD is hard to teach in that you need to go slowly -- the changes made
SDD by inheritance take a while to get.
They're used to using objects in real life, but they're not used to
having scaffolding when it's not needed. Case in point:
class Hello {
public static void main(String[] args) {
System.out.println(Hello);
}
}
What's a beginner supposed to do with this Java program? What's
public? static? void? etc. Of course:
print 'Hello'
they can handle just fine. After a little experience with the
interpreter, they can easily pick up methods:
words = s.split()
They just grok immediately that what follows the dot pertains to
what is before it. This is a perfect lead-in to real classes.
After having taught C, C++, and Java for years, and mathematics for
decades, my 2 cents are:
1) Start with what they know from real life (numbers, simple computations, text
processing), in this sense, you begin procedural to some degree
2) Python is the best thing I've seen in 30 years of computing for
pedogogical and productive purposes. Only when I want speed do I see a
need for something else (I'm a C++ guy).
As I predicted last week, my current corporate teaching of Python at
Symantec is exceeding expectations. I am teaching testers, mostly with
no programming experience, Python programming. Man are we smokin'! Man
are they going fast! And they are *so* impressed. We just finished our
third 4-hour session with list comprehensions and all about
dictionaries (every method, including iterators). After modules we'll
hit classes. This has been one of the easiest and most rewarding
teaching experiences in my career. Even those who have a little Python
exposure are amazed when they see truly Pythonic solutions.
Python lets you start where people are and naturally proceed to
higher-level abstractions. But wait at least until the 4th or 5th day
before you do classes :-).
--
Best regards,
Chuck
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
