python without OO

[Davor]

M.E.Farmer,

first to clarify few things - I'm neither manager nor professionally
involved in code development - I'm just embarking on a small project
that I would like to attract some programmers to later on and make it a
nice open-source system. Based on my previous experience with few SMALL
projects, I would like to avoid object orientation as much as possible.
The reason is that I always ended up working with people who were
without much experience, same as me, but they were all so influenced by
OO propaganda that it was impossible to reason with them and to go with
as simple solution as possible (not saying that OO solution is
necessarily more complex than a structured one IN ALL CASES - but in
any single case I've seen so far it was). So every single time I was
wasting time trying to explain why not to go with cool OO way as
opposed to simple un-cool structured solution. So, if the application
was feasible to develop in C or C++, the solution would be easy - just
choose C and avoid all OO mess - of course would have slightly more
problems with C's looser type-checking but in my experience it's far
less problem then troubles that happen when one starts going crazy with
C++ generic classes, multiple inheritance, deep inheritance trees,
etc.. The nature of the application that I'm planning on is perfectly
suited to a good high-level scripting language, and python looked very
attractive so I decided to take look at it, but  then i realized it has
all this OO stuff that I got scared off immediately :-) - luckily some
of these other guys including yourself mentioned that there are not
that many issues with Python's OO stuff as there is with Java's of C++
(seems I'm not the only one with Java&C++ OO traumas :-)) - so I'm
encouraged to proceed with Python.

> It seems you are telling me that :
> 1) You do not understand most programming concepts

not really - I rather want to prevent incorporation of anything that is
not really needed in the code...

> 2) You are not willing to learn.

more that I like to reject anything that is not obviously substantiated
and that many people seem to have problems with...

> 3) You might not have the skill set to manage developers

maybe not good management approach but I would always opt for "not
giving them the tools I don't want them to use" over "giving them
tools I don't want them to use and then forbidding them to use these
tools" - especially if they are not getting paid for what they are
building :-)

> Stop telling your programmers how to program! Seriously NOW.
> If you managed a group of doctors would you tell them that they could
> only use techniques that *YOU* understood, even if the were STANDARD
> and well known by others?

This sounds like one of those ideas preached by agile community - I say
set up the rules and conventions as much as you can (in a
*non-intrusive* way) if you are a manager... Exactly the group of
professionals you mentioned in your example is support for what I am
claiming. In fact in that profession everything is exactly about the
rules, precise techniques, and exact processes that have to be done and
when they have to be used. If anything gets done outside of recommended
practices they are legally responsible for. For example, if a person
has to undergo sinus surgery and the endoscopic version is sufficient
(simple, non-intrusive, internal incision) and a doctor decides to do
the traditional surgery with external cutting - I guess everyone would
be pissed off - especially the patient :-)..

Also, yes, I have read GOF book... but I never found it a big deal  -
no one ever had to document structured patterns - which definitely
exist - but seem to be obvious enough that there is no need to write a
book about them...

Thanks for your feedback!
Davor