Criticisms of OOP (Object Oriented Programming)
top...@technologist.com
Title: Criticisms of Object Oriented Programming
It seems to me that OOP has been over-hyped and has failed to improve
programmer productivity in building custom business software.
I have built a list of OOP criticisms along with a proposed alternative or
enhancement. This enhancement is called Table Oriented Programming (TOP).
Some writers call it "Data-Centric" programming.
I invite you all to read about my comments on OOP and TOP and provide
thoughtful replies.
It starts with the first two menu items on:
http://www.geocities.com/SiliconValley/Lab/6888/
At the end of the TOP section is a link to an archived forum from InfoWorld
magazine in which these views were hotly debated. (A lot of flaming too.) I
invite you to look at these messages also.
-The Thinker-
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Charles R. Martin
top...@technologist.com writes:
>
>
>
> Title: Criticisms of Object Oriented Programming
>
> It seems to me that OOP has been over-hyped and has failed to improve
> programmer productivity in building custom business software.
Your biggest problem is going to be explaining all the reports of
productivity increases of anywhere from 30-40 percent to 15-20 TIMES.
Thaddeus L. Olczyk
responding to the post not the Web Page.
His biggest problem is that he is a moron. From the first line he shows
that he is completely ignorant of what OOP is. Despite this he feels
justified to run his mouth off. How stupid.
As for "lowestmind", OO is not founded in GUI. OO originally had nothing
to do with GUI. I have never heard of reuse taking seven years. RDBMS
do have p[roblems with complex objects, have you ever heard of
Bill-of-Materials?
vgoldberg
>His biggest problem is that he is a moron. From the first line he shows
>that he is completely ignorant of what OOP is. Despite this he feels
>justified to run his mouth off. How stupid.
It is very sad that when somebody collects enough guts to publicly ask for
help in improving his knowledge, (s)he gets attacked personally, at the
level of kindergarten. Under this light, who is the moron and the stupid?
Victor
Marcel Popescu
vgoldberg wrote in message <6fn76p$5vg$1...@newsfep4.sprintmail.com>...
Well, I stand by mr. Olczyk's claim. This guy (gal?) is really a moron. It
is not admissible for someone to pretend to be a programmer and at the same
time say something this stupid (read the web articles for more info). OOP is
a lot more than (s)he sees; and claims like "I will eat a week's salary if
oop is still en vogue in 2015" add to the lousy impression he is making...
Mark
vgoldberg
Professionalism has a number of components. One is to know your stuff.
However, this is not necessarily sufficient. Knowing how to communicate,
being informative without being abrasive, is an important component too.
I really don't believe that Topmind's ignorance is a good excuse for others
to be nasty. What benefit can anybody get from insulting another person?
Five seconds of a fake feeling of superiority? What else could be going
wrong in the life of the insulter that such a satisfaction becomes suposedly
meaningful? Maybe taking care of these other problems will be more efective
than putting down people that are trying to learn something new?
Victor
Marcel Popescu wrote in message <6fod0k$9st$1...@main.roknet.ro>...
Russell Wallace
Thaddeus L. Olczyk wrote:
[re: criticisms of OOP]
> His biggest problem is that he is a moron. From the first line he shows
> that he is completely ignorant of what OOP is. Despite this he feels
> justified to run his mouth off. How stupid.
IMO, the criticizer has some valid points.
Yes, OOP has good aspects. It also has bad aspects. The web site lists
several.
One of its bad aspects that we see a demonstration of above is that it
has a lunatic fringe of adherents who start foaming at the mouth at the
slightest suggestion that OOP mightn't be the perfect tool for every
situation.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mano...@iol.ie
Thaddeus L. Olczyk
Russell Wallace wrote:
>
> IMO, the criticizer has some valid points.
Lacking a clear reference to which person you are speaking about,
I must assume it is the original poster ( Note: All posters to this
thread
could have criticised). In which case I must ask exactly what points are
valid?
I'm curious as to what the ratio of valid points to shear stupid
statements is ( my guess 1:5 to 1:10).
Or in simpler talk, put up or shut up.
>
> Yes, OOP has good aspects. It also has bad aspects. The web site lists
> several.
Such as?
Since the statements on the web page seem to indicate that "lowestmind"
learned all his OO from PC World and InfoWorld, or magazines along those
lines, it is hard to believe the guy got anything right.
>
> One of its bad aspects that we see a demonstration of above is that it
> has a lunatic fringe of adherents who start foaming at the mouth at the
> slightest suggestion that OOP mightn't be the perfect tool for every
> situation.
1) Since I have always said that I suspect something will come along
that will
supercede OO, I find it hard to believe that I'm part of that lunatic
fringe.
2) My objection is not to criticisms of OO, it is idiots who pick
insufficient
reference materials to learn X and then go out and criticise it to boost
their egos.
My experience is that any value such people's opinion have is not worth
having to deal
with their stupidity and arrogance.
3) Any one who goes out and tries to get public praise should be able to
handle public criticism.
Harry Protoolis
OK, I read your page, mostly I disagree with it. Here are my comments:
> The GUI Link
>
> OOP became popular primarily because of GUI interfaces. Screen objects
False. OOP has it's roots in systems simulation, this opening assertion
suggests that you need to do some serious research. It's popularity
began with systems programming, what do you think they were building at
Bell Labs ? Word processors ? No, in fact as I recall they were looking
at software for conrtrolling telephone switches.
> correspond closely with OOP objects, making them easier to manipulate
> in a program. We do not disagree that OOP works fairly well for GUI's,
> but it is now being sold as the solve-all and be-all of programming.
The number of times I have heard respected OO people give the 'no silver
bullet' speech ..., OO is not a silver bullet, if anything one if the
fundamental assertions is that there *is no silver bullet*.
> Some argue that OOP is still important even if not dealing directly
> with GUI's.
It is, most of my work is with high end real time systems for signal
processing, OO techniques are a vital part of our approach and have had
a major positive impact.
> In our opinion, much of the hype about OOP is faddish. OOP
> in itself does NOT allow programs to do things that they could not do
> before. OOP is more of a program organizational tool rather than a set
> of new solutions or functions.
Yes ! absolutely. OO is about organising software to deal with large
complex systems. If all it does is allow us to build larger more complex
systems than before then it is a revolution.
> Although GUI's revolutionized the industry, there is more to computers
> than GUI's. Also, there may be other was to handle GUI's besides OOP.
OO is not primarily, or even mostly, about GUI's. OO is about large
systems with complex behaviour.
> Nobody ever bothered to do a proper study. There is more proof to the
> existence of UFO's than to OOP being the best way to do GUI's or any
> other programming topic.
There is no 'proof' of the exitence of UFO's at all. There is a
respectable and growing body of OO research. Certainly it is early days
yet.
> There are what we call table-intensive or list-intensive applications
> (or parts of applications), batch-intensive applications,
> animation-intensive applications, communication-intensive
> applications, etc. The syntax or native data types optimized for each
> type of application could be very different. Although a generic
> programming language could probably be used for most or all of these,
> this does not make the generic language the best solution. We
> especially beleive this to be true for table/list-intensive
> programming.
Yep, fine, write it in dBase IV for all I care. We have done the 4GL
experiment, it works well for small simple projects, it is a disaster
when you try to model complex behaviours.
> We are not saying the OOP is bad, per se; we are just frustrated with
> the fact that OOP has slowed or even reversed programming progress in
> these other areas. OOP has contributed some good ideas to programming,
> but is certainly no holy grail.
OO is a powerful meme, it is attractive. The dominant anecdotal evidence
is that programmers enjoy working on OO systems. If you want to do
research on other approaches, go for it. However don't blame others if
your favourite research topic doesn't find favour with the industry.
> Note: Some people associate "drop-in objects" with object oriented
> programming.
This is ridiculous.
> Drop-in or draggable objects or icons can be completely
> implemented without OOP. OOP is a programming technique, not
> necessarily a GUI technique.
OOP is *not* a GUI technique.
> Payoff Rare
>
> There are several studies that show that OOP only pays off if a
> programming project is "well-managed". There are also a few studies
> that show that even non-OOP COBOL projects can achieve the same famous
> "code reuse" and "flexibility" goals that OOP lays claim to if managed
> properly. (Sorry, we lost the references.)
I have a perfectly mervellous proof of this theorem which the margin is
too narrow to contain - Fermat.
> Studies show that most OOP projects do not really achieve the goals
> (improvements) of the OOP promise because all parties have to buy into
> the proper methodologies. These parties include programmers, project
> managers, and top level managers. Since code reuse and added
> flexibility often come only after about 7 years, many are unwilling to
> follow the process correctly. Using OOP often slows down progress in
> the first few years. If done right, OOP works as a long-term
> investment; it is not an instant results tool even according to OOP
> experts.
Yes, and ?
> Many project teams just slap the label "OOP" on their project because
> they used OOP languages and tools, not because they took advantage of
> OOP potential. OOP by itself does not improve productivity. Many
> studies say in practical terms that most OOP projects fail to produce
> benefits over non-OOP methods because for political, technical, or
> training reasons, OOP is "not being used properly."
Yes, and ?
> As programmers we can say from experience that managers rarely reward
> or encourage long-term planning. Obviously there will always be a
> tradeoff between getting a project done fast and building a project
> with future changes in mind. Since managers do not give a rats behind
> about 7 years away when their job may not last another 7 months, the
> programmer is usually forced to take the fast route. This is the sad
> but true reality.
Yes, but in 7 years which companies will be left ? I heard this argument
10 years ago as to why I should become a mainframe COBOL programmer
rather than a Unix C programmer. Me and my bank manager are both glad I
chose the latter even though at the time COBOL and mainframes were dominant.
> It is also difficult to quantify the amount of future planning in
> application design. The proof is in the future and in the details, and
> the people who sign a developer's paycheck rarely dig this deep.
Again, lets see what happens, this sort of unsupported forecasting adds
nothing to the argument. Obviously a lot of people are investing in OO,
otherwise you wouldn't be complaining about it.
> OOP Community Still Divided
>
> In addition, the OOP community is strongly divided on whether the
> "component" model or the "inheritance" model is the way to go.
> Microsoft seams to favor the component model. The jury is still out on
> this one. Without getting into the details of this battle, let's just
> say OOP still has some growing up to do.
This appears to be made up. There is no such general debate. There are
debates about such issues as remote method invocation, persistence and
object distribution, but they have nothing to do with the general
concepts of OO.
> Not Table-Friendly
>
> OOP often does not map well to relational databases. Even though OOP
> languages are common, object-oriented databases (known as "OODMS") are
> not. OODMS's are in their infancy and are not selling very well at the
> moment. In business applications, most object instances are actually
> equivalent to fields and records. A good data dictionary
> (table-oriented technique) is almost identical to using OOP
> constructors, destructors, and attributes associated with fields and
> tables.
No it is not. The relational model fails to address issues of complex
objects with the sort of heirarchical structure commonly found in the
real world. Have you ever heard of the Bill-Of-Materials problem ? A
common business problem which the realtional model totally fails to
address.
> Using relational tables with OOP requires converting fields into
> objects and visa-verse when putting them back into the tables. This is
> a painstaking process and can waste a lot of programming time. The
> popular OOP languages like Java and C++ require the use of API's or
> API-like constructs to manipulate databases. API's are fine for
> occasional or special use, but if 80 percent of your program
> manipulates tables, API's become a bottleneck.
By API you mean libraries ? What is an API-like construct ? If it's a
database language you want so problem, but why not an OO database
language ?
> We liken API's to having to reach into a small hole to get tools in
> and out of a tool box. Table-oriented languages are like dumping the
> tools all over the floor around you so that they are readily
> available. Although this analogy makes it sound messy, it actually
> makes one much more productive because more of the programming code is
> to directly manipulate data instead of pre- and post-processing it as
> it comes and goes through API's.
Surely this depends on your API, in any event your data will be getting
transformed as it goes to and from your persistent store.
> Melding Can Be Hazardous
>
> OOP pushers like to talk about how great it is to meld the methods
> (procedures) and the data together. Data in traditional relational
> form is relatively easy to transfer to different systems as technology
> and vendors change. Procedures are NOT easy to transfer. If you mix
> the data in with methods, then you are STUCK with the current
> programming language. You cannot easily read the data except with the
> OOP language that generated it.
What does the data *mean* without the associated behaviours ? This is
one of the true powers of OO. Instead of a row of data like this:
name rate level
-------------------------------------
John Smith 8000.00 2
I get an object which I can ask questions like:
o.name()
o.costPerHour()
o.isManager()
> When a new language fad replaces OOP, how do you convert legacy Java
> objects into Zamma-2008 objects? (If objects even exist in the future.
> I will eat a week's pay if OOP is still in vogue in 2015.)
I'll hold you to that ...
> How many
> times do different programming languages and systems have to share
> data? Very often in the real world. Thus, it is usually safer to keep
> large data pools separate from methods.
Where two or more pieces of software share a piece of data surely you
want them to treat the data in the same way, observe the same invariants
and apply a number of the same algorithms. If John is a manager in the
security system he should be a manager in the payroll system. If payroll
is paying him $50.00 per hour, financial planning had better be planning
to pay him $50.00 per hour.
> Tree-Happy
>
> The 'inheritance' model of OOP tends to assume the world can be forced
> into a hierarchical structure, when in fact the relational structure
> is more flexible and better matches the real world. Even a company
> management hierarchy is often defined in a nonhierarchical way when
> management plays political games or uses the matrix approach. Several
> times we have seen simple hierarchical structures turn into something
> a bit different when new government regulations or management changes
> come along. Although it is true that OOP does not have to use
> hierarchies, it would lose one of its alleged great selling points
> without hierarchies.
How does the relational model deal with the the fact that the world
contains clear is-a relationships ? How about many-to-many aggregation ?
While you are right the not *everything* is a heirarchy, many things
are, given that the relational model is very bad at handling simple
heirarchies, let alone complex ones, how does that make it better ?
> Research Lacking
>
> Furthermore, there is very little research on whether non-OOP
> languages can be used such that reuse and flexibility can be increased
> to the same levels as properly-used OOP. In other words, the industry
> keeps adding new languages and features to solve the same problems
> instead of improving use of existing languages. Many are coming to
> believe that most of the computer industry is led by hype instead of
> careful research. OOP spread like a weed before there was any proof
> that it could or would be beneficial. (And the current proof is highly
> conditional).
Yes, but there is some. OOP spread because programmers liked it and
because it *is* getting results. Otherwise all those companies out there
using OO would be getting mowed down by their non OO competitors.
> The hardest part of getting OOP to deliver promised benefits,
> according to the experts, is identifying common and generic business
> functions and processes. Once identified, they perhaps can be
> implemented in a Table-Oriented language or any other general-purpose
> language as easily as they are in OOP, especially with a good
> data-dictionary-like model. (The data dictionary can be 'virtual', it
> does not have to be built into the language.)
Language support helps though. Look at X Windows to see how hard OO is
without language support. Without support for key concepts like
inheritence and polymorphism few of the key benefits of abstraction of
the business model can be achieved.
> Another Fad?
>
> OOP is a lot like those idealistic development fads that failed to
> prove themselves in the real world. Expert systems, CASE, and 3-tier
> client/server technology are three other examples of technology that
> failed in the real world or took on a niche status. After the market
> place realizes the shortcomings of these technologies, the die-hard
> supporters always say the same thing: "They WOULD work if people
> simply used them properly." We are already hearing this from OOP
> apologists.
How many of the above list of failures achieved the prominence that OO
has already acheived ? OO is already a success beyond anything acheived
by Expert systems, or CASE or the others.
I've run out of time. This will do for now ,..
H
Jim Cochrane
In article <6ft2sm$8...@b2.nautronix.com.au>,
Harry Protoolis <ha...@nautronix.com.au> wrote:
>OK, I read your page, mostly I disagree with it. Here are my comments:
>
>
>
>No it is not. The relational model fails to address issues of complex
>objects with the sort of heirarchical structure commonly found in the
>real world. Have you ever heard of the Bill-Of-Materials problem ? A
For the benefit of those of us who have not come across this problem
(Bill-of-Materials), would you mind posting a reference? Thanks.
>>...
>
>What does the data *mean* without the associated behaviours ? This is
>one of the true powers of OO. Instead of a row of data like this:
>
>name rate level
>-------------------------------------
>John Smith 8000.00 2
>
>I get an object which I can ask questions like:
>
>o.name()
>
>o.costPerHour()
>
>o.isManager()
This is a totally unrelated topic (I'm too lazy right now to start
another thread), but I've been wondering for the past several months
what the rationale is behind a standard naming convention for queries
such as the above, which is to prefix the word get in front of the
query name. So with the convention, the above queries would become:
o.getName()
o.getCostPerHour()
o.getIsManager()
(Most people wouldn't use the last one - I just thought I'd throw it in
to exaggerate the awkwardness of the convention <g>)
I have never seen a good explanation for this convention. I find it awkward
compared to the convention used in your example. (For example, the line
if (o.getName() == "Fred") {...}
compared to:
if (o.name() == "Fred") {...}
I find the second one much more readable. In addition, putting get in
front implies to me retrieval of an attribute, but it is not wise to
make the fact that a property is implemented as an attribute (rather
than as an argumentless function) known to a client using the class
interface (that is, the fact that it's an attribute should remain
hidden in the class implementation). Can anyone provide a convincing
argument for getx naming convention?
Jim Cochrane
j...@dimensional.com
top...@technologist.com
>His biggest problem is that he is a moron. From the first line he shows
>that he is completely ignorant of what OOP is.
Reply:
I added a new paragraph to my page to defend your "moron" claim:
Q: You are nothing but a bigmouth who has not studied OOP well enough to know
how to apply it to something other than GUI's.
A: I am the product of the same education process that most of the other
programmers out there get. Most OOP books focus on GUI's. When they cover
data handling, they fail to show how OOP is an improvement over table-
oriented or other methods. If I am uninformed, then so are most programmers.
If you agree with this, then OOP is doomed because the industry is not
presenting [training] OOP properly. My alleged ignorance may simply be a
mirror to a much larger problem.
Mr. Topmind
top...@technologist.com
Reply:
There are reports of successes, and reports of failures. Since people tend
not to advertise failures, you often don't here about them. I have no 100%
reliable stats (either do you), but I do hear very mixed reports. Anecdotal
reports tell very little.
Mr. Topmind
-----------------------
In article <wkyaxtt...@pop.connix.com>,
crma...@connix.com (Charles R. Martin) wrote:
>
> top...@technologist.com writes:
>
> >
> >
> >
> > Title: Criticisms of Object Oriented Programming
> >
> > It seems to me that OOP has been over-hyped and has failed to improve
> > programmer productivity in building custom business software.
>
> Your biggest problem is going to be explaining all the reports of
> productivity increases of anywhere from 30-40 percent to 15-20 TIMES.
>
Olen Vance Sluder, Jr.
Jim Cochrane <j...@jupiter.milkyway.org> wrote in article
<6ftlvp$d...@jupiter.milkyway.org>...
> For the benefit of those of us who have not come across this problem
> (Bill-of-Materials), would you mind posting a reference? Thanks.
I had the extreme (perverse) pleasure of programming a bill-of-materials
processor about 12 years ago in the Lotus 1-2-3 macro language, so I will
venture a quick (simplistic?) explanation. A bill-of-materials is a
collection of all the parts contained within a manufactured item, usually
divided by assembly and subassembly down to the "piece part", e.g., screw
or wire. Sounds easy enough except for a major problem with recursion.
The same piece part can be used in multiple subassemblies, the same
subassembly in multiple assemblies, and so on... Now Manufacturing is
happy with a report showing assembly, subassembly, and piece part. On the
other hand, Purchasing wants a report with the total counts of all the
piece parts. <sigh>
--
Olen Vance Sluder, Jr. | <mailto:ol...@acm.org>
Professional Codeslinger |
San Antonio, Texas USA | "Have CASE, Will Travel"
Tim Ottinger
top...@technologist.com wrote:
> It seems to me that OOP has been over-hyped and has failed to improve
> programmer productivity in building custom business software.
This is true of every technology that's ever been useful. Remember the
"structured"thing back a few years? And the "desktop" thing? And the "Handheld"
thing? And
GUI, and CASE, and 4GL?
If the argument is that OOP has been taught poorly and overhyped, then you are
right. But you blame OOP itself for being poorly taught and overhyped, then
that
is not correct. The practitioners of OO tend to be very conservative. It's
salespeople
and marketers who've made a mess of things. And inexperienced folks who manage
to get too much play in major magazines.
Any tool will suffer as much from popularity as from obscurity. OO, when
obscure,
didn't have the big problems of being ill-managed, sold as a cure-all, and
hyped from
the rooftops.
Likewise, SQL was not the end-all language it was hyped to be. Hypesters (not
DB experts) claimed that with SQL all of our apps would be 100% portable, that
all databases would support the SQL the same way, and that we'd no longer have
to design data access because the declarative language would make all data
access
completely transparent. In reality, SQL helped in some ways and is a useful
tool.
But it didn't come close to the hype.
Then, are we to throw out the baby with the bath water? Is SQL evil and wrong?
Does it "suck" because people who were peripherally involved made claims that
the experts knew were unrealistic?
I blame the hype, and the hypesters. OO is a tool. It does help. It's useful in
a great many realms (systems programming, GUI, multithreaded apps, server
designs, business apps, workflow systems, etc). But that doesn't mean that it
will live up to unrealistic hype in any realm.
Your history is also off, as is your understanding of the intent of OO.
But you probably came by it honestly, reading the wrong trade rags.
Whatever you do, don't learn OO by reading management magazines.
You'll never be more wrong.
You are also neither the first nor the only one to decry the hype. I know
a rather famous object oriented magazine that caters to manager-level
folks (I'll not divulge more) where a high-ranking official claims that OO
is losing saleability because the hype was not lived up to. OO is seen
as being difficult (finally).
OO isn't the easiest thing to learn (neither is algebra). It's not going to
give "quick hit" fixes whereever it's applied. It is focused on the long
life and maintainability/flexibility of systems instead of a fast first
delivery.
It sometimes does greatly reduce time to market, and other times not.
None of these things say that it's not good engineering.
Beware, though, because you are walking in paths previously trod.
You are the latecomer to the 4GL hype. Be careful that you don't
commit the same sins as you accuse others of, as 4GLs have all
through the years.
> I have built a list of OOP criticisms along with a proposed alternative or
> enhancement. This enhancement is called Table Oriented Programming (TOP).
> Some writers call it "Data-Centric" programming.
A lot of the criticisms are simply saying "the hypesters were wrong", and
notthat OO is wrong. By the way, you've swung the pendulum too far the other
way in attempting to make OO sound nearly useless. The truth is moderate,
and both viewpoints are too radical.
That's all I have to say.
Todd Hoff
Jim Cochrane wrote:
>
> I have never seen a good explanation for this convention. I find it awkward
> compared to the convention used in your example. (For example, the line
>
> if (o.getName() == "Fred") {...}
>
> compared to:
>
> if (o.name() == "Fred") {...}
If a reference is returned the value can be changed
which is not often wanted, at least in the public interface.
If a new object is created it tends to be inefficient.
Historically using the get/set prevents name clashes
with class and variable names.
It also doen't allow for the class containing the
name object to specialize the set behaviour without
deriving a new class. Using a setX allows you to do anything
you want in the process of setting the value. It
could include stricter validation, firing an event
to an observer, etc.
I talk about different get/set approaches in my C++
coding standard at http://www.possibility.com/Cpp.
------------------------------------------------------------------
t...@possibility.com http://www.possibility.com/Tmh
I have no interest in any ship that does not sail fast, for I
plan to go in harm's way. -- J.P. Jones
Tim Ottinger
top...@technologist.com wrote:
> Q: You are nothing but a bigmouth who has not studied OOP well enough to know
> how to apply it to something other than GUI's.
>
> A: I am the product of the same education process that most of the other
> programmers out there get. Most OOP books focus on GUI's. When they cover
> data handling, they fail to show how OOP is an improvement over table-
> oriented or other methods. If I am uninformed, then so are most programmers.
> If you agree with this, then OOP is doomed because the industry is not
> presenting [training] OOP properly. My alleged ignorance may simply be a
> mirror to a much larger problem.
You know, there are good introductions available, too. I don't have any of the
"focused on GUI" books, and I've been collecting books for a while. In one
of them, the data handling issues are clearly explained.
However, see my earlier post as to what I think is going on. In short, I think
the popularity of OO has caused a surge of quackery where everyone who's
been on one, two, or three projects and has read a book claims guruhood.
It's sad, but remember "Professer" Brown from the Edison/Westinghouse
wars? This isn't a new thing.
When database scripting langua... er.. 4GLs were all the rage, there was
just as much hackery in that quarter. Still is, actually. They run on Fear,
Uncertainty, and Doubt against OO and IE instead of capitalizing on
market optimism like they used to.
tim
Marcel Popescu
Russell Wallace wrote in message <35216E...@iol.ie>...
>IMO, the criticizer has some valid points.
>
>Yes, OOP has good aspects. It also has bad aspects. The web site lists
>several.
>
>One of its bad aspects that we see a demonstration of above is that it
>has a lunatic fringe of adherents who start foaming at the mouth at the
>slightest suggestion that OOP mightn't be the perfect tool for every
>situation.
He didn't list that one... :-)
Neither I, not the original "adherent" has seen any valid "bad aspect" of
OOP - only a general misunderstanding of the whole subject. The only valid
point that I see (and this is not specifically discussed in the web site) is
that OOP can be hard for no-brainers; which is something I can understand,
and I can wholeheartedly recommend something easier for them.
Mark
top...@technologist.com
reply to Harry
> False. OOP has it's roots in systems simulation, this
> opening assertion suggests that you need to do some
> serious research.
I did not say it had its ROOTS in GUI's, I said it became popular because of
GUI's. Who is lacking in the "serious research" now? Birth and growth are
different.
> The number of times I have heard respected OO people give
> the 'no silver bullet' speech ..., OO is not a silver bullet,
> if anything one if the fundamental assertions is
> that there *is no silver bullet*.
But its hype-to-usefulness ratio is way too high. It spread like wildfire in
the market.
> It is, most of my work is with high end real time systems for
> signal processing, OO techniques are a vital part of our
> approach and have had a major positive impact.
Signal processing may fall into the "in-memory intensive" category that I
talked about. It may indeed help there. But what percent of programmers do
primarily signal processing for a living?
> If all it does is allow us to build larger more complex
> systems [better] than before then it is a revolution.
For some systems perhaps, but not necessarily all.
> There is a respectable and growing body of OO research.
What were they comparing it against?
Who sponsered the research?
> The dominant anecdotal evidence is that programmers
> enjoy working on OO systems.
My impression is that academics love it because it is intellectually "nifty";
however, paid programmers use it simply because they fear falling behind and
have been told OOP is modern and everything else will make them obsolete.
(I have not seen your part 2 yet, so I will wait to respond to it.)
top...@technologist.com
reply to: Tim Ottinger
> This [hype] is true of every technology that's ever been useful
It is also true of stuff that settled into SMALL niches, like expert systems
and CASE. I agree OOP has a niche, the issue is how big the niche should
and/or will be.
> Then, are we to throw out the baby with the bath water? Is SQL evil and
wrong?
> Does it "suck" because people who were peripherally involved made claims
that
> the experts knew were unrealistic?
It is a matter of balance. The OOP hype factor is ruining a lot of good
products, projects, and research IMO because it distracts effort from other
improvements. Part of the reason I am so musturdy about OOP is that it ruined
a lot of my favorite features/tools because these tools were not able to ride
the hype.
> it is focused on the long life and
> maintainability/flexibility of systems instead of a fast > first delivery.
It seems like fast first delivery is what the market actually *wants*. With
buyouts, layoffs, and restructuring so common, most business only plan up to
about 18 months. They also (rightfully) see technology as dynamic and fadish.
What use is it to build your future on OOP when OOP may disappear from vogue
(either because of lack of merit or some new hype).
> By the way, you've swung the pendulum too far the other
> way in attempting to make OO sound nearly useless.
IMO, you have to fight fire with fire. Hype made it too tall, so hype may be
needed to tear it down to a realistic height. Hopefully though, I put in
enough specifics to guide those who see thru the hype.
top...@technologist.com
> You know, there are good introductions available, too. I don't have any of
> the
> "focused on GUI" books, and I've been collecting books for a while. In one
> of them, the data handling issues are clearly explained.
I have also seen data handling DONE in OOP, I just have not seen how its an
improvement over alternatives.
I also think that data handling is crying for more research and attention. I
have no strong evidence that something really nifty will be found, but I have
a strong hunch. My most productive programming time was when using data-
centric languages and approaches. OOP has its values, but IMO, there are
still good ideas yet to be found and/or promoted.
Mr. Topmind
P.S. Thanks for not overflaming me. I might deserve a little flaming, but
not the stronger names like "moron" and "idiot". It seems the stronger the
flames, the less constructive criticism is given. c = 1/f
Jim Cochrane
In article <6fu0cd$asq$1...@nnrp1.dejanews.com>,
<top...@technologist.com> wrote:
>
>>His biggest problem is that he is a moron. From the first line he shows
>>that he is completely ignorant of what OOP is.
>
>Reply:
>
>I added a new paragraph to my page to defend your "moron" claim:
>
>how to apply it to something other than GUI's.
>
>Most OOP books focus on GUI's.
How did you get that impression? I have somewhere between 10 and 20
OO and OO-related books on my bookshelf and none of them focus on GUIs.
(Oops, I'm wrong - one of them does: OOP with C++ and OSF/Motif.)
These include the standard OO books, such as Booch, Jacobson, Meyer, etc.
Perhaps it's true that most OOP books focus on GUIs, but it is obviously
not true that most _good_ OOP books (books that are valuable for learning
OOP properly) focus on GUIs.
>data handling, they fail to show how OOP is an improvement over table-
>oriented or other methods. If I am uninformed, then so are most programmers.
>If you agree with this, then OOP is doomed because the industry is not
>presenting [training] OOP properly. My alleged ignorance may simply be a
>mirror to a much larger problem.
>
>Mr. Topmind
What an unusual name you have <g> Is it English?
Jim Cochrane
j...@dimensional.com
Thaddeus L. Olczyk
Jim Cochrane wrote:
>
> For the benefit of those of us who have not come across this problem
> (Bill-of-Materials), would you mind posting a reference? Thanks.
>
Title: An Introduction To Relational Database Systems (I think).
Most well stocked books stores (Borders, Barnes and Noble) should
carry it.
Harry Protoolis
In article <35228E87...@possibility.com>,
Todd Hoff <t...@possibility.com> writes:
> Jim Cochrane wrote:
>>
>
>> I have never seen a good explanation for this convention. I find it awkward
>> compared to the convention used in your example. (For example, the line
>>
>> if (o.getName() == "Fred") {...}
>>
>> compared to:
>>
>> if (o.name() == "Fred") {...}
>
> If a reference is returned the value can be changed
> which is not often wanted, at least in the public interface.
> If a new object is created it tends to be inefficient.
>
> Historically using the get/set prevents name clashes
> with class and variable names.
>
> It also doen't allow for the class containing the
> name object to specialize the set behaviour without
> deriving a new class. Using a setX allows you to do anything
> you want in the process of setting the value. It
> could include stricter validation, firing an event
> to an observer, etc.
I think you misread his post, thats an == up there, not an =
Personally I gave get/set up some time ago. The rule I use is of the
form:
const string &name() const { return m_name; }
void name(const string &name) { m_name = name; }
which is used as follows:
string x = o.name();
o.name("Fred");
I find it a lot more readable without the get/set prefix.
I do use the prefix 'is' for queries, i.e
bool isManager() const;
My rule is that the accessor and query method must be const, as must the
argument to the mutator. (i.e. void name(const string &), not
void name(string &)).
Works for me, and it is easy to teach and enforce. IMHO any coding
standard that is hard to enforce is probably a bad standard ...
--
-
Harry Protoolis Nautronix Limited
ha...@nautronix.com.au Fremantle, Western Australia
Patrick Logan
top...@technologist.com wrote:
: There are reports of successes, and reports of failures. Since people tend
: not to advertise failures, you often don't here about them. I have no 100%
: reliable stats (either do you), but I do hear very mixed reports. Anecdotal
: reports tell very little.
The same is true for relational database projects, or any set of
significant software projects. Some are successful and some are not, and
the root causes are not commonly accurately made known.
Significant successes have been achieved by all kinds of software tools
and techniques. Good, experienced people will play a large role, managers
and developers.
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Thaddeus L. Olczyk
lowes...@technologist.com wrote:
>
> reply to: Tim Ottinger
>
> about 18 months. They also (rightfully) see technology as dynamic and fadish.
> What use is it to build your future on OOP when OOP may disappear from vogue
> (either because of lack of merit or some new hype).
Thaddeus L. Olczyk
top...@technologist.com wrote:
>
> Reply:
>
> There are reports of successes, and reports of failures. Since people tend
> not to advertise failures, you often don't here about them.
advantage.
Dave Harris
ha...@nautronix.com.au (Harry Protoolis) wrote:
> const string &name() const { return m_name; }
>
> void name(const string &name) { m_name = name; }
I agree about the accessor, but not the modifier.
From a theoretical point of view, the methods are doing very different
things so IMHO it is an abuse of overloading to give them the same name.
In practise, I sometimes want to search for "all places where the name is
set" and that's easier if they are tagged with "setName".
I think it gets especially confusing when you have accessors that take
arguments. Eg suppose the interest rate can change monthly, so that:
float rate( int month );
is an accessor; with your convention it looks just like a modifier. I
think changing the state of an object is a "big deal"; the distinction
between state-changing methods and methods that don't change state is one
of the most important we can make.
I agree about the accessor, though. Adding "set" to the modifier satisfies
my requirements so adding "get" to the accessor is unnecessary. It doesn't
add any value and it wastes source space. It make sense for the accessor
to be shorter because it is (usually) used more often than the modifier.
In C++, it's cool to make the accessor function "name()" no longer than
the variable itself "m_name" (or "myName"), to reduce the temptation to
get the variable directly.
All that said, nowadays I use Java where the standard is to use "getName".
In this case it's better to with the standard even though it's wrong :-(
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Rick Jones
j...@jupiter.milkyway.org (Jim Cochrane) wrote:
> Can anyone provide a convincing
> argument for getx naming convention?
It seems to have become "de-rigeur" largely as a consequence of Java
Beans. It is mandated (or at least strongly recommended) in the Bean
interface specification so that introspection can determine that a pair
of get/set methods retrieve and set a "property". This property can
then be exposed to an application builder as one thing instead of two.
I personally think this approach pollutes the language in order to
simplify the higher-level component world. I much prefer to use just a
name at least for the retrieval of a value. In fact I think Java went
wrong in sticking to the gratuitous use of () when calling a function.
It's necessary in C because you can also get the function's address, but
not in Java. I don't think there are any other languages that require
empty () just because it's a function, even when there are no arguments.
If you omit them, then you have uniformity of syntax, and you can
implement a value as an actual member, or as a function - the calling
syntax is the same (assuming read-only). As the user of an interface I
shouldn't need to care whether I get the name by o.name because it's a
variable, or o.name() because it's returned to me from a function. Or
worse as we now have, because it's a function I have to "get" it so I
call o.getName().
What I do need to be clear about with a reference-based language is
whether a function that returns an object gives me a reference to the
same instance that the object I got it from is using, or a copy (this
only matters if the object is mutable). getX doesn't help here at all.
I try to use either newX or createX when a copy is returned. I try to
keep createX for an object that performs a factory function, rather than
just returning a copy of a property.
I also think the whole concept of "setX" as an interface style is bad OO
thinking. An object has state, which you can see by looking at its
current values, but all changes to that object's state should be under
control of the class. The user of an object has no right to say "set
the value of this attribute to something new". Just implementing a
"set" function which says "I'll check if the change you want to make is
valid before accepting it" doesn't address the real problem. The user
of the object should not treat the values as things he can individually
tweak, he should see methods that perform defined transformations on the
object.
The get/set mentality comes from still seeing objects as data
structures, with public members. If a member is public you can read it
and change it - right? Should be wrong, a better way to expose state is
to have values that are accessible read-only, and methods that perform
transformations of state. The methods don't have to correlate to
one-per-attribute, but should reflect an intrinsic behaviour of the
object that results in a change of state. And if you get rid of "()",
then values/attributes/properties can be accessed as a member variable
or as a function transparently.
Although expecting Java to change is wishful thinking, you can implement
the concept by careful design. A good naming convention, even when
everything is actually a function, is:
Noun a property or value of the object - e.g. name(), value()
newNoun a copy of a property, where the property is itself an object
Question a boolean property - e.g. isNew(), hasPrice()
Verb a change to the object - e.g. update(...), adjust(...)
my $.02 + x% worth
dogmat
top...@technologist.com wrote in message
<6fv2fc$b1g$1...@nnrp1.dejanews.com>...
>
>> You know, there are good introductions available, too. I don't have any
of
>> the
>> "focused on GUI" books, and I've been collecting books for a while. In
one
>> of them, the data handling issues are clearly explained.
>
>I have also seen data handling DONE in OOP, I just have not seen how its an
>improvement over alternatives.
>
>I also think that data handling is crying for more research and attention.
I
>have no strong evidence that something really nifty will be found, but I
have
>a strong hunch. My most productive programming time was when using data-
>centric languages and approaches. OOP has its values, but IMO, there are
>still good ideas yet to be found and/or promoted.
I understand what you are saying about the GUI-based books, however, these
tend to be older and simplistic.
There are newer books that cover more general topics and do a much better
job.
GUI has certainly been a visible use of OO concepts (pun both intended and
not intended). However, there is much
more. I personally use OO in numerical methods and think it is the greatest
thing yet. However, the simpler concepts
are not valid. The general trend for the best OO for data handling is to
move away from the initial hyped concepts (inheritance;
keeping all methods in the classes where they reference the attributes --
impossible), and back towards the Function-Data models,
this time with OO in one's pocket. For example, I use both Function and Data
instances, i.e., "Functions are Objects too". It took
me a long time to think my way "back" to the "old ways"
I agree that data handling is crying for more research and attention. If
researchers focused more on applied mathematical applications,
I believe they would greatly extend our understanding and appreciation of
OO.
P.S. For a discussion of why numerical methods are "different", see the
topic called "Aspect-Oriented Programming".
Bottom line: Criticism of OO is fine, as long as you limit it to our current
understanding. However, I strongly believe that the
"good ideas yet to be found and/or promoted" are going to be called OO and
will fit into OO, no matter what they are.
Tim Ottinger
top...@technologist.com wrote:
> reply to Harry
>
> > False. OOP has it's roots in systems simulation, this
> > opening assertion suggests that you need to do some
> > serious research.
>
> I did not say it had its ROOTS in GUI's, I said it became popular because of
> GUI's. Who is lacking in the "serious research" now? Birth and growth are
> different.
I also have no idea where you get this. All of my work experience for many
years has been in OO, but I've never done a GUI. At all. I am only now getting
involved in GUI stuff, and it's only because I'm writing a whole app by myself
instead of serving as a server builder and architect. OO is very popular in other
realms. Ivar Jacobson's work was in telecomms initially, I believe, and Booch
was in military stuff in Ada. I don't think those are GUI realms particularly.
I think that MS and a few others made PC OO popular for writing windows
apps, but that's just on the PC. In the rest of the world, OO has been popular
for quite a while without being focused on GUI.
Tim
Tim Ottinger
top...@technologist.com wrote:
> I have also seen data handling DONE in OOP, I just have not seen how its an
> improvement over alternatives.
Ah, well, there are two situations. One is when you have calculations that
arevery complex. Rather than write them in the client, you write them in the
object.
Is this better than a loose function? Well, it's clearly really a loose function
in
disguise, but it's keeping the data and the function which reference it near each
other for editing purposes. I think that's and advantage.
With objects, when you have a lot of calculations and a lot of invariants to
protect, the object is responsible for its own state. It prevents you from doing
things like changing only the zip code on an address. Otherwise, you have to
rely upon people just not doing that. People will do whatever's easiest. If they
can change something and violate the invariants instead of thinking a little
more,
eventually someone will. Objects (well, encapsulation by any means) make
it easier for us to protect the invariants of the data
Is this a bad thing?
Another is that object frameworks can protect us nicely from dependency on
a particular vendor's database (note: VENDORS don't like you to think about
this very much). Admittedly, you could build such frameworks with more labor
using C or some other language, but often the 4GL crowd write directly to a
database API, and often the 4GL is vendor-specific. In these cases, you have
no freedom to change vendor (which is why they don't like you to think about
it). With OO, it's easier to organize the code that does this and with
encapsulation,
you can manage the invariants of the case.
A good OO framework would also isolate you from schema changes. I think
Sutherland has been working on this, and others. You work with data, so you
surely know what the value of this is. A lot of changes in schema are not due
to adding entries and very few are deletes. The rest tend to be tables being
split/joined, etc for normalization or denormalization, or changes for the sake
of other applications. If you are isolated from the schema, you have the ability
to survive these changes with a minimum of effort, and your changes will not
take place where the UI or business logic are written, but in the persistence
layers only (or in metadata only, which is better yet). Admittedly you can try
to do the same thing in a 3GL, but the OO languages help you to organize
and plan the code, and also to measure how well you've managed your
dependencies.
OO is just a way of organizing programs, after all. it's not such a radical
departure as it is an addition of tools and rules that can help you make long
lasting code. This alone is a reason to use OO in many places, but not all.
With OO organization, we can separate the invariant from the variable,
the reusable from the disposable, and the essential from the detail. This
allows us to build the variable and disposable parts so that changes to
them will not propagate through the whole system.
Does this mean that they do SQL more efficiently? No, and anyone
claiming it would would be lying. Does it mean we can write formulae
that we could not write before? Of course not. Anyone who thinks
that OO is a change to functionality is hyping and probably lying. It's
a change in how you implement the same old functionality. But I think
that in most cases it's a better way than 4GLs and 3GLs gave us.
But if you are writing a program that is unlikely to last and unlikely to
spawn a family of products, and there are no OO frameworks or
libraries you would like to use, and you have a perfectly good tool
for putting together little store-and-report apps, and you're just doing
a store-and-report app, then don't use OO.
Nobody ever said that you have to use OO. Not in front of me, at
least. It's just offered as a *good* way to build things that are
complex, and/or must last.
> My most productive programming time was when using data-
> centric languages and approaches
Function points per week, I would say this is probably true. Forcontract
programmers, that's the important thing. But what is it like
on the 20th revision? I would bet that the same tools that make it
easy to write the initial version start to weaken when it comes to
making changes to the business rules, schema, and UI. Typically,
there is a lot of repeated code, and the concerns of schema, business,
and UI are munged together to get the app out the door quickly.
But you will have to tell me when you've worked on the same
product for a few years in 4GL-style programming, and then
in OO for a like (or longer) period. I think it's a shared experience
among OO people that a poor separation of concerns (in whatever
language or style) leads to maintenance problems.
> . OOP has its values, but IMO, there are
> still good ideas yet to be found and/or promoted.
There are indeed, and many of them are being grafted onto the
OO vine. Take DBC, which is a very fine idea. Also look at
the many kinds of metaprogramming that are coming out. These
are also being added. Reflection isn't necessarily an OO aspect,
but it's in more languages after it was found so useful in smalltalk
and its fellow travelers. Components are also being grafted onto
to OO vine, and that's a good thing. And networking, and more
concurrency and distribution.
I don't see why making an advance necessarily means making a
break from the best habits, principles, and practices we have going
today. I'd be more interested in seeing what you could do in data
processing under OO than what you can do without it, because
most people would like having both under the same roof.
tim
Tim Ottinger
top...@technologist.com wrote:
> > This [hype] is true of every technology that's ever been useful
>
> It is also true of stuff that settled into SMALL niches, like expert systems
> and CASE. I agree OOP has a niche, the issue is how big the niche should
> and/or will be.
CASE is a kind of tool. Expert systems (by the way, rule-based and
constraint-based systems my be on the rise again) are a kind of technology. OO is
a way
to do things, not a thing you do. Still, I posted earlier where I don't believe
OO
is particularly applicable. I'll not repeat.
> > Then, are we to throw out the baby with the bath water? Is SQL evil and
> wrong?
> > Does it "suck" because people who were peripherally involved made claims
> that
> > the experts knew were unrealistic?
>
> It is a matter of balance. The OOP hype factor is ruining a lot of good
> products, projects, and research IMO because it distracts effort from other
> improvements.
I agree OO hype is evil and wrong. We're 100% in agreement. But OOhype is not
OOP. It's not the programmers doing it.
> Part of the reason I am so musturdy about OOP is that it ruined
> a lot of my favorite features/tools because these tools were not able to ride
> the hype.
Agreed. The hype is wrong. That's not saying OO is wrong.
> > it is focused on the long life and
> > maintainability/flexibility of systems instead of a fast > first delivery.
>
> It seems like fast first delivery is what the market actually *wants*. With
> buyouts, layoffs, and restructuring so common, most business only plan up to
> about 18 months. They also (rightfully) see technology as dynamic and fadish.
> What use is it to build your future on OOP when OOP may disappear from vogue
> (either because of lack of merit or some new hype).
Okay, this is a different thing. Here we are talking about whether OO is a
technology.What do you think there is about OO that will make the whole way of
working
become obsolete? It's not bound to a language (languages die, but the OO
languages
are the most popular on earth right now). It's not bound to a platform or a
vendor (these
also fade). It's not owned by a company. It's not bouyed by a government agency.
It's not a thing, it's a way.
I imagine that OODBMS will change or die, and that OOPLs will change and some
will die. If all our platforms that exist died out, it would change nothing. OO
is used
in embedded systems, in realtime, in huge financial planning, on evey platform,
and
by all kinds of programmers in many languages. That to me is proof of general
applicability. That's more than a single niche.
> > By the way, you've swung the pendulum too far the other
> > way in attempting to make OO sound nearly useless.
>
> IMO, you have to fight fire with fire. Hype made it too tall, so hype may be
> needed to tear it down to a realistic height. Hopefully though, I put in
> enough specifics to guide those who see thru the hype.
I hate the hype also, and fight it all of the time. Every class OMA teachesstarts
with hype-busting and continues to hybe-bust throughouit the course.
That's just being responsible. On the other hand, we do use OO methods,
and we believe strongly that they are the best on hand for building complex,
long-lived software. It's a good way to reason about problems, a good way
to design the structures, and a set of useful languages for implementing.
To hate a thing and to hate the jerks who sell it are two different things.
I like Mentos candies, but I think the commercials are absurd. I like
Kook-Aid, but I think those are some of the dumbest commercials
around. My 7-year-old often wants to buy breakfast cereal just because
of the commercials, and I'm training him up to be a cynic instead. Any
one of questionable character who wants to sell you a thing will tell you
anything you'll believe about it to close the sale. But that doesnt' mean
the products stink, just the salespeople.
tim
Phlip
dogmat wrote:
>GUI has certainly been a visible use of OO concepts (pun both intended and
>not intended).
The continental divide between all graphic representation systems is between
Vector and Raster images. 8 years ago I'm a lab aide in my college's
computer graphics center, and a Fine Arts professor tells the kids that the
Vector-based animation program we are demonstrating is "object oriented". I
knew better than to say anything.
>However, there is much
>more. I personally use OO in numerical methods and think it is the greatest
>thing yet. However, the simpler concepts
>are not valid. The general trend for the best OO for data handling is to
>move away from the initial hyped concepts (inheritance;
>keeping all methods in the classes where they reference the attributes --
>impossible), and back towards the Function-Data models,
>this time with OO in one's pocket. For example, I use both Function and
Data
>instances, i.e., "Functions are Objects too". It took
>me a long time to think my way "back" to the "old ways"
On the subject of Data Representation vs OO Purity, my company has for a
while invested in an object called a "Reality Variable". It is the
equivalent of a database Column, where each Field stores an engineering
sample value recorded from external sensors (hence "Reality"). Therefor it
has a Hardware Name ("MFC 2"), a User Alias ("Low Nitrogen"), and Units,
Scales, Ranges etc.
This is a very important object, but in each focus of activity a different
class stores it. In the monitoring programs it's an 'RdfItem'; in a data
display program it's a 'Variable', and in our central database it is
scattered in several tables with links between these.
There should be a theory for this, but the only ones that have soaked in so
far are either "Write the class _once_, re-use it _everywhere_, and give it
a wide interface." Or we hear "write get/set accessors for each data member
of the disparate object types, and copy from one to the other a lot."
Bzzzt.
Just as we sometimes have the same type with different meanings, often we
are stuck with different types with the same meaning.
>Bottom line: Criticism of OO is fine, as long as you limit it to our
current
>understanding. However, I strongly believe that the
>"good ideas yet to be found and/or promoted" are going to be called OO and
>will fit into OO, no matter what they are.
And OO is a correct-enough metaphor to embrace and extend these new ideas.
-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- got hemp? --
top...@technologist.com
Reply to Harry:
part 2
> Yes, but in 7 years which companies will be left ? I heard this argument
> 10 years ago as to why I should become a mainframe COBOL programmer
> rather than a Unix C programmer. Me and my bank manager are both glad I
> chose the latter even though at the time COBOL and mainframes were dominant.
If your predictive powers are so great, you should be in the weather
business. Note that COBOL still pays quite well.
> This appears to be made up. There is no such general debate.
I have read articles in two different publications about the split. I
apologize for not having the references. Packrats are punished around here.
> Have you ever heard of the Bill-Of-Materials problem ?
Nope. Do you have any references about it?
> What is an API-like construct?
A function or method call that is needed to pull data in or push data out.
Some languages, like xbase, let you reference table fields almost directly,
without first manually loading them into memory. If more than 50% of your
code deals with tabled data, then this becomes a very nice shortcut.
> but why not an OO database language ?
If you see a GOOD one, let me know.
> in any event your data will be getting transformed as it goes to
> and from your persistent store.
In ITOP, the process is more transparent to the programmer, and is also
controlled by the Data Dictionary, which is easier to deal with because its
presented in 2 dimensions, instead of 1 dimension like code is.
> I get an object which I can ask questions like: o.name()
First, this kind of syntax existed without OOP. Second, its usually more like
o.field("name") in early-bind compilers.
> Where two or more pieces of software share a piece of data surely
> you want them to treat the data in the same way
In an ideal world, yes. However, I not going to assume that every machine is
going to use the same language (or even same version), or that the same
language will exist from year to year. You underestimate change, dude.
> How does the relational model deal with the the fact that the
> world contains clear is-a relationships ?
I don't see clean hiearchies in the real world very often. And when I do,
they are rarely more than 2 levels. Control tables are better at dealing with
changing heirarchies than hardwiring hiearchies into code. The real world
seems to consist mostly of network (web) type relationships, NOT CLEAN
hiearchies.
> OOP spread because programmers liked it and
> because it *is* getting results.
My observation is that OOP became associated with GUI's, drag-and-drop,
icons, and VBX's in managers' (and some programmers) minds. I even talked to
network engineers who thought this also. There was rarely a knowledgable
debate or test before picking OOP. It rode in on GUI coattails. GUI's sold
like hotcakes and nobody wanted to appear anti-GUI by attacking anything
remotely associated with GUI's. It was taboo.
> Without support for key concepts like inheritence and
> polymorphism few of the key benefits of abstraction of
> the business model can be achieved.
ITOP supports a form of inheritence and abstraction. Polymorphism is mostly
useful for only systems programming and GUI's IMO.
> Without support for key concepts like
> inheritence and polymorphism few of the key benefits of
> abstraction of the business model can be achieved.
From a marketing standpoint, yes. From a technical standpoint? Well, that is
where we disagree. You repeat those concepts like a religious doctrine.
Perhaps if you are told they are the ultimate savior for long enough, you
believe it regardless of merit.
Do you think Microsoft made it to prominance by technical merit alone? Be
careful before you associate technical merit with popularity.
top...@technologist.com
...
> and techniques. Good, experienced people will play a large role, managers
> and developers.
>
Huh?
top...@technologist.com
> Some people don't advertise successes, it's called a competetive
> advantage.
>
Not very common, especially for companies in which IT is not their primary
market.
-Topmind -
Harry Protoolis
In article <6fv61u$e8q$1...@nnrp1.dejanews.com>,
top...@technologist.com writes:
> reply to Harry
>
>> False. OOP has it's roots in systems simulation, this
>> opening assertion suggests that you need to do some
>> serious research.
>
> I did not say it had its ROOTS in GUI's, I said it became popular because of
> GUI's. Who is lacking in the "serious research" now? Birth and growth are
> different.
I still disagree, note that both of the major GUI frameworks in use (X
and Win32) are both written in non-OO languages (MFC just doesn't count
as OO, but that's another argument). What are you basing your assertion
on ? You give no evidence for it at all. OO's popularity was driven more
by business modelling than it was by GUI's.
>> The number of times I have heard respected OO people give
>> the 'no silver bullet' speech ..., OO is not a silver bullet,
>> if anything one if the fundamental assertions is
>> that there *is no silver bullet*.
>
> But its hype-to-usefulness ratio is way too high. It spread like wildfire in
> the market.
Agreed, but IME most OO transitions are pushed from the ground up,
something is selling programmers on OO, and it isn't just hype. Hype
tends to sell to managers first ...
>> It is, most of my work is with high end real time systems for
>> signal processing, OO techniques are a vital part of our
>> approach and have had a major positive impact.
>
> Signal processing may fall into the "in-memory intensive" category that I
> talked about. It may indeed help there. But what percent of programmers do
> primarily signal processing for a living?
Certainly, but prior to this I have used OO in financial applications,
business applications and in the mining sector, and I have heard reports
from a wide range of other areas that suggest that it is having a very
positive impact.
>> If all it does is allow us to build larger more complex
>> systems [better] than before then it is a revolution.
>
> For some systems perhaps, but not necessarily all.
>
>> There is a respectable and growing body of OO research.
>
> What were they comparing it against?
> Who sponsered the research?
OO research is happening at a range of places, from Lucid Labs to
Washington U (ACE). They are not comparing it to anything, they are
doing research in the use of OO techniques to solve a range or problems.
>> The dominant anecdotal evidence is that programmers
>> enjoy working on OO systems.
>
> My impression is that academics love it because it is intellectually "nifty";
> however, paid programmers use it simply because they fear falling behind and
> have been told OOP is modern and everything else will make them obsolete.
No way, how many paid programmers and academics did you interview to get
this ? IME the situation is the reverse, professional programmers love
OO because it helps get the job done. Academics tend to prefer
relational/functional/logic programming because it has more academic
rigour. This is because OO is about programming-in-the-large, and most
academics are about programming-in-the-small (which is sad ...)
> (I have not seen your part 2 yet, so I will wait to respond to it.)
I never did get to the end ... :-(
H
Harry Protoolis
In article <6g1vf0$pgq$1...@nnrp1.dejanews.com>,
top...@technologist.com writes:
> Reply to Harry:
>
> part 2
>
>> Yes, but in 7 years which companies will be left ? I heard this argument
>> 10 years ago as to why I should become a mainframe COBOL programmer
>> rather than a Unix C programmer. Me and my bank manager are both glad I
>> chose the latter even though at the time COBOL and mainframes were dominant.
>
> If your predictive powers are so great, you should be in the weather
> business. Note that COBOL still pays quite well.
:-), sure but OO pays better.
>> This appears to be made up. There is no such general debate.
>
> I have read articles in two different publications about the split. I
> apologize for not having the references. Packrats are punished around here.
Hmm, they won't let you keep journals around ? Get a new job ... :-)
>> Have you ever heard of the Bill-Of-Materials problem ?
>
> Nope. Do you have any references about it?
There were a bunch posted to the group earlier, check out Chris Date's
Intro to Relational Database Systems. It is the basic whole-part
problem found in almost all manufacturing systems.
>> but why not an OO database language ?
>
> If you see a GOOD one, let me know.
Seriously, I think this is most of your problem, you are being asked to
move from dBase, or Progress (or something) to C++ in the name of OO
when what you need is dBase++, and OO database language to give you the
best of both worlds.
>> in any event your data will be getting transformed as it goes to
>> and from your persistent store.
>
> In ITOP, the process is more transparent to the programmer, and is also
> controlled by the Data Dictionary, which is easier to deal with because its
> presented in 2 dimensions, instead of 1 dimension like code is.
In has nothing to do with ITOP, it's a language thing. You want a
language with a strong binding to a persistent store. Have you looked at
things like Orbix ?
>> I get an object which I can ask questions like: o.name()
>
> First, this kind of syntax existed without OOP.
Nope, this syntax *is* OO. (if by the above you mean call a function
which will return 'o''s name, in which case 'o' is an object)
>Second, its usually more like o.field("name") in early-bind compilers.
Depends on the binding of your objects to your persistent store, and on
how you model stuff.
>> Where two or more pieces of software share a piece of data surely
>> you want them to treat the data in the same way
>
> In an ideal world, yes. However, I not going to assume that every machine is
> going to use the same language (or even same version), or that the same
> language will exist from year to year. You underestimate change, dude.
No I don't, however in a true object database there would be some way to
store behaviour with data (sadly this is beyond most so called OO
databases today). Today, you just use the same (or analogous) class to
access the data, and only store the attributes in your persitent store.
>> How does the relational model deal with the the fact that the
>> world contains clear is-a relationships ?
>
> I don't see clean hiearchies in the real world very often. And when I do,
> they are rarely more than 2 levels. Control tables are better at dealing with
> changing heirarchies than hardwiring hiearchies into code. The real world
> seems to consist mostly of network (web) type relationships, NOT CLEAN
> hiearchies.
I said clear, not clean. A manager *is* an employee, an employee *is* a
person. Clear, obvious, trivial to model in OO, hard to model as
tables.
Of course inheritence hierarchies can become complex, are you suggesting
that for this reason we should not model them at all ?
>> OOP spread because programmers liked it and
>> because it *is* getting results.
>
> My observation is that OOP became associated with GUI's, drag-and-drop,
> icons, and VBX's in managers' (and some programmers) minds.
I assure this is rare IME.
> I even talked to
> network engineers who thought this also.
Did you talk to any software engineers ?
> There was rarely a knowledgable
> debate or test before picking OOP. It rode in on GUI coattails. GUI's sold
> like hotcakes and nobody wanted to appear anti-GUI by attacking anything
> remotely associated with GUI's. It was taboo.
So you don't like GUI's either ?
>> Without support for key concepts like inheritence and
>> polymorphism few of the key benefits of abstraction of
>> the business model can be achieved.
>
> ITOP supports a form of inheritence and abstraction. Polymorphism is mostly
> useful for only systems programming and GUI's IMO.
Huh ? What about business programming ?
>> Without support for key concepts like
>> inheritence and polymorphism few of the key benefits of
>> abstraction of the business model can be achieved.
>
> From a marketing standpoint, yes. From a technical standpoint? Well, that is
> where we disagree. You repeat those concepts like a religious doctrine.
I use these concepts every day, there is nothing religious about this
for me, it works, it's good. If it weren't I wouldn't use it.
> Perhaps if you are told they are the ultimate savior for long enough, you
> believe it regardless of merit.
Did I not say that OO was no silver bullet ? Shall I say it again ? It
is useful, it works, show me something better and I'll use that.
> Do you think Microsoft made it to prominance by technical merit alone? Be
> careful before you associate technical merit with popularity.
Yes, but OO is popular with technical people, hype usally only works on
managers...
--
Ell
Tim Ottinger (otti...@oma.com) wrote:
:
: To hate a thing and to hate the jerks who sell it are two different things.
: I like Mentos candies, but I think the commercials are absurd.
Absurd? They are not profound, but are they really "ridiculously
incongruous or unreasonable"? Most of us take for granted that many
commercials are comedic, light-hearted, and are basically fluff. Accepting
that, I like the Mentos commercials. In fact, I find them to be good
natured, refreshing, and melodic diversions,
Similarly, accepting that hype exists, I find that some software marketing
is a pleasant diversion.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
Graham Perkins
top...@technologist.com wrote:
> > Some people don't advertise successes, it's called a competetive
> > advantage.
> Not very common, especially for companies in which IT is not their primary
> market.
If they keep quiet, you wouldn't know whether rare or common.
That's the point.
Also IT is often an important part of company infrastructure, even
for companies with other primary markets. Are you saying they
have no interest in protecting their infrastructure advantages?
----------------------------------------------------------------
Department of Turbo Pascal, De Montfort University Milton Keynes
http://www.mk.dmu.ac.uk/~gperkins/
Graham Perkins
top...@technologist.com wrote:
> > False. OOP has it's roots in systems simulation, this
> > opening assertion suggests that you need to do some
> > serious research.
>
> I did not say it had its ROOTS in GUI's, I said it became popular because of
> GUI's. Who is lacking in the "serious research" now? Birth and growth are
> different.
Well there's OOP and there's OOP. What are the *really* popular
GUI tools? How do the ordinary masses of programmers and dilettantes
use these tools? Do they build software which has a good architectural
design, highly cohesive and decoupled sub-components, high
maintainability and testability? Is the Pope an atheist?
Maybe you are confusing the object structure of supplied windowing
components with object oriented programming. I don't see much
OOP in the software that people *generate* using Delphi, Access,
of Visual-Anything-Else. The tools encourage them to organise
application functionality around event handlers. Avoiding such
fragmentation is hard work, and only good software engineers
bother to do it. Multi-threading and heterogeneous network
distribution is a real pig with such tools.
I see recent releases of MS-Access have become more object-
oriented by changing the syntax of some commands to contain a dot.
[insert smileys as you see fit]
> > that there *is no silver bullet*.
> But its hype-to-usefulness ratio is way too high. It spread like
> wildfire in the market.
Can't be helped. Same with Buzz Lightyear and Teletubbies.
There is a solid software engineering side to OO and I'm
sure people are obtaining benefits where they use it. Those
who use the latest tools simply because they're the latest,
and continue to roll out the same poorly designed and
unmaintainable software, will continue to suffer.
> > It is, most of my work is with high end real time systems for
> > signal processing, OO techniques are a vital part of our
> > approach and have had a major positive impact.
>
> Signal processing may fall into the "in-memory intensive" category that I
> talked about. It may indeed help there. But what percent of programmers do
> primarily signal processing for a living?
To do a bit of distributed programming, I'd rather use object-style
sockets, object serialisation, remote method handling, and/or
object request brokerage technology. My progress will be much
faster, I'm sure, than by hacking out mountains of TCP/IP calls.
The actual application area is not a decider here - it's
the presence of heterogeneous network.
> My impression is that academics love it because it is
> intellectually "nifty";
Some hate it because they think it is "wrong". Some are
uncomfortable because they feel it is tricky and advanced
form of algorithmic programming. Some love it because they
think that playing with GUI kits makes them OO experts.
Others, like me, appreciate the way Object Orientation has
dragged serious software engineering out of academia/defence
and into the mainstream.
really, academic not that different from everyone else
Ell
Harry Protoolis (ha...@nautronix.com.au) wrote:
:
: top...@technologist.com writes:
: >
: > Harry:
: >>
: >> False. OOP has it's roots in systems simulation, this
: >> opening assertion suggests that you need to do some
: >> serious research.
: > I did not say it had its ROOTS in GUI's, I said it became popular because of
: > GUI's. Who is lacking in the "serious research" now? Birth and growth are
: > different.
: and Win32) are both written in non-OO languages (MFC just doesn't count
: as OO, but that's another argument). What are you basing your assertion
: on ? You give no evidence for it at all. OO's popularity was driven more
: by business modelling than it was by GUI's.
I know that OO began in the simulation area with Simula in '67, not GUI
(not in '67). However, I find in the US that objects got a big burst of
publicity and popularity when the object metaphor was applied to GUIs
(Windows, Motif, etc), and GUI frameworks. E.g. buttons, listboxes,
windows, scroll bars, etc as objects.
Tim Ottinger
top...@technologist.com wrote:
> > Some people don't advertise successes, it's called a competetive
> > advantage.
> >
>
> Not very common, especially for companies in which IT is not their primary
> market.
You mean which is not common? Almost all of my best work has been
done under NDA (commercial) or under military security (not commercial).
An awful lot of the best stuff that is done in objects will never be written
up.
This is very sad.
tim
Tim Ottinger
Harry Protoolis wrote:
> > But its hype-to-usefulness ratio is way too high. It spread like wildfire in
> > the market.
>
> Agreed, but IME most OO transitions are pushed from the ground up,
> something is selling programmers on OO, and it isn't just hype. Hype
> tends to sell to managers first ...
This is very true, and sometimes it sells to managers only. Apparently it's
easier to sell technology to people who know less about it, and hear the
argument expressed in dates and dollars. Maybe we should all learn how
to do that.
A manager (non-tech) once asked me why we care what language we
program in. He said "it's all just syntax, and functionality is the interesting
stuff, anyway". What I should have done, but did not, was to ask him why
he cares what language we program in, as long as we deliver his functionality.
But this is what the French used to call "staircase wit". Sigh.
tim
Tim Ottinger
Ell wrote:
> : To hate a thing and to hate the jerks who sell it are two different things.
> : I like Mentos candies, but I think the commercials are absurd.
>
> Absurd? They are not profound, but are they really "ridiculously
> incongruous or unreasonable"?
I believer that they are. Someone is in a minor jam. They pop a Mentoin their
mouths, and it enables them to conceive and carry out very rude
behavior, and everyone will think they're clever... supposedly because
they smell minty?
> Most of us take for granted that many
> commercials are comedic, light-hearted, and are basically fluff.
Why do you always prefix an opinion with the word "Most"?In this case, we have
room for agreement. Commercials are all
absurd fluff. They have usually no information content, and little
relevancy to real life. They're useless, except to stick brand names
into your brain via silly little ditties. It's just propaganda, and not
the worst kind we see.
Among the worst kind we see is the kind of absurd propaganda
for this or that allegedly OO tool, whose mere presence in your
company will improve production by 80% by pure osmosis. You
don't even have to learn to use it. It's all automatic. You'll pay
<insert five-digit number for Unix, four-digit for Windows> for
it, and all of your projects will be done sooner and better, and
you don't need any experienced staff! The tool has all the
experience you need! Buy one today! Buy a few dozen seats!
Hey, what's a few million when we're talking IMPROVEMENT!
BTW: If you use this, you'll be IS9000, CMM 5, and everyone
will love you, and you can do incredibly rude things and people
will think you're clever and charming.
Okay, that's stretching things a bit, but it's not far off. You've
had to host a salesman or two in your time, I bet. You know
that they promise the moon and the stars.
tim
Patrick Logan
Ell <e...@access4.digex.net> wrote:
: I know that OO began in the simulation area with Simula in '67, not GUI
: (not in '67). However, I find in the US that objects got a big burst of
: publicity and popularity when the object metaphor was applied to GUIs
: (Windows, Motif, etc), and GUI frameworks. E.g. buttons, listboxes,
: windows, scroll bars, etc as objects.
Actually the boost in popularity due to GUI began in ernest with the
Macintosh. (And of course, the origins of Macintosh is legendary... Lisa,
Smalltalk, etc.)
Windows, Motif, etc. came later.
Macintosh... forgotten but not gone.
top...@technologist.com
Response to Harry:
> Have you looked at things like Orbix ?
Probably an uncommon, proprietary language. Who wants to bet their career on
a little corner. I might be great technically, but market share is important.
> Nope, this syntax *is* OO
Well, it was something very similar. Call it whatever you want.
> however in a true object database there would be some way to
> store behaviour with data (sadly this is beyond most so called OO
> databases today). Today, you just use the same (or analogous) class to
> access the data, and only store the attributes in your persitent store.
I have already described how risky it is to store behavior with data. Storing
the attributes with data is similar to a Data Dictionary (in ITOP). However,
IMO it is best not to store the DD directly with the data. You can't share
(inherit) field attributes easily this way. (ITOP *does* have inheritance of
a sort.)
> A manager *is* an employee, an employee *is* a
> person. Clear, obvious, trivial to model in OO, hard to model
> as tables.
Not if you have 500,000 of them! It is fairly easy to show such heirarchies
in flexible tables. I have done it many times at least 2 different ways.
Perhaps you guys are as uneducated with table usage as I am (allegedly) with
OOP. I can do powerful data structures (trees, etc.) in tables easier and
safer than with traditional memory pointers and nodes.
> Did you talk to any software engineers?
I talked to one guy who seemed to love OOP. However, when I asked him about
persistant storage, his facial expression changed and he said, "well, that is
a rough spot at this point."
-Topmind-
top...@technologist.com
Response to Harry:
> note that both of the major GUI frameworks in use (X and Win32) are both
> written in non-OO languages
I am not talking about big-name software.
> OO's popularity was driven more by business modelling
> than it was by GUI's. [or hype]
This is where you and me disagree.
> something is selling programmers on OO, and it isn't just hype. Hype
> tends to sell to managers first ...
And managers decide or greatly influence what us poor peon
programmers use. Also, many programmers were curious about
it because it sounded so esoteric at the time.
> They are not comparing it to anything [in research]
AH HAH! Do you realize what you just said???? The research
only shows that OOP succeeds in many cases. This does
not mean its better. (Although just finishing alone is
a relief these days.) Comparitive research is lacking!
top...@technologist.com
Response to Harry: (Part 2)
> So you don't like GUI's either ?
I did not say this. I have nothing against GUI's. (Although they sometimes
slow down data entry from the character mode days.)
> Huh ? What about business programming ?
I would have to look at a specific case. There are many ways to
skin a cat. OOP is only one of them.
> [oop] is useful, it works, show me something better and I'll use that.
Perhaps it is a personal preference. Working with other programmers shows one
how different each mind is. I find tables a very visual and compact place to
store attributes and control code. They are easier to see and manage than
program code IMO.
> Yes, but OO is popular with technical people, hype [MS] usally only
> works on managers...
Aren't you contradicting yourself? First you say that OOP hype would not
affect programmers (another msg), only managers. Then you are agreeing that
Microsoft is common (even with programmers), but you attribute it to hype. It
sounds like hype can control programmers as much as technical merit. If so,
you cannot use popularity alone to show that OOP is better.
-Topmind- (an arrogant alias, wouldn't you say?)
P.S. Thanks for the dialog. I appreciate the feedback.
top...@technologist.com
<insert five-digit number for Unix, four-digit for Windows>
Why do you think this is the case? Is it that the volume of Windows is
greater? Or that UNIX people are used to shelling out dough?
(UNIX users shell out, while Windows users sell out.) Ha ha, me clever!
-Bottommind-
top...@technologist.com
> You mean which is not common? Almost all of my best work has been
> done under NDA (commercial) or under military security (not commercial).
> An awful lot of the best stuff that is done in objects will never be written
> up.
> This is very sad.
>
> tim
>
>
I meant that if IT is not one's main business, the incentives to hide success
are not very strong. (Plus, bragging is good advertizing)
Regarding your disappointment in the good stuff not being written up, it is
*equally* disappointing that the failures never get written up. There are a
lot of good lessons that are lost. Failure is just as good of a teaching tool
as success. Why do you think toddlers fall down all the time? (Object
Oriented Bruises)
-A mind-
top...@technologist.com
> Are you saying they
> have no interest in protecting their infrastructure advantages?
I have seen far more articles of smiling CEO's after installing some new-
fangled gizmo (oop and other things) than of sad CEO's talking about failure.
Bragging about an IT success is great advertizing.
-A Person-
Dave Harris
ha...@nautronix.com.au (Harry Protoolis) wrote:
> [On OO and GUIs]
I expect Smalltalk has something to do with this. Early Smalltalk had a
GUI class library at a time when GUIs weren't very common.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Christopher Barber
top...@technologist.com writes:
> Response to Harry:
>
> > Have you looked at things like Orbix ?
>
> Probably an uncommon, proprietary language. Who wants to bet their career on
> a little corner. I might be great technically, but market share is important.
Why can't you just say "no" instead of going on about something you
nothing about? Orbix is one of the leading CORBA implementations. CORBA
is not proprietary and Orbix has quite a significant market share among
CORBA vendors. CORBA itself is an open OO distributed "middleware"
standard. You should read up on it before commenting further.
- Christopher
--
Christopher Barber ----- Software Engineer ---- D.E.Shaw & Co.
Tim Ottinger
top...@technologist.com wrote:
> <insert five-digit number for Unix, four-digit for Windows>
>
> Why do you think this is the case? Is it that the volume of Windows is
> greater? Or that UNIX people are used to shelling out dough?
I've no idea, but if it is to be corrected, I'd like to see everything goto
three-digit (or two-digit) pricing. I think that paying $2000.00/seat
or 10K/seat for developers tools is just guaranteeing a very high end-
user price for software, which limits the situations in which a tool can
be used.
Hurray for freeware. Gnu Grules.
RSanderson
>Not if you have 500,000 of them! It is fairly easy to show such heirarchies
>in flexible tables. I have done it many times at least 2 different ways.
>Perhaps you guys are as uneducated with table usage as I am (allegedly)
with
>OOP. I can do powerful data structures (trees, etc.) in tables easier and
>safer than with traditional memory pointers and nodes.
If I understand correctly, if you want to work with these 500,000 names, you
access the database fields directly each time (e.g. CustomerTable->name)
without loading into memory, and not using the memory variable for further
references. Is this correct?
If so, how slow are the programs you write?
If not, then you _are_ working with memory variables. In which case, why
not use OO to encapsulate those variables into meaningful objects that can
be read/manipulated/displayed/reported as a whole?
>I talked to one guy who seemed to love OOP. However, when I asked him about
>persistant storage, his facial expression changed and he said, "well, that
is
>a rough spot at this point."
Then your friend did not know how to create a persistence mechansm for
objects. And this is where your entire argument comes from.
A good OO persistence mechanism needs to be created once, which can then be
re-used for all types of objects. It's not easy, but once its done, its
done. As you add new objects to your project, you add them to a data
dictionary or another mapping mechanism, again, just once.
Once your framework is created, you can work solely with objects and gain
all the benefits of doing so, without having to manually reach into a
database table to get the data.
Lets say, given the third lineitem of a given invoice number, you need to
phone the vendor of that product. You _could_ go:
dial
invoice(num).line(lineitem).product().vendor().mainContact().phoneNumber() )
;
With an OO approach, the above query did not have to be pre-imagined by the
writer of the objects, nor the writer of the persistence mechanism.
Unless I'm mistaken, you believe the following is somehow better?
(from memory, this uses Clipper syntax, which you claim is one of the
wonderful TOP languages)
select("invoicelines")
dbsetorder( 1 )
seek num+lineitem
select("product")
dbsetorder(1)
seek invoicelines->productno
select("vendor")
dbsetorder(1)
seek product->vendorno
select("contact")
dbsetorder(1)
seek vendor->maincontact
dial( contact->phoneNo )
The writer of this query not only must have knowledge of the tables and
columns, but must also be prepared to change this (as well as other code
strewn throughout the program) if, for example, the database administrator
decides to put the maincontacts phone number in the vendor table for
efficiency sake.
With a good OO design, the query would be unchanged by schema changes. One
single change to the "mapper" or data dictionary would resolve the schema
change for ANY query.
Your whole basis for poo-pooing OO is your lack of understanding of its
power once sound OO constructs and mechanisms are understood and employed.
Rick.
Thaddeus L. Olczyk
top...@technologist.com wrote:
>
> I meant that if IT is not one's main business, the incentives to hide success
> are not very strong. (Plus, bragging is good advertizing)
>
If I'm company A with a $10 billion dollar budget, and new improvements
in IT allow me to cut my budget by $1 billion, do you want me to let
my competitor company B know about this? If I do, then they can copy
my success and take away the competitive advantage that better IT
provides.
This particular post does convince me of one thing. I need to apologise.
To stupid people out there, I'm sorry I've equated you with
"lowestmind".
Thaddeus L. Olczyk
top...@technologist.com wrote:
>
> Perhaps you guys are as uneducated with table usage as I am (allegedly) with
> OOP. I can do powerful data structures (trees, etc.) in tables easier and
> safer than with traditional memory pointers and nodes.
>
Thaddeus L. Olczyk
top...@technologist.com wrote:
>
> Response to Harry:
> > OO's popularity was driven more by business modelling
> > than it was by GUI's. [or hype]
>
> This is where you and me disagree.
>
OO has very little to do with GUI's. Of course you're
to lasy to do that.
Marcel Popescu
Graham Perkins wrote in message <3524B3...@dmu.ac.uk>...
>Maybe you are confusing the object structure of supplied windowing
>components with object oriented programming. I don't see much
>OOP in the software that people *generate* using Delphi, Access,
>of Visual-Anything-Else. The tools encourage them to organise
>application functionality around event handlers. Avoiding such
>fragmentation is hard work, and only good software engineers
>bother to do it. Multi-threading and heterogeneous network
>distribution is a real pig with such tools.
I am a Delphi programmer. I take this personally. :-)
OK, now let's get back to the main idea. OOP has nothing to do with the
tool, but with the metodology. You want to emphasize that many people use OO
tools the wrong way, because they are too easy to be used the wrong way. You
are right. Naming C++Builder or Microsoft J++ won't help... :-)
I really think lots of programmers (the guy who started all this being a
clear example) have no idea what OO is about. Well, it might be because the
professionals keep this only to themselves...
Mark
Marcel Popescu
top...@technologist.com wrote in message
<6g4hgb$oiu$1...@nnrp1.dejanews.com>...
>I have already described how risky it is to store behavior with data.
Where have you done that?
>> Did you talk to any software engineers?
>I talked to one guy who seemed to love OOP. However, when I asked him about
>persistant storage, his facial expression changed and he said, "well, that
is
>a rough spot at this point."
Well... he talked to *one* guy... this is really as much as he could do.
Give him a break, he might need the other neuron...
Mark
top...@technologist.com
In article <3526F25D...@interaccess.com>,
If you can recommend a book about data handling and persistant storage with
oop, and it shows how oop IMPROVES these over other models, then I will
certainly look into it. (Don't forget the IMPROVE part).
Can you meet the challenge, or are you "too lazy"?
top...@technologist.com
>
> Okay, this is a different thing. Here we are talking about whether OO is a
> technology.What do you think there is about OO that will make the whole way
of
> working
> become obsolete? It's not bound to a language (languages die, but the OO
> languages
> are the most popular on earth right now). It's not bound to a platform or a
> vendor (these
> also fade). It's not owned by a company. It's not bouyed by a government
agency.
> It's not a thing, it's a way.
Either were Expert Systems, yet they niched away.
-T.mind-
top...@technologist.com
In article <3526F092...@interaccess.com>,
with
> > OOP. I can do powerful data structures (trees, etc.) in tables easier and
> > safer than with traditional memory pointers and nodes.
> >
> If so how come you don't know what Bill-of-Materials is?
>
Congratulations! You are the first person I met that knows everything about
business. Your life is complete, you can die now.
top...@technologist.com
In article <m2qk995...@fardm4.boston.deshaw.com>,
Well, then, its too new to bet the farm on. Java is still too new to bet the
farm on. (ASP is also too new, but MS can force feed it.)
-MiddleMind-
top...@technologist.com
In article <3526ED9E...@interaccess.com>,
How about you get some irrefutable numbers before you spout off your
behavioral guess and insulting me for disagreeing. At least I don't flame
people for disagreeing with my guesses (at least not more than 2% of the
time).
Harry Protoolis
In article <6g4h9e$o8a$1...@nnrp1.dejanews.com>,
>> written in non-OO languages
>
> I am not talking about big-name software.
Nor am I, most people use MFC/X to write custom stuff.
>> OO's popularity was driven more by business modelling
>> than it was by GUI's. [or hype]
>
> This is where you and me disagree.
Fine, it doesn't really matter all that much.
>> something is selling programmers on OO, and it isn't just hype. Hype
>> tends to sell to managers first ...
>
> And managers decide or greatly influence what us poor peon
> programmers use. Also, many programmers were curious about
> it because it sounded so esoteric at the time.
Speak for yourself, ever attempt I have seen to enforce technical change
against resistence from the technical staff has failed, often taking
the company with it.
So far, btw, you have characterised your workplace as a place where you
are 'punished' for keeping journals about, and are treated like a
'peon'. Did I mention getting a new job ?
>> They are not comparing it to anything [in research]
>
> AH HAH! Do you realize what you just said???? The research
> only shows that OOP succeeds in many cases. This does
> not mean its better. (Although just finishing alone is
> a relief these days.) Comparitive research is lacking!
Certainly what *comparative* research exists is between conventional
structured methods and OO, even this is hard for reasons others have
elaborated. (Confidentiality etc).
--
-
Harry Protoolis Nautronix Limited
ha...@nautronix.com.au Fremantle, Western Australia
Harry Protoolis
In article <6g4hgb$oiu$1...@nnrp1.dejanews.com>,
>
> Probably an uncommon, proprietary language. Who wants to bet their career on
> a little corner. I might be great technically, but market share is important.
You really don't know *anything* about OO at all do you ? Orbix is one
of the most widely used implementations of the CORBA standard for object
distribution.
>> Nope, this syntax *is* OO
>
> Well, it was something very similar. Call it whatever you want.
Hey, I didn't make the names up. As soon as you have syntax like
customer.price(), you are mixing behaviour with data. (I thought that
you thought that this was evil.)
>> however in a true object database there would be some way to
>> store behaviour with data (sadly this is beyond most so called OO
>> databases today). Today, you just use the same (or analogous) class to
>> access the data, and only store the attributes in your persitent store.
>
> I have already described how risky it is to store behavior with data.
You may assume you were unconvincing.
> Storing
> the attributes with data is similar to a Data Dictionary (in ITOP). However,
> IMO it is best not to store the DD directly with the data. You can't share
> (inherit) field attributes easily this way. (ITOP *does* have inheritance of
> a sort.)
Again, without behaviour data has little meaning.
>> A manager *is* an employee, an employee *is* a
>> person. Clear, obvious, trivial to model in OO, hard to model
>> as tables.
>
> Not if you have 500,000 of them!
Why not ?
> It is fairly easy to show such heirarchies
> in flexible tables. I have done it many times at least 2 different ways.
> Perhaps you guys are as uneducated with table usage as I am (allegedly) with
> OOP. I can do powerful data structures (trees, etc.) in tables easier and
> safer than with traditional memory pointers and nodes.
Given that you did not even know what the Bill-Of-Materials problem was
I suspect I may have more experiece with 'table usage' than you.
>> Did you talk to any software engineers?
>
> I talked to one guy who seemed to love OOP. However, when I asked him about
> persistant storage, his facial expression changed and he said, "well, that is
> a rough spot at this point."
Umm did I mention doing more research ? A graph with only one point
tends not to show much in the way of trends ...
top...@technologist.com
Reply to Rick:
> If so [read from disk], how slow are the programs you write?
Since about 1989, most software and/or hardware buffers disk data in memory,
thus speeding up many operations. Smaller tables will even fit entirely in
memory. All this is *transparent* to the program and programmer.
Also, if you have a zillion records, at one point its going to HAVE TO go
onto disk. If you use tables, then scalability is built in. You *never* have
to ask, "hey what if it all gets too big and no longer fits in memory at the
same time?"
You do not seem to understand the power of tables, at least not after 1989.
> dial(invoice(num).line(lineitem).product()
> .vendor().mainContact().phoneNumber() )
Nobody will remember this sequence. They will most probably want to view an
image of the invoice on the screen and locate it that way.
Also, what if a vendor has no product or mainContact? (service companies or
typo, for example) This is an example of how ooper's get heirarcy-happy. One
weak link in the hierarchy, and boom!
(Perhaps I hate hierarchies so much because I forget how to spell them. My
spell-checker does not work because it takes up too much memory; probably an
OOP design.)
Also, with indexed tables, you can index on the phone number, the vendor, the
product, etc. *independantly* of the others (if needed). And if there is no
index, a sequential search is very easy to do. One is not stuck with some
hierarchy which may be *arbitrary* to a user's particular needs.
What if I know the main contact, but not the vendor? What If I know the
product, but not the invoice?
What if I know only the invoice number and the phone number, but want to know
the vendor.
Etc. Using OOP this would produce some nasty sequential searches.
> uses Clipper syntax, which you claim is one of
> the wonderful TOP languages
I did *not* say it was the most wonderful language (it is not even ITOP). I
only borrowed features I liked for my examples. I have plenty of criticisms
of xbase (but less than most oop languages).
Stop putting words in my mouth, please. I do not appreciate it.
Regarding your example, If you are talking about a copy of a printed invoice,
then one would probably not have to traverse that many tables--One for the
invoice image, and one for the vendor master. You only need one table for the
invoice image. The syntax also depends on the query question. Most queries
are asked without knowing all fields (or properties) involved.
> With a good OO design, the query would be unchanged by > schema changes.
One
> single change to the "mapper" or data dictionary would > resolve the schema
change for ANY query.
I don't beleive this. How are your example objects stored? If you sell me, I
will shut up and go home. Is that an incentive or what?
> if, for example, the database administrator
> decides to put the maincontacts phone number in the
> vendor table for efficiency sake.
If there is only one main contact per vendor, then it belongs in the vendor
master anyhow. Otherwise the word "main" has no meaning.
There are as many bad OOPDBM's as bad non-OOP DBM's. I truely doubt OOP can
reduce problems caused by stupid structure changes. Tree structures are more
fragile than graphs (nets). Sure, you can override a parent's method. But
over time everything will be overridden and the hiearchy has less and less
meaning. OOP creates a new problem: spagetti trees. Or perhaps I should call
them "orphanned parents"?
-TopMind-
Harry Protoolis
In article <6g4i4s$pbj$1...@nnrp1.dejanews.com>,
top...@technologist.com writes:
>
>
> Response to Harry: (Part 2)
>
>> So you don't like GUI's either ?
>
> I did not say this. I have nothing against GUI's. (Although they sometimes
> slow down data entry from the character mode days.)
Surely that depends on the GUI ? I agree that often programmers forget
they are building a data-entry screen and get carried away. In any event
data entry is no longer a dominant portion of the user interface market.
>> Huh ? What about business programming ?
>
> I would have to look at a specific case. There are many ways to
> skin a cat. OOP is only one of them.
If you are trying to model a complex business, like, for example, a
bank, OO is a very powerful tool. It allows you to capture the complex
behaviour of these sorts of systems in ways which can be mapped into
running systems. This is very different from traditional ERD+DFD type
modelling, where the model may very well have captured the business, but
while the ERD could be translated into an database fairly readily,
the behavioural model (the DFD) was completely useless (IMO&E)
>> [oop] is useful, it works, show me something better and I'll use that.
>
> Perhaps it is a personal preference. Working with other programmers shows one
> how different each mind is. I find tables a very visual and compact place to
> store attributes and control code. They are easier to see and manage than
> program code IMO.
So what do you use to model behaviour ?
>> Yes, but OO is popular with technical people, hype [MS] usally only
>> works on managers...
>
> Aren't you contradicting yourself? First you say that OOP hype would not
> affect programmers (another msg), only managers. Then you are agreeing that
> Microsoft is common (even with programmers), but you attribute it to hype. It
> sounds like hype can control programmers as much as technical merit. If so,
> you cannot use popularity alone to show that OOP is better.
No, IME Microsoft is more popular with non-technical people than it is
with programmers. Non-technical people like MS for two reasons, one of
them is most certainly hype, the other is the fact that for many of
their problems it is the best available tool.
I have *never* met a single programmer who claimed that DOS (including
Win95) was a good operating system. Even the most extreme MS-bigots
argue from the position of market dominance, not technical merit (i.e.
we should use DOS/Win9x because everyone else does).
> -Topmind- (an arrogant alias, wouldn't you say?)
Yes, it makes you sound like an idiot. Try using your name ...
Harry
Ell
Thaddeus L. Olczyk (olc...@interaccess.com) wrote:
: top...@technologist.com wrote:
: >
: > Response to Harry:
: > > than it was by GUI's. [or hype]
: >
: > This is where you and me disagree.
: OO has very little to do with GUI's. Of course you're
: to lasy to do that.
The current emphasis of OO book topics says nothing conclusively about
the history of OO, and what the emphasis was at an earlier time.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
RSanderson
top...@technologist.com wrote in message
>Reply to Rick:
>
>> If so [read from disk], how slow are the programs you write?
>
>Since about 1989, most software and/or hardware buffers disk data in
memory,
>thus speeding up many operations. Smaller tables will even fit entirely in
>memory. All this is *transparent* to the program and programmer.
>
>Also, if you have a zillion records, at one point its going to HAVE TO go
>onto disk. If you use tables, then scalability is built in. You *never*
have
>to ask, "hey what if it all gets too big and no longer fits in memory at
the
>same time?"
>
>You do not seem to understand the power of tables, at least not after 1989.
>
These points are irrelevant to a comparison between OO and TOP. Both can
take advantage of server and client side caching. My original question
concerned whether you use a direct reference to a column in a table (for
reading AND writing) throughout your program, as opposed to working with
memory variables, where YOU control when to read and write those variable
values from/to the actual table. I would beg to differ that a program that
performs all of its processing work against tables and columns will be
faster than working with in memory lists and variables.
>> dial(invoice(num).line(lineitem).product()
>> .vendor().mainContact().phoneNumber() )
>
>Nobody will remember this sequence. They will most probably want to view an
>image of the invoice on the screen and locate it that way.
>
Who said you had to? Even so, I would suggest its easier than remembering
which tables, indexes, column names your data comes from.
Note that I said that the query COULD be in the format given. It was an
example of what COULD be done given a specific scenario. You have not
countered my point.
>Also, what if a vendor has no product or mainContact? (service companies or
>typo, for example) This is an example of how ooper's get heirarcy-happy.
One
>weak link in the hierarchy, and boom!
What planet are you from? How on earth did you get that question from the
query I presented? Note that the query contains "product().vendor()" which
means we definately have a product, and then query for its vendor. BTW, a
service can certainly be represented as a product, if a designer so sees
fit.
And if there is no mainContact, then the dial will fail, won't it. This is
the case in ANY case.
>Also, with indexed tables, you can index on the phone number, the vendor,
the
>product, etc. *independantly* of the others (if needed). And if there is no
>index, a sequential search is very easy to do. One is not stuck with some
>hierarchy which may be *arbitrary* to a user's particular needs.
>
You keep talking about a hierarchy. What hierarchy? If, given the example,
the programmer felt that the query is an often occurrence, using OO he COULD
(could is different than would) write a service of invoice which retrieves a
vendors phone number:
invoice().phoneNumOfVendorForItem(3).dial()
Note that indexes, tables, columns are not mentioned in this query. ( In
case of ambiguity, I am assuming we are talking about queries written by
programmers for services to be provided to a user, not ad hoc queries in a
query screen for users)
>What if I know the main contact, but not the vendor?
contact.getVendor(); // or contact.belongsToList()
> What If I know the product, but not the invoice?
product.getInvoicesSold();
>What if I know only the invoice number and the phone number, but want to
know
>the vendor.
Telephone phone;
invoiceBroker.find(5656)->vendorList().where( phone=="555-1212" );
// the phone object COULD be responsible for building a SQL where condition.
or, more easily,
phoneBroker.find("555-1212")->getOwner().
>Etc. Using OOP this would produce some nasty sequential searches.
>
My first thought: "Yeah, right!"
Then...
Why? What about OOP makes it impossible for the database to have indexes
and other optimisations for queries? Where does this differ from working
directly with tables?
>Stop putting words in my mouth, please. I do not appreciate it.
Pot calling the kettle black.
>
>Regarding your example, If you are talking about a copy of a printed
invoice,
>then one would probably not have to traverse that many tables--One for the
>invoice image, and one for the vendor master. You only need one table for
the
>invoice image. The syntax also depends on the query question. Most queries
>are asked without knowing all fields (or properties) involved.
>
And? ...
>> With a good OO design, the query would be unchanged by > schema changes.
>One
>> single change to the "mapper" or data dictionary would > resolve the
schema
>change for ANY query.
>
>I don't beleive this.
Are you calling me a liar? [see previous Pot/Kettle analogy]
> How are your example objects stored?
>
That's the point of OO. The application programmer does not need to know
how the objects are stored. When the db administrator creates or changes
table schema, the data dictionary/mapper objects are created/changed to
resolve that schema. The application programmer does not know (or care)
that the location of stored data has changed.
To answer your question, objects are stored in tables, and just as you would
imagine, the tables are created with a schema which best balances Normal
Forms and efficiency. Data storage is data storage. It does not matter
whether you write OO or procedural programs to access that data.
> If you sell me, I will shut up and go home. Is that an incentive or what?
>
No, its not an incentive, since I don't really care how you write your
programs, or more specifically, how often you go home. I have spent my time
on this thread because it is fun.
As far as selling you goes, I'm not sure you are up to the task [read:
desire, time, and/or ability] of learning what would be required in order to
be sold.
Try out this book, though: "Building Scalable Database Applications,
Object-Oriented Design, Architectures, and Implementations", Peter M
Heinckiens, Addison Wesley, 1997. It's not a well written book, but the
ideas in it CAN be implemented. I know this because I've implemented a
persistence layer for objects which is somewhat similar to Heinckiens
approach that works quite nicely, thank you.
>> if, for example, the database administrator
>> decides to put the maincontacts phone number in the
>> vendor table for efficiency sake.
>
>If there is only one main contact per vendor, then it belongs in the vendor
>master anyhow. Otherwise the word "main" has no meaning.
>
That *might* be why a db administrator would move it there. However, the
contact does not necessarily BELONG in the vendor table. If you wanted to
find a contacts phone number, then looking in the CONTACT table (for main
contacts and ancilliary contacts) shoudl suffice. With what you suggest,
you'd also have to look in vendors.
>There are as many bad OOPDBM's as bad non-OOP DBM's. I truely doubt OOP can
>reduce problems caused by stupid structure changes. Tree structures are
more
>fragile than graphs (nets). Sure, you can override a parent's method. But
>over time everything will be overridden and the hiearchy has less and less
>meaning. OOP creates a new problem: spagetti trees. Or perhaps I should
call
>them "orphanned parents"?
>
You know not of what you speak. Enough said.
Rick.
Don Stacy
On Wed, 01 Apr 1998 12:28:52 -0600, Tim Ottinger <otti...@oma.com>
wrote:
>
>
>top...@technologist.com wrote:
>
>> It seems to me that OOP has been over-hyped and has failed to improve
>> programmer productivity in building custom business software.
>
>This is true of every technology that's ever been useful. Remember the
>"structured"thing back a few years? And the "desktop" thing? And the "Handheld"
>thing? And
>GUI, and CASE, and 4GL?
>
<snip>
Couple of questions. What does topmind consider a OOP
ToolSet/Language??
What OOP Tools has he used to base his opinions.
The reason I ask is out of curiosity. Having walked the fire on the
mainframe with Cobol & ACL, I was glad to start using Powerbuilder.
After the systems we built started to scale I escaped the GUI all
together because things had gotten out of control. The last few
system's I built I worked strictly in SQL stored procedures. During
those last few systems I started self training in Smalltalk, one of
the purest(please no flames) OO languages. My first impression was so
what!! I could not see what the big deal was. Then out of the blue I
saw the light. I started looking at everything I had done in the past
three years and saw how much easier it could be. I don't think you
will ever understand OO until you've worked with it a while.
We just started the second phase of a three phase project to rewrite
our customers systems using Smalltalk/CORBA. Is it a success, our
customer thinks so. The have remarked about how fast the turnaround
is on enhancemnts/changes.
Most F500 companies have large mission critical systems built using
OOP. They are not crazy about having the content or the software they
used to build the system made public knowledge. You will find that
most large corporations that have highly flexible/dynamic business
rules will lean towards an OOP solution due to maintenance reasons and
they feel that it gives them an edge.
There are several fine Object Databases on the market. One of the
most popular for Smalltalk is Gemstone, which is currently available
in JAVA also. You should go to their web site and read thier white
paper. They support complex indexing.
There are several OO tools that can be downloaded on the web
(Smalltalk, Lisp, Eiffel,Ada,C++,LOGO). Spend some time with one
before you make judgement.
BTW if I was told I had to go back to procedural code or SQL I would
die!!
Don Stacy
EDS
dst...@firstnethou.com
Tim Ottinger
Ell wrote:
> The current emphasis of OO book topics says nothing conclusively about
> the history of OO, and what the emphasis was at an earlier time.
This is true. OO long ago grew out of the box it came in. It's now
pretty pervasive. When I got involved, GUI was not a big focus,
and I'm still not sure that OO and GUI have ever been very close
bedfellows. Where GUI is involved, OO language features are
capitalized on, but not for OO design. Typically the OO is
a retrofit on an existing GUI.
Have any of the GUIs been designed to be OO from the ground
up? All those I know of for Windows and (by my suspicion) for
X are retrofits. Maybe NeXt? I understand that the Mac was
retrofit also.
But C++ frameworks (OO or not) are all over the GUI scene
these days. And components. And it's still an ugly scene. But
it's better than the pre-OO framework days, when you had to
learn a flat space of a few hundred APIs.
Tim.
tim
Graham Perkins
top...@technologist.com wrote:
> Since about 1989, most software and/or hardware buffers disk data in memory,
> thus speeding up many operations. Smaller tables will even fit entirely in
> memory. All this is *transparent* to the program and programmer.
>
> Also, if you have a zillion records, at one point its going to HAVE TO go
> onto disk. If you use tables, then scalability is built in. You *never* have
> to ask, "hey what if it all gets too big and no longer fits in memory at the
> same time?"
>
> You do not seem to understand the power of tables, at least not after 1989.
Well there are some good OO databases out there. Certainly O2 and
Gemstome
keep methods synched with data and don't make you keep whole dataset in
memory. Because of nature of Object Persistence and transactions, you
often get locking at object level (even complex object) rather than page
or table level. Which I think can often be an advantage, and sometimes
essential (eg for very long deep transactions).
Also if you are using a good OO database, then indexed table is one of
the
storage containers you can use. But also you might prefer to ask
for set, vector, hash table, binary search tree ... as your container.
(although it is true that ad-hoc queries are harder to handle
in OO environment)
> > dial(invoice(num).line(lineitem).product()
> > .vendor().mainContact().phoneNumber() )
>
> Nobody will remember this sequence. They will most probably want to view an
> image of the invoice on the screen and locate it that way.
but it looked a lot simpler than the sql code you cut. No point in
comparing with visual navigation .. that's an app., and could be
implemented with object chasing or table chasing behind the scenes.
> Also, what if a vendor has no product or mainContact? (service companies or
> typo, for example) This is an example of how ooper's get heirarcy-happy. One
> weak link in the hierarchy, and boom!
It's not a hierarchy. It's a graph.
In both cases, you ought to handle absent links. Table
query will return empty set which you have to handle,
object query will raise "null object" exception which
you have to handle.
> Also, with indexed tables, you can index on the phone number, the vendor, the
> product, etc. *independantly* of the others (if needed). And if there is no
> index, a sequential search is very easy to do. One is not stuck with some
> hierarchy which may be *arbitrary* to a user's particular needs.
It's not a hierarchy. It's a graph.
Did someone tell you that a collection of objects cannot be indexed
on more than one key? They were having you on.
> What if I know the main contact, but not the vendor? What If I know the
> product, but not the invoice?
> What if I know only the invoice number and the phone number, but want to know
> the vendor.
> Etc. Using OOP this would produce some nasty sequential searches.
You run into nasty sequential searches also with tables if
someone wants to make a query whose structure you did not
take account of in your table design. Maybe that same person
above also told you that once an object is in one graph, it
is not allowed to go into another search structure as well.
> There are as many bad OOPDBM's as bad non-OOP DBM's. I truely doubt OOP can
> reduce problems caused by stupid structure changes. Tree structures are more
> fragile than graphs (nets).
Do you mean tree data structures or tree-organised source code
categorisation? Your posting are littered with assertions
that seem to indicate you are a little confused between tree
structured data structures and inheritance trees.
> Sure, you can override a parent's method. But
> over time everything will be overridden
Why?
Do you believe that every new class *must* be written as a descendant
of an existing one? Do you think that inheritance derivation is a
complete substitute for version control?
> and the hiearchy has less and less
> meaning. OOP creates a new problem: spagetti trees.
> Or perhaps I should call them "orphanned parents"?
Of course you can build poor hierarchies, just as you can
design tables badly. We saw one table design recently for
another college where user had to type in full name and
address of examiner of a module for each and every student
taking that module.
-----------------------------
Now let me explain a couple of core tenets of the OO Programming
1) encapsulate your state
This reduces coupling, eases testing, reduces error propagation,
localises effect of change, and generally eases the process of
maintenance and evolution. [by comparison with unencapsulated
state] You think these things are useless hype?
2) capture service commonalities in superclasses and hide
implementation variations in subclasses
Find some good books on OO modelling and you'll see models
in which object interactions occur at a high level of abstraction.
This massively reduces the number of interaction channels and
is a huge aid to reducing complexity of software.
You know, of course, hoary old problem of putting more
people on a late project .. it just makes it even later
because interaction complexity grows exponentially. It's
the same with software. Proper use of abstraction allows
you to keep interaction complexity stable and localise the
effect of system growth.
----------------------------------------------------------------
Department of Turbo Pascal, De Montfort University Milton Keynes
http://www.mk.dmu.ac.uk/~gperkins/
top...@technologist.com
Reply to Rick:
> I would beg to differ that a program that
> performs all of its processing work against tables and columns will be
> faster than working with in memory lists and variables.
Well beg then. With caching, the speed difference is minimal.
Reading and writing all happens in memory. The memory is not written to disk
until either the next disk sector is needed, or an explicit "flush buffer"
command is issued.
> Even so, I would suggest [OOP branching is] easier than remembering
> which tables, indexes, column names your data comes from.
If so, its a very marginal improvment. To the user and/or programmer its
highly gobbledygook.
> You have not countered my point.
Which point is that?
> In case of ambiguity, I am assuming we are talking about queries written by
> programmers for services to be provided to a user, not ad hoc queries in a
> query screen for users)
Aaaaaah! I did not know this. If this is the case, then why are you concerned
about me naming tables and indexes? Functions/methods can be created to
shorten any query. This.dot.thingy.thongy.gringy.grongy() is not a good
SHORTCUT to anything. Why have your long query calls if they are not related
to a hierarchy or something? I am confused about your choice of syntax. You
showed a longcut, not a shortcut.
> invoice().phoneNumOfVendorForItem(3).dial()
What about something more like:
Dial("where invoice=27 and invline=3", "vendor")
It is much less dependant on how methods are layered or grouped. The first
parameter tells where to look and the second one tells what to dial. My
example is perhaps too SQLish, but there are other similar ways to define such
without having to know the method hierarchies.
> What about OOP makes it impossible for the database to have indexes
> and other optimisations for queries? Where does this differ from working
> directly with tables?
If you deviate too much from the table structure, then you can get "runaway
queries" where many sequential search(es) have to be done. Also, the more
layers of abstraction there is, the more that can go wrong when changes are
made.
> Are you calling me a liar?
No, just mistaking. You could even be right, but have yet to show me why.
> That's the point of OO. The application programmer does not need to
> know how the objects are stored.... the data dictionary/mapper objects
> are created/changed to resolve that schema
So you are saying that this mapper thing *can* be used to access regular
relational tables in an *effective* manner? But how is the relationship
between the tables represented (in code)? What exactly does this mapper look
like using the usual customer, vendor, product, invoice, etc. tables?
> It's not a well written book, but the
> ideas in it CAN be implemented.
I am a little hesitent to read a "non-well-written book". (Thanks for being
honest about it, though.) Also, just because something can be implimented does
not mean it should. It still seems like getting good data-centric OOP
information and/or results is difficult.
> However, the contact does not necessarily BELONG in the vendor table.
Now that I think about it, you may be right to store it in Contacts instead.
> You know not of what you speak. Enough said.
Insults without info. Ive seen about 20 of these already.
Like I said before, if I am ignorant of OOP, then so are a majority of
programmers out there. I can find very little or no info on how OOP improves
data access coding. You can call me stupid a million times, but it will not
fix a major problem, whether this problem is a flaw in education, a flaw in
programmers, or a flaw in OOP.
The flaw is in one or more of these three places, but you have fixed it in
zero of three places.
Nice try, though.
-Topmind-
top...@technologist.com
>
> I really think lots of programmers (the guy who started all this being a
> clear example) have no idea what OO is about. Well, it might be because the
> professionals keep this only to themselves...
>
If this is true, then OOP will fail in the marketplace because bad
OOP programmers will make messes and OOP will be discredited in the minds of
the purse holders.
Whether the OOP problems I am talking about are technical faults or
educational faults, either spell doom for OOP. Nobody has addressed this.
Note: somebody implied that ITOP and OOP are mutually exclusive. If you have
been following, you would know that this is not the case. (I can't find the
original message.)
dogmat
top...@technologist.com wrote in message
<6ghfp1$tb9$1...@nnrp1.dejanews.com>...
>
>If you deviate too much from the table structure, then you can get "runaway
>queries" where many sequential search(es) have to be done.
This is a problem in the relational world. It may or may not be a problem in
the OO world, depending on how smart the programmer was. The latter point is
hard to explain, because we have to step back to the big picture, which is:
"Forget tables. Think objects." (Sounds a little empty, I know, but the only
approach is to break away from the mindset.) If you think tables, you will
just be writing table code with a little help from the OO tools, which is to
miss the whole point of OO. If you think objects, then all the table woes go
away, or at least are abstracted out into a layer where the object-to-table
"impedance-mismatch" can be managed locally.
>Also, the more layers of abstraction there is, the more that can go wrong
when changes are
>made.
There is some debate about this point, however, I believe in the other
extreme. If you abstract badly, then changes will propogate. However, proper
abstraction localizes changes. This is fuzzy, but it comes down to what
"types" of abstraction we are talking about. If one thinks abstraction is
just using inheritance, then changes will kill you. However, if one thinks
about abstraction as separating functionality or "things", then changes can
be managed.
For example, if I "abstract" out the mapping of objects to how they are
persistently stored, then persistent objects do not need to care about how
they are stored. Rather, a "PersistenceManager" object will handle that. So
if a persistent object needs to store itself, it simply calls the
PersistenceManager with itself as the argument. So: (1) programmers can
forget about persistence which is good, and (2) when changes are made to how
objects are stored, only the PersistenceManager needs to be changed, which
is also good.
Remember, the point is to *localize* changes, and if abstraction helps that,
then it is good.
Is it possible to have too much abstraction? I suppose so, however, I have
never found this personally. The more I can abstract, the better. OTOH, good
abstraction is *very* hard. This is true for all programming, not just OO.
The fact is, though, that OO provides more tools and concepts in which to
accomplish this.
>> That's the point of OO. The application programmer does not need to
>> know how the objects are stored.... the data dictionary/mapper objects
>> are created/changed to resolve that schema
>
>So you are saying that this mapper thing *can* be used to access regular
>relational tables in an *effective* manner? But how is the relationship
>between the tables represented (in code)? What exactly does this mapper
look
>like using the usual customer, vendor, product, invoice, etc. tables?
Well, the objects are the thing and the mapping to the relational models is
called the "impendance mismatch", because the relational model is different,
read inferior. The goal is for application objects to deal with application
objects and not give a damm about persistence, tables etc. That is the
"abstraction". Now behind the scenes, each persistent object needs to be
mapped to a relational table(s), which is the task of the mapper. This is
another "abstraction". "Effective" can mean a lot of things, however, in
general, one would map each object class to a separate table, store
object-to-object references as relations, etc, etc. Whatever it takes to
convert the object structures to the relational storage. Exactly how the
mapper looks is dependent on the OO language, but the point is that the
mapper will know the "schema" of the object structure, then be able to
convert that to one or more SQL statements.
>Like I said before, if I am ignorant of OOP, then so are a majority of
>programmers out there. I can find very little or no info on how OOP
improves
>data access coding. You can call me stupid a million times, but it will not
>fix a major problem, whether this problem is a flaw in education, a flaw in
>programmers, or a flaw in OOP.
>
>The flaw is in one or more of these three places, but you have fixed it in
>zero of three places.
OOP is tough. In fact, it seems that the more experience one has with non-OO
programming, the tougher it is to "get" it. It is really easy to teach OO to
a novice, because they have no preconceptions, i.e., they will not rebel
when one states: "There are objects, they have attributes and methods. Duh."
An experienced programmer may not take the time to ponder this sufficiently.
Learning OO is a recurring sequence of "aha", "this is easy", then "no it
isn't". It is also frustrating because a statement such as: "I can find very
little or no info on how OOP improves data access coding" is best answered
by: "Well that sentence tells me right off that you already missed the
point.". Try stepping back to consider the following: You don't learn OO to
figure out how to improve data access code. You learn OO so you can (1) put
all that data access code in one place, then (2) forget about it and get
onto the important stuff.
dogmat
top...@technologist.com wrote in message
<6ghh8b$v3u$1...@nnrp1.dejanews.com>...
>
>>
>> I really think lots of programmers (the guy who started all this being a
>> clear example) have no idea what OO is about. Well, it might be because
the
>> professionals keep this only to themselves...
>>
>
>If this is true, then OOP will fail in the marketplace because bad
>OOP programmers will make messes and OOP will be discredited in the minds
of
>the purse holders.
>
>Whether the OOP problems I am talking about are technical faults or
>educational faults, either spell doom for OOP. Nobody has addressed this.
Nothing will spell doom for OOP, period. Limitations of the theory and
educational faults will slow down its progress, however OOP is a better
"hammer", and will therefore always be used until something better comes
along. And you know what: That will be OOP too, whether or not it is
recognized as such. Ultimately, all development of programming theory is a
progression towards "pure" information theory. And information theory means
to slice and dice information. Slicing and dicing means creating boundaries
between "things". What these things ultimately are many take many more
lifetimes to think about (I doubt it will ever be "complete"). But the fact
that there will be things and boundaries between these things means that
there will be objects.
top...@technologist.com
> It is also frustrating because a statement such as: "I can find very > little or no info on how OOP improves data access coding" is best answered > by: "Well that sentence tells me right off that you already missed the > point.". Try stepping back to consider the following: You don't learn OO to > figure out how to improve data access code. You learn OO so you can (1) put > all that data access code in one place, then (2) forget about it and get > onto the important stuff. > You seem to be saying that I should blindly accept the fact that OOP is better and someday I will see that it really is better if I keep searching and trying. You sound almost like a missionary who cannot offer up-front proof. This may be okay if there is only one religion, but if 500 say the same thing, then you have to either make the best guess up front, or consider it all bologny. Is OOP really that evasive?
top...@technologist.com
> but it looked a lot simpler than the sql code you cut. I did not show SQL
code in the message you replied to. I am not sure what is being referred to
here. (I did propose a more non-positional syntax in another message based on
QBE techniques.) > Do you mean tree data structures or tree-organised source
code > categorisation? I meant inheritance and method levels. >
encapsulate your state What is meant by "state"? > Find some good books on
OO modelling and you'll see models > in which object interactions occur at a
with data persistance, data queries, and relational-OO mapping? Thanks for
the reply. -Tmind-
top...@technologist.com
> So what do you use to model behaviour ?
Have only one routine or function that handles updates to an item. However,
since reading does not hurt stuff, it often does not need stringent
restrictions IMO. Since behavior requirements change drastically over time,
modeling is usually not an issue.
> > -Topmind- (an arrogant alias, wouldn't you say?)
>
> Yes, it makes you sound like an idiot. Try using your name ...
I use the funny name to filter out spam.
top...@technologist.com
> When I got involved, GUI was not a big focus, > and I'm still not sure
you hung around acedemics and technical people, but in manager's mind,
"Visual", "Component", "Objects", "GUI", "Windows", "Drag-and-drop icons"
were all lumped together as a "new vision of doing things". This vision may
not be accurate, but that is the perception that made OO languages a must for
product pickers. > But C++ frameworks (OO or not) are all over the GUI scene
> these days. And components. And it's still an ugly scene. But > it's
better than the pre-OO framework days, when you had to > learn a flat space
"math_trig_sin()" really different from "math.trig.sin()" ? (I still prefer
"sin()") -Tmind-
top...@technologist.com
> > Macintosh... forgotten but not gone. > Based on its market share curve despite being loved by its fans, perhaps it should be: "Macintosh... gone, but not forgotten" (Note: I am *not* bashing the Mac as a technology, just its market share)
top...@technologist.com
> > BTW if I was told I had to go back to procedural code or SQL I would > die!! > I finally found this quote. I remembered reading it, but could not find it again until now. ITOP and OOP are *not* mutually exclusive. This has already been explained. -Tmind-
top...@technologist.com
> Well there are some good OO databases out there. Certainly O2 and >
expensive, proprietary system. I am hoping for something data/table oriented
that is as common, standard, and popular as Java, C++, and VB (well, VB is
not standard). X-base was approaching such popularity and
defacto-standardization until about 1995 when OOP focus popped and splintered
it. (xbase has many faults, but could have served as an inroad to ITOP.)
top...@technologist.com
> With objects, when you have a lot of calculations and a lot of invariants
to > protect, the object is responsible for its own state. It prevents you
from doing > things like changing only the zip code on an address. My
proposed ITOP has features like this also. > Another is that object
frameworks can protect us nicely from dependency > on a particular vendor's
database SQL was supposed to solve this, but the standard left too many
fuzzy issues open, like hit-list size quotas and Join syntax. Perhaps SQL can
be fixed to make it more generic. > But if you are writing a program that is
unlikely to last and unlikely to > spawn a family of products, and there are
no OO frameworks or > libraries you would like to use...then don't use OO.
But there are not very many table-oriented products out that like this that
are accepted by the client (payer). Like I said before, the market focus on
OOP left other options in the dust (from a practical sense). Also, I was
perfectly able to build lasting, long-sighted mechenisms before OOP became
mainstream. I don't see how OOP improves what I have learned about long-term
planning. Data Dictionaries can handle encapsulation just fine and can be
given features that allow field property inheretance (even to memory vars.)
> I'd be more interested in seeing what you could do in data > processing
under OO than what you can do without it, because > most people would like
having both under the same roof. I have nothing against hybridization or
combining of table oriented and OO ideas. I just think that the T.O. side of
research and market thrust has gotten the short end of the stick. That is my
main beef. OOP sucked other concepts dry with attention.
Marcel Popescu
top...@technologist.com wrote in message
<6gjmfq$eh6$1...@nnrp1.dejanews.com>...
>Is OOP really that evasive?
He was never evasive. He said that programming has NOTHING to do with data
access (or with binary trees, or with garbage collection, whatever). Those
are fields of interest for certain programmers in certain programs. The
other programmers should not be bothered with the details.
Let's take xBase languages. It's true, you won't choose one of these if you
want to do maths. But, if you need, among other things, data manipulation,
these languages will force you to deal with every aspect of tables and
indices and memo files (and so on) in every bit of the program. You might
need to store the results of some computation. Great! You choose a table for
this. Even better. Now why on Earth should you bother with paths and file
names (system specifics), disk errors, index corruption and so on? (I mean
why here; of course I'll have to deal with these, they are part of the
program; but it would be much better to confine them to one ResultsManager
object, derived from PersistentObjectManager, and forget about it.)
Mark
Marcel Popescu
top...@technologist.com wrote in message
<6gjndc$fep$1...@nnrp1.dejanews.com>...
>> Find some good books on
>>OO modelling and you'll see models
>> in which object interactions occur at a
>>high level of abstraction.
>Can you recommend any, especially those dealing
>with data persistance, data queries, and relational-OO mapping?Thanks for
>the reply.-Tmind-
Boy, you haven't understood a thing, have you? Data design books deal with
what you said. Object modelling books deal with object modelling. They teach
you how to create your object structure - more important, how to model the
world so your object architecture is both flexible and powerful. But they
won't usually show you how to implement a 5-bit counter...
Forget about this data-related stuff. You can't really use a microscope to
crack nuts. Data processing is one FIELD. The application space has many of
these. Think! Forget about tables.
A person is an object. It doesn't care if you keep its attributes in one or
52 tables. All it cares is to be able to save its state so it can reload it
later.
You give it that save/load ability by writing a specific part of the code to
deal with it. Then you write it for the Manager object. Then for the Clerk
object.
Or you start thinking, and derive all of them (or use a member field) from
Persistent. And implement the data manipulation once, in this object. And
then forget, 'cause you have to do person manipulation, not data.
Mark
Marcel Popescu
top...@technologist.com wrote in message
<6gjnrb$g5r$1...@nnrp1.dejanews.com>...
>Have only one routine or function that handles updates to an item. However,
>since reading does not hurt stuff, it often does not need stringent
>restrictions IMO. Since behavior requirements change drastically over time,
>modeling is usually not an issue.
This because of your way of thinking. "Reading does not hurt stuff". Yuck!
Reading will hurt you, when you will want to compute something based on the
reading, or to check the item based on something else, and then you and your
code will chase each other (have you seen the damn thing moving around? :-)
Forget this ugly way of thinking! Even SA/SD has had modularity. At least
keep everything behaviour-related in one module.
Mark
top...@technologist.com
Hey, something is changing the way I put quote brackets around statements.
I would have noticed it if the original was as messed up as the final result.
I may have made 2 quote typos without noticing, but not 10!
Whatever the cause, I apologize for funny quoting.
-Topmind-
top...@technologist.com
>
> Forget about this data-related stuff. You can't really use a microscope to
> crack nuts. Data processing is one FIELD. The application space has many of
> these. Think! Forget about tables.
>
> A person is an object. It doesn't care if you keep its attributes in one or
> 52 tables. All it cares is to be able to save its state so it can reload it
> later.
>
By "Table Oriented" I mean more than traditional tables. See my comments about
control tables, for example.
A person is an object. If there is only one person than OOP makes it easy to
make all kinds of fancy behavior for that person. However, if there are 100
persons, then do we allocate 100 objects? How do we track, link, group, and
sort these 100 humans?
How about 1,000, or 1,000,000 of these humans?
OOP makes for very powerful individuals, but it SUCKS at relationships. Your
person object is a fricken genious hermit! OOP can make great Unibombers,
but lousy cities. Get my point?
Tim Ottinger
top...@technologist.com wrote:
> > When I got involved, GUI was not a big focus,
> > and I'm still not sure that OO and GUI have ever been very close
> > bedfellows.
>
> This may be so if
> you hung around acedemics and technical people
Technical people, yes. Academics, only recently. I learned OO completelywithout
any academic folks or academies being involved. I learned in industry,
with books and experience and practitioners.
> , but in manager's mind,
> "Visual", "Component", "Objects", "GUI", "Windows", "Drag-and-drop icons"
> were all lumped together as a "new vision of doing things".
This is more of the hype that is wrong, not a technology that failed.
> What do you mean by "flat space"? how is
> "math_trig_sin()" really different from "math.trig.sin()" ? (I still prefer
> "sin()")
It's grouped. Have you ever read Brad Cox' book on OO? He invented
the Objective C language, and his book was quite wonderful. He talked
about "surface area" and "software ICs". Great stuff.
The first change is that the APIs are grouped. But grouping APIs is not
at all the same as creating classes and objects (ignore what M$ says).
A class like "string" from the C++ std. is much easier to learn than an
equivalent number of loose string functions. The grouping is there, and
the syntax is much easier to understand.
string s;
s = "something";
s += " else ";
s = s + " to do with";
cout << s;
That's using operators (which is a C++ trick), but make it much
easier to work with strings than learning string.assign, string.append,
string.print. It's much, much easier to learn to use a class than to
learn a bunch of apis. The conceptual grouping and attention to
semantics and readabilty help so much.
In the GNU library, String had a bazillion methods, but you know
what? It was easy to work with. Most of the methods were overloads
for characters, arrays, strings, etc. Many of them had the same name,
so you just remembered what the name was, and you knew that it
worked for String, char*, char, etc. Also, you knew that in most
read-only contexts, you could use regex also (transparently!). It
was wonderful for such a huge class.
This is a huge difference.
One of the best parts of OO is that you look at a problem that you
have to work with, build up the domain-specific language that you
need to work on the problem (in classes) and then refine the language
and the solution together. That's a great thing to be able to do.
A good library (look at some of the stuff from ObjectSpace, for
instance) is easy and pleasant to use and makes the domain you
are working in conceptually clean (if not simple). A bad library
(like MFC) simply gives some notational convenience over using
a C library directly.
But header files are supposed to be good documentation. That
they're sometimes not is an implementer's shortcoming, not the
paradigm's.
Remember that Date has been saying for a long time that the
Relational model is perfect, but nobody's bothered to implement
it yet. What he says for RDBMS is not true of OO. But there are
companies with a lot of commercial success who haven't caught
on yet. Lots of other successful companies are doing OO well.
Tim
Tim Ottinger
dogmat wrote:
> Is it possible to have too much abstraction?
It's definitely possible to have the wrong abstractions, and it's possible
tohave unneeded abstractions. In those cases, getting rid of the unneeded
ones and replacing the wrong ones are very important design activities.
B.Meyer says that class rejection is *at least* as important as class
discovery.
> >So you are saying that this mapper thing *can* be used to access regular
> >relational tables in an *effective* manner? But how is the relationship
> >between the tables represented (in code)? What exactly does this
> > mapper look like using the usual customer, vendor, product, invoice,
> > etc. tables?
My papers at http://www.oma.com/ottinger/BakersDozen were recentlyupdated a
little. It's still work in progress for me (lots of survey and little
time spent on it) but it's going to be completed someday. I'm going to
try to drive more time into it very soon.
Tim
Tim Ottinger
top...@technologist.com wrote:
> Whether the OOP problems I am talking about are technical faults or
> educational faults, either spell doom for OOP. Nobody has addressed this.
Everyone who's answered you is addressing this, and my company in
particular is addressing the educational problem. In fact, we have more
business than we can handle addressing the educational problem. And
it's not just us. Look at Scott Meyers, Bruce Webster, Marshall Kline,
Ralph Johnson, etc, and you will see that the educational faults are
being addressed right and left.
By the way, there are as many faults (technical and educational) in any
technology once it becomes popular (for instance, 4GLs and RDBMS).
It's the popularity, not the technology, that gives rise to the unrealistic
hype and expectations. When it becomes popular or profitable to be
associated with any technology (ANY technology) then quackery is
the natural result.
Tim
Tim Ottinger
top...@technologist.com wrote:
> You seem to be saying that I should blindly accept the fact that OOP is better and
> someday I will see that it really is better if I keep searching and trying. [...] Is OOP
> really that evasive?
First: you should not blindly accept anything. You should, however learn enough
to tell the difference between the pony and the horsesh**. That means accepting
that maybe you don't know all that is worth knowing, and looking at the way
the technology was intended to be used, and for what. That means taking a
position other than "this is inferior". It also means not looking at marketing materials
to learn technical truths. Talk to the techies. Managers and marketers are almost
always wrong about tech.
If you want to talk about OO, you've come to the right place, but you will only
get little sound bites here. You really need to make a proper study. I could recommend
a few books or sites if you would like the direction.
It's only evasive if you try to learn it from tool vendors and marketing papers.
It really is somewhat difficult to learn and apply at first, but that's because you
are getting the benefit of 30 years of development and you can't learn all of
that in an afternoon, or by "just thinking about it". It requires some study.
Pardon a religious metaphor:
Getting OO from marketing is like learning the Bible from Newsweek. It's mentioned
now and then, but only to generate controversy or to expose people with extreme
views. If you want to learn about the Bible, you have to pick one up and read it all
with an open mind. Any idiot can read a verse here and there and get the whole
thing wrong. And nobody should allow anyone else to control their knowledge of it.
You should probably read some of the stuff put out by our company at our web
page, but don't settle for any single source. You should also read Booch, Rumbaugh,
Jacobson, etc. You really, really should read what Bertrand Meyer says, and what
Meilir Page-Jones writes. There are people who know what they're doing, and try
very hard to teach everyone else.
Tim
Tim Ottinger
top...@technologist.com wrote:
> I have heard good things about Gemstone. However, it is an
> expensive, proprietary system.
As opposed to Oracle and DB2, which are free and nonproprietary?Nah, they all
cost too much. They all are proprietary, though some
of them conform to some standards.
> I am hoping for something data/table oriented that is as common,
> standard, and popular as Java, C++, and VB (well, VB is not
> standard).
Would be nice.
Tim
Tim Ottinger
top...@technologist.com wrote:
> SQL was supposed to solve this, but the standard left too many
> fuzzy issues open, like hit-list size quotas and Join syntax. Perhaps SQL can
> be fixed to make it more generic.
But it wouldn't help. If you use SQL, you are dependent on the schema,which is
completely concrete and will change for reasons that have nothing
to do with your application logic. You'll be forever adjusting SQL once
you start to allow your applicaton to be based on it.
> > But if you are writing a program that is
> unlikely to last and unlikely to
> > spawn a family of products, and there are
> no OO frameworks or
> > libraries you would like to use...then don't use OO.
>
> But there are not very many table-oriented products out that like this that
> are accepted by the client (payer). Like I said before, the market focus on
> OOP left other options in the dust (from a practical sense).
If you don't have a complex app, or a family of products, or don'thave a long
life for the product, then OO probably doesn't matter.
If you are going to scribble-up a one-up app, and you know that
it won't be in use three-to-five years from now, then do it in
VB or PB or something and to heck with it.
> Also, I was perfectly able to build lasting, long-sighted mechenisms
> before OOP became mainstream. I don't see how OOP improves what
> I have learned about long-term planning.
Then you've not learned anything about OO yet. OO is all aboutseparating the
essential from the details, the reusable from the
disposable.
If you have worked on long-lasting, far-sighted code, then you've
probably either 1) had to do a lot more maintenance than even a
moderately good OO version, or 2) were unintentionally using
several of the principles OO is based on.
> I have nothing against hybridization or
> combining of table oriented and OO ideas. I just think that the T.O. side of
> research and market thrust has gotten the short end of the stick. That is my
> main beef. OOP sucked other concepts dry with attention.
You're seeing a slap-back. The table side of things got too much hype
and too many unrealistic expectations, and failed to live up to it's marketing
just before OO got really big. OO was a refuge from the failed world of
relational/table/SA systems. It's funny, though, that to you table stuff is
new and OO is old. I guess everything old is new again.
By the way, the table-oriented stuff failed for the same reasons you
claim OO is failing. So consider that you're not David against
Goliath, but you're really representing the old guard here.
Still, tables and objects are both necessary. To claim that one is
perfect and the other is worthless is silly. "New" is no more a
synonym for "good" than "old" is.
Tim
dogmat
top...@technologist.com wrote in message
<6glvch$a7j$1...@nnrp1.dejanews.com>...
>
>
>>
>> Forget about this data-related stuff. You can't really use a microscope
to
>> crack nuts. Data processing is one FIELD. The application space has many
of
>> these. Think! Forget about tables.
>>
>> A person is an object. It doesn't care if you keep its attributes in one
or
>> 52 tables. All it cares is to be able to save its state so it can reload
it
>> later.
>>
>
>By "Table Oriented" I mean more than traditional tables. See my comments
about
>control tables, for example.
>
>A person is an object. If there is only one person than OOP makes it easy
to
>make all kinds of fancy behavior for that person. However, if there are 100
>persons, then do we allocate 100 objects? How do we track, link, group, and
>sort these 100 humans?
By classes and instances. A person "type" is a class. You could also think
of this as a "template". A class is then "instantiated" into an instance for
each copy you want. So you would have one Person class and 100 Person
instances.
>How do we track, link, group, and sort these 100 humans?
Anyway you want. Anything from not bothering to track them at all to "Person
allInstances". Since you are table-fixated, there are Collection instances
in the OO languages that can do all kinds of things for you, such as
iterate, sort, slice and dice, etc. Believe me, the power of OO languages is
far more powerful for manipulating these collections than simple SQL.
>OOP makes for very powerful individuals, but it SUCKS at relationships.
Your
>person object is a fricken genious hermit! OOP can make great Unibombers,
>but lousy cities. Get my point?
No I don't get your point. It is always dangerous to attempt a joke when you
are discussing something you have already admitted to being ignorant about.
First of all, OO is wonderful for dealing with relationships. Where did you
pick up such nonsense? Isn't a relationship an object too, therefore
perfectly amenable to OO modeling? Admittedly, this latter point (modeling a
relationship as an object, i.e., instance of a Relationship class) is an
extension to what you have probably heard (and I am sure you will not
understand what I getting at, because you don't understand the
fundamentals), but it is perfectly natural and a good idea if it helps
simplify the model. Second of all, what I just stated has nothing to do with
what you are talking about, but I cannot figure out what you are talking
about. A genius hermit? A Unibomber? No, I have absolutely no idea what you
mean, and I don't care to decipher. Look, we have already ascertained that
(a) you have some blind spots in your knowledge of OO, and (b) you and
everyone else in this newsgroup use different terminologies, so don't waste
our time by making it more difficult than it already is.
I am reminded of a great quote: "Its not what you don't know that gets you
into trouble. Its what you know that ain't so!"
RSanderson
top...@technologist.com wrote in message
>
>OOP makes for very powerful individuals, but it SUCKS at relationships.
Your
>person object is a fricken genious hermit! OOP can make great Unibombers,
>but lousy cities. Get my point?
Not exactly. Strike that... Not at all !
OO is full of relationships. Its what its all about. Here are some
examples (given certain assumptions):
"Smith" is an instance of the person class.
A person has an address.
A customer is a person.
A customer, who is a person, buys products. (2 relationships for the price
of 1).
Products are shipped to addresses.
etc...
Allow me to expand the "manager is a person" relationship, in simplified
code:
class Person
{
string name;
Address address; // relationship between Person and
Address!
void doSomethingThatPeopleDo();
}
// a customer relates to a person by inheriting Person attributes/behavior.
class Customer: public Person
{
int accountNo;
Money accountBalance;
}
Even though we have put only accountNo and accountBalance in the Customer,
you can still go :
Customer aCust;
aCust.name = "Smith";
aCust.doSomethingThatPeopleDo();
Isn't that pretty groovy?
Now imagine an object infinitely (well, at least substantially) more
complex. This object has been used throughout your code for sometime, and
works great. But now you need to specialize this ComplexObject for a
particular purpose. Without breaking (or even touching) any of the previous
working code, you can go:
class MyComplexObject: public ComplexObject
{
Attribute myNewAttribute;
void myNewFeature();
}
You can now use MyComplexObject in your new code, but with this little
definition, you not only get to call myNewFeature() but also any features
that were in the original ComplexObject.
Object-Oriented Programing 101 (abridged) complete.
To directly counter your point about a Person object "being a fricken
genious hermit", consider the following: (assume that the add() function
creates a person object, and initializes its name with the argument).
PersonBroker people;
people.add("Unabomber")
people.add("AnotherUnabomber")
people.add("YetAnotherUnabomber")
etc...
Wow! Before long, we'll have a "city" full of Unabombers. Taken further,
and in line with this thread about databases, we can say:
PersonBroker people;
Person theUnabomber = people.select("Unabomber");
theUnabomber.bombSomeBuildingsAndPeople();
theUnabomber.address = "Federal Penitentiary";
people.update(theUnabomber);
There is nothing to stop the PersonBroker from *representing* millions of
people. It does not have to have all of them in memory. It may cache some
people for efficiency, but othewise it can load/update/insert/delete a
person (or a whole set of people) from a database containing millions of
people.
Now. Are you actually able to say that the last above example is more
difficult to work with than having to deal with indexes, SQL code, tables,
foreign keys, joins, etc?
Back to you.....
Rick.