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 -- http://mail.python.org/mailman/listinfo/python-list