On Sat, Sep 6, 2008 at 1:09 PM, Andre Roberge <andre.roberge@gmail.com> wrote:

On Sat, Sep 6, 2008 at 11:29 AM, <ajudkis@verizon.net> wrote:

...

Steve,

Neat idea, nice implementation! I want to call everyone's attention to RUR-PLE, another Karel successor that the students control with actual Python. I've used it quite successfully for 3 or 4 years now, it provides a great wading pool for trying out the basic concepts, and they get exposed to the real syntax from the first day.

Check it out at http://rur-ple.sourceforge.net/.

And Andre, if you're reading this, my students still have a soft spot for Reeborg, some of them were talking about him just yesterday.

:-)

Yes, I am still reading this. :-)

While rur-ple is very usable in its current state (1.0 release candidate 3), there are still a few things left to clean up for the final 1.0 release. "Unfortunately", I have not had the energy to spend any time on it for well over a year. I put "unfortunately" in quotation marks the lack of time spent on rur-ple has been caused in large parts by working on Crunchy. And "one of these days", Crunchy will support an embedded world for Reeborg to move in. Perhaps it will make use of Steve's Webster...

Well, it turned out to be easier (to get started) than I thought. For those interested, I have adapted Steve's Webster so that 1. it uses Reeborg's images (which I did send to Steve as well) 2. it has a color scheme inspired by rur-ple 3. it uses a *small* subset of Python's syntax. For example, the following is a valid program: for some_variable in range(4): move() turn_left() move() build_wall_on_left() If you want a copy to play with, please send me an email off-list. Cheers, André

Cheers,

André

...

Cheers, Andy Judkis Academy of Allied Health and Science Neptune, NJ

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

On Mon, Sep 8, 2008 at 12:44 PM, kirby urner <kirby.urner@gmail.com> wrote:

...

For example, the following is a valid program: for some_variable in range(4): move() turn_left() move() build_wall_on_left()

So no explicit target or receiver for the message, as the Smalltalk people might say? I.e. you don't say myturtle.move() but just move(), more like Logo?

That is correct. This is how Guido van Robot is [although it uses move and not move()], and how rur-ple is. In rur-ple, one can later have reeborg = Robot() reeborg.move() reeborg.turn_left() etc., but it does start with simple functions and build from there. One can see move() as equivalent to reeborg.move(), but where the instantiation of the Robot class has happened behind the scene, i.e. reeborg = Robot() move = reeborg.move turn_left = reeborg.turn_left etc. My plans would be the same when integrated with Crunchy. I think (and Andy will be able to confirm/infirm based on his real life experience) that it is better to use a more gradual approach like this (i.e. hide the object-oriented construction at the beginning). André

Kirby

Thanks for the clarifications, good to know both options (receiver and receiverless) are both in the mix. Our use of 'procedural' may confuse some students as OO syntax is eminently step-by-step with flow of control and all the rest of it, very recognizably procedural the way I learned the term, with or without the explicit dot notation (which is difficult to hide in real Python). I'm inclined to *not* see 'procedural' and 'object oriented' as orthogonal concepts i.e. they mix together. Where I do see a big dichotomy is in whether one is expected to define new classes oneself, or simply use the ones provided. Apparently early versions of Visual Basic were "read only" in terms of not having a class defining infrastructure, merely giving developers access to canned OCX objects (instances) with canned APIs, but I could be wrong, that's not a track I've ever followed, even to this very day. As I mention in my Chicago talk, I tell my students "I've never heard of procedural programming, it gives me the creeps" but that's just a rhetorical device to get the ball rolling, as I start with dot notation immediately, within the first 10 minutes. But that's because I'm teaching core Python, not another language *implemented* in core Python. These aren't little children. They may have done Logo or other 3rd person avatar controlling (ala Sims) well before taking my class, so I presume this as background, allude to Sims as "objects" and so on, project a YouTube or two if they seem unclear what I'm talking about. Kirby

This sounds like something we should hear about at PyCon 2009 in Chicago. Can you do it either as a presentation or a tutorial? If you can, we can organize a coding sprint for you. Also, please consider any such educational Python projects for inclusion in Sugar on the OLPC XO. http://www.sugarlabs.org/. On Mon, Sep 8, 2008 at 10:23 AM, kirby urner <kirby.urner@gmail.com> wrote:

Just to elaborate a bit, I do get around to telling longer stories, sharing "geek lore" as I call it, and the story I tell goes something like this:

In the early days of assembly language, it was all about conditional jumping to get choices or forks in the road, which led to a first generation of higher level coder to write "spaghetti code" even when infrastructure for subprocedures was provided.

Djikstra went on the war path to rationalize coding around a main call sequence with branching to subprocedures in a tree pattern, reusing library utilities, but with much less reliance on global variables, context, side effects, other subtle stuff (all that "anti-encapsulation" infrastructure). "Never use GOTO" was his advice and many languages took it out.

*That* was the hallmark of the 'procedural programming' era (might've been called 'subprocedural' but that's picking nits), to never use GOTO, or at least not gratuitously (which is almost always is), to always do a kind of top-down style with a main call sequence.

The OO revolution built on top of the procedural programming resolution, by giving us encapsulation and inheritance infrastructure that would more closely model the guts of a knowledge domain, i.e. your job is to think in terms of cells, DNA, airports, train yards or whatever but *not* in terms of some CPU with access to memory (way too low level and irrelevant to the problems in scope).

OO was also of key importance given the evolution of GUIs and non-menu-driven modes of interactivity, where users could (and still do) fire off events from a mouse, keyboard, any number of screen widgets, and the code had to be "ready" (i.e. "listening") -- much more like interrupt-driven operating system design, with event queues and so forth.

This is still a challenging kind of programming, goes into threading and the rest of it, but we get our feet wet with such curricula as John Zelle's, which relies on the cross-platform Tk widget set.

I prefer doing more with SQL first, introduce "multi-user" as an ACID challenge (thinking about airline reservations systems), then turn to the Web for widget programming, skip the whole "thick client" business until a later course. The old LAMP infrastructure really doesn't require any specialized widget programming, just XHTML forms, buttons and so on.

Python is a clean implementation of the OO style of thinking, and if your knowledge domain is amendable to decomposition in terms of objects, then chances are there'll be a way to express it in OO terms. Instances are a lot like subprocedures in some ways, in promoting encapsulation, not willy-nilly sharing of globals, plus we still don't need GOTO if we ever did (we did with assembler, still do).

I've notice high schoolers are able to follow all this, a kind of storytime interlude, like when a teacher reads a story to the group, although here I ad lib, might project a comic strip sometime.

I could also see doing this history in a more cartoon form, have been urging O'Reilly to branch into the cartoon business more concertedly, but that's a difficult transition for a wood pulp publishing giant ('Head First' a good first step).

There's lots more to this lore (some of which I get to, a lot of which I'm still learning), but the mode is one of standing back, overview, altitude viewing. That's very important in introductory classes, in literature, philosophy, art or mathematics. We neglect it at our significant peril in my view. Leave out the historical dimension only if you wish to consign your curriculum to the ash heap of history is my motto.

These days, I'm less likely to work directly with high school aged students, am more peddling my Python Briefing to their teachers, so they're the ones getting this lore, perhaps to pass it back to their math classes, along with a syllabus of optional viewing DVDs etc., plus Neal Stephenson's 'In the beginnning...' is still a classic.

Kirby

On Mon, Sep 8, 2008 at 9:41 AM, kirby urner <kirby.urner@gmail.com> wrote:

...

Thanks for the clarifications, good to know both options (receiver and receiverless) are both in the mix.

Our use of 'procedural' may confuse some students as OO syntax is eminently step-by-step with flow of control and all the rest of it, very recognizably procedural the way I learned the term, with or without the explicit dot notation (which is difficult to hide in real Python).

I'm inclined to *not* see 'procedural' and 'object oriented' as orthogonal concepts i.e. they mix together. Where I do see a big dichotomy is in whether one is expected to define new classes oneself, or simply use the ones provided.

Apparently early versions of Visual Basic were "read only" in terms of not having a class defining infrastructure, merely giving developers access to canned OCX objects (instances) with canned APIs, but I could be wrong, that's not a track I've ever followed, even to this very day.

As I mention in my Chicago talk, I tell my students "I've never heard of procedural programming, it gives me the creeps" but that's just a rhetorical device to get the ball rolling, as I start with dot notation immediately, within the first 10 minutes. But that's because I'm teaching core Python, not another language *implemented* in core Python. These aren't little children.

They may have done Logo or other 3rd person avatar controlling (ala Sims) well before taking my class, so I presume this as background, allude to Sims as "objects" and so on, project a YouTube or two if they seem unclear what I'm talking about.

Kirby

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

-- Silent Thunder [ 默雷 / शब्दगर्ज / شبدگر ج ] is my name, And Children are my nation. The Six Worlds are my dwelling place, And Truth my destination.

Hi Kirby, Thanks for this response, and the follow up as well. See my comments and questions inline. Thanks, Steve --- On Mon, 9/8/08, kirby urner <kirby.urner@gmail.com> wrote:

From: kirby urner <kirby.urner@gmail.com>

Our use of 'procedural' may confuse some students as OO syntax is eminently step-by-step with flow of control and all the rest of it, very recognizably procedural the way I learned the term, with or without the explicit dot notation (which is difficult to hide in real Python).

Agreed that 'procedural' and 'OO' have a lot more common than different. I didn't mean to suggest in any way that the concepts were orthogonal. Python does have plenty of builtins, where the target is either implicit or supplied as a parameter: http://docs.python.org/lib/built-in-funcs.html Perhaps the "print" statement would be the best example in Python of conciseness winning out over explicitness. Java is perhaps the other extreme, with its "system.out.println" idiom.

I'm inclined to *not* see 'procedural' and 'object oriented' as orthogonal concepts i.e. they mix together. Where I do see a big dichotomy is in whether one is expected to define new classes oneself, or simply use the ones provided.

I agree with the dichotomy. There's some middle ground too, where students can alter or extend existing classes before they write their own.

Apparently early versions of Visual Basic were "read only" in terms of not having a class defining infrastructure, merely giving developers access to canned OCX objects (instances) with canned APIs, but I could be wrong, that's not a track I've ever followed, even to this very day.

Most of us learn to read before we write, so I'm not so sure it's necessarily a bad thing to introduce OO to students as consumers before they become producers. On the other hand, I totally understand your desire to have students write their own objects from the beginning. What's an example of a small Python program that your students have written that uses objects that they built? Do they start with model/view/controller objects or otherwise?

As I mention in my Chicago talk, I tell my students "I've never heard of procedural programming, it gives me the creeps" but that's just a rhetorical device to get the ball rolling, as I start with dot notation immediately, within the first 10 minutes.

Do students ever get confused by the dot notation, or at least frustrated with the wordiness?

But that's because I'm teaching core Python, not another language *implemented* in core Python. These aren't little children.

I think it's great that you have students who are ready to jump right into core Python, but I don't think you have to be a little child to benefit from small languages like Karel, Logo, and various cousins. When I was in college, lots of non-CS students got exposed to programming through Karel and got a lot out of it. That was nearly 20 years ago, so I'm sure today's generation comes in with a little more sophistication, but I still see the benefit of starting with a language with very limited syntax. Even if you have a bit of programming background coming into a small language, it can still be a really refreshing exercise to work within its limitations. One of the funnest programs I ever wrote was to have Karel determine whether his beeper world was palindromic. Try to do that without variables! Getting back to little children, though, I do think there will come a day where smaller children learn to program as easily as they learn reading, writing, arithmetic, music, etc.

Steve Howell wrote:

There are some object-oriented variants of Karel the Robot:

http://pclc.pace.edu/~bergin/karel.html

Guido van Robot and Webster van Robot are purely procedural, which has the following benefits:

1) There's a lot less typing, which means more time for thinking, exploring, etc. 2) You can master simple, but fundamental, concepts like creating methods and nesting loops without the conceptual overhead of object-oriented programming.

I would love to brainstorm ideas on creating a path from GvR and WvR to more object-oriented programming. IMHO you need to make sure you do it in a non-superficial way. For example, I would want your object space to be rich enough that you actually have objects that interface with each other.

The way it usually is presented in Logo is like: TELL :robot [FD 10] That is, you have some actors (activated with TELL), and you have commands, and the commands are passed to the actors. There's a default actor. Like everything else in logo, it is dynamically scoped, not lexically, which makes methods and functions less distinct. That is, if you do: TO SQUARE :size REPEAT 4 [FD :size RT 90] END TELL :robot [SQUARE 100] then even though SQUARE is a procedure, it uses FD, and FD is a method. Or, something like a method. Anyway, it's not exactly applicable to Python, though it could be. Here's a factoring of turtles: class active_method(object): def __init__(self, func): self.func = func def __get__(self, obj, type=None): if obj is None: # Maybe with some default too, like the turtle module lazily # creates an instance obj = type.active_turtles[-1] return new.instancemethod(self.func, obj, type) class Pen(turtle.Pen): active_objects = [] def __enter__(self): self.__class__.active_objects.append(self) return self def __exit__(self): active = self.__class__.active_objects assert active[-1] is self active.pop() @active_method def fd(self): whatever fd does... ... and so one, with more @active_method... fd = Pen.fd ... and again, for every method ... def square(size): for i in range(4): fd(size) rt(90) with Pen(): setxy(100, 10) square() -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org