Hi Mathieu Bouchard,

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

I've been programming for over 20 years. I would not call myself a
great programmer, but I'm okay. I was first interoduced to OOP via VB
and then really hunkerd down with it in Ruby. So maybe 5 or so of OOP.
In the past I could just sit down and hammer out a pretty nice program.
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.

Take the simple example I just went through, where I had to figure our
how to best represent a encapsulation of "how to find a piece of
subtext" and the encapsulation of "what to create when you find that
thing", and there were various parts shared among them, so 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) and subclassing a
class that extends a module which extenda a module doesn't seem to fly
(I beleive that was the pattern) and not to metntion the well known
DynamicModuleInclusion problem (inlcuding a module in a module poist
instantiation), well needless to say it took quite sometime to find
something "artisian" --and I won't even do into the same old same old
with trying to get access to an object far up the hierarchy fromthe
bottom (always fun to pass a self down four levels ;-)

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. 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_.

I don't find this comment intereting:

> One should map patterns of thought to patterns of
> mechanisms in the most convenient way possible. Clinging
> to recipebooks and phrasebooks and taking guidelines as
> if they were hard rules, those are things that make verbose
> and clunky programs, OOP or not.

I respectively disagree. I think OOP itself can often make that more
difficult.

T.