One case proves nothing

Post #27,733 by tablizer 2/7/02 9:31:22 PM 2/7/02 9:35:34 PM Reply	One case proves nothing Large OOP systems have also had huge catastrophies. Unfortunately, companies rarely brag and publish failures (and even sue if consultants mention it). In such a lawyer-friendly environment, anecdotal information is not a very representative sampling technique. Edward Yourden, an IT writer, has surveyed companies to see which technologies IT managers thought were helpful. OO scored no better than average. In fact, it scored better than average early in its odoption, but pettered out to the average line. He speculated that "OO enthusiasts" were deluted over time by "regular" programmers coming into the mix who did not have the same zeal as the initial OO fans. Further, that page borrowed some of the drivel from Bertrand Meyer it appears. (I have a whole webpage critiquing his book.) ________________ oop.ismad.com Edited by tablizer Feb. 7, 2002, 09:35:34 PM EST One case proves nothing Large OOP systems have also had huge catastrophies. Unfortunately, companies rarely brag and publish failures (and even sue if consultants mention it). Edward Yourden, an IT writer, has surveyed companies to see which technologies IT managers thought were helpful. OO scored no better than average. In fact, it scored better than average early in its odoption, but pettered out to the average line. He speculated that "OO enthusiasts" were deluted over time with "regular" programmers who did not have the same zeal as the initial OO fans. ________________ oop.ismad.com Collapse All History
Post #27,825 by a6l6e6x 2/8/02 12:57:32 PM Reply	Re: One case proves nothing There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". Or, words to that effect. So in that sense you are right. But, on the other hand, I did not claim this was some kind of proof. It only an example where an OO design (actually re-design) approach worked well. I mentioned the gas meter object. One of the things that happened was the application users, in reporting a problem, would say "The gas meter is broken. It does...". The communication between the users and developers was enhanced. And, the developers could zoom in on the relevant code quickly. Can you imagine a user saying "You've got this table, and it..."? Not likely. Alex "Of course, you realize this means war." -B. Bunny
Post #27,865 by tablizer 2/8/02 8:21:27 PM Reply	ad-hoc >> There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". << You only presented one, not 1000. I am not saying that all OOP applications are crap. That is not my stance. I am only saying that OOP is overhyped and the hype is ruining progress and tools for the alternatives. >> Can you imagine a user saying "You've got this table, and it..."? Not likely. << Are you saying that tables are less trace-able than objects? Let's see you do an ad-hoc query on a bunch of objects? For example, "Show me all meters west-side that have reported leakage or cracking problems since last month and serviced by Bob". ________________ oop.ismad.com
Post #27,875 by a6l6e6x 2/8/02 9:29:58 PM Reply	Re: ad-hoc >> There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". << You only presented one, not 1000. I am amused that you don't recognize that I'm agreeing with you on that point. What I am saying here is that even if I did give you a thousand examples, it would still not be a proof. I am not saying that all OOP applications are crap. That is not my stance. I am only saying that OOP is overhyped and the hype is ruining progress and tools for the alternatives. >> Can you imagine a user saying "You've got this table, and it..."? Not likely. << Are you saying that tables are less trace-able than objects? Let's see you do an ad-hoc query on a bunch of objects? For example, "Show me all meters west-side that have reported leakage or cracking problems since last month and serviced by Bob". My point here is that users do not think in terms of tables, but developers do. Users think in terms of things in their problem domain, otherwise known as objects. Tables are things in the solution domain. When the objects in the problem domain match the objects in the solution domain, communication between developers and users is easier. Ad hoc queries are a separate issue. You either design for them or not depending on user requirements. OO does not exclude use of relational databases. Alex "Of course, you realize this means war." -B. Bunny
Post #27,878 by tablizer 2/8/02 11:05:54 PM Reply	English Oriented Programming >> My point here is that users do not think in terms of tables, but developers do. Users think in terms of things in their problem domain, otherwise known as objects. << Yeah, like they are really gonna relate to things like class TransitionStateManager. Programmers rarely man the customer phones anyhow (except in really small shops). Even under the longshot that I agreed with you that OOP was closer to English, it is mostly moot. I don't really see how OOP is close to English anyhow. Like I said, English sentences are based on one verb and potentally many nouns. "Bob and Dora rode a snowmobile to Grandma's house." This better maps to functions if you ask me. Verbs are more pivotable to English than nouns. >> OO does not exclude use of relational databases. << Yes, but does not get along with them very well. OOP and relational thinking tend to fight over territory. Either one gives in, or you duplicate (mirror) stuff. ________________ oop.ismad.com

Welcome to IWETHEY!