On Mon, 2004-12-13 at 22:33, projecktzero wrote: > I know this might not be the correct group to post this, but I thought > I'd start here. > > A co-worker considers himself "old school" in that he hasn't seen the > light of OOP.(It might be because he's in love with Perl...but that's > another story.) He thinks that OOP has more overhead and is slower than > programs written the procedural way. I poked around google, but I don't > know the magic words to put in to prove or disprove his assertion. Can > anyone point me toward some resources? > > We do web programming. I suspect that OO apps would behave as good as > procedural apps, and you'd get the benefit of code reuse if you do it > properly. Code reuse now consists of cutting and pasting followed by > enough modification that I wonder if it was worth it to cut and paste > in the first place. > > Thanks.
Code reuse is not copying and pasting. This truly misses what code can be. Code isn't, well shouldn't be, a static entity that written once and forgotten. It is gradually enhanced, generalized, factored, improved, optimized, rethought, etc etc. A Properly Written (tm) application will have each abstract concept implemented just once; in a properly written application a single change is propagated throughout the system. In what you describe, a change entails hunting the code you have pasted and changing it in a number of locations. Depending on the size of your program and how badly your application begs for code reuse, you can find yourself changing your code in hundreds of places just to change a single data structure. Seriously, ever put off changing an array to a linked list, a list to a map, or some other similar change simply because you don't want to the coding and testing? In a proper OOP application, different parts of your program will *ask* for some abstract task to be performed, but only one small part will actually deal with the details of doing it. Change that and nothing else knows any better. The "overhead" of OOPLs is bogus. C++ was explicitly designed so that each and every OO operation was as fast as or faster than faking it in C. Do you use structures in C with special functions to act on them? Then you are already using objectish methods ... only proper C++ object methods will be no slower, but a good deal cleaner. Even in instances where this is the case, for instance, comparing early smalltalk interpreters to your friendly C compiler, it is almost always the case that the expressive power and abstraction of an OOPL allows for the use of greater algorithmic sophistication. So, sure, your C linked list searches might beat my Smalltalk linked list search, but in the same amount of programmer time I'd be able to implement something better. I really don't care to prove my point, only to point out that if your assertion that this individual does not understand OOP is true, then he his point likely isn't coming from knowledge and experience, but fear of the unknown. Now, if you said that your co-worker was old school and into functional programming, I'd agree to disagree and point out functional programmings weaknesses with respect to complexity and the ability to partition knowledge. Forget goggle. Go to Amazon and get some texts on OOPL. Learn C++, Java, Python for that matter. Practice casting problems as classes in Python and submit them here for praise and criticism. Lastly, Perl is an OOPl in its own right ... like Python and quite unlike Java, it doesn't jam its OOP-ness down your throat. Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
