teaching OO

[Gabriel Zachmann]

This post is not strictly Python-specific, still
I would like to learn other university teachers' opinion.

Currently, I'm teaching "introduction to OO programming" at the undergrad
level. My syllabus this semester consists of a bit of Python (as an example
of a scripting language) and C++ (as an example of a compiled language).
With C++, I go all the way up to meta-programming.

My question now is: do you think I should switch over to Python completely
(next time), and dump all the interesting issues involved in C++'s virtual
classes, overloading, and templates? (In Python, all of that would just
disappear ... ;-) )

(The opinion of the people on this NG might well be a little bit biased
towards Python, but that's ok ;-).)

Interested in all kinds of thoughts.

Best regards,
Gabriel.

--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

[Stelios Xanthakis]

Gabriel Zachmann wrote:

My question now is: do you think I should switch over to Python completely
(next time), and dump all the interesting issues involved in C++'s virtual
classes, overloading, and templates? (In Python, all of that would just
disappear ... ;-) )

No! Python, being a dynamic language has certain advantages over
compiled languages.
In analogy with C/C++, in python:
* all functions are pointers to functions
* all methods are virtual
* all classes have a virtual table (__dict__)
* all types are "virtual"
* as a result everything is polymorphic and generic
* etc.

Moreover, in python an instance can have it's own methods, so the
class/instance distinction is different than C++ and friends. Python's
classes are more like "flying dictionaries" or something:)

IMO, it would be better to proceed normally teaching OOP with C++ and
dedicate extra lessons on "dynamic/interpreted languages and how can
they do everything OOP'd like to".
Stelios
--------------------
How's the PEP going?

[Rob Snyder]

Gabriel Zachmann wrote:

This post is not strictly Python-specific, still
I would like to learn other university teachers' opinion.

Currently, I'm teaching "introduction to OO programming" at the undergrad
level. My syllabus this semester consists of a bit of Python (as an
example of a scripting language) and C++ (as an example of a compiled
language). With C++, I go all the way up to meta-programming.

My question now is: do you think I should switch over to Python completely
(next time), and dump all the interesting issues involved in C++'s virtual
classes, overloading, and templates? (In Python, all of that would just
disappear ... ;-) )

(The opinion of the people on this NG might well be a little bit biased
towards Python, but that's ok ;-).)

Interested in all kinds of thoughts.

Best regards,
Gabriel.

Gabriel -

I was in a similar position, and decided to make the change over to Python
completely. Key for me was that I knew these same students, at some point
in time, would *also* being taking several courses that involved C++. In
other words, they didn't need this course to cover C++, they only needed it
to get introduced to OO programming, and by switching to Python, I gave
them an environment to learn that they could really get their heads around.

If the students wouldn't be getting immersed in C++ otherwise, I don't think
I would have made the switch, and may have continued not using any Python
at all.

Python, IMHO, is an excellent teaching language. In my observations, by
switching to Python for the OO concepts class, I'd say we easily covered
50% more material in the same amount of time.

As for the interesting C++ issues, those same students were able to pick
those concepts up quickly in their later classes. "Overloading", for
example, was a pretty simple concept to grasp for people who had previously
spent a whole semester heads down learning OO.

Rob

[Neil Benn]

<snip>

As for the interesting C++ issues, those same students were able to pick
those concepts up quickly in their later classes. "Overloading", for
example, was a pretty simple concept to grasp for people who had previously
spent a whole semester heads down learning OO.

Rob

Hello,

Just out of interest, did the students get confused between
polymorphism acheived through duck-typing and polymorphism acheived
through inheritence. Obviously not all OO languages have duck typing
and they are subtly different concepts which may confuse a learner.

Just a question, I'm not in education so I wouldn't know the best
way to perform structured education (my teacher friends remind me of
this all the time!!).

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Rob Snyder]

Neil Benn wrote:

<snip>

As for the interesting C++ issues, those same students were able to pick
those concepts up quickly in their later classes. "Overloading", for
example, was a pretty simple concept to grasp for people who had
previously spent a whole semester heads down learning OO.

Rob

Hello,

Just out of interest, did the students get confused between
polymorphism acheived through duck-typing and polymorphism acheived
through inheritence. Obviously not all OO languages have duck typing
and they are subtly different concepts which may confuse a learner.

Just a question, I'm not in education so I wouldn't know the best
way to perform structured education (my teacher friends remind me of
this all the time!!).

Cheers,

Neil

Neil -

At first, yes. What I found quite interesting was that most students seemed
to naturally think that duck typing was the only "sensible" way things
should work, and later, when faced with C++, they did often stumble.

I am more careful now to seperate the Python way of doing things from the
general theory behind inheritance, interfaces, and class types, and I try
to cover up front how a lot of the rest of the world works.

Regards,

Rob

[Ian Bicking]

Gabriel Zachmann wrote:

This post is not strictly Python-specific, still
I would like to learn other university teachers' opinion.

Currently, I'm teaching "introduction to OO programming" at the undergrad
level. My syllabus this semester consists of a bit of Python (as an example
of a scripting language) and C++ (as an example of a compiled language).
With C++, I go all the way up to meta-programming.

My question now is: do you think I should switch over to Python completely
(next time), and dump all the interesting issues involved in C++'s virtual
classes, overloading, and templates? (In Python, all of that would just
disappear ... ;-) )

(The opinion of the people on this NG might well be a little bit biased
towards Python, but that's ok ;-).)

Well, I haven't taught Python (though I think it would be fun to try
sometime), so you can take my opinion as you will. But, if I was
judging languages I'd find Python's advantage to be primarily the
simplicity of the interface and tools. With Python you don't have to
spend (much) time learning the tools, or even the library; students in
many intro CS classes seem to spend a lot of time getting *anything* to
work, and it keeps them from getting to the interesting programming
problems. I also think OO and other programming methodologies become
more relevent when you are faced with significant design challenges, and
intro programmers won't ever be able to make a significant program in a
C++ class.

More generally, I think a good class is one that gives the students many
opportunities for making mistakes. Ideally every student would make
many, many mistakes -- no matter their skill. More skilled students
should simply be making more ambitious projects, and failing at a more
advanced level. From this perspective, simply making programming fun is
particularly important, because if it's not fun the students won't press
themselves to the limit of their skills, they'll only be doing the
prescribed work. And Python is more fun.

From a CS perspective, I'd obviously (since this is a partisan forum)
say that Python presents the core concepts of OO better than C++. But I
actively disagree with the core concepts of OO as defined by most C++
academics, really falling into the Smalltalk camp; treasuring
flexibility and cooperation of systems over formalism and encapsulation.
In many ways the result can be the same -- the objects and methods and
interactions of similar systems may look the same across these
langauges. But I prefer the carrot (the potential to make a great
program) over the stick (the inability to use code in ways the initial
programmer did not intend). This philosophy of transparency and
no-boundry refactoring is also fundamental to the free/open source
software community, which I honestly see as fundamentally (if sometimes
subtley) different from proprietary development; it's not just a matter
of license.

Anyway, I see many C++-specific OO notions (like templates, by-reference
vs. by-value calling, etc) as coping mechanisms. This is because I come
at it from the perspective of a dynamic language programmer (before
Python I preferred languages like Scheme or Smalltalk). These
judgements are something a programmer acquires early on. Conversely, if
you start with C++ or C, you might see a dynamic language as a facade
ontop of the more fundamental notions of pointers and memory management.
Certainly people drift, and one class won't set a person's perspective
in stone, but it's important. At the same time, the students are young
-- you aren't training them for what is, but what will be. I think it's
clear the future of programming won't look like C++. It won't
necessarily look like Python either; Java and C# fall somewhere in
between; they appear somewhat like C in syntax, but you have to
remembering that they too don't have manually memory management,
templating, heavily-used overloading, or pointers.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Ville Vainio]

>>>>> "Gabriel" == Gabriel Zachmann <za**@cs.uni-bonn.de> writes:

Gabriel> My question now is: do you think I should switch over to
Gabriel> Python completely (next time), and dump all the
Gabriel> interesting issues involved in C++'s virtual classes,
Gabriel> overloading, and templates? (In Python, all of that would
Gabriel> just disappear ... ;-) )

I don't think virtual classes (as in inheriting from base classes
"virtually" to avoid a certain multiple inheritance problems) is all
that important in this single inheritance favouring world.

The concept of overloading is easy, you can go one step further by
introducing generic functions / multimethods through one of the
modules floating around the net.

--
Ville Vainio http://tinyurl.com/2prnb

[Gabriel Zachmann]

Thanks a lot for your response and sharing your thoughts.

I think it's
clear the future of programming won't look like C++. It won't
You know, I keep wondering exactly what we will be teaching as programming
languages become easier and easier to learn.

Programming itself? -- won't be enough for a whole semester.
Algorithms? -- is and will be a whole different class.
Patterns? -- needs too large programming assignments.
....

vs. by-value calling, etc) as coping mechanisms. This is because I come
at it from the perspective of a dynamic language programmer (before
Python I preferred languages like Scheme or Smalltalk). These
judgements are something a programmer acquires early on. Conversely, if
you start with C++ or C, you might see a dynamic language as a facade
ontop of the more fundamental notions of pointers and memory management.

I learnt OO the smalltalk way, and i loved it.
But i program a lot in C++ and i do like it, too.

Another question is: can you teach effectively the inner workings, if you
teach only a dynamic language?
Best regards,
Gabriel.

--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

[Gabriel Zachmann]

> Just out of interest, did the students get confused between

polymorphism acheived through duck-typing and polymorphism acheived
i haven't gotten so far yet.
and this semester, i won't do everything in parallel.

But I can say that it is very convincing to explain dynamic typing vs.
static typing, and weakly typed vs. stringly typed by contrasting how
things work in python vs how they work in c++.
way to perform structured education (my teacher friends remind me of

hm, i'm not an educated teacher, just an assistant professor --
could you please explain to me what "structured education" means? ;-)

Cheers,
Gab.

--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

[Gabriel Zachmann]

> I don't think virtual classes (as in inheriting from base classes

"virtually" to avoid a certain multiple inheritance problems) is all
that important in this single inheritance favouring world.
ah, sorry, i meant "classes with virtual methods" (i.e., classes that have
RTTI).
The concept of overloading is easy, you can go one step further by
introducing generic functions / multimethods through one of the
modules floating around the net.

You mean in Python? (or C++)
Could you give me a pointer to one of those modules?

TIA,
Gab.
--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

[Gabriel Zachmann]

> If the students wouldn't be getting immersed in C++ otherwise, I don't think

I would have made the switch, and may have continued not using any Python

ah, here they won't necessarily be confronted with c++ any more.
more likely java.
and they won't have any dedicated programming classes at all any more.

Cheers,
gab.
--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

[Ville Vainio]

>>>>> "Gabriel" == Gabriel Zachmann <za**@cs.uni-bonn.de> writes:

I don't think virtual classes (as in inheriting from base classes
"virtually" to avoid a certain multiple inheritance problems) is all
that important in this single inheritance favouring world.
Gabriel> ah, sorry, i meant "classes with virtual methods" (i.e.,
Gabriel> classes that have RTTI).

Ah, ok. Python has the clear upper hand here because everything is
"virtual", type(obj) is always the "most derived" version.

BTW, a slight terminology correction - having a "virtual table"
doesn't necessitate existence of RTTI, in fact some systems (Symbian
OS at least) omit RTTI on purpose but still have virtual
functions. Having RTTI means dynamic_cast<Foo>(obj) can return NULL if
obj can not be cast to Foo, while e.g. in Symbian OS C++ environment
dynamic_cast is just the same as static_cast, with all the Access
Violations that go with it :-).
The concept of overloading is easy, you can go one step further by
introducing generic functions / multimethods through one of the
modules floating around the net.

Gabriel> You mean in Python? (or C++)
Gabriel> Could you give me a pointer to one of those modules?

http://www-106.ibm.com/developerwork.../l-pydisp.html

http://www.cis.upenn.edu/~edloper/pydecorators.html

(the last one has the wrong guess for @decorator syntax, and so has
the examples wrong).

Google for "python generic function decorator" or something along
those lines for more. I bet we'll see one @decorator implementation
become pretty "standard" once Python 2.4 goes final.

--
Ville Vainio http://tinyurl.com/2prnb

[Ian Bicking]

Gabriel Zachmann wrote:

The concept of overloading is easy, you can go one step further by
introducing generic functions / multimethods through one of the
modules floating around the net.

You mean in Python? (or C++)
Could you give me a pointer to one of those modules?

There's a simple example of multimethods in the Python Cookbook
(online). PEAK now includes a generic function implementation, a bit
more at http://dirtsimple.org/2004/11/generi...ve-landed.html

Adaptation and interfaces are related idea. I feel like they are a
little vague at this point, as far as best-practices go.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Ian Bicking]

Gabriel Zachmann wrote:

Another question is: can you teach effectively the inner workings, if you
teach only a dynamic language?

To a degree, maybe not. But I don't think that's the place to start --
to me the foundation of CS is abstract algorithmic thought, not a CPU;
math, not electronics. Again, that's not a perspective everyone agrees
with, some feel it's best to start with assembler.

But then, if you are writing assembler, there's a good chance now that
you'd be writing MIX or some other fake assembler for a fake CPU. I can
imagine approaching that from Python -- code an assembler and virtual
CPU in Python, and start programming it. To the degree that the virtual
CPU looks like real CPUs, you learn about processors. The assembler
teaches the beginning of compiler design.

The next level up -- C, where you are dealing with pointers and memory
management -- probably isn't feasible from Python. In assembler you are
only writing trivial programs, so it's not a big deal that it's slow;
you can't realistically implement either C or an efficient runtime
environment in Python; even if you could, the task would be too large.
But that's okay, C still has an important role in a CS education. I'm
less certain about C++ -- it's neither low level nor high level.

And since Java or C# will almost inevitably be taught at some point,
most of C++'s features and complications are not novel, again making C
seem more reasonable.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Alan Gauld]

On 24 Nov 2004 18:31:13 GMT, Gabriel Zachmann
<za**@cs.uni-bonn.de> wrote:

You know, I keep wondering exactly what we will be teaching as programming
languages become easier and easier to learn.

Programming itself? -- won't be enough for a whole semester.
Oh no way. You could teach a whole semester just using flow chart
stule diagrams. The concepts of programming stay the same
regardless of language. You just won't need to spend so much time
on syntax, you can focus on the real issues like jump tables,
data types - and how the data structure shapes the code
structure! Issues of locking, error handling strategies,
threading, event-handling etc etc... All of these stop being
advanced features and move into mainstream. Someday.... :-)
Another question is: can you teach effectively the inner workings, if you
teach only a dynamic language?

Yes, its just different inner workings. :-)

But to be serious. I've never quite understood the sense in
universities teaching students about how C++ VMTs etc work.
They are only relevant to one language - and possibly one
implementation of one language since they aren't part of the
standard - and languages change on a ~10 yearly cycle. (Which
means Java should soon be making way for the Next Big Thing -
BEPL maybe?...)

Concepts like hashes and jump tables and generic compiler
techniques are universal but how a particular language is
implemented is only of marginal value IMHO. It would be
like an Electronics professor spending a lecture dismantling
an oscilloscope and discussing the circuit diagram - mildy
interesting, but ultimately pointless!

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld