On Sat, 29 Jan 2005, Trans wrote:

> First off I'm wondering if you read the referenced post?

If you mean the one from gmane.org, yes, and I think it misses a few
things.

The word "purity" it uses is straight from Java gospel, and ignores other
definitions of purity in OOP thinking. From my perspective, purity means
that a language _integrates_ the concepts of OOP quite deeply into its
design. If OOP was only added as an afterthought (C++ over C) then more
purity can be achieved by reexpressing parts of the base language so that
OOP can be better integrated with it. In that sense, both C++ and Perl get
the spirit of OOP better and deeper than Java because they offer features
to allow user-defined code to look like the base non-OOP language.

Purity is only mentioned a bit, but all of the article seems to be
attacking mostly Java, with little evidence of any research into other
approaches to OOP. For something in a Python newsgroup I'd expect
something more enlightened than that.

> I've been programming for over 20 years.

Same here, although I started quite young and half of the years involved
almost only BASIC and LOGO...

> But with OOP I find myself spending much more time on the "proper
> model". OOP has made me an aweful programmer by comparision. Yea, so
> great others can more easily use my code. That's nice. But it sure as
> hell doesn't make my coding any simpler.

Here's my impression of your situation, which is also a lot my personal
experience:

OOP made you raise your standards enormously, and ask yourself lots of
questions and doubt of your ways to write code. This is good, but there
has to be some kind of stopper, to avoid getting in an endless loop of
rewriting programs. It's good to plan for future expansions, but it
shouldn't be overdone. In particular, there is no single ideal way that a
program should be written, and some redesigns may look like switching from
one ideal to another and back and forth and getting lost. Extreme
Programming methodology mentions that problem and advocate a more
laid-back attitude about this (just code the "minimum" and redesign only
to fill in new actual needs or to shorten the program... well that's _my_ 
interpretation of it anyway...)

> I wnated to modularize, but it's tricky b/c modules don't include
> class level stuff (without wrtting some meta-code to manually do it)
[...]
> Now my problems aside, consider all those OOP design patterns. All very
> cool I think, but a whole lot more complexity. OOP is NOT simple.
> Otherwise it wouldn't be so difficult to teach.

First, the module-vs-class concept of Ruby is superfluous, and it's a
pity, because CommonLisp has the same mixin system using only classes, and
so demonstrates you don't need modules. Apparently Modules were introduced
to make things more intuitive, but my experience has been the reverse, and
I have spent significant time circumventing that distinction.

Apart from that, I'd like to give the example of Complex Numbers. In
Mathematics, Complex Numbers are defined by an extremely short
formula: i*i=-1. That doesn't seem very complex, isn't it? Then you can
work out a full course explaining to students the _consequences_ of that
little formula on usual arithmetics. However, Complex Numbers are very
much used in practice, as a way to _simplify_ formulas, some becoming 3
times shorter or even better. Some things even look like they were made
for being used with complex numbers. (ask physicists and engineers)

I think it's a good example of a tradeoff, of having to learn more
complexity, to later be able to reduce it even more in various
situations. Just like OOP.

> I don't believe teaching how to use any set of language constructs is
> neccessarily hard. Kids program in Logo! Becoming an expert is hard,
> _especailly in a hard thing_.

Oh yeah. But then, you wouldn't use Logo to code the projects you have
today. Why is that then?

_____________________________________________________________________
Mathieu Bouchard -=- MontrñÂl QC Canada -=- http://artengine.ca/matju