Re: lies about OOP
... C++ *appears* to increase the cost of fixing defects ... Some additional points: Some languages allow direct pointer manipulation which favors certain classes of bugs. This is independent of whether the language is OO, and these are probably the most costly defects to find (hanging pointers, buffer overflows, array index busting, memory leakages, etc.). Some languages have strong type checking, which reduces some classes of bugs. This is independent of whether the language is OO. Some people like to think they are OO if they wrap every incoming piece of data in get/put methods in classes. This reduces some categories of errors at the cost of flexibility. When the input format changes, the code needs serious modification everywhere. This is also independent of whether the language is OO, and is a matter of style. While python classes permit you to wrap everything, python classes are so thin a wrapper that it is as if they almost aren't wrapped. A trend for style would be to use OO for the methods on stable objects (a continually decreasing breed over time) and use data-driven methods to permit handling data of very flexible input formats. This trend will permit more use of techniques like XSLT, where data structures define the transformations instead of classical code, and techniques like semantical analysis using ontologies, taxonomies, thesaurii, dictionaries, and mappings of semantics into real-world contexts. In other words, data-driven software is not top-down (problem-oriented). It is also not bottom-up (object-oriented). It is simply data-oriented, and totally driven by the input data. This trend will result in the number of lines of code going down, the cost of software going down, and the consciousness of data relationships going up. We will then see Python-D, the python Data language. While Python said: indentation of code is everything, Python-D will say: all the relational arrows in your dataflow diagram (which IS your code) must be pointing upwards. While Python said: simplify, reduce coupling, increase cohesion of the software, and do tricks with lambda, Python-D will say: simplify, reduce coupling, and increase cohesion of the data, and do tricks with metadata. Mike Brenner -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
[EMAIL PROTECTED] wrote: A paper finding that OOP can lead to more buggy software is at http://www.leshatton.org/IEEE_Soft_98a.html Sure, OOP *can* lead to more buggy software, that doesn't mean it always does. Les Hatton Does OO sync with the way we think?, IEEE Software, 15(3), p.46-54 This paper argues from real data that OO based systems written in C++ appear to increase the cost of fixing defects significantly when compared with systems written in either C or Pascal. It goes on to suggest that at least some aspects of OO, for example inheritance, do not fit well with the way we make mistakes. So, he has data that shows that C++ *appears* to increase the cost of fixing defects, then *suggests* that its because C++ is an OO language? Sounds like he is ignoring his own data to me... Mr. Hatton suffers from the same problem that many OO critics suffer. He thinks that the language choice decides whether the program written is an OO program. I've seen plenty of very non-OO systems written in OO languages, I've seen expert OO systems written in non-OO languages. OOP isn't a language choice, it is a style of problem solving. I'm happy to accept that it could take longer to fix bugs in programs written in C++ when compared to either C or Pascal, the language itself is quite a bit more complicated than either of the latter. You know, it tends to take longer to repair a 2004 Mustang than it does a 1964 Mustang, does that mean the newer car is not as good? If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++? All three of the systems in question were begun before C++ was standardized. Python was also implemented in Java, does that mean OO other than C++ is good? Of course not, the fact that the three projects in question were implemented in C is not an indictment against OO in any way. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
H. S. Lahman [EMAIL PROTECTED] wrote: Les Hatton Does OO sync with the way we think?, IEEE Software, 15(3), p.46-54 This paper argues from real data that OO based systems written in C++ appear to increase the cost of fixing defects significantly when compared with systems written in either C or Pascal. It goes on to suggest that at least some aspects of OO, for example inheritance, do not fit well with the way we make mistakes. Try and find and experienced OO developer who would advocate that large, complex generalizations are a good practice. You can write lousy programs in any paradigm. The likelihood increases when you use the most technically deficient of all the OOPLs. (If those developers had used Smalltalk, I'll bet their defect rates would have been substantially lower even if they weren't very good OO developers.) Careful, the paper never claims that C++ produced more defects than C or Pascal. It only claims that the defects found in the C++ program were more costly to fix. That is a very big difference. However, I agree completely with the rest of your comments. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
On Wed, 15 Dec 2004 17:37:08 -0500, rumours say that Peter Hansen [EMAIL PROTECTED] might have written: Martijn Faassen wrote: Peter Hansen wrote: Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Then there's us Danes, with sen instead of son (as many people think it ought to be). And I can't even claim the wrong form sounds noticably different, making any defense seem petty. So this means that if Guido was Dane too we would program in Pythen. The Zon of Pythen. The Sen Of Dr Strangelove. Nice. Happy new year in advance every one, don't start drinking before you drive home :) -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul Foley wrote: That's because their language is derived from Serbo-Croat. No it isn't. time to tune your absurd humour sensor somewhat slightly? I thought the next sentence was a pretty obvious giveaway: But both the Finns and the Swedes will tell you it's the Norwegians who are alcoholics. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
To canadians there is no outside of hockey games. Jeff Shannon wrote: Peter Hansen wrote: P.S.: I'm only half Danish, but the other half is from a particularly bloodthirsty line of Canadians. I thought it was physically impossible for Canadians to be bloodthirsty outside of hockey games... ;) Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
In article [EMAIL PROTECTED], Peter Hansen [EMAIL PROTECTED] wrote: P.S.: I'm only half Danish, but the other half is from a particularly bloodthirsty line of Canadians. Oh, you're part Quebecois? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Peter Hansen wrote: Martijn Faassen wrote: Peter Hansen wrote: Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Then there's us Danes, with sen instead of son (as many people think it ought to be). And I can't even claim the wrong form sounds noticably different, making any defense seem petty. Obviously -sen is the only real suffix, as it's -sen in Dutch as well, as in Faas-sen. :) (Darn those Norwegians, influencing people's ideas of how a name like Hansen ought to be spelled, grumble, grumble. If they'd just invent a cell phone that used Python, as the Swedish have, they might deserve all that extra attention.) ;-) That's not the Swedes, it's the Finnish that did that. They typically don't like being mistaken for Swedes. :) Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
H. S. Lahman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Responding to Daniel T Try and find and experienced OO developer who would advocate that large, complex generalizations are a good practice. You can write lousy programs in any paradigm. The likelihood increases when you use the most technically deficient of all the OOPLs. (If those developers had used Smalltalk, I'll bet their defect rates would have been substantially lower even if they weren't very good OO developers.) Careful, the paper never claims that C++ produced more defects than C or Pascal. It only claims that the defects found in the C++ program were more costly to fix. That is a very big difference. You're right. That's what I get for responding from memory of my original reading of the paper. The mind is the second thing to go. If it claims there are more defects in C++ than in C, then I am more than willing to believe it, I would struggle to get a 3 line c++ program to compile let alone run. The leap that equates C++ to OOP, and C to SP would seem to be tenuous though. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Martijn Faassen wrote: Peter Hansen wrote: Martijn Faassen wrote: Peter Hansen wrote: Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Then there's us Danes, with sen instead of son (as many people think it ought to be). And I can't even claim the wrong form sounds noticably different, making any defense seem petty. Obviously -sen is the only real suffix, as it's -sen in Dutch as well, as in Faas-sen. :) (Darn those Norwegians, influencing people's ideas of how a name like Hansen ought to be spelled, grumble, grumble. If they'd just invent a cell phone that used Python, as the Swedish have, they might deserve all that extra attention.) ;-) That's not the Swedes, it's the Finnish that did that. They typically don't like being mistaken for Swedes. :) That's because their language is derived from Serbo-Croat. But both the Finns and the Swedes will tell you it's the Norwegians who are alcoholics. They're all dreadful liars, these Scandinavians ;-) regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Peter Hansen wrote: P.S.: I'm only half Danish, but the other half is from a particularly bloodthirsty line of Canadians. I thought it was physically impossible for Canadians to be bloodthirsty outside of hockey games... ;) Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] provide class methods. Though for the life of me I don't *really* know why I find it acceptable in Python to have to write module.func(args) when I dislike having to write class.meth(args) in Java. I have the same reaction and I strongly suspect it is because the concept of OOP class (of instances) has more mental baggage than module as convenient name-grouping. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Mike Meyer wrote: If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++? Because C++ combines the worst features of C and OO programming. It also makes some defaults go the wrong way, and forces decisions onto the programmer that are best left up to the compiler, as the programmer is liable to get them wrong. that's a nice rant about C++, but it's not the right answer to the question. the Python core developers are perfectly capable of writing working C++ code, and both the core and most extensions would benefit from C++ features (just look at Boost and other C++ layers). but C++ wasn't a serious contender back when CPython development was started, and nobody's going to convert the existing codebase... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
binL9yPfo4Fv5.bin Description: application/pgp-encrypted msg.asc Description: Binary data -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul McGuire wrote: Martijn Faassen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Paul McGuire wrote: [snip] I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published Use of GOTO Considered Harmful) to OOP, and that OOP wasn't really joyful until the early-to-mid 90's. IMMEDIATE NOTICE TO ALL PYTHON SECRET UNDERGROUND MEMBERS. Classified. Any disclosure to non-PSU members prohibited. Offenders will be apprehended and removed from the time stream, permanently. snip - it's Dijkstra not Djikstra, you dolt! :) Yikes! (or better, Jikes! or even Yijkes!?) - my bad. And he was on faculty at UT right here in Austin, too. It's a very common mistake I've seen so often that for a while I wondered whether his name really *was* Djikstra, but I knew he was Dutch and that it couldn't be so. That the PSU picked you for its disclosure is just a random coincidence, I'm sure.. :) Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Martijn Faassen wrote: Peter Hansen wrote: Well, in any case, thanks for setting the record straight, Martjin. That of course also happens to me once every while. I can take care of myself though -- Dijkstra however needs an advocate for the correct spelling of his name in this earthly realm. Then there's us Danes, with sen instead of son (as many people think it ought to be). And I can't even claim the wrong form sounds noticably different, making any defense seem petty. (Darn those Norwegians, influencing people's ideas of how a name like Hansen ought to be spelled, grumble, grumble. If they'd just invent a cell phone that used Python, as the Swedish have, they might deserve all that extra attention.) ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Peter Hansen: (Darn those Norwegians, influencing people's ideas of how a name like Hansen ought to be spelled, grumble, grumble. And then there's my sister, a Nelson, who drove with friends of their's, the Olsons, to visit our aunt and uncle, the Larsons, and my grandmother, born a Hanson. Scandinavian heritage? Det vet jag inte. :) Sadly, none of them know Python. And my g'grandfather was German in case you were wondering. Andrew Dalke [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
On Tue, 2004-12-14 at 18:27, Roy Smith wrote: Terry Reedy [EMAIL PROTECTED] wrote: I did not really 'get' OOP until after learning Python. The relatively simple but powerful user class model made more sense to me than C++. So introducing someone to Python, where OOP is a choice, not a mandate, is how *I* would introduce a procedural programmer to the subject. YMMV. OOP is a choice in C++ too. You can write procedural C++ code; no need to use classes at all if you don't want to. Something like Java is a different story. Java *forces* you to use classes. Nothing exists in Java that's not part of some class. Static methods act like C functions. Sure, they are members of classes, but in name only. Besides, just as you can use a procedural language in an OO fashion with enough programmer discipline, you can write in a procedural style with an OOP language with sufficient rebellion. Just use one class, put everything in it and create one instance on startup. Now that I think about it, Java is an exception to this. There are per class code and variable limits in the JVM, limiting the size of your procedural program masquerading as a class. Perhaps that is a good thing. Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
In article [EMAIL PROTECTED], Adam DePrince wrote: On Tue, 2004-12-14 at 18:27, Roy Smith wrote: Terry Reedy [EMAIL PROTECTED] wrote: I did not really 'get' OOP until after learning Python. The relatively simple but powerful user class model made more sense to me than C++. So introducing someone to Python, where OOP is a choice, not a mandate, is how *I* would introduce a procedural programmer to the subject. YMMV. OOP is a choice in C++ too. You can write procedural C++ code; no need to use classes at all if you don't want to. Something like Java is a different story. Java *forces* you to use classes. Nothing exists in Java that's not part of some class. Static methods act like C functions. Sure, they are members of classes, but in name only. Besides, just as you can use a procedural language in an OO fashion with enough programmer discipline, you can write in a procedural style with an OOP language with sufficient rebellion. Just use one class, put everything in it and create one instance on startup. Maybe I'm reading this wrong, but it seems like you're implying that procedural code is inherently unmodular. Why would just one class/instance suffice to represent a procedural program? I think of namespacing and code organization as broad concepts that cut across all styles of programming. Interestingly, Python's main unit of modularity is the module, not the class. A direct translation of a typical Python module to Java would look something like a Java class containing only static methods and inner classes. Even this would be considered rebellious within the context of ordinary Java programming. -- .:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:. talking about music is like dancing about architecture. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Daniel T. wrote: [EMAIL PROTECTED] wrote: A paper finding that OOP can lead to more buggy software is at http://www.leshatton.org/IEEE_Soft_98a.html Sure, OOP *can* lead to more buggy software, that doesn't mean it always does. I think that costs(=time) to develop and maintain software depends not on wheter it is based on OOP or not but on two factors: * Number of NEW Code lines to solve the given problem * Complexity of this new code The anwser to the question if OOP is better is: it depends If the given problem is solved with less code and complexity in OOP then it is the better approach if not the reverse is true. Thats why I like python because it does not force to use OOP or procedural programming. But isnt the main argument to code in Python (or other high level languages) easy of use and compact code? Therefore should Python code be less buggy and cheaper to develop and maintain. Are there any papers on that? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Daniel T. wrote: Mr. Hatton suffers from the same problem that many OO critics suffer. He thinks that the language choice decides whether the program written is an OO program. I've seen plenty of very non-OO systems written in OO languages, I've seen expert OO systems written in non-OO languages. OOP isn't a language choice, it is a style of problem solving. And he suffers from the common misunderstanding that OO is better because it matches the way we think about the world. It wouldn't suprise me if design created with that reasoning in mind is more costly than a good non-OO design. If you use the features of an OOPL, most importantly polymorphism, to manage the dependencies in your code, and you do have some experience doing so, I'm quite certain that it reduces corrective maintenance cost. Take care, Ilja -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
A paper finding that OOP can lead to more buggy software is at http://www.leshatton.org/IEEE_Soft_98a.html Les Hatton Does OO sync with the way we think?, IEEE Software, 15(3), p.46-54 This paper argues from real data that OO based systems written in C++ appear to increase the cost of fixing defects significantly when compared with systems written in either C or Pascal. It goes on to suggest that at least some aspects of OO, for example inheritance, do not fit well with the way we make mistakes. His comments under invited feedback are amusing and confirm my impression that OOP is partly (but perhaps not entirely) hype: I should not that this paper because it criticised OO had an unusually turbulent review period. 2 reviewers said they would cut their throats if it was published and 3 said the opposite. The paper was only published if the OO community could publish a rebuttal. I found this very amusing as my paper contains significant data. The rebuttal had none. This sort of thing is normal in software engineering which mostly operates in a measurement-free zone. What papers have scientific evidence for OOP? Paul Graham's skeptical comments on OOP are at http://www.paulgraham.com/noop.html . If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++? -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Paul McGuire wrote: Jive [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] snip But by '86, the Joy of OOP was widely known. Widely known? Errr? In 1986, object-oriented programming was barely marketing-speak. Computing hardware in the mid-80's just wasn't up to the task of dealing with OO memory and messaging overhead. Apple Macs were still coding in C and Forth. Borland didn't ship Turbo-Pascal with Object-Oriented programming until 1989, and Turbo-C++ shipped in 1991. Smalltalk had been around for 10 years by 1986, but it was still a curiosity, hardly widely known. It wasn't until the publication of David Taylor's Object Technology: A Manager's Guide in 1990 that OOP began to be legitimized to many management decision makers, that it was more than just fairy dust (as Bill Gates had characterized it in an attempt to discredit Borland's forays into the field). Well, that's not true either, and the fact that Bill Gates was denigrating it implies that he at least knew about it, even if he chose not to adopt it (then: of course nowadays Microsoft call almost all their technologies object oriented; sometimes this description is as accurate as when Gates speaks about our open Windows environment). I would pick the publication of Design Patterns in 1995 by the Gang of Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when the Joy of OOP would be widely known. DP formalized a taxonomy for many of the heuristics that had evolved only intuitively up until then. Its emergence reflects a general maturation of concept and practice, sufficient to say that the Joy of OOP could be said to be widely known. We could all make our own choices, but anyone who's been programming *seriously* since the 60s will likely remember Simula as the birth of many oft he ideas later picked up by Alan Kay and promoted by the Xerox PARC SmallTalk group. I visited that group in 1981 (after Kay left, unfortunately, and then being headed by Adele Goldberg, who is now coincidentally promoting the delights of Python at conferences like OSCON), and object-oriented programming was certainly something that was being taken pretty seriously in the academic world as a potential solution to some serious PLIT engineering problems. The fact that it took the technology a relatively long time to appear in the wild, so to speak, is simply the natural maturation of any new technology. Given that UNIX was developed in the early 1970s I'd say it took UNIX 20 years to start becoming mainstream. But a lot of people knew about it before it *became* mainstream, especially those who had to place their technology bets early. The same is true of object-oriented concepts. I guess this is just to say that I'd dispute your contention that SmallTalk was a curiosity - unless you define anything of interest mostly to the academic world as a curiosity, in which case there's no way to overcome your objection. It was the first major implementation of an entire system based exclusively on OO programming concepts and, while far from ideal, was a seminal precursor to today's object-oriented systems. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 Good points all. And yes, I recall the BYTE article on Smalltalk. I guess I was just reacting mostly to the OP's statement that by '86 the Joy of OOP was widely known. He didn't say OOP all began when... or OOP was widely known, which I think still would have been a stretch - he implied that by '86 OOP was widely recognized as Goodness, to which I disagree. This was the year of the first OOPSLA conference, but as PyCon people know, just having a conference doesn't guarantee that a technology is widely and joyfully accepted. Just as my commercial-centric view may understate academic interest in some topics, an academic-centric view may overestimate the impact of topics that are ripe for research, or technically cool, but little understood or adopted outside of a university setting. I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published Use of GOTO Considered Harmful) to OOP, and that OOP wasn't really joyful until the early-to-mid 90's. (And I apologize for characterizing Smalltalk as a curiosity. I admit my bias is for software that is widely commercially deployed, and even the most ardent Smalltalkers will have difficulty citing more than a handful of applications, compared to C,C++,VB,COBOL,Delphi, etc. I personally have seen Smalltalk-based factory control and automation systems, but they are rapidly self-marginalizing, and new customers are extremely reluctant to enfold Smalltalk into an already patchwork
Re: lies about OOP
Paul McGuire wrote: Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [some stuff] Good points all. And yes, I recall the BYTE article on Smalltalk. I guess I was just reacting mostly to the OP's statement that by '86 the Joy of OOP was widely known. He didn't say OOP all began when... or OOP was widely known, which I think still would have been a stretch - he implied that by '86 OOP was widely recognized as Goodness, to which I disagree. This was the year of the first OOPSLA conference, but as PyCon people know, just having a conference doesn't guarantee that a technology is widely and joyfully accepted. Just as my commercial-centric view may understate academic interest in some topics, an academic-centric view may overestimate the impact of topics that are ripe for research, or technically cool, but little understood or adopted outside of a university setting. I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published Use of GOTO Considered Harmful) to OOP, and that OOP wasn't really joyful until the early-to-mid 90's. (And I apologize for characterizing Smalltalk as a curiosity. I admit my bias is for software that is widely commercially deployed, and even the most ardent Smalltalkers will have difficulty citing more than a handful of applications, compared to C,C++,VB,COBOL,Delphi, etc. I personally have seen Smalltalk-based factory control and automation systems, but they are rapidly self-marginalizing, and new customers are extremely reluctant to enfold Smalltalk into an already patchwork mix of technologies, as is typically found in factory settings.) Nothing to disagree with here. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul McGuire wrote: Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [some stuff] Good points all. And yes, I recall the BYTE article on Smalltalk. I guess I was just reacting mostly to the OP's statement that by '86 the Joy of OOP was widely known. He didn't say OOP all began when... or OOP was widely known, which I think still would have been a stretch - he implied that by '86 OOP was widely recognized as Goodness, to which I disagree. This was the year of the first OOPSLA conference, but as PyCon people know, just having a conference doesn't guarantee that a technology is widely and joyfully accepted. Just as my commercial-centric view may understate academic interest in some topics, an academic-centric view may overestimate the impact of topics that are ripe for research, or technically cool, but little understood or adopted outside of a university setting. I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published Use of GOTO Considered Harmful) to OOP, and that OOP wasn't really joyful until the early-to-mid 90's. (And I apologize for characterizing Smalltalk as a curiosity. I admit my bias is for software that is widely commercially deployed, and even the most ardent Smalltalkers will have difficulty citing more than a handful of applications, compared to C,C++,VB,COBOL,Delphi, etc. I personally have seen Smalltalk-based factory control and automation systems, but they are rapidly self-marginalizing, and new customers are extremely reluctant to enfold Smalltalk into an already patchwork mix of technologies, as is typically found in factory settings.) Nothing to disagree with here. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
projecktzero wrote: A co-worker considers himself old school in that he hasn't seen the light of OOP ... He thinks that OOP has more overhead and is slower than programs written the procedural way. He may be right, but consider the alternatives. Think of an integer. An integer is an object! You can assign a new integer-value to the object. You can read the integer-value of the object. (The integer can be part of complex expressions.) Usually you are unaware (or don't care) _how_ the object is implemented. Wether the bits are red, green, turns upside-down or are inverted - you doesn't really care, as long as it can hold the values that you want it to hold and be used in the relevant contexts (addition, multiplication, ...). Some lanugages gives you the choise of many integer-implementations, some languages gives you only a few choises and some languages gives you only one choise. Surely we can agree that the presence of an integer-object is extremely useful! If you had to do all the integer-stuff in machine code _every_ time, you would soon be very, very tired of working with integers. There is no doubt that objects are (or can be) extremely useful, time-saving and very efficient. Chances are that your own machine-code integer-inplementation is not nearly as good as the one made by a team of top-tuned programmers (no offense) programming the integer-implementation object. Wether the language should give you the choise of one, some, many or extremely many integer-implementations, depends entirely on your needs (what a pervert - he needs an integer!). Lowering the number of choises of implementations, rises the chances of having to chose a not very good implementation. Letting the language automaticly chose the right one, frees your mind to other processes, but at the risk of some kind of run-time overhead. --- Tomas -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
[EMAIL PROTECTED] wrote: A paper finding that OOP can lead to more buggy software is at http://www.leshatton.org/IEEE_Soft_98a.html [snip description of paper that compares C++ versus Pascal or C] What papers have scientific evidence for OOP? That's of course a good question. I'm sure also that comp.object has argued about this a thousand times. I'll just note that one paper is just a single data point with specific circumstances. The OO languages under investigation might have caused increased or lower failure rates for other reasons than their (lack of) object-orientedness, for instance. It is of course possible to come up with a lot of other explanations for a single data point besides a conclusion that OOP can lead to more buggy software. It for instance certainly not surprising to me that C++ can lead to more buggy software than some other languages. :) [snip] If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++? Because C++ is not an ideal object oriented language? Because a Linux kernel has very stringent predictability requirements for what kind of machine code is generated that C meets and is much harder to do with C++? There are other reasons to choose C, such as portability, obiquity and performance. Some of the same reasons probably apply to Perl and Python, though at a lesser degrees. I do not know a lot about Perl's implementation. I do know that Guido van Rossum has in fact considered rewriting Python in C++ in the past. And right now, there are various projects that are using object oriented languages to reimplement Python, including Python itself. Finally, it is certainly possible to program in object oriented style in C. It is more cumbersome than in a language that supports it natively, but it is certainly possible. Such OO in C patterns occur throughout the Linux kernel, which needs a pluggability architecture for its various types of drivers. It can also be seen in many aspects of Python's implementation. Another example of a C-based system that uses object oriented technologies is the GTK+ widget set. Anyway, this question is using a few data points to make an overly generic argument, and the data points themselves do not really support the argument so very well either. Regards, Martijn -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Roy Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think the real reason Python is a better teaching language for teaching OO concepts is because it just gives you the real core of OO: inheritence, encapsulation, and association of functions with the data they act on. C++ has so much stuff layed on top of that (type bondage, access control, function polymorphism, templates) that it's hard to see the forest for the trees. You get C++ jocks who are convinced that that stuff is part and parcel of OO, and if it doesn't have (for example), private data, it can't be OO. +1, QOTW!! :) (esp. type bondage!) -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Instead of copy and paste, I use functions for code reuse. I didn't see the light of OOP, yet. I use Python but never did anything with OOP. I just can't see what can be done with OOP taht can't be done with standart procedural programing. There are cases where functions just don't do the job. I at one time needed to use the little-used (and probably little-know) account featre of an ftp server to automate a regular file transfer. Both Perl and Python come with ftp modules. Perl's was (is?) procedural, Python's is OO. Neither supported the account feature. Now, if I used perl to do this, I'd have to either modify the module in place, meaning I'd have to remember to put the mods back every time we updated perl if I couldn't get them to buy the patch, or I could make a local copy of the module, meaning it wouldn't get any bug fixes that might come with new versions of perl. With the Python version, I created a subclass of the FTP connection module, rewrote just the login method, and installed that locally. Now I don't have to worry about installing new versions of Python, as my code is outside the distribution. But I still get the benefit of any bug fixes that show up outside the login method. I also submitted the new login method, and it's now part of the standard module. This kind of code reuse just isn't possible with procedural code. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
projecktzero wrote: 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? Sounds like your co-worker has a major case of premature optimization. I don't know about speed issues with OO, but for large projects, using OOP makes data encapsulation so much easier. Writing correct code with minimum effort should be the first goal, speed issues (at that level) should be brought into the game later on. You should ask your co-worker if he also puts all his data in global variables :) *wink* -- Timo Virkkala -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Jive [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] snip But by '86, the Joy of OOP was widely known. Widely known? Errr? In 1986, object-oriented programming was barely marketing-speak. Computing hardware in the mid-80's just wasn't up to the task of dealing with OO memory and messaging overhead. Apple Macs were still coding in C and Forth. Borland didn't ship Turbo-Pascal with Object-Oriented programming until 1989, and Turbo-C++ shipped in 1991. Smalltalk had been around for 10 years by 1986, but it was still a curiosity, hardly widely known. It wasn't until the publication of David Taylor's Object Technology: A Manager's Guide in 1990 that OOP began to be legitimized to many management decision makers, that it was more than just fairy dust (as Bill Gates had characterized it in an attempt to discredit Borland's forays into the field). I would pick the publication of Design Patterns in 1995 by the Gang of Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when the Joy of OOP would be widely known. DP formalized a taxonomy for many of the heuristics that had evolved only intuitively up until then. Its emergence reflects a general maturation of concept and practice, sufficient to say that the Joy of OOP could be said to be widely known. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
projecktzero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. Just how old *is* his school? I saw the light in the 70's. For those of you too young to remember, those were menacing and sinister days, when pant legs were too wide at the bottom, and the grotesque evil of top down programming was on the land. But by '86, the Joy of OOP was widely known. Flowers bloomed and birds chirped. Pant legs narrowed. I believe that was the year I attended the first C++ conference in Santa Fe. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
In article [EMAIL PROTECTED], projecktzero [EMAIL PROTECTED] 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. In the world of computers, the statement X is slower than Y is true for almost every value of X and Y under some circumstances. IMHO, loves perl doesn't mesh with either old school or cares about overhead, but that's just me. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Hello projecktzero, 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? Try http://www.dreamsongs.com/Essays.html (search for Objects Have Failed) for an interesting discussion. Bye. -- Miki Tebeka [EMAIL PROTECTED] http://tebeka.bizhat.com The only difference between children and adults is the price of the toys -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
[EMAIL PROTECTED] wrote: I just can't see what can be done with OOP taht can't be done with standart procedural programing. Well, there's absolutely nothing you can do with OOP that can't be done with standard procedural programming (SPP). But that's hardly the point. After all, anything you can do with OOP or SPP can be done with assembly language as well. OOP is way of approaching the design and construction of the software. As a starting point, consider the advantages of procedural programming over using raw assembly language. Now consider that there might be similar advantages in using OOP instead of procedural programming. And, lastly, to bring this on topic for this forum, consider that there might be advantages in using *Python*, specifically, for doing this OOP programming, compared to many other languages. Not that you can do things in Python you can't do in other languages (such as, say, assembly). Just that you can do them much more easily, and the resulting code will be much more readable to you and others. (To be fair, for certain tasks using OOP provides basically no advantages, and in fact might represent a more awkward model for the code than a simple procedural program would. If that's the sort of program you are faced with writing, by all means stick with SPP and leave OOP to those who write complex applications that really benefit from it.) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
projecktzero wrote: 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? There's no magic in OOP. It's just more natural to human nature, so you should point your friend to works of Aristotle or Sancti Thomae Aquinatis, specially their writings on natural sciences and theory of species. -- Jarek Zgoda http://jpa.berlios.de/ | http://www.zgodowie.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
I did not really 'get' OOP until after learning Python. The relatively simple but powerful user class model made more sense to me than C++. So introducing someone to Python, where OOP is a choice, not a mandate, is how *I* would introduce a procedural programmer to the subject. YMMV. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Paul McGuire wrote: [snip] I would characterize the 80's as the transitional decade from structured programming (which really started to hit its stride when Djikstra published Use of GOTO Considered Harmful) to OOP, and that OOP wasn't really joyful until the early-to-mid 90's. IMMEDIATE NOTICE TO ALL PYTHON SECRET UNDERGROUND MEMBERS. Classified. Any disclosure to non-PSU members prohibited. Offenders will be apprehended and removed from the time stream, permanently. Words in human languages typically consist of a combination of vowels and consonants, at least up until the start of the posthumanist revolution in 3714, when the Morning Light Confederation's ships reached the ablethik-seganichek world of Kaupang again (on Hellenberg consensus time streams with catalog marker AB-7). Alphabetic scripts are a typical way to represent them. Even in the posthuman phase on Kaupang they were widely appreciated as a quaint representation. The language English, an indo-european tongue of the west-germanic persuasion (expressiveness rating 7, comprehensiveness rating 12, fits in the moderate Y group of the Lespan pan-species language classification system), is widely in use throughout a surprisingly long period on many time streams. This language does not have overly long consonant combinations. The language Dutch, though closely related to the language English has a slightly different sound to glyph mapping system. Dutch is, of course, the true language of the Python Secret Underground and the official native language of Python users. In the language Dutch, a certain vowel sound is expressed as a combination of the glyphs 'i' and 'j'. The glyph 'j' however is exclusively used for consonants in the English language, unlike in Dutch, where 'j' serves a dual role. Human brains used to the English language cannot cope with glyph representations that express consonants in too long a sequence, without any space left for vowels. A combination like 'jkstr' in the English language is inevitably considered to be a spelling error, and corrective procedures automatically attempt to correct the spelling of such a word to a more acceptable combination. This happens frequently to the name 'Dijkstra', a name that originated in the Dutch natural language. The English eye cannot accept such a ridiculous combination of consonants (j k s t *and* r?), and desperately tries to resolve the situation. As a result, the glyphs 'i' and 'j' are frequently reversed. This is extremely unfortunate, as Djikstra is well known to be a primary moniker for the leader of the Insulationist faction within the Gheban coalition. The Insulationist faction is, of course, a prominent member the alliance that produced the Alien Whitespace Eating Nanovirus. Djikstra is therefore an enemy of the Python programming language. All that we stand for. All our hopes. All our dreams will come to naught if Djikstra gets his way. The moniker Djikstra is to be avoided in public utterances. PSU members can give themselves away and draw unwanted attention from the Insulationist overlord at this critical junction. What's worse, innocents might be caught up in this cosmic web of intrigue. While most innocents can of course be safely ignored, any innocent of temporal tension rating 17 and above (revised scale) should not be exposed to undue danger, as they may be essential for our time stream manipulations. It is therefore important to avoid the utterance of Djikstra's name at all costs! ADDENDUM FOR PSU MEMBERS OF CLASSES NE-100 AND HIGHER The relation between Djikstra and Dijkstra's name is of course not a coincidence. As was already evidenced in the famous Considered Harmful article, the great philosopher Dijkstra was on to a monumental cosmic secret: that reality is bound by a term rewriti -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Mike Thompson none.by.e-mail wrote in message news:[EMAIL PROTECTED] Then came Brad Cox's book. I read it. Then there was Glockenspiel's C++ for PC in about '87 or '88. I didn't PC in those days. I Unixed. And, of course, cfont on unix from about, what, '85? That's about when I got it. I used to chat with B.S. on the phone, discussing and proposing features. Now he's rich and famous. Me? Would you believe rich? How about not destitute? Across the late '80s there was, of course, Eiffel which seemed a remarkable piece of work for the time. And was backed by a terrific book by Myer. I puzzled long over whether to adopt C++ or Eiffel at the company I was with at the time. I went with C++, dispite the fact that cfront was slow as death and buggy. C++ made it bigtime and the company went public. Lucky guesses? Hah! Ah, nostalgia isn't what it used to be. Jive -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Try comp.object. John Roth projecktzero [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
projecktzero wrote: 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. The question in your first paragraph is largely answered (albeit indirectly) by your second. You are doing web programming. It's highly unlikely that you currently are near your limits in terms of either overhead (I'll take that to mean memory usage) or performance, and you are almost certainly limited by bandwidth. In other words, you're I/O bound and not CPU or memory bound, so any fuzzy concerns about the supposed sluggishness of OOP code are seriously misplaced. If I'm wrong, and your company has only just been surviving in the market, solely by virtue of the incredibly quick and lightweight code crafted by your wizardly but dated co-worker, then I'll happily go to work disproving his ludicrous claim. Until then, it's hardly worth the discussion... a clear case of premature optimization, and in this case costing your company huge benefits in lowered maintenance costs, higher code quality, greater reuse, access to more up-to-date programmers than your co-worker ;-) and so on. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
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
Re: lies about OOP
On Mon, 13 Dec 2004 19:33:25 -0800, projecktzero wrote: 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? Oh, he's probably telling the truth, in that unless you have the type of an object defined at run time then a straight procedural call is going to be quicker, because classic procedural code has a very tight mapping to the underlying hardware. Of course, the issue is not about raw speed - which in many cases does not matter (and the few where it does you can work around) ; it's about maintainability, modularity and so on. I once worked at a place (this would be mid 1980s) where the other coders would not accept that it was better to use names for subroutines such as CalculateBillingTotal or variables such as StaffName. The argument was well, gosub 13000 and S$ are the same thing which misses the point. If he's that obsessed speed what is he doing coding with Perl (hell I like Perl) which is compiled to a bytecode which is then interpreted why not code in 'C' or even Assembler, then it'll be really quick ? Answer ; you like the facilities of the language. So it is a trade off. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
Craig Ringer wrote: On Tue, 2004-12-14 at 16:02, Mike Thompson wrote: I would pick the publication of Design Patterns in 1995 by the Gang of Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when the Joy of OOP would be widely known. DP formalized a taxonomy for many of the heuristics that had evolved only intuitively up until then. Its emergence reflects a general maturation of concept and practice, sufficient to say that the Joy of OOP could be said to be widely known. In actual fact, virtually all the design patterns came from the Interviews C++ GUI toolkit written in the early '90s. What an utterly brilliant piece of work that was. As somebody who has just been bowled over by how well Qt works, and how it seems to make OOP in C++ work right (introspection, properties, etc), I'd be interested in knowing what the similarities or lack thereof between Qt and Interviews are. Qt provides widgets that a client app. can compose into a GUI. InterViews provides 'glyphs' [*] that form a scene graph in a display server. Although InterViews usually was compiled into a client-side library, it provided all the functionality required by a display server such as redisplay and pick traversals. Indeed, the X Consortium supported InterViews (and its successor Fresco) for a while as the next generation for its 'X Windowing System', until it was dropped (for mostly political reasons, as usual) about '95. (Fresco had been nominated, together with OpenDoc, as candidates for an 'Compound Document Architecture' RFP on the Object Management Group. OpenDoc won.) [*] The term 'glyph' reflexts the fact that the scene graph nodes in InterViews are extremely fine-grained, i.e. glyphs can represent individual characters or elements of vector graphics such as paths. That's unlike any conventional 'toolkit' such as Qt, where a 'widget' is quite coarse-grained, and the display of such 'widgets' is typically not that of a structured graphic, but procedural. Regards, Stefan -- http://mail.python.org/mailman/listinfo/python-list
lies about OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
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. https://www.tundraware.com/Technology/Bullet/ -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- http://mail.python.org/mailman/listinfo/python-list
