Whose Fish?
Jordan Marr
I was once given this question at a job interview (my boss liked to
stress people out). Although I didn't finish the question during the
interview, I still got the job.
So this weekend I created an OO program that solves the problem within
1 to 29 seconds, depending on what order my attributes are initially
entered.
Mine is totally OO and uses no relation database at all, however, it
seems like a great problem to throw at a relational database, which I
would guess may be able to solve it faster.
Any takers? <ahem> ;^)
Jordan
topmind
Personally, I don't think these kinds of puzzles are very useful for
comparing the real-world utility of paradigms. Perhaps they are good
for training newbies or practicing concepts, but *not* for comparing
the relative *value* of techniques in a realistic setting/domain.
They are sort of analogous to slam-dunk contests to the game of
basketball. The best slam-dunker is not necessarily the best player. I
have similar complaints about the shape, animal, and device-driver
examples heavily used in OO books.
(BTW, I submitted my source-coded version of Robert C. Martin's
payroll example here a few weeks ago in an attempt to spark debate on
a semi-realistic example.)
-T-
Jordan Marr
> comparing the real-world utility of paradigms.
What is not "real world" about solving variance problems? There are
plenty of business uses here. Oh wait, you must mean "real world", as
in "Topmind's world".
> Perhaps they are good
> for training newbies or practicing concepts, but *not* for comparing
> the relative *value* of techniques in a realistic setting/domain.
If this is "newbie training" then you should have no problems
designing a solution.
Btw, this NG is not called "comp.object.businessapps", it's called
"comp.object". You continually try to shove every thread you
participate in to your little "business app domain" where they don't
all belong.
> They are sort of analogous to slam-dunk contests to the game of
> basketball. The best slam-dunker is not necessarily the best player. I
> have similar complaints about the shape, animal, and device-driver
> examples heavily used in OO books.
Relax, I'm not attacking your programming style of choice! I
genuinely want to see this problem solved with a DB. I know it can be
done, and it may even work better. This is supposed to be a fun,
intellectual challenge.
But you are so used to disagreeing with everyone that you are not
seeing it that way.
You're the one that comes in here and attacks OOP on an OOP discussion
board. If you are going to come in with your big soap box rants, why
do you think YOU get to set all the parameters? "No no, it CAN'T be a
shapes app.. it CAN'T be this.. it CAN'T be about variations..."
Guess what? IT CAN.
That's like someone trying to show me the "ultimate defensive fighting
maneuver" and saying, "attack me! No.. you can't attack me that way!
Attack me with your LEFT hand.. yeah.. BAM! I win again!!"
> (BTW, I submitted my source-coded version of Robert C. Martin's
> payroll example here a few weeks ago in an attempt to spark debate on
> a semi-realistic example.)
Like I said... that has zero to do with THIS thread. Thank you. Oh
right, you're trying to stand on the nearly off topic soap box AND
control the parameters of the argument at the same time. ;^)
Jordan
Jordan Marr
> examples heavily used in OO books.
Sentence should read:
"I have similar complaints about the shape, animal, and device-driver
examples heavily used in *real-life*."
Jordan
topmind
Fine, if you are the one in a hundred who are actually writing an
animal, shape, or device driver app, use OO.
In biology, there are actually usually multiple candidate taxonomies
such that it is not a clean tree. I think it would be better to keep
such info in a database so that different researchers can access them
with different tools rather than force them all to use Java or Python,
etc.
Further, most device driver writers are being outsourced to 3rd world
anyhow. The further you are from end-user requirements, the more
likely your job is to be offshored (for good or bad).
>
> Jordan
-T-
topmind
Jordan Marr wrote:
> > Personally, I don't think these kinds of puzzles are very useful for
> > comparing the real-world utility of paradigms.
>
> What is not "real world" about solving variance problems? There are
> plenty of business uses here. Oh wait, you must mean "real world", as
> in "Topmind's world".
It is *not* representative of the apps and issues I have faced. Maybe
I live in a bubble somehow, but perhaps you do also. If I can be
mislead, so can you. You are not the center of the universe; we each
only have one lifetime to live.
>
> > Perhaps they are good
> > for training newbies or practicing concepts, but *not* for comparing
> > the relative *value* of techniques in a realistic setting/domain.
>
> If this is "newbie training" then you should have no problems
> designing a solution.
I don't care about solving training/lab examples anymore. That was 20
odd years ago. I care about real-world stuff now. A tool that helps me
insert my knee into my ear is not going to be of much use unless I
join the circus.
>
> Btw, this NG is not called "comp.object.businessapps", it's called
> "comp.object". You continually try to shove every thread you
> participate in to your little "business app domain" where they don't
> all belong.
But there is already a glut of lab/training examples. We need more of
them like holes in the head.
>
> > They are sort of analogous to slam-dunk contests to the game of
> > basketball. The best slam-dunker is not necessarily the best player. I
> > have similar complaints about the shape, animal, and device-driver
> > examples heavily used in OO books.
>
> Relax, I'm not attacking your programming style of choice! I
> genuinely want to see this problem solved with a DB. I know it can be
> done, and it may even work better. This is supposed to be a fun,
> intellectual challenge.
>
> But you are so used to disagreeing with everyone that you are not
> seeing it that way.
No, I am right. It's that simple.
>
> You're the one that comes in here and attacks OOP on an OOP discussion
> board. If you are going to come in with your big soap box rants, why
> do you think YOU get to set all the parameters? "No no, it CAN'T be a
> shapes app.. it CAN'T be this.. it CAN'T be about variations..."
>
> Guess what? IT CAN.
I didn't "set all the parameters". I simply gave an opinion on
something. If you don't like my opinion, then either challenge it
directly on the topic, or ignore it. Complaining about me complaining
is recursive hypocracy. If you feel a rant is off topic or
unimportant, simply ignore it. Ranting about rants just leads to more
rants.
>
> That's like someone trying to show me the "ultimate defensive fighting
> maneuver" and saying, "attack me! No.. you can't attack me that way!
> Attack me with your LEFT hand.. yeah.. BAM! I win again!!"
>
>
> > (BTW, I submitted my source-coded version of Robert C. Martin's
> > payroll example here a few weeks ago in an attempt to spark debate on
> > a semi-realistic example.)
>
> Like I said... that has zero to do with THIS thread. Thank you. Oh
> right, you're trying to stand on the nearly off topic soap box AND
> control the parameters of the argument at the same time. ;^)
>
> Jordan
S Perryman
>>Personally, I don't think these kinds of puzzles are very useful for
>>comparing the real-world utility of paradigms.
> What is not "real world" about solving variance problems? There are
> plenty of business uses here. Oh wait, you must mean "real world", as
> in "Topmind's world".
Actually, this puzzle is very "real world" .
And here is a USA-specific example :
In IEEE Spectrum last year (I don't recall if it was the issue focussing on
counter-terrorism or just a regular article - I think it was the former) ,
there was an article regarding a company who had a system that was building
an info base of facts akin to the puzzle, that could then establish
relationships between entities in the info base.
This system was being used for intelligence/counter-terrorism purposes (the
system also had a good feature in that it was able to 'anonymise' the info
base so that the query/execution engine operated without revealing
human-valued data - names, addresses, acquaintances, bank accounts etc) .
Regarding best implementation, declarative systems (logic programming etc)
are usually best-suited for solving problems akin to the puzzle
[ Complaints about topmind always attempting to change the goal-posts
regarding any problem domain other than the ill-defined "biz app" ,
snipped but read and acknowledged. ]
Regards,
Steven Perryman
Daniel T.
I think it is important to remember why Simula was developed in the
first place. If your problem domain does not involve doing simulations,
then OO may very well not be appropriate.
Jordan Marr
> I live in a bubble somehow, but perhaps you do also. If I can be
> mislead, so can you. You are not the center of the universe; we each
> only have one lifetime to live.
MOST of the business apps I have coded have been pretty straight
forward CRUD style apps, current project included. I'm not cocky
enough to say I've mastered those, but I feel pretty confident in
them.
But I have also worked on some reallllly cool apps, and this example
could easily factor in to one of the cooler projects I aspire to work
on in my career. You know, the "fun stuff" that you still get paid
for. (Actually, I find all programming fun, even the CRUD stuff is
entertaining to me).
It seems like your mission on here is to fix something that's not
broken. Most programmers already know how to program CRUD business
apps, so you're beating a dead horse.
So let's go ahead and add "apps that deal with variance" to your ever
growing list of apps that PR can't deal with well.
What is that now? Variance apps, drivers, reusable frameworks, CAD
based, and ANYTHING other that CRUD "business apps".
Nice. Where do I sign up?!
Jordan
Jordan Marr
> animal, shape, or device driver app, use OO.
I don't write drivers, but writing reusable frameworks is basically
the same, and I do write those all the time. The idea is, instead of
solving a problem once in a very app specific way, you abstract and
encapsulate the solution to the problem in a OO way that is reusable
for ANY problem (especially including business domain problems!).
In fact, to solve this "unrealistic" problem, I reused my very own OO
<gasp!> reusable <gasp!> business framework<gasp!>, and I also created
a new reusable OO class that I will most certainly use at some point
in the future on a... you guessed it... business app!
Yeah, that's right, because the definition of "business app" really ==
"any project that is important enough to be funded". So I'm coming
out of this exercise ahead and more OO for the wear.
Jordan
Jordan Marr
> > plenty of business uses here. Oh wait, you must mean "real world", as
> > in "Topmind's world".
>
> Actually, this puzzle is very "real world" .
> And here is a USA-specific example :
It really is; but you have to be an abstract thinker to be able to
look at a very specific problem (ex: "whose fish"), and be able to
abstract it into a generic variance problem framework. The ability to
solve this example is the ability to solve many "paying" i.e. business
problems. In your example we're getting into US government level
problems. Hooketh me up!!
topmind
Jordan Marr wrote:
> > It is *not* representative of the apps and issues I have faced. Maybe
> > I live in a bubble somehow, but perhaps you do also. If I can be
> > mislead, so can you. You are not the center of the universe; we each
> > only have one lifetime to live.
>
> MOST of the business apps I have coded have been pretty straight
> forward CRUD style apps, current project included. I'm not cocky
> enough to say I've mastered those, but I feel pretty confident in
> them.
CRUD apps are often not trivial because they are often marred in tons
of funny little business rules. I often consider business modeling the
modeling of the current manager's/owner's/customer's personality and
whims rather than a striving for a "one true" math or science.
Sometimes techies will indeed say, "this is what the framework gives
you and you will live with it", which simplifies developement (at
least initially), but users are not happy with such.
I will agree they were simpler in the pre-web days because desktop
GUI's were easier and richer than the web equivalent (although harder
to deploy), but funny little biz rules and exceptions to the rules
still complicated things.
If it was easy, it would all be automated by now. I find most CRUD
abstractions fall prey to the 80/20 rule where the abstraction handles
80% of the cases, but 20% muck it up and need nitty gritty diddling.
> But I have also worked on some reallllly cool apps, and this example
> could easily factor in to one of the cooler projects I aspire to work
> on in my career. You know, the "fun stuff" that you still get paid
> for. (Actually, I find all programming fun, even the CRUD stuff is
> entertaining to me).
>
> It seems like your mission on here is to fix something that's not
> broken. Most programmers already know how to program CRUD business
> apps, so you're beating a dead horse.
Many also do a bad job on them. They may "run", but maintainability is
out the door.
>
> So let's go ahead and add "apps that deal with variance" to your ever
> growing list of apps that PR can't deal with well.
Reframe your example in terms of a fairly common business need/example
instead of classroom back-page stuff, and maybe I will comment on it.
Otherwise, failing to comment on it does not necessarily make PR flunk
it. If it is a common biz need like you imply, then such a reframing
should be fairly easy for you. Why produce shapes and animals when you
can do invoices, orders, products, etc. to illustrate the same
thing???
> What is that now? Variance apps, drivers, reusable frameworks, CAD
> based, and ANYTHING other that CRUD "business apps".
Let's see your reusable CRUD framework that bends to user requirements
well. Dispite the prevalence of CRUD, nobody has mastered such a
framework. The most effective, or at least popular, solutions seemed
to be things like Visual Basic and PowerBuilder that let one create
crap fast. Businesses figure if the end result is always messy, you
might as well make creating that mess a quicker process. If you have
to go to the dentist for a root-canal, might as well take the short
road.
>
> Nice. Where do I sign up?!
>
> Jordan
-T-
AndyW
wrote:
>
>Jordan Marr wrote:
>> > Personally, I don't think these kinds of puzzles are very useful for
>> > comparing the real-world utility of paradigms.
>>
>> What is not "real world" about solving variance problems? There are
>> plenty of business uses here. Oh wait, you must mean "real world", as
>> in "Topmind's world".
>
>It is *not* representative of the apps and issues I have faced. Maybe
>I live in a bubble somehow, but perhaps you do also. If I can be
>mislead, so can you. You are not the center of the universe; we each
>only have one lifetime to live.
>
Sorry I managed to delete the first few posts in the thread, so this
post is really directed at the first one as well as this one.
In my mind there are two issues that I have problems with. The first
one is where someone is trying to convert a 'logic' problem to an OO
one. I have an issue with this because to me, logic is not
condusive to facilitating object oriented conceptualising which as far
as I am concerned requires a great deal of fuzzyness.
To me, logic will always equate to procedural thinking (and should not
be equated to being a bad thing - it is, in its place a good thing).
But I will say that to me an object may contain logic parts and in
that regard one could also say that an object may contain procedural
parts, but that does not mean to me that objects are always logical
entities.
I have noticed over the years that some people require contextual
detail when doing OO and some people don't. I wonder if that culture
defines whether someone does OO following rigerous methods and
techniques (OO Principles) or if they just go with the flow so to
speak. i.e. does the 'context' of ones culture (whether they are
naturally high or low context people) affect the way people approach
OO.
The second issue more directly relates the problem being solved to the
solution provided. That is, to me this type of problem (logic
problems) are usually solved by some form of mathematical equation.
I think that in software development I have always referred to these
types of equations as 'algorithms' which are usually I think
implemented in a single high level function call (often to a bunch of
smaller detailed function calls). Given this, I cant say how one
could claim to have developed an object oriented solution when
implementing a single algorithm when the whole meta structure of
executing an algorigm is nothing more (to me) than the procedural
implementation of a logical set of steps (calculations). I think
one could say they have used object oriented techniques to solve the
problem (such as encapsulation, polymorphism and abstraction), but I
dont think one should suggest that the result is in its nature object
oriented, as I do not see an algorithm as being 'oriented towards
objects' (its more oriented towards being a service) since it can be
executed as a function/method call which to me at best perhaps is
merely part of an object.
----------------
AndyW,
Mercenary Software Developer
topmind
Jordan Marr wrote:
> > Fine, if you are the one in a hundred who are actually writing an
> > animal, shape, or device driver app, use OO.
>
> I don't write drivers, but writing reusable frameworks is basically
> the same, and I do write those all the time. The idea is, instead of
> solving a problem once in a very app specific way, you abstract and
> encapsulate the solution to the problem in a OO way that is reusable
> for ANY problem (especially including business domain problems!).
"Reuse" has seemed to fall out of favor as a top claim of OOP.
("Making programs easier to change" seems to be the top claim by my
observation in many debates, closely followed by "models human
thinking better"[1].) Even OO proponents generally don't claim reuse
improvement much anymore. If you wish to show OO being better reuse,
be my guest.
>
> In fact, to solve this "unrealistic" problem, I reused my very own OO
> <gasp!> reusable <gasp!> business framework<gasp!>, and I also created
> a new reusable OO class that I will most certainly use at some point
> in the future on a... you guessed it... business app!
Sounds great. Now show the code and show how it kicks P/R's butt. I
finished my example with runnable source code (R. Martin's payroll).
Your turn. Verbal claims don't cut it here.
>
> Yeah, that's right, because the definition of "business app" really ==
> "any project that is important enough to be funded". So I'm coming
> out of this exercise ahead and more OO for the wear.
>
Not usable info.
>
> Jordan
>
[1] This is perhaps true on a relative scale. OO may indeed model some
people's head better, but you can't assume everybody's head is the
same. This issue is one of the reasons I chose "topmind" as my handle:
because my head best fits Table Oriented Programming.
-T-
topmind
If the industry agreed that OO generally only shines for physical
simulations and not push it into nearly all domains, then I would not
be ranting against it. You may feel it is meant for mostly physical
niches, but that is not the consensus among OO proponents
-T-
Jordan Marr
> > the same, and I do write those all the time. The idea is, instead of
> > solving a problem once in a very app specific way, you abstract and
> > encapsulate the solution to the problem in a OO way that is reusable
> > for ANY problem (especially including business domain problems!).
>
> "Reuse" has seemed to fall out of favor as a top claim of OOP.
> ("Making programs easier to change" seems to be the top claim by my
> observation in many debates, closely followed by "models human
> thinking better"[1].) Even OO proponents generally don't claim reuse
> improvement much anymore. If you wish to show OO being better reuse,
> be my guest.
These days every program consists of two or three parts:
Language Framework: the framework of preexisting *reusable* classes
provided by the language developer. This framework is OO and
excercises the *reuse* that I am touting.
User Frameworks: frameworks created by users. These can be pre-
existing frameworks that were created before the project that are
generic and abstract enough to be reused to solve the same kinds of
problems continually. An example would be a business framework that
encapsulates dealing with business validation rules. In my mind this
also includes the business domain layer, which can serve multiple apps
(but usually only serves one).
The Application itself: This is where the procedural programming
comes into play. This layer calls upon all the framework objects it
needs to solve the needs of the application at hand.
When I start an app I first check to see if the tools I need to solve
the problem already exist in the language framework. If I need more
tools, my next stop is to look in the public domain arena for well
abstracted classes that are generic enough to be resued in my app.
Finally, if none exist, I create my own reusable object.
As an example, say my app requires that I pick a random number between
1 and 10,000. First I would look to the language framework for a
random number generator (which .net has one already). An object
should have one purpose, and .net's random number generator does just
that.. this allows it to be used in many projects.
If a random generator did not exist, I would create my own reusable
random generator class, and then plug it into my app.
Now, what many non OO people would do is to write the random number
generator algorithm directly inside their application layer
somewhere... perhaps they parameterize it and put it in a method
somewhere, or even worse, maybe they integrate the algorithm right in
with the button even where it is required.
> Sounds great. Now show the code and show how it kicks P/R's butt. I
> finished my example with runnable source code (R. Martin's payroll).
> Your turn. Verbal claims don't cut it here.
OK, but I don't really have anywhere to post it unless I simply post
the source here.
Jordan
Jordan Marr
> of funny little business rules. I often consider business modeling the
> modeling of the current manager's/owner's/customer's personality and
> whims rather than a striving for a "one true" math or science.
>
> Sometimes techies will indeed say, "this is what the framework gives
> you and you will live with it", which simplifies developement (at
> least initially), but users are not happy with such.
Artificial constraints (technology or whatever) should never define
the results. I believe the results should be stated ideally, and then
everyone should strive to satisfy that goal.
A good app meets every last one of the client's needs as stated in the
specs, regardless of whether its P/R or OO.
> I will agree they were simpler in the pre-web days because desktop
> GUI's were easier and richer than the web equivalent (although harder
> to deploy), but funny little biz rules and exceptions to the rules
> still complicated things.
Indeed.
> If it was easy, it would all be automated by now. I find most CRUD
> abstractions fall prey to the 80/20 rule where the abstraction handles
> 80% of the cases, but 20% muck it up and need nitty gritty diddling.
I agree.
> > It seems like your mission on here is to fix something that's not
> > broken. Most programmers already know how to program CRUD business
> > apps, so you're beating a dead horse.
>
> Many also do a bad job on them. They may "run", but maintainability is
> out the door.
I agree, many do a horrible job. I always strive for maintainability
while designing and coding a problem.. The temptation is always there
to take a shortcut and simply solve the problem at the expense of
future maintainability. But a little bit of forethought can really do
a lot for the future of an app!
> Reframe your example in terms of a fairly common business need/example
> instead of classroom back-page stuff, and maybe I will comment on it.
> Otherwise, failing to comment on it does not necessarily make PR flunk
> it. If it is a common biz need like you imply, then such a reframing
> should be fairly easy for you. Why produce shapes and animals when you
> can do invoices, orders, products, etc. to illustrate the same
> thing???
Once again, you want me to conform to your conditions, and then,
MAYBE, you will grace me with a comment! lol. That is rich!
No, reframing that question would NOT be fairly easy, and I can see it
would be a waste of my time, as you would probably just dismiss it for
one reason or another.
While I will not re create a perfectly good problem, I will suggest a
possible variation of the problem and let your imagination do the
rest:
Consider the human genome project. Goals:
- identify all the approximately 20,000-25,000 genes in human DNA
- determine the sequences of the 3 billion chemical base pairs that
make up human DNA
- store this information in databases
- improve tools for data analysis
Notice they said "store" this information in a database. hehe.
This problem is very similar to "whose fish", and you can't see why,
I'm not telling you! ;^)
> Let's see your reusable CRUD framework that bends to user requirements
> well. Dispite the prevalence of CRUD, nobody has mastered such a
> framework. The most effective, or at least popular, solutions seemed
> to be things like Visual Basic and PowerBuilder that let one create
> crap fast. Businesses figure if the end result is always messy, you
> might as well make creating that mess a quicker process. If you have
> to go to the dentist for a root-canal, might as well take the short
> road.
My apps bend just fine to user requirements. That's why I have so
much time to debate with you. :)
Jordan
topmind
What is wrong with putting such in a function? An entire class is
overkill. Also, as far as reuse, I lean toward mix-and-match "helpers
instead of wrappers" because one-size-fits-all genericy is not a
realizable goal I've found out the hard way. More on this:
http://c2.com/cgi/wiki?HelpersInsteadOfWrappers
>
> > Sounds great. Now show the code and show how it kicks P/R's butt. I
> > finished my example with runnable source code (R. Martin's payroll).
> > Your turn. Verbal claims don't cut it here.
>
> OK, but I don't really have anywhere to post it unless I simply post
> the source here.
It's fairly easy to have your own web-log these days (if you don't
mind annoying ads).
>
> Jordan
-T-
Jordan Marr
> one is where someone is trying to convert a 'logic' problem to an OO
> one. I have an issue with this because to me, logic is not
> condusive to facilitating object oriented conceptualising which as far
> as I am concerned requires a great deal of fuzzyness.
>
> To me, logic will always equate to procedural thinking (and should not
> be equated to being a bad thing - it is, in its place a good thing).
> But I will say that to me an object may contain logic parts and in
> that regard one could also say that an object may contain procedural
> parts, but that does not mean to me that objects are always logical
> entities.
Andy,
In fact, all software applications have logic. They all have user
input, some sort of logic processing on the input, and finally some
sort of output, to the screen, printer, network, db, or somewhere. An
OO software without any logic would simple be a abstracted model of
the problem domain that didn't do anything!
> I have noticed over the years that some people require contextual
> detail when doing OO and some people don't. I wonder if that culture
> defines whether someone does OO following rigerous methods and
> techniques (OO Principles) or if they just go with the flow so to
> speak. i.e. does the 'context' of ones culture (whether they are
> naturally high or low context people) affect the way people approach
> OO.
I think that people who are not good at abstracting problems will
definitely be more productive writing strictly procedural code. Of
course they will have to master OO techniques only enough to
understand how to utilize the OO framework tools that are already in
place to help them. Those reusable framework tools are of course
created by abstract thinkers who intended to create a generic tool to
solve many peoples' problems, instead of the immediate issue at hand.
> The second issue more directly relates the problem being solved to the
> solution provided. That is, to me this type of problem (logic
> problems) are usually solved by some form of mathematical equation.
> I think that in software development I have always referred to these
> types of equations as 'algorithms' which are usually I think
> implemented in a single high level function call (often to a bunch of
> smaller detailed function calls). Given this, I cant say how one
> could claim to have developed an object oriented solution when
> implementing a single algorithm when the whole meta structure of
> executing an algorigm is nothing more (to me) than the procedural
> implementation of a logical set of steps (calculations).
It is all in how you percieve the problem domain and how you choose to
model it.
> I think
> one could say they have used object oriented techniques to solve the
> problem (such as encapsulation, polymorphism and abstraction), but I
> dont think one should suggest that the result is in its nature object
> oriented, as I do not see an algorithm as being 'oriented towards
> objects' (its more oriented towards being a service) since it can be
> executed as a function/method call which to me at best perhaps is
> merely part of an object.
Modelling the problem domain into software objects is IMO an OO
solution.
Jordan
Jordan Marr
> > first place. If your problem domain does not involve doing simulations,
> > then OO may very well not be appropriate.
>
> If the industry agreed that OO generally only shines for physical
> simulations and not push it into nearly all domains, then I would not
> be ranting against it. You may feel it is meant for mostly physical
> niches, but that is not the consensus among OO proponents
All problems model the physical domain and can be modelled in an OO
fashion.
Jordan
topmind
Jordan Marr wrote:
> > CRUD apps are often not trivial because they are often marred in tons
> > of funny little business rules. I often consider business modeling the
> > modeling of the current manager's/owner's/customer's personality and
> > whims rather than a striving for a "one true" math or science.
> >
> > Sometimes techies will indeed say, "this is what the framework gives
> > you and you will live with it", which simplifies developement (at
> > least initially), but users are not happy with such.
>
> Artificial constraints (technology or whatever) should never define
> the results. I believe the results should be stated ideally, and then
> everyone should strive to satisfy that goal.
I have to dissagree. It is not economical to supply all features as
requested. Compromises should be made and fitting the existing
technology should probably be part of it. I've seen time/money wasted
up the wazoo to cater to dumb whims of prima dona executives.
>
> A good app meets every last one of the client's needs as stated in the
> specs, regardless of whether its P/R or OO.
Spec-based development is sort of becomming a thing of the past
because if you have a clear spec, it is offshored. Thus, onshore
projects tend to be those that are more interactive (give-and-take) in
nature.
>
> > I will agree they were simpler in the pre-web days because desktop
> > GUI's were easier and richer than the web equivalent (although harder
> > to deploy), but funny little biz rules and exceptions to the rules
> > still complicated things.
>
> Indeed.
>
> > If it was easy, it would all be automated by now. I find most CRUD
> > abstractions fall prey to the 80/20 rule where the abstraction handles
> > 80% of the cases, but 20% muck it up and need nitty gritty diddling.
>
> I agree.
>
> > > It seems like your mission on here is to fix something that's not
> > > broken. Most programmers already know how to program CRUD business
> > > apps, so you're beating a dead horse.
> >
> > Many also do a bad job on them. They may "run", but maintainability is
> > out the door.
>
> I agree, many do a horrible job. I always strive for maintainability
> while designing and coding a problem.. The temptation is always there
> to take a shortcut and simply solve the problem at the expense of
> future maintainability. But a little bit of forethought can really do
> a lot for the future of an app!
Its a matter of balance. There are extremists on both sides, such as
XP'ers who only impliment here-and-now requirements, and on the other
those who over-engineer the thing.
>
> > Reframe your example in terms of a fairly common business need/example
> > instead of classroom back-page stuff, and maybe I will comment on it.
> > Otherwise, failing to comment on it does not necessarily make PR flunk
> > it. If it is a common biz need like you imply, then such a reframing
> > should be fairly easy for you. Why produce shapes and animals when you
> > can do invoices, orders, products, etc. to illustrate the same
> > thing???
>
> Once again, you want me to conform to your conditions, and then,
> MAYBE, you will grace me with a comment! lol. That is rich!
I am only stating the conditions on which I will respond. If you don't
like them, then simply ignore them. Its that simple.
>
> No, reframing that question would NOT be fairly easy, and I can see it
> would be a waste of my time, as you would probably just dismiss it for
> one reason or another.
As long as it is a good reason.
>
> While I will not re create a perfectly good problem, I will suggest a
> possible variation of the problem and let your imagination do the
> rest:
>
> Consider the human genome project. Goals:
> - identify all the approximately 20,000-25,000 genes in human DNA
> - determine the sequences of the 3 billion chemical base pairs that
> make up human DNA
> - store this information in databases
> - improve tools for data analysis
>
> Notice they said "store" this information in a database. hehe.
>
> This problem is very similar to "whose fish", and you can't see why,
> I'm not telling you! ;^)
But that's a very specialized domain. You would spend most of your
time educating the reader about biology and DNA. How are we going to
evaluate the frequency of suggested change scenarios if we are not
biologists? For that reason, it would probably not make a very good
example.
>
> > Let's see your reusable CRUD framework that bends to user requirements
> > well. Dispite the prevalence of CRUD, nobody has mastered such a
> > framework. The most effective, or at least popular, solutions seemed
> > to be things like Visual Basic and PowerBuilder that let one create
> > crap fast. Businesses figure if the end result is always messy, you
> > might as well make creating that mess a quicker process. If you have
> > to go to the dentist for a root-canal, might as well take the short
> > road.
>
> My apps bend just fine to user requirements. That's why I have so
> much time to debate with you. :)
Yes, but that is still anecdotal evidence. Everybody claims their
favorite tool/paradigm is better and faster and cheaper, etc. We need
a way to evaluate such common claims in order to filter the hop from
the hype.
>
>
> Jordan
-T-
Jordan Marr
> > generator algorithm directly inside their application layer
> > somewhere... perhaps they parameterize it and put it in a method
> > somewhere, or even worse, maybe they integrate the algorithm right in
> > with the button even where it is required.
>
> What is wrong with putting such in a function?
There is nothing "wrong" with parameterizing it and putting it in a
function inside the application layer, and in fact, many programmers
do just that.
But it does defeat the ability to easily reuse the existing code in
another application.
> An entire class is overkill.
I do not share your opinion here at all.
> Also, as far as reuse, I lean toward mix-and-match "helpers
> instead of wrappers" because one-size-fits-all genericy is not a
> realizable goal I've found out the hard way. More on this:
I do not advocate encapsulating everything into reusable objects all
the time. It's easy enough to go back and refactor code in this way
if needed.
I'm simply pointing out that intra-app code reuse is an OO advantage
that I often utilize.
There are some things that do not lend themselves to this kind of
reuse. Random number generation, OTOH, is a pretty generic concept.
The reusable object does not need any application specific code in
it. A well designed reusable framework will have virtual methods that
allow someone to import the object and still easily create a
descendent object with any application specific modifications
needed.
Jordan
topmind
They do? Stocks, debt, crime laws, software licenses, and sales credit
are not physical. Yes, we can model them with paper and clerks with
bins, but equivalency is not the same as being.
> and can be modelled in an OO
> fashion
I think it is understood we are talking about being "geared toward"
rather than merely running. Otherwise, it is just a declaration of
Turing Equivalency, which doesn't tell us anything useful. We already
know one can write a Smalltalk interpreter in Fortran and visa versa.
When one talks about physical simulation, generally they mean things
like modeling tugboat movement and loading docks.
>
> Jordan
-T-
topmind
> > > Now, what many non OO people would do is to write the random number
> > > generator algorithm directly inside their application layer
> > > somewhere... perhaps they parameterize it and put it in a method
> > > somewhere, or even worse, maybe they integrate the algorithm right in
> > > with the button even where it is required.
>
> > What is wrong with putting such in a function?
>
> There is nothing "wrong" with parameterizing it and putting it in a
> function inside the application layer, and in fact, many programmers
> do just that.
>
> But it does defeat the ability to easily reuse the existing code in
> another application.
How so? I don't know what difficulties or behavior you are mentally
comparing.
>
> > An entire class is overkill.
>
> I do not share your opinion here at all.
>
> > Also, as far as reuse, I lean toward mix-and-match "helpers
> > instead of wrappers" because one-size-fits-all genericy is not a
> > realizable goal I've found out the hard way. More on this:
>
> I do not advocate encapsulating everything into reusable objects all
> the time. It's easy enough to go back and refactor code in this way
> if needed.
>
> I'm simply pointing out that intra-app code reuse is an OO advantage
> that I often utilize.
>
> There are some things that do not lend themselves to this kind of
> reuse. Random number generation, OTOH, is a pretty generic concept.
> The reusable object does not need any application specific code in
> it. A well designed reusable framework will have virtual methods that
> allow someone to import the object and still easily create a
> descendent object with any application specific modifications
> needed.
>
> Jordan
-T-
Jordan Marr
> > > simulations and not push it into nearly all domains, then I would not
> > > be ranting against it. You may feel it is meant for mostly physical
> > > niches, but that is not the consensus among OO proponents
>
> > All problems model the physical domain
>
> They do? Stocks, debt, crime laws, software licenses, and sales credit
> are not physical. Yes, we can model them with paper and clerks with
> bins, but equivalency is not the same as being.
You can still model anything, physical or conceptual, in OO software.
Jordan Marr
>
> - Show quoted text -
At least with parameterized methods you can copy and paste the source
code itself into another project. But most frameworks are precompiled
into their own library that can be easily distributed w/out the source
code.
Jordan
Daniel T.
> Daniel T. wrote:
> > I think it is important to remember why Simula was developed in the
> > first place. If your problem domain does not involve doing simulations,
> > then OO may very well not be appropriate.
>
> If the industry agreed that OO generally only shines for physical
> simulations and not push it into nearly all domains, then I would not
> be ranting against it.
Wait, why the restriction of "physical" simulations? Simula and other OO
languages are excellent at modeling simulations, "physical" or otherwise.
AndyW
>> In my mind there are two issues that I have problems with. The first
>> one is where someone is trying to convert a 'logic' problem to an OO
>> one. I have an issue with this because to me, logic is not
>> condusive to facilitating object oriented conceptualising which as far
>> as I am concerned requires a great deal of fuzzyness.
>>
>> To me, logic will always equate to procedural thinking (and should not
>> be equated to being a bad thing - it is, in its place a good thing).
>> But I will say that to me an object may contain logic parts and in
>> that regard one could also say that an object may contain procedural
>> parts, but that does not mean to me that objects are always logical
>> entities.
>
>Andy,
>In fact, all software applications have logic. They all have user
>input, some sort of logic processing on the input, and finally some
>sort of output, to the screen, printer, network, db, or somewhere. An
>OO software without any logic would simple be a abstracted model of
>the problem domain that didn't do anything!
Sorry, I think you may be missing my point. Back several decades ago
(before the OO craze), one wrote software using logic techniques taken
from mathematics. The perception then was that one needed to be good
at math to be able to write software as math taught the disciple of
using logical thought process. Thus, many of the programming
techniques were taken from math.
Given that, programming theory of the time stated that good code
consisted of a problem broken down into a clearly defined set of steps
set out in 'logical' order. This is the definition of logic that I am
using.
Later, in the 80s when the modern OO craze really started to take off,
there was a suggestion that the best OO practitioners seemed to not be
good at math. The hypothesis was that perhaps the more involved one
was in logic the harder it became to 'get' or understand the
principles of OO. That is, it was suggested that logical people
cannot abstract as well as those with no logic training.
topmind
Again, Turing Equivalency does not tell us anything useful. We can
also write it all in Assembler language or BrainF*ck language.
-T-
topmind
I am not sure what your point is. There appears to be context
confusion.
-T-
topmind
That depends on how the *language* is implemented. If somebody
impliments functions in a stupid or limiting way, that is not a pock
on all of P/R. I've used languages where functions could be compiled
into P-code and referenced in that form. C is NOT the pinnical of P/R.
>
>
> Jordan
-T-
topmind
This sounds like yet another "you hate OO because you don't get OO"
insult. To me, OO is a *lower* level of abstraction than p/r because
it uses objects pointing to objects instead of relational rigor to
define most of the relationships between things. OO is like the Go To
of modeling: a wad of pointers. Good p/r also tends to meta-tize
things that OO'ers like to hard-wire into code. I've demonstrated this
already with my Payroll code example versus R. Martin's. How is hard-
wiring a higher abstraction? OO has no definable, dissectable,
analyzable rigor. If there is a genius to it, nobody has been able to
isolate it in a western-reductionalist style, instead sounding like a
bad episode of Kung fOO. (I am not saying traditional Eastern
thinking is necessarily bad, just that it is harder to dissect and
test in a reproducable, measurable, and scientific way. Maybe fuzzy
Zen thinking works better, but it eludes dissection.)
> Of
> course they will have to master OO techniques only enough to
> understand how to utilize the OO framework tools that are already in
> place to help them. Those reusable framework tools are of course
> created by abstract thinkers who intended to create a generic tool to
> solve many peoples' problems, instead of the immediate issue at hand.
You still haven't demonstrated with code that OO automatically leads
to more reuse or better biz frameworks.
>
> > The second issue more directly relates the problem being solved to the
> > solution provided. That is, to me this type of problem (logic
> > problems) are usually solved by some form of mathematical equation.
> > I think that in software development I have always referred to these
> > types of equations as 'algorithms' which are usually I think
> > implemented in a single high level function call (often to a bunch of
> > smaller detailed function calls). Given this, I cant say how one
> > could claim to have developed an object oriented solution when
> > implementing a single algorithm when the whole meta structure of
> > executing an algorigm is nothing more (to me) than the procedural
> > implementation of a logical set of steps (calculations).
>
> It is all in how you percieve the problem domain and how you choose to
> model it.
So we *are* modeling our view of the world instead of modeling the
world? That can lead to a lot of bias because people will give a
better score to techniques that better model their internal world, not
necessarily those that are objectively better. I am sure Seung-Hui
Cho's mental model is different than Mary Poppin's.
>
> > I think
> > one could say they have used object oriented techniques to solve the
> > problem (such as encapsulation, polymorphism and abstraction), but I
> > dont think one should suggest that the result is in its nature object
> > oriented, as I do not see an algorithm as being 'oriented towards
> > objects' (its more oriented towards being a service) since it can be
> > executed as a function/method call which to me at best perhaps is
> > merely part of an object.
>
> Modelling the problem domain into software objects is IMO an OO
> solution.
"IMO", that's the problem. You have to SHOW, not TELL. You have to
show how OO better fits the actual real world. And what about things
based on intellectual property or capital, like money? They are not
physical. Yes, you can model money transactions as a bunch of
mechanical hands moving coins around, but most would agree that is a
clumsy way to go about it. Sometimes the real world is F'd such that
we *don't* want to recreate it. Few miss library card catalogs, and
you would get fired if you emulated them if charged with building an
online book search. The purpose of biz computers is to make business
more efficient, not necessarily copy physical versions of the
activities.
>
> Jordan
-T-
Daniel T.
Simulation: the imitative representation of the functioning of one
system or process by means of the functioning of another. For example
when a computer program simulates the processes employed by a book
keeper, bank teller, or stock trader...
topmind
Yes, but in practice we don't do it that way. The manual processes are
designed to reduce human errors, not necessarily geared toward
efficiency. One often changes the way the process is done when
computerizing it. Even double-entry bookkeeping is unnecessary with
modern ACID transactions. (We had a fat fight on this several months
ago.)
-T-
Daniel T.
It is still a simulation. Simulations are not expected or required to
perform the process the exact same way, as long as the results are
equivalent.
Jordan Marr
> insult. To me, OO is a *lower* level of abstraction than p/r because
> it uses objects pointing to objects instead of relational rigor to
> define most of the relationships between things. OO is like the Go To
> of modeling: a wad of pointers. Good p/r also tends to meta-tize
> things that OO'ers like to hard-wire into code. I've demonstrated this
> already with my Payroll code example versus R. Martin's. How is hard-
> wiring a higher abstraction? OO has no definable, dissectable,
> analyzable rigor. If there is a genius to it, nobody has been able to
> isolate it in a western-reductionalist style, instead sounding like a
> bad episode of Kung fOO. (I am not saying traditional Eastern
> thinking is necessarily bad, just that it is harder to dissect and
> test in a reproducable, measurable, and scientific way. Maybe fuzzy
> Zen thinking works better, but it eludes dissection.)
This thread is about the Whose Fish riddle, and you're going off on
your typical BS. As usual, because it's the only thing you have to
say. I don't care to argue the same points you've been arguing on
every other thread on this NG. And now this thread looks just like
any other, regardless of its potential.
> You still haven't demonstrated with code that OO automatically leads
> to more reuse or better biz frameworks.
Ugh, Whose Fish would have been so much more interesting than business
apps, which you are stuck on.
Have a good look at Lhotka's CSLA reusable business framework.
> > It is all in how you percieve the problem domain and how you choose to
> > model it.
>
> So we *are* modeling our view of the world instead of modeling the
> world? That can lead to a lot of bias because people will give a
> better score to techniques that better model their internal world, not
> necessarily those that are objectively better.
Yes, the author obviously models their own view of the world. So?
And some models will function better than others.
> "IMO", that's the problem. You have to SHOW, not TELL.
Right. I don't have to do jack. Pearls before swine as far as I'm
concerned.
If I replied to all of your replies I envision this thread never
ending. You have your mind made up already. If I posted any examples
you would go into them with the intent to rip it apart to find
problems because your mind is already made up. It is a waste of
time.
Now, if this was actually a forum of OO enthusiasts, I can see posting
the code of this puzzle for everyone to enjoy. However, in the
current context, I don't think it is.
On a slightly different topic, I think most people are actually more
middle ground than you imagine them to be. You say OO has taken over
the industry, but every job I've ever worked was a bunch of datasets
and PR code. It's just easier to do.
The projects that do incorporate OO still use a relational DB as
opposed to loading the entire DB into objects. I just don't see the
industry as biased toward pure OO as you seem to say it is. Most
people are willing to incorporate the best of both worlds, instead of
your world of pure case statements.
> You have to
> show how OO better fits the actual real world. And what about things
> based on intellectual property or capital, like money? They are not
> physical. Yes, you can model money transactions as a bunch of
> mechanical hands moving coins around, but most would agree that is a
> clumsy way to go about it. Sometimes the real world is F'd such that
> we *don't* want to recreate it. Few miss library card catalogs, and
> you would get fired if you emulated them if charged with building an
> online book search. The purpose of biz computers is to make business
> more efficient, not necessarily copy physical versions of the
> activities.
I don't think you have to model it the same as reality... IOW, you
could come up with a better model and write it that way.
Jordan
Jordan Marr
>
> - Show quoted text -
So you're saying that the more mathematically oriented people could
probably abstract the problem down to a purer, leaner form in their
code, without needing the extra overhead of modeling objects around
the problem domain?
jordan
topmind
Jordan Marr wrote:
> > This sounds like yet another "you hate OO because you don't get OO"
> > insult. To me, OO is a *lower* level of abstraction than p/r because
> > it uses objects pointing to objects instead of relational rigor to
> > define most of the relationships between things. OO is like the Go To
> > of modeling: a wad of pointers. Good p/r also tends to meta-tize
> > things that OO'ers like to hard-wire into code. I've demonstrated this
> > already with my Payroll code example versus R. Martin's. How is hard-
> > wiring a higher abstraction? OO has no definable, dissectable,
> > analyzable rigor. If there is a genius to it, nobody has been able to
> > isolate it in a western-reductionalist style, instead sounding like a
> > bad episode of Kung fOO. (I am not saying traditional Eastern
> > thinking is necessarily bad, just that it is harder to dissect and
> > test in a reproducable, measurable, and scientific way. Maybe fuzzy
> > Zen thinking works better, but it eludes dissection.)
>
> This thread is about the Whose Fish riddle, and you're going off on
> your typical BS. As usual, because it's the only thing you have to
> say. I don't care to argue the same points you've been arguing on
> every other thread on this NG. And now this thread looks just like
> any other, regardless of its potential.
If your justification for the example looks like any other reply then
of course my answer will also. It is not my fault that all roads lead
to Rome.
>
> > You still haven't demonstrated with code that OO automatically leads
> > to more reuse or better biz frameworks.
>
> Ugh, Whose Fish would have been so much more interesting than business
> apps, which you are stuck on.
Perhaps. But practicality should trump mental masturbation unless we
are entering "American Paradigm Idol".
> Have a good look at Lhotka's CSLA reusable business framework.
Awk! He's selling a book. At least the Payroll example is free. He
also mentioned "distributed environment". This usually means a RDBMS
hater, so my yellow flag is up. I already spent gobs on OO books
recommended by others.
>
> > > It is all in how you percieve the problem domain and how you choose to
> > > model it.
> >
> > So we *are* modeling our view of the world instead of modeling the
> > world? That can lead to a lot of bias because people will give a
> > better score to techniques that better model their internal world, not
> > necessarily those that are objectively better.
>
> Yes, the author obviously models their own view of the world. So?
> And some models will function better than others.
Beyond "correct output", "better" is probably also in the eye of the
beholder. My wife's method of organizing (wooden) desk doodads is
different than mine. Is one or the other "wrong"?
>
> > "IMO", that's the problem. You have to SHOW, not TELL.
>
> Right. I don't have to do jack. Pearls before swine as far as I'm
> concerned.
> If I replied to all of your replies I envision this thread never
> ending. You have your mind made up already.
It is not. If you show me OOP kicking P/R's bootie in a clear
objective way, and I'll reconsider.
> If I posted any examples
> you would go into them with the intent to rip it apart to find
> problems because your mind is already made up. It is a waste of
> time.
>
> Now, if this was actually a forum of OO enthusiasts, I can see posting
> the code of this puzzle for everyone to enjoy. However, in the
> current context, I don't think it is.
>
> On a slightly different topic, I think most people are actually more
> middle ground than you imagine them to be. You say OO has taken over
> the industry, but every job I've ever worked was a bunch of datasets
> and PR code. It's just easier to do.
In practice they are indeed middle ground. However, OO has become kind
of elistist, and is comparable to "eat your vegitibles". People are
made to feel guilty if they are not doing OO.
>
> The projects that do incorporate OO still use a relational DB as
> opposed to loading the entire DB into objects.
They still do a lot of DB mirroring. In-App composition & aggregation,
common OO techniques, is a form of mirroring. One generally does not
do this in P/R because one uses queries to "flatten" the view to fit
the particular task at hand.
> I just don't see the
> industry as biased toward pure OO as you seem to say it is. Most
> people are willing to incorporate the best of both worlds, instead of
> your world of pure case statements.
Lots of similar case statements can often be factored to tables, I
would note.
>
> > You have to
> > show how OO better fits the actual real world. And what about things
> > based on intellectual property or capital, like money? They are not
> > physical. Yes, you can model money transactions as a bunch of
> > mechanical hands moving coins around, but most would agree that is a
> > clumsy way to go about it. Sometimes the real world is F'd such that
> > we *don't* want to recreate it. Few miss library card catalogs, and
> > you would get fired if you emulated them if charged with building an
> > online book search. The purpose of biz computers is to make business
> > more efficient, not necessarily copy physical versions of the
> > activities.
>
> I don't think you have to model it the same as reality... IOW, you
> could come up with a better model and write it that way.
Sets and relational seem to work pretty well most of the time for biz
apps. OO thinking seems to ignore them. Whether sets and relational
fit the "real world" better, I don't know. They just make it easier
for the developer (at least this one) to design, manage, trace, grok,
and study the design. OO looks like Goto's uglier brother to me. At
the least, sets/R are a more "useful lie" to me than OO.
If you can documenet the pyschology for properly grokking navigational
structures (wrapped in set/gets now), please do. Some of us just don't
see the appeal, similar to the complaints Dr. Codd had against them in
the late 60's. 30+ years and nobody has answered the Doctor's issues.
>
> Jordan
-T-
topmind
If we have N different models that *all* produce the right answer
given the same set of input, how do we evaluate which is "better"?
(Let's ignore processing speed for now.)
(I replied to this earlier, but it seems to be vacationing in the
Usenet Black Hole)
-T-
Jordan Marr
> > your typical BS. As usual, because it's the only thing you have to
> > say. I don't care to argue the same points you've been arguing on
> > every other thread on this NG. And now this thread looks just like
> > any other, regardless of its potential.
>
> If your justification for the example looks like any other reply then
> of course my answer will also. It is not my fault that all roads lead
> to Rome.
Rome may be connected to the road system, but that doesn't mean you
have to keep going there.
> > Ugh, Whose Fish would have been so much more interesting than business
> > apps, which you are stuck on.
>
> Perhaps. But practicality should trump mental masturbation unless we
> are entering "American Paradigm Idol".
Why is "mental masturbation"? Because it wasn't a paying project?
Neither was your customer / invoice program. You wrote that
completely for completely intellectual / educational purposes too.
Same as what I did. You just don't don't like the Whose Fish puzzle
because it's harder, so you're trying to degrade it by writing it off
as something below you.
> > Have a good look at Lhotka's CSLA reusable business framework.
>
> Awk! He's selling a book. At least the Payroll example is free. He
> also mentioned "distributed environment". This usually means a RDBMS
> hater, so my yellow flag is up. I already spent gobs on OO books
> recommended by others.
Lhotka's very robust reusable business framework is available for
free, and it's completely documented in code. There are also example
projects demonstrating how to use it. You don't have to buy the
book.
And there is nothing RDBMS hater about it. It works very much hand in
hand with the RDB.
Once again, I throw something out and you dismiss it immediately.
Let's face it: OO can (and does) write the same apps with the same
functionality (CRUD, business database apps, etc), AND it can handle
all the stuff that PR doesn't do well at (drivers, CAD, frameworks,
etc). You don't prefer it.. I do.
And I don't buy your implications that "OO" means loading the entire
contents of the database into an in memory OO DB of composition and
hierarchies. Most database are size prohibitive for that anyway.
> > Yes, the author obviously models their own view of the world. So?
> > And some models will function better than others.
>
> Beyond "correct output", "better" is probably also in the eye of the
> beholder. My wife's method of organizing (wooden) desk doodads is
> different than mine. Is one or the other "wrong"?
Better, to me, means the assurance that a change won't indirectly
cause other bugs. That means that the code has to be organized in an
intuitive way, as it is with a good object model, and the logic is
encapsulated inside those models in an intuitive place. Then it is
easy to see what will be affected by changes.
> > You have your mind made up already.
>
> It is not. If you show me OOP kicking P/R's bootie in a clear
> objective way, and I'll reconsider.
You just said that better is in the eye of the beholder, and you
already behold your way as better.
> > Now, if this was actually a forum of OO enthusiasts, I can see posting
> > the code of this puzzle for everyone to enjoy. However, in the
> > current context, I don't think it is.
> In practice they are indeed middle ground. However, OO has become kind
> of elistist, and is comparable to "eat your vegitibles". People are
> made to feel guilty if they are not doing OO.
I hate elitism but I like OO. The industry has been so dataset
oriented lately that I feel more persecuted as an OO fan than not.
Most programming language frameworks are OO, so it behooves most
programmers to be grounded in OO programming concepts.
> > The projects that do incorporate OO still use a relational DB as
> > opposed to loading the entire DB into objects.
>
> They still do a lot of DB mirroring. In-App composition & aggregation,
> common OO techniques, is a form of mirroring. One generally does not
> do this in P/R because one uses queries to "flatten" the view to fit
> the particular task at hand.
Whatever, most of the apps that I've ever worked on only load the data
that is necessary for the current use case. So the data is still
flattened, but it's in objects instead of table structures. At that
point, why does it matter if they are composed? The composition
collection is already flattened.. it just needs databound into a
control most of the time anyway. There is no need to traverse
anything.
Although I will say that the next version of C# will have an
integrated query language for querying in memory collections. (yay!)
>> Sets and relational seem to work pretty well most of the time for biz
> apps. OO thinking seems to ignore them.
No, it just skins them in objects with related behavior. And for
maintenance, I know if I change the behavior of an object, I'm not
going to inadvertently affect the behavior of other objects in the
code.
topmind
Jordan Marr wrote:
> > > This thread is about the Whose Fish riddle, and you're going off on
> > > your typical BS. As usual, because it's the only thing you have to
> > > say. I don't care to argue the same points you've been arguing on
> > > every other thread on this NG. And now this thread looks just like
> > > any other, regardless of its potential.
> >
> > If your justification for the example looks like any other reply then
> > of course my answer will also. It is not my fault that all roads lead
> > to Rome.
>
> Rome may be connected to the road system, but that doesn't mean you
> have to keep going there.
Maybe I should give my arguments numbers, and just say, "Oh yeah
smarty pants, well #635!".
>
> > > Ugh, Whose Fish would have been so much more interesting than business
> > > apps, which you are stuck on.
> >
> > Perhaps. But practicality should trump mental masturbation unless we
> > are entering "American Paradigm Idol".
>
> Why is "mental masturbation"? Because it wasn't a paying project?
> Neither was your customer / invoice program. You wrote that
> completely for completely intellectual / educational purposes too.
Yes, but it is a degree or two closer to projects people actually
encounter. Just because we cannot acheive the perfect example does
not mean we shouldn't do any. A "C+" example is better than a "D"
example.
> Same as what I did. You just don't don't like the Whose Fish puzzle
> because it's harder, so you're trying to degrade it by writing it off
> as something below you.
So you claim. It does not resemble the majority of biz projects I have
worked on. I state that with full honesty. If your experience is
different, the so be it. We can agree to disagree on that point. The
reader can apply whichever branch best fits their experience.
I would point out that there is a whole subfield of "optimization"
problems in biz, somewhat related to the Traveling Salesman problem,
perhaps something FedEx faces when deciding how to load and move their
trucks. Maybe those are better in objects, I don't know. I haven't
done much of those so don't dwell on them.
>
> > > Have a good look at Lhotka's CSLA reusable business framework.
> >
> > Awk! He's selling a book. At least the Payroll example is free. He
> > also mentioned "distributed environment". This usually means a RDBMS
> > hater, so my yellow flag is up. I already spent gobs on OO books
> > recommended by others.
>
> Lhotka's very robust reusable business framework is available for
> free, and it's completely documented in code. There are also example
> projects demonstrating how to use it. You don't have to buy the
> book.
I would suggest you provide more detailed links next time, rather than
"Joe Smith at LSFU made something". If you want to encourage people to
take a look at something specific, then refer them to something
specific.
>
> And there is nothing RDBMS hater about it. It works very much hand in
> hand with the RDB.
>
> Once again, I throw something out and you dismiss it immediately.
> Let's face it: OO can (and does) write the same apps with the same
> functionality (CRUD, business database apps, etc), AND it can handle
> all the stuff that PR doesn't do well at (drivers, CAD, frameworks,
> etc). You don't prefer it.. I do.
>
> And I don't buy your implications that "OO" means loading the entire
> contents of the database into an in memory OO DB of composition and
> hierarchies. Most database are size prohibitive for that anyway.
Where did I ever say "entire"? I even gave an example of what OO tends
to do to reduce such confusion.
>
>
> > > Yes, the author obviously models their own view of the world. So?
> > > And some models will function better than others.
> >
> > Beyond "correct output", "better" is probably also in the eye of the
> > beholder. My wife's method of organizing (wooden) desk doodads is
> > different than mine. Is one or the other "wrong"?
>
> Better, to me, means the assurance that a change won't indirectly
> cause other bugs. That means that the code has to be organized in an
> intuitive way, as it is with a good object model,
If "intuitive" is our metric, then sets and relational are far more
intuitive to me than OOP's navigational structures. This is partly
because they are more *sift-able* than OO code: I can bring together
and alter my view of factors much more easily. I don't want to see
things how Bill Gates codes them, I want to see them how *I* want to
see them, and making factors query-able acheives that better than any
known technology. It provides a more flexible way of seeing stuff.
Your OO code will stay OO code in one way in one form. (OO code
browsers are clunky navigational query systems.)
My view of how I query info may be different than even what ANOTHER
relational weenie wants to see. I am not stuck with his/her view
either. You can't say this about OOP code.
It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!
This, and more consistency across shops are the two main features of
relational.
Again, I don't dispute that OO may fit your head. But to extrapolate
your head to everyone else is a mistake.
> and the logic is
> encapsulated inside those models in an intuitive place. Then it is
> easy to see what will be affected by changes.
Better yet if you can do it by querying, or that a non-programmer can
do it by using query tools (such as Query-By-Example) such that the
programmer does not have to be a glorified product clerk.
If you could provide a specific change example along with code impact
and how you think about it, that may be helpful. I cannot read your
mind.
>
> > > You have your mind made up already.
> >
> > It is not. If you show me OOP kicking P/R's bootie in a clear
> > objective way, and I'll reconsider.
>
> You just said that better is in the eye of the beholder, and you
> already behold your way as better.
Everybody has their fav techniques.
>
> > > Now, if this was actually a forum of OO enthusiasts, I can see posting
> > > the code of this puzzle for everyone to enjoy. However, in the
> > > current context, I don't think it is.
>
> > In practice they are indeed middle ground. However, OO has become kind
> > of elistist, and is comparable to "eat your vegitibles". People are
> > made to feel guilty if they are not doing OO.
>
> I hate elitism but I like OO. The industry has been so dataset
> oriented lately that I feel more persecuted as an OO fan than not.
>
> Most programming language frameworks are OO, so it behooves most
> programmers to be grounded in OO programming concepts.
True, but that is kind of a QWERTY Keyboard argument: we use it
because everyone else uses it, not because it is better.
>
> > > The projects that do incorporate OO still use a relational DB as
> > > opposed to loading the entire DB into objects.
> >
> > They still do a lot of DB mirroring. In-App composition & aggregation,
> > common OO techniques, is a form of mirroring. One generally does not
> > do this in P/R because one uses queries to "flatten" the view to fit
> > the particular task at hand.
>
> Whatever, most of the apps that I've ever worked on only load the data
> that is necessary for the current use case. So the data is still
> flattened, but it's in objects instead of table structures. At that
> point, why does it matter if they are composed? The composition
> collection is already flattened.. it just needs databound into a
> control most of the time anyway. There is no need to traverse
> anything.
This sounds contradictory. May I request some psuedocode?
>
> Although I will say that the next version of C# will have an
> integrated query language for querying in memory collections. (yay!)
I also enjoy languages/tools that offer "local queries". They fell out
of favor, but are slowly creeping back, fortunately.
>
> >> Sets and relational seem to work pretty well most of the time for biz
> > apps. OO thinking seems to ignore them.
>
> No, it just skins them in objects with related behavior. And for
> maintenance, I know if I change the behavior of an object, I'm not
> going to inadvertently affect the behavior of other objects in the
> code.
Again, you have not shown how OO acheives this better than
alternatives (outside of shapes, animals, and device drivers).
-T-
Daniel T.
> If we have N different models that *all* produce the right answer
> given the same set of input, how do we evaluate which is "better"?
The answer, of course, is highly dependent on context. How many people
are working on the project? What is their general skill level? Is the
project projected for continual development or will there be a drop-dead
date? I'm sure there are many more variables...
topmind
Is there too many variables, too many *subjective* variables, or both?
If there is a *single* significant subjective variable, then we will
never turn paradigm comparison into a science even IF we can measure
the other variables.
Put another way, can the psychology of developers ever be removed from
a good comparison?
-T-
AndyW
What I am suggesting (and it would require a study) is that the more
'compex' or higher order math a person learns the more likely they are
to tend towards creating procedural systems and the less likely they
are to be able to deal with OO techniques at a conceptual level.
Don Roby
This would certainly require a study, and I find the suggested theory
pretty dubious. Of course I would, being a mathematically oriented
person working as a software developer and producing object-oriented
systems. ;-)
Math involves some pretty abstract concepts, so I don't see the
expectation of a decreased ability to deal with abstraction in software.
If you elaborate on why you expect this, it might be an interesting
discussion.
--
Don Roby
Daniel T.
> On May 14, 4:32 pm, "Daniel T." <danie...@earthlink.net> wrote:
> > topmind <topm...@technologist.com> wrote:
>
> > > If we have N different models that *all* produce the right answer
> > > given the same set of input, how do we evaluate which is "better"?
> >
> > The answer, of course, is highly dependent on context. How many people
> > are working on the project? What is their general skill level? Is the
> > project projected for continual development or will there be a drop-dead
> > date? I'm sure there are many more variables...
>
> Is there too many variables, too many *subjective* variables, or both?
I don't know that there are too many variables and I don't think that
any of the variables are subjective. So my answer to the above is
"neither".
However, the variables are still important. Paradigms cannot be compared
in a vacuum. You yourself have admitted as much; when I first started
reading your posts here back about 10 years ago (has it been 10?) you
said "OO bad", now you have to put a whole bunch of qualifiers on in
what contexts you are considering when you say that.
Jordan Marr
sacraficed to Google.Kong.
> Maybe I should give my arguments numbers, and just say, "Oh yeah
> smarty pants, well #635!".
That would be much more in line with your Table Oriented Programming
approach. It would really cut down on the "duplicated responses"!
Codd would be so proud! ;^)
> > Same as what I did. You just don't don't like the Whose Fish puzzle
> > because it's harder, so you're trying to degrade it by writing it off
> > as something below you.
>
> So you claim. It does not resemble the majority of biz projects I have
> worked on. I state that with full honesty. If your experience is
> different, the so be it. We can agree to disagree on that point. The
> reader can apply whichever branch best fits their experience.
I'm sure plenty of comp.object readers have programmed (or are
currently programming) non CRUD business apps. I'd be interested to
see a voting pole. 1) have you ever worked on a non CRUD/Biz app, and
2) what type of project are you current coding.
> I would point out that there is a whole subfield of "optimization"
> problems in biz, somewhat related to the Traveling Salesman problem,
> perhaps something FedEx faces when deciding how to load and move their
> trucks. Maybe those are better in objects, I don't know. I haven't
> done much of those so don't dwell on them.
>
>
>
> > > > Have a good look at Lhotka's CSLA reusable business framework.
> I would suggest you provide more detailed links next time, rather than
> "Joe Smith at LSFU made something". If you want to encourage people to
> take a look at something specific, then refer them to something
> specific.
Sorry. His free reusable business framework can be downloaded here:
http://www.lhotka.net/cslanet/download.aspx
> > And I don't buy your implications that "OO" means loading the entire
> > contents of the database into an in memory OO DB of composition and
> > hierarchies. Most database are size prohibitive for that anyway.
>
> Where did I ever say "entire"? I even gave an example of what OO tends
> to do to reduce such confusion.
You seemed to imply (or maybe I inferred) that OO is a bunch of
inefficient navigation through collections. I am just saying that the
composed collections are usually pre-filtered from the DB when they
are loaded into an object.
> > Better, to me, means the assurance that a change won't indirectly
> > cause other bugs. That means that the code has to be organized in an
> > intuitive way, as it is with a good object model,
>
> If "intuitive" is our metric, then sets and relational are far more
> intuitive to me than OOP's navigational structures. This is partly
> because they are more *sift-able* than OO code: I can bring together
> and alter my view of factors much more easily. I don't want to see
> things how Bill Gates codes them, I want to see them how *I* want to
> see them, and making factors query-able acheives that better than any
> known technology. It provides a more flexible way of seeing stuff.
> Your OO code will stay OO code in one way in one form. (OO code
> browsers are clunky navigational query systems.)
I don't understand why you say this. An in memory table is itself a
collection of info. I really don't see the difference between having
two in memory tables with a SalesPerson and his releated Sales vs a
SalesPerson object with its own collection of related Sales objects.
Well, except for the fact that all my data is active: it is self
validating in real time and has its own associated behavior, where as
yours is just passive data. Meaning some junior can't incorrectly
change a field on one of my business objects that is invalid and then
save it to the DB. It just can't happen.
I will hand it to you that datasets take less work to use than
creating an object model. I think it is worth the trade off to create
models so that I can have strongly typed, self validating data
objects. I created my own object code generator though, and there are
plenty of free ones out there that almost completely eliminate the
extra overhead time, creating a best of both worlds scenerio for me.
> My view of how I query info may be different than even what ANOTHER
> relational weenie wants to see. I am not stuck with his/her view
> either. You can't say this about OOP code.
>
> It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!
I can create my objects to fit any view I want or need for any given
use case. And I can create different views of similar data for
different use cases. Ex, I might load CustomerInfo with read only ID
and Name fields to populate a list.. Then selecting a customer will
pass the ID to an edit page, where I can use that to load a Customer
object with editable fields for all the information, validation rules,
DB update, etc.
> This, and more consistency across shops are the two main features of
> relational.
The data in OO systems is still saved in the database that other
internal apps can access. Or we can create a webservice layer.
> Again, I don't dispute that OO may fit your head. But to extrapolate
> your head to everyone else is a mistake.
I know you're not going to change your mind. I'm just defending what
you attack on comp.object on a regular basis.
> > and the logic is
> > encapsulated inside those models in an intuitive place. Then it is
> > easy to see what will be affected by changes.
>
> Better yet if you can do it by querying, or that a non-programmer can
> do it by using query tools (such as Query-By-Example) such that the
> programmer does not have to be a glorified product clerk.
So you're saying you anticipate all future requirements into an app at
design time such that a programmer is no longer required?
> If you could provide a specific change example along with code impact
> and how you think about it, that may be helpful. I cannot read your
> mind.
I'm not good at coming up with real world examples.. and the last time
I did you said you didn't know enough about the problem domain, so I'm
not gonna waste my time.
> > > > You have your mind made up already.
>
> > > It is not. If you show me OOP kicking P/R's bootie in a clear
> > > objective way, and I'll reconsider.
Man, what is your myers briggs type? INTJ?
> > Most programming language frameworks are OO, so it behooves most
> > programmers to be grounded in OO programming concepts.
>
> True, but that is kind of a QWERTY Keyboard argument: we use it
> because everyone else uses it, not because it is better.
There is a big difference between what "everyone else" is programming
in (which doesn't affect me), and what the designers of my software
language are doing. Learning OO has helped me tremendously in using
the .net framework.
> > > > The projects that do incorporate OO still use a relational DB as
> > > > opposed to loading the entire DB into objects.
>
> > > They still do a lot of DB mirroring. In-App composition & aggregation,
> > > common OO techniques, is a form of mirroring. One generally does not
> > > do this in P/R because one uses queries to "flatten" the view to fit
> > > the particular task at hand.
This is where I think you are applying non-existent conditions of
"what is OO". I think an object model can pre load its objects with
pre-filtered (queried) data, and still be OO (non-P/R). You say that
I am just doing P/R in OO clothes, but when I see your code and all
the case statements, I have to say that my solutions are more OO than
P/R.
> > Whatever, most of the apps that I've ever worked on only load the data
> > that is necessary for the current use case. So the data is still
> > flattened, but it's in objects instead of table structures. At that
> > point, why does it matter if they are composed? The composition
> > collection is already flattened.. it just needs databound into a
> > control most of the time anyway. There is no need to traverse
> > anything.
>
> This sounds contradictory. May I request some psuedocode?
class SalesPerson
{
public string Name;
public Collection Sales;
public SalesPerson(int id)
{
// Load Name from db
...
// Load related sales
...
}
}
There is nothing to navigate, just load and bind to controls for
viewing / editing.
> > Although I will say that the next version of C# will have an
> > integrated query language for querying in memory collections. (yay!)
>
> I also enjoy languages/tools that offer "local queries". They fell out
> of favor, but are slowly creeping back, fortunately.
Really? I imagined you would be against an in memory querying
feature.
> > >> Sets and relational seem to work pretty well most of the time for biz
> > > apps. OO thinking seems to ignore them.
Really? Not in my apps.
Jordan
topmind
It's called "learning". I started off with 2 primary assumptions that
I slowly found to be wrong, or at least non-reliable. In particular
I've learned:
1. Psychology is key: Every person's mental model of the world and how
they view and deal with code, grids, languages, etc. is vastly
different from each other.
2. What works well for the domain I am familiar with may not be the
case in other domains.
I think software engineering is *inharently* tied to human psychology
on both a global and local (individual) level. You appear to imply[1]
all that it takes is an expert "judge" to render a professional
opinion, and that that is as good as or nearly the same as objective
metrics. It is not. If one cannot dissect out the specifics,
something is probably wrong or subjective about the technique.
[1] Without details, it is difficult to better characterize your
method of measurment.
-T-
topmind
> I already replied, but it seems that every third post must be
> sacraficed to Google.Kong.
>
> > Maybe I should give my arguments numbers, and just say, "Oh yeah
> > smarty pants, well #635!".
>
> That would be much more in line with your Table Oriented Programming
> approach. It would really cut down on the "duplicated responses"!
> Codd would be so proud! ;^)
That's kind of what Wiki's are for. C2.com is sort of like this, but
the granularity is not small enough in my opinion, and holy wars start
over how fine the granularity should be there. Maybe when I retire
I'll rework my Opinion Tracking System. By then, robots will probably
do all the programming anyhow :-)
>
> > > Same as what I did. You just don't don't like the Whose Fish puzzle
> > > because it's harder, so you're trying to degrade it by writing it off
> > > as something below you.
> >
> > So you claim. It does not resemble the majority of biz projects I have
> > worked on. I state that with full honesty. If your experience is
> > different, the so be it. We can agree to disagree on that point. The
> > reader can apply whichever branch best fits their experience.
>
> I'm sure plenty of comp.object readers have programmed (or are
> currently programming) non CRUD business apps. I'd be interested to
> see a voting pole. 1) have you ever worked on a non CRUD/Biz app, and
> 2) what type of project are you current coding.
You seem to be equating non-crud with fish-example-like.
The dichotomy between crud and non-crud can get a little fuzzy and
sticky. Business logic and "crud" stuff are often integrated. (Some
argue to heavily separate them, but that often creates verbose red-
tape interface bloat IMO).
Optimization problems (described below) are probably the closest I can
think of right now to "non-crud" biz apps. This is because they are
sort of computational-intensive batch jobs with little or no user
interaction once the process is underway. I don't have much of an
opinion either way about whether P/R or navigational/OO techniques are
better for such because I've had only a little exposure to such. I've
seen some evidence that special dedicated software is sometimes
available for such tasks such that much of the coding is not via
general internal developers. It may just be generic-able such that one
can almost buy Microsoft Optimizer 6.0 and plug NBA play schedules,
UPS package shipping, etc. into them and press a few buttons. Ask an
expert in that.
>
> > I would point out that there is a whole subfield of "optimization"
> > problems in biz, somewhat related to the Traveling Salesman problem,
> > perhaps something FedEx faces when deciding how to load and move their
> > trucks. Maybe those are better in objects, I don't know. I haven't
> > done much of those so don't dwell on them.
> >
> >
> >
> > > > > Have a good look at Lhotka's CSLA reusable business framework.
>
> > I would suggest you provide more detailed links next time, rather than
> > "Joe Smith at LSFU made something". If you want to encourage people to
> > take a look at something specific, then refer them to something
> > specific.
>
> Sorry. His free reusable business framework can be downloaded here:
> http://www.lhotka.net/cslanet/download.aspx
I was hoping for documentation on the interfaces and hopefully small
examples of each one in action. It still appears one has to buy the
books to see that. I could not find an online sample and reference.
>
> > > And I don't buy your implications that "OO" means loading the entire
> > > contents of the database into an in memory OO DB of composition and
> > > hierarchies. Most database are size prohibitive for that anyway.
> >
> > Where did I ever say "entire"? I even gave an example of what OO tends
> > to do to reduce such confusion.
>
> You seemed to imply (or maybe I inferred) that OO is a bunch of
> inefficient navigation through collections. I am just saying that the
> composed collections are usually pre-filtered from the DB when they
> are loaded into an object.
I don't think I mentioned "inefficient", at least not from a CPU
standpoint. I didn't focus on that.
As far as "pre-filtered", then why create one-to-many structures that
seem common in OO? In P/r, you generally create a flattened view that
is specific for the task. (There are exceptions, but they would be
less so if the language supported local tables/queries well.) You
don't in an in-app one-to-many structure for most tasks. Seems OO
tries to create "intermediate duration" model of something. I don't
see much practical need for this, and it complicates multi-user
coordination and data integrity. If I need an intermediate structure,
then I create one in the database.
For example, a web shopping cart. OO'ers want to create Cart objects
that hold all the items. I find it cleaner to create Cart table(s).
Each task queries the Cart table(s) as needed rather than leave the
cart structure/object floating around in the app.
-T-
> > > Better, to me, means the assurance that a change won't indirectly
> > > cause other bugs. That means that the code has to be organized in an
> > > intuitive way, as it is with a good object model,
> >
> > If "intuitive" is our metric, then sets and relational are far more
> > intuitive to me than OOP's navigational structures. This is partly
> > because they are more *sift-able* than OO code: I can bring together
> > and alter my view of factors much more easily. I don't want to see
> > things how Bill Gates codes them, I want to see them how *I* want to
> > see them, and making factors query-able acheives that better than any
> > known technology. It provides a more flexible way of seeing stuff.
> > Your OO code will stay OO code in one way in one form. (OO code
> > browsers are clunky navigational query systems.)
>
> I don't understand why you say this. An in memory table is itself a
> collection of info. I really don't see the difference between having
> two in memory tables with a SalesPerson and his releated Sales vs a
> SalesPerson object with its own collection of related Sales objects.
First is data-integrity issues. How long do you keep it in app ram?
What if a change is made by another user? Do you do periodic
refreshes? If you keep stuff around too long, these become an bigger
issue.
Second, if the structure is *already* in the RDBMS, why mirror it in
app objects? It is unnecessary duplication. Related:
http://www.c2.com/cgi/wiki?AbstractionsTooNear
> Well, except for the fact that all my data is active: it is self
> validating in real time and has its own associated behavior, where as
> yours is just passive data. Meaning some junior can't incorrectly
> change a field on one of my business objects that is invalid and then
> save it to the DB. It just can't happen.
If the rule is truely universal, then RDBMS integrity checking
(triggers, look-ups, etc) is more effective than class-level because
it applies *across* languages and applications.
But, I can make an app-level P/R framework for validation also. One is
not forced to use it, but one is not forced to use class-X to always
"talk too" thing Y either. OO's "gate-keeper" claims are exaggerated.
Classes cannot replace spanking.
>
> I will hand it to you that datasets take less work to use than
> creating an object model. I think it is worth the trade off to create
> models so that I can have strongly typed, self validating data
> objects.
Strongly typed? Does this mean that Smalltalk, Python, etc. is not
getting OO's real benefits?
> I created my own object code generator though, and there are
> plenty of free ones out there that almost completely eliminate the
> extra overhead time, creating a best of both worlds scenerio for me.
>
> > My view of how I query info may be different than even what ANOTHER
> > relational weenie wants to see. I am not stuck with his/her view
> > either. You can't say this about OOP code.
> >
> > It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!
>
> I can create my objects to fit any view I want or need for any given
> use case. And I can create different views of similar data for
> different use cases. Ex, I might load CustomerInfo with read only ID
> and Name fields to populate a list.. Then selecting a customer will
> pass the ID to an edit page, where I can use that to load a Customer
> object with editable fields for all the information, validation rules,
> DB update, etc.
I would have to see more specifics. This also seems to be leaking into
debates about GUI frameworks, which I would rather avoid for now
because it is a long and complicated topic.
>
> > This, and more consistency across shops are the two main features of
> > relational.
>
> The data in OO systems is still saved in the database that other
> internal apps can access. Or we can create a webservice layer.
>
> > Again, I don't dispute that OO may fit your head. But to extrapolate
> > your head to everyone else is a mistake.
>
> I know you're not going to change your mind. I'm just defending what
> you attack on comp.object on a regular basis.
You are not defending it with anything objective. If your preference
is based on subjective factors and so is mine, it is unrealistic to
expect me to change my mind.
>
> > > and the logic is
> > > encapsulated inside those models in an intuitive place. Then it is
> > > easy to see what will be affected by changes.
> >
> > Better yet if you can do it by querying, or that a non-programmer can
> > do it by using query tools (such as Query-By-Example) such that the
> > programmer does not have to be a glorified product clerk.
>
> So you're saying you anticipate all future requirements into an app at
> design time such that a programmer is no longer required?
Reduce dependency upon.
>
> > If you could provide a specific change example along with code impact
> > and how you think about it, that may be helpful. I cannot read your
> > mind.
>
> I'm not good at coming up with real world examples.. and the last time
> I did you said you didn't know enough about the problem domain, so I'm
> not gonna waste my time.
Nobody said providing good evidence is a half-hour task. Generally I
suggest samples such as college grade tracking, airline reservations,
payroll, etc., because most are generally familiar with the domain
issues in them, reducing the need for domain education for your
example.
> > > Most programming language frameworks are OO, so it behooves most
> > > programmers to be grounded in OO programming concepts.
> >
> > True, but that is kind of a QWERTY Keyboard argument: we use it
> > because everyone else uses it, not because it is better.
>
> There is a big difference between what "everyone else" is programming
> in (which doesn't affect me), and what the designers of my software
> language are doing. Learning OO has helped me tremendously in using
> the .net framework.
I am not sure what your point is. Learning machine language helps one
understand assembler language, but that does not mean that using
assembler is the most productive way to go.
>
> > > > > The projects that do incorporate OO still use a relational DB as
> > > > > opposed to loading the entire DB into objects.
> >
> > > > They still do a lot of DB mirroring. In-App composition & aggregation,
> > > > common OO techniques, is a form of mirroring. One generally does not
> > > > do this in P/R because one uses queries to "flatten" the view to fit
> > > > the particular task at hand.
>
> This is where I think you are applying non-existent conditions of
> "what is OO". I think an object model can pre load its objects with
> pre-filtered (queried) data, and still be OO (non-P/R). You say that
> I am just doing P/R in OO clothes, but when I see your code and all
> the case statements, I have to say that my solutions are more OO than
> P/R.
How do we know it is "OO"? Is everything done in an OO-capable
language automatically "OO"? Is anything with a dot?
>
> > > Whatever, most of the apps that I've ever worked on only load the data
> > > that is necessary for the current use case. So the data is still
> > > flattened, but it's in objects instead of table structures. At that
> > > point, why does it matter if they are composed? The composition
> > > collection is already flattened.. it just needs databound into a
> > > control most of the time anyway. There is no need to traverse
> > > anything.
> >
> > This sounds contradictory. May I request some psuedocode?
>
> class SalesPerson
> {
> public string Name;
> public Collection Sales;
>
> public SalesPerson(int id)
> {
> // Load Name from db
> ...
> // Load related sales
> ...
> }
> }
>
> There is nothing to navigate, just load and bind to controls for
> viewing / editing.
Why not just:
result = query("select * from emp natural join sales where empID=" &
useID);
If you use the same query 20 times, then put it into a shared
function. I still see no need for a one-to-many structure in app ram
so far. I won't say I never encounter such a need, but it is not that
common for interactive apps (and you don't need OO to do it even if
you go that route).
>
> > > Although I will say that the next version of C# will have an
> > > integrated query language for querying in memory collections. (yay!)
> >
> > I also enjoy languages/tools that offer "local queries". They fell out
> > of favor, but are slowly creeping back, fortunately.
>
> Really? I imagined you would be against an in memory querying
> feature.
Ideally, I don't have to know or care whether its stored in memory,
cached on disk, etc. The app developer should be hidden from hardware
concerns like that if possible. The strong dichotomy between Big Iron
RDBMS and smaller ones is mostly an artificial artifact of historical
habit.
>
> > > >> Sets and relational seem to work pretty well most of the time for biz
> > > > apps. OO thinking seems to ignore them.
>
> Really? Not in my apps.
>
Show me.
>
> Jordan
-T-
topmind
Whether the above is true or not, I think one has to agree that OO is
kind of the anthesis of math. It tries to deal with things as
mirroring some kind of physical representation (objects, things,
little machines that talk to each other) and navigate them as if
walking around a room or hallways (getNext), etc. A more mathlike
approach would do something like (A x B), applying transformation A to
all B. It does not strive to mirror the physical world of things if it
is not necessary to solve the problem. For example, a transformation
to one item versus the same transformation to 1000 items may not be
treated different in math-think.
Food for fodder...
(I smell a coming debate on the meaning of "math"...)
>
> --
> Don Roby
-T-
Don Roby
One certainly does not have to agree to this. I do not.
> It tries to deal with things as
> mirroring some kind of physical representation (objects, things,
> little machines that talk to each other) and navigate them as if
> walking around a room or hallways (getNext), etc.
A set of interacting state machines is not quite the "antithesis of math".
Nor is the use of list or tree styled data structures and traversal by
iterators.
> A more mathlike
> approach would do something like (A x B), applying transformation A to
> all B. It does not strive to mirror the physical world of things if it
> is not necessary to solve the problem. For example, a transformation
> to one item versus the same transformation to 1000 items may not be
> treated different in math-think.
>
OO can be used to model real things. This is perhaps one of the
historical roots of the paradigm, but this is not all it's useful for.
Math also has historical roots in modeling, measuring and counting real
things. It has evolved to model, measure and count non-real things,
such as models, counts and measures.
In both, unimportant stuff for the current goal is omitted from the
models. That to my mind defines the word 'abstraction'.
What you're trying to describe with your (A x B) and transformations
blather is likely also mathematical, but not clearly any more so than
OO. Nor does it clearly describe something contrary to OO so far as I
can understand it. Perhaps you've omitted too much from your model.
> Food for fodder...
>
> (I smell a coming debate on the meaning of "math"...)
>
Debate all you like. I expect I'll stop here.
topmind
But it still carries the philosophical baggage of "physical stuff"
modeling and hierarchical noun taxonomies (or mutually-exclusive
subtypes). You can work around it, but it FEELS like a workaround
still.
>
> In both, unimportant stuff for the current goal is omitted from the
> models. That to my mind defines the word 'abstraction'.
To your mind only. Sets and relationial are a better abstraction than
polymorphism to my mind. Sets better fit how I see biz info and see it
change over time and offer me easier ways to study such info from
different angles. Sets allow a more "mathy" way to work with info
than polymorphism.
>
> What you're trying to describe with your (A x B) and transformations
> blather is likely also mathematical, but not clearly any more so than
> OO. Nor does it clearly describe something contrary to OO so far as I
> can understand it. Perhaps you've omitted too much from your model.
>
> > Food for fodder...
> >
> > (I smell a coming debate on the meaning of "math"...)
> >
>
> Debate all you like. I expect I'll stop here.
We'll just have to agree to disagree. I find OO rather low-level,
messy, primative, and Go To like.
-T-
topmind
prune it more.)
Jordan Marr wrote:
> > Maybe I should give my arguments numbers, and just say, "Oh yeah
> > smarty pants, well #635!".
>
> That would be much more in line with your Table Oriented Programming
> approach. It would really cut down on the "duplicated responses"!
> Codd would be so proud! ;^)
That's kind of what Wiki's are for. C2.com is sort of like this, but
the granularity is not small enough in my opinion, and holy wars start
over how fine the granularity should be there. Maybe when I retire
I'll rework my Opinion Tracking System. By then, robots will probably
do all the programming anyhow :-)
>
> > > Same as what I did. You just don't don't like the Whose Fish puzzle
> > > because it's harder, so you're trying to degrade it by writing it off
> > > as something below you.
> >
> > So you claim. It does not resemble the majority of biz projects I have
> > worked on. I state that with full honesty. If your experience is
> > different, the so be it. We can agree to disagree on that point. The
> > reader can apply whichever branch best fits their experience.
>
> I'm sure plenty of comp.object readers have programmed (or are
> currently programming) non CRUD business apps. I'd be interested to
> see a voting pole. 1) have you ever worked on a non CRUD/Biz app, and
> 2) what type of project are you current coding.
You seem to be equating non-crud with fish-example-like.
The dichotomy between crud and non-crud can get a little fuzzy and
sticky. Business logic and "crud" stuff are often integrated. (Some
argue to heavily separate them, but that often creates verbose red-
tape interface bloat IMO).
Optimization problems (described previously) are probably the closest
I can think of right now to "non-crud" biz apps. This is because they
are sort of computational-intensive batch jobs with little or no user
interaction once the process is underway. I don't have much of an
opinion either way about whether P/R or navigational/OO techniques are
better for such because I've had only a little exposure to such. I've
seen some evidence that special dedicated software is sometimes
available for such tasks such that much of the coding is not via
general internal developers. It may just be generic-able such that one
can almost buy Microsoft Optimizer 6.0 and plug NBA play schedules,
UPS package shipping, etc. into them and press a few buttons. Ask an
expert in that.
> > > > > Have a good look at Lhotka's CSLA reusable business framework.
>
> > I would suggest you provide more detailed links next time, rather than
> > "Joe Smith at LSFU made something". If you want to encourage people to
> > take a look at something specific, then refer them to something
> > specific.
>
> Sorry. His free reusable business framework can be downloaded here:
> http://www.lhotka.net/cslanet/download.aspx
I was hoping for documentation on the interfaces and hopefully small
examples of each one in action. It still appears one has to buy the
books to see that. I could not find an online sample and reference.
>
> > > And I don't buy your implications that "OO" means loading the entire
> > > contents of the database into an in memory OO DB of composition and
> > > hierarchies. Most database are size prohibitive for that anyway.
> >
> > Where did I ever say "entire"? I even gave an example of what OO tends
> > to do to reduce such confusion.
>
> You seemed to imply (or maybe I inferred) that OO is a bunch of
> inefficient navigation through collections. I am just saying that the
> composed collections are usually pre-filtered from the DB when they
> are loaded into an object.
I don't think I mentioned "inefficient", at least not from a CPU
standpoint. I didn't focus on that.
As far as "pre-filtered", then why create one-to-many structures that
seem common in OO? In P/r, you generally create a flattened view that
is specific for the task. (There are exceptions, but they would be
less so if the language supported local tables/queries well.) You
don't in an in-app one-to-many structure for most tasks. Seems OO
tries to create "intermediate duration" model of something. I don't
see much practical need for this, and it complicates multi-user
coordination and data integrity. If I need an intermediate structure,
then I create one in the database.
For example, a web shopping cart. OO'ers want to create Cart objects
that hold all the items. I find it cleaner to create Cart table(s).
Each task queries the Cart table(s) as needed rather than leave the
cart structure/object floating around in the app.
> > > Better, to me, means the assurance that a change won't indirectly
> > > cause other bugs. That means that the code has to be organized in an
> > > intuitive way, as it is with a good object model,
> >
> > If "intuitive" is our metric, then sets and relational are far more
> > intuitive to me than OOP's navigational structures. This is partly
> > because they are more *sift-able* than OO code: I can bring together
> > and alter my view of factors much more easily. I don't want to see
> > things how Bill Gates codes them, I want to see them how *I* want to
> > see them, and making factors query-able acheives that better than any
> > known technology. It provides a more flexible way of seeing stuff.
> > Your OO code will stay OO code in one way in one form. (OO code
> > browsers are clunky navigational query systems.)
>
> I don't understand why you say this. An in memory table is itself a
> collection of info. I really don't see the difference between having
> two in memory tables with a SalesPerson and his releated Sales vs a
> SalesPerson object with its own collection of related Sales objects.
First is data-integrity issues. How long do you keep it in app ram?
What if a change is made by another user? Do you do periodic
refreshes? If you keep stuff around too long, these become an bigger
issue.
Second, if the structure is *already* in the RDBMS, why mirror it in
app objects? It is unnecessary duplication. Related:
http://www.c2.com/cgi/wiki?AbstractionsTooNear
> Well, except for the fact that all my data is active: it is self
> validating in real time and has its own associated behavior, where as
> yours is just passive data. Meaning some junior can't incorrectly
> change a field on one of my business objects that is invalid and then
> save it to the DB. It just can't happen.
If the rule is truely universal, then RDBMS integrity checking
(triggers, look-ups, etc) is more effective than class-level because
it applies *across* languages and applications.
But, I can make an app-level P/R framework for validation also. One is
not forced to use it, but one is not forced to use class-X to always
"talk too" thing Y either. OO's "gate-keeper" claims are exaggerated.
Classes cannot replace spanking.
>
> I will hand it to you that datasets take less work to use than
> creating an object model. I think it is worth the trade off to create
> models so that I can have strongly typed, self validating data
> objects.
Strongly typed? Does this mean that Smalltalk, Python, etc. is not
getting OO's real benefits?
> > My view of how I query info may be different than even what ANOTHER
> > relational weenie wants to see. I am not stuck with his/her view
> > either. You can't say this about OOP code.
> >
> > It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!
>
> I can create my objects to fit any view I want or need for any given
> use case. And I can create different views of similar data for
> different use cases. Ex, I might load CustomerInfo with read only ID
> and Name fields to populate a list.. Then selecting a customer will
> pass the ID to an edit page, where I can use that to load a Customer
> object with editable fields for all the information, validation rules,
> DB update, etc.
I would have to see more specifics. This also seems to be leaking into
debates about GUI frameworks, which I would rather avoid for now
because it is a long and complicated topic.
> > Again, I don't dispute that OO may fit your head. But to extrapolate
> > your head to everyone else is a mistake.
>
> I know you're not going to change your mind. I'm just defending what
> you attack on comp.object on a regular basis.
You are not defending it with anything objective. If your preference
is based on subjective factors and so is mine, it is unrealistic to
expect me to change my mind.
>
> > > and the logic is
> > > encapsulated inside those models in an intuitive place. Then it is
> > > easy to see what will be affected by changes.
> >
> > Better yet if you can do it by querying, or that a non-programmer can
> > do it by using query tools (such as Query-By-Example) such that the
> > programmer does not have to be a glorified product clerk.
>
> So you're saying you anticipate all future requirements into an app at
> design time such that a programmer is no longer required?
Reduce dependency upon.
>
> > If you could provide a specific change example along with code impact
> > and how you think about it, that may be helpful. I cannot read your
> > mind.
>
> I'm not good at coming up with real world examples.. and the last time
> I did you said you didn't know enough about the problem domain, so I'm
> not gonna waste my time.
Nobody said providing good evidence is a half-hour task. Generally I
suggest samples such as college grade tracking, airline reservations,
payroll, etc., because most are generally familiar with the domain
issues in them, reducing the need for domain education for your
example.
> > > Most programming language frameworks are OO, so it behooves most
> > > programmers to be grounded in OO programming concepts.
> >
> > True, but that is kind of a QWERTY Keyboard argument: we use it
> > because everyone else uses it, not because it is better.
>
> There is a big difference between what "everyone else" is programming
> in (which doesn't affect me), and what the designers of my software
> language are doing. Learning OO has helped me tremendously in using
> the .net framework.
I am not sure what your point is. Learning machine language helps one
understand assembler language, but that does not mean that using
assembler is the most productive way to go.
> > > > > The projects that do incorporate OO still use a relational DB as
> > > > > opposed to loading the entire DB into objects.
> >
> > > > They still do a lot of DB mirroring. In-App composition & aggregation,
> > > > common OO techniques, is a form of mirroring. One generally does not
> > > > do this in P/R because one uses queries to "flatten" the view to fit
> > > > the particular task at hand.
>
> This is where I think you are applying non-existent conditions of
> "what is OO". I think an object model can pre load its objects with
> pre-filtered (queried) data, and still be OO (non-P/R). You say that
> I am just doing P/R in OO clothes, but when I see your code and all
> the case statements, I have to say that my solutions are more OO than
> P/R.
How do we know it is "OO"? Is everything done in an OO-capable
language automatically "OO"? Is anything with a dot?
> > > Whatever, most of the apps that I've ever worked on only load the data
> > > that is necessary for the current use case. So the data is still
> > > flattened, but it's in objects instead of table structures. At that
> > > point, why does it matter if they are composed? The composition
> > > collection is already flattened.. it just needs databound into a
> > > control most of the time anyway. There is no need to traverse
> > > anything.
> >
> > This sounds contradictory. May I request some psuedocode?
>
> class SalesPerson
> {
> public string Name;
> public Collection Sales;
>
> public SalesPerson(int id)
> {
> // Load Name from db
> ...
> // Load related sales
> ...
> }
> }
>
> There is nothing to navigate, just load and bind to controls for
> viewing / editing.
Why not just:
result = query("select * from emp natural join sales where empID=" &
useID);
If you use the same query 20 times, then put it into a shared
function. I still see no need for a one-to-many structure in app ram
so far. I won't say I never encounter such a need, but it is not that
common for interactive apps (and you don't need OO to do it even if
you go that route).
> > I also enjoy languages/tools that offer "local queries". They fell out
> > of favor, but are slowly creeping back, fortunately.
>
> Really? I imagined you would be against an in memory querying
> feature.
Ideally, I don't have to know or care whether its stored in memory,
cached on disk, etc. The app developer should be hidden from hardware
concerns like that if possible. The strong dichotomy between Big Iron
RDBMS and smaller ones is mostly an artificial artifact of historical
habit. The key things are:
1. Don't mirror the DB structure locally if you don't have to.
2. Relational is just better than navigational (to me at least).
>
> Jordan
-T-
AndyW
That pretty much makes my point really. OO reducd down to a set of
rules regardless of the cognetive problems that are used within it.
In other words one has ignored half of what OO is in order to make it
fit to a math concept.
JXStern
wrote:
>But it [math] still carries the philosophical baggage of "physical stuff"
>modeling and hierarchical noun taxonomies (or mutually-exclusive
>subtypes).
But I *like* the baggage of "physical stuff"!
However, I wish to point out that this baggage does not imply the need
for noun-taxonomies or mutually-exclusive subtypes. One problem with
OO is that it suggests you try to taxonimize something, which leads to
multiple-inheritance systems, which leads to (directed-graph)
spaghetti, and both semantic and implementation ambiguities. So, few
people really try do to that with OO, although they make believe they
do, ... and there are always newbies who don't know what they're
getting into!
Second, on the pragmatic level, there are in most languages collection
classes that hold sets of unordered and mixed instances of many
classes. Again, it is mostly a C++-derived idea that it is even
crufty to do this, in a purer sense of OO, it is completely neat, with
polymorphism unrelated to class hierarchies, if indeed there even are
class hierarchies.
I'm a happy relational guy myself, and when I do OO, I make it look
relational. I just see it as OO being underconstrained, but then,
current relational technology is overconstrained in handling only
scalar datatypes, I think. Heck, a row can only belong to a single
table, doesn't that upset you? :)
J.
Don Roby
I'm not sure I follow this. What is your point really?
I don't advocate ignoring things to make them fit math concepts. You
should ignore things only if they don't matter. In this exchange, I was
simply noting that there are math concepts where Bryce apparently can't
see them.
topmind
JXStern wrote:
> On 17 May 2007 08:54:31 -0700, topmind <top...@technologist.com>
> wrote:
>
> >But it [math] still carries the philosophical baggage of "physical stuff"
> >modeling and hierarchical noun taxonomies (or mutually-exclusive
> >subtypes).
"It" was supposed to refer to OO and not "math" I believe.
>
> But I *like* the baggage of "physical stuff"!
I generally don't. The physical world is limiting. It offers
familiarity, but not flexibility. For example, "encapsulation"
sometimes should be situational and relative, not an absolute
property.
>
> However, I wish to point out that this baggage does not imply the need
> for noun-taxonomies or mutually-exclusive subtypes. One problem with
> OO is that it suggests you try to taxonimize something, which leads to
> multiple-inheritance systems, which leads to (directed-graph)
> spaghetti, and both semantic and implementation ambiguities. So, few
> people really try do to that with OO, although they make believe they
> do, ... and there are always newbies who don't know what they're
> getting into!
OOP is "conceptually optimized" for tree taxonomies and mut-ex
subtypes. For one, you get very few opportunities to use polymorphism
if you don't at least use conceptual subtypes. If you don't use much
polymorphism, then it is hard to call the result "OOP". It is
procedural modules in verbose OO clothing.
>
> Second, on the pragmatic level, there are in most languages collection
> classes that hold sets of unordered and mixed instances of many
> classes. Again, it is mostly a C++-derived idea that it is even
> crufty to do this, in a purer sense of OO, it is completely neat, with
> polymorphism unrelated to class hierarchies, if indeed there even are
> class hierarchies.
I have agreed that polymorphism does not require inheritance. But *in
practice* it does usually require at least conceptual subtyping.
Without conceptual subtyping, the actual uses of poly are just not
that common or at least play a minor role in the design.
>
> I'm a happy relational guy myself, and when I do OO, I make it look
> relational. I just see it as OO being underconstrained, but then,
> current relational technology is overconstrained in handling only
> scalar datatypes, I think. Heck, a row can only belong to a single
> table, doesn't that upset you? :)
Relational's rules reign in the kind of shanty-town messes you have in
OO/navigational. Usually if one feels there is a need to violate them,
on further investigation it can be traced back to bad schema design or
limits of a particular vendor's product. If you have a good scenario
to show it being needed, please do show it.
>
> J.
-T-
topmind
Don Roby wrote:
> I don't advocate ignoring things to make them fit math concepts. You
> should ignore things only if they don't matter. In this exchange, I was
> simply noting that there are math concepts where [topmind?] apparently can't
> see them.
Since math can be made Turing Complete, everything is math and math is
everthing, one could perhaps say.
My main point was that by striving to copy the physical "human" world,
OO failed to obsorb some of the better ideas of math-like
abstractions, or at least abstractions that don't *tie* us to physical
concepts (if the word "math-like" is deamed not appropriate).
OO is stuck with the philosophical baggage of what Simula was
orginally made for: physical simulations. In the biz world where one
is modeling intellectual or conceptual property more so than physical
things, OO's roots hurt it, in my opinion. Relational is a system to
manage on a mass-production scale lots of attributes and relationships
in a meta kind of way. OO tends to manage them like a mom-and-pop shop
such that it gets messy and hacky when you try to scale it or change
it over time because it was designed for the here-and-now based on
initial gut "physical" needs. It hard-wires relationships and
taxnomies into the code such that additional relationships or
additional taxnomonies/classifications bump into the original ones in
a harsh way. Relational says, "If I need to be 10-demensional, so be
it". OO says, "Oh, you must go thru dimension 1 and dimension 2 to
reach dimension 3, or else refactor your whole app."
-T-
JXStern
wrote:
>JXStern wrote:
>> On 17 May 2007 08:54:31 -0700, topmind <top...@technologist.com>
>> wrote:
>>
>> >But it [math] still carries the philosophical baggage of "physical stuff"
>> >modeling and hierarchical noun taxonomies (or mutually-exclusive
>> >subtypes).
>
>"It" was supposed to refer to OO and not "math" I believe.
er, yeah, I knew that, sorry, fingers not connected to brain there, I
read "OO" and somehow typed "math".
>> But I *like* the baggage of "physical stuff"!
>
>I generally don't. The physical world is limiting. It offers
>familiarity, but not flexibility. For example, "encapsulation"
>sometimes should be situational and relative, not an absolute
>property.
But it tends to be the physical world we're interested in.
And it turns out that Intel processor chips are actually physical
devices themselves.
Between those two factoids, I have a whole involved philosophy project
on the implications of physicalism to computation - that started out
with some noodling about OO, about fifteen years ago, though it pretty
much lost any direct connection to OO about ten years ago!
>OOP is "conceptually optimized" for tree taxonomies and mut-ex
>subtypes. For one, you get very few opportunities to use polymorphism
>if you don't at least use conceptual subtypes. If you don't use much
>polymorphism, then it is hard to call the result "OOP". It is
>procedural modules in verbose OO clothing.
I'll say it yet again, don't limit your view of the OO concepts to the
limits and common abuses of the C++ world. That's no more valid than
some OO guy looking at relational databases and seeing only isolated
tables or b-tree indexed files.
>I have agreed that polymorphism does not require inheritance. But *in
>practice* it does usually require at least conceptual subtyping.
>Without conceptual subtyping, the actual uses of poly are just not
>that common or at least play a minor role in the design.
Just not true.
I was introduced to OO on a system that allowed you to put a .print()
method on any class, without sharing any explicit ancestor (except
TOFU - top of universe), which didn't need an "abstract" stub to make
it work.
And on any OOP language, you are free to put a "color" property on a
class or instance, without using inheritance. Just as you are always
free to put a .print() method on parallel classes. And when you do,
the simple matter of conventions in the overall namespace provides a
linkage - you the programmer are free to call the .print() method
whether the underlying mechanism realizes they are related or not.
Better of course if you have some print class you can "mixin" via
multiple inheritance or something, but it is not necessary, it is very
easy, and you are making believe OO does not support it.
The problem is in OO you typically have no central meta-dictionary,
the way RDB's are supposed to have, but that meta-stuff is seldom used
in RDB, either. It remains to be developed on both sides.
>Relational's rules reign in the kind of shanty-town messes you have in
>OO/navigational. Usually if one feels there is a need to violate them,
>on further investigation it can be traced back to bad schema design or
>limits of a particular vendor's product. If you have a good scenario
>to show it being needed, please do show it.
I repeat: use OO to write relational-looking code, and you're off to a
good start, and you have much more control over caching and scrolling
and stuff related to realizations (presentation) and not semantics.
On a total app, use the RDB to hold a data model, rather than
"persisted instances" in class-tables, and use the OO front and middle
tiers basically as event handlers and smart caches.
The mess generally comes when OO guys spend a week writing code that
could be done in five minutes of SQL, they accumulate four hundred of
these, then spend months and years "refactoring" stuff they shouldn't
bother with in the first place, and still don't have ACID properties
on because they're not system programmers in the first place. But you
can't blame that on OO. Heck, the greatest problem with most realworld
systems is piss-poor error handling, so why should we expect anyone to
get the architecture right?
J.
topmind
JXStern wrote:
> On 18 May 2007 23:03:37 -0700, topmind <top...@technologist.com>
> wrote:
>
> >JXStern wrote:
> >> On 17 May 2007 08:54:31 -0700, topmind <top...@technologist.com>
> >> wrote:
> >>
> >> >But it [math] still carries the philosophical baggage of "physical stuff"
> >> >modeling and hierarchical noun taxonomies (or mutually-exclusive
> >> >subtypes).
> >
> >"It" was supposed to refer to OO and not "math" I believe.
>
> er, yeah, I knew that, sorry, fingers not connected to brain there, I
> read "OO" and somehow typed "math".
>
> >> But I *like* the baggage of "physical stuff"!
> >
> >I generally don't. The physical world is limiting. It offers
> >familiarity, but not flexibility. For example, "encapsulation"
> >sometimes should be situational and relative, not an absolute
> >property.
>
> But it tends to be the physical world we're interested in.
>
> And it turns out that Intel processor chips are actually physical
> devices themselves.
>
> Between those two factoids, I have a whole involved philosophy project
> on the implications of physicalism to computation - that started out
> with some noodling about OO, about fifteen years ago, though it pretty
> much lost any direct connection to OO about ten years ago!
Not surprising. My philosophising about biz modeling has also lead me
away from OO. The "smorgishboard/buffet of features" is a direct
result of this insight.
>
>
> >OOP is "conceptually optimized" for tree taxonomies and mut-ex
> >subtypes. For one, you get very few opportunities to use polymorphism
> >if you don't at least use conceptual subtypes. If you don't use much
> >polymorphism, then it is hard to call the result "OOP". It is
> >procedural modules in verbose OO clothing.
>
> I'll say it yet again, don't limit your view of the OO concepts to the
> limits and common abuses of the C++ world. That's no more valid than
> some OO guy looking at relational databases and seeing only isolated
> tables or b-tree indexed files.
>
>
> >I have agreed that polymorphism does not require inheritance. But *in
> >practice* it does usually require at least conceptual subtyping.
> >Without conceptual subtyping, the actual uses of poly are just not
> >that common or at least play a minor role in the design.
>
> Just not true.
>
> I was introduced to OO on a system that allowed you to put a .print()
> method on any class, without sharing any explicit ancestor (except
> TOFU - top of universe), which didn't need an "abstract" stub to make
> it work.
I have called this kind of polymorphism "utility" polymorphism.
(Another example is "toString".) However, it is not the cornerstone of
OO biz modeling, at least not the examples that I've seen. One is not
going to build an *entire* app this way.
>
> And on any OOP language, you are free to put a "color" property on a
> class or instance, without using inheritance. Just as you are always
> free to put a .print() method on parallel classes. And when you do,
> the simple matter of conventions in the overall namespace provides a
> linkage - you the programmer are free to call the .print() method
> whether the underlying mechanism realizes they are related or not.
> Better of course if you have some print class you can "mixin" via
> multiple inheritance or something, but it is not necessary, it is very
> easy, and you are making believe OO does not support it.
Again again again, I said it was "not common" or "not key". I did NOT
say it was not possible. You are confusing existence with utility.
>
> The problem is in OO you typically have no central meta-dictionary,
> the way RDB's are supposed to have, but that meta-stuff is seldom used
> in RDB, either. It remains to be developed on both sides.
Developed?
>
>
> >Relational's rules reign in the kind of shanty-town messes you have in
> >OO/navigational. Usually if one feels there is a need to violate them,
> >on further investigation it can be traced back to bad schema design or
> >limits of a particular vendor's product. If you have a good scenario
> >to show it being needed, please do show it.
>
> I repeat: use OO to write relational-looking code, and you're off to a
> good start,
If so, then why not skip the OO?
> and you have much more control over caching and scrolling
> and stuff related to realizations (presentation) and not semantics.
Example? I generally do not want to micromanage caching anyhow. At
best, offer "hints" about when to do garbage collection, etc, but not
micromanage it.
>
> On a total app, use the RDB to hold a data model, rather than
> "persisted instances" in class-tables, and use the OO front and middle
> tiers basically as event handlers and smart caches.
Why not use procedures for event handlers? And what exactly is a
"smart cache"?
>
> The mess generally comes when OO guys spend a week writing code that
> could be done in five minutes of SQL, they accumulate four hundred of
> these, then spend months and years "refactoring" stuff they shouldn't
> bother with in the first place, and still don't have ACID properties
> on because they're not system programmers in the first place. But you
> can't blame that on OO. Heck, the greatest problem with most realworld
> systems is piss-poor error handling, so why should we expect anyone to
> get the architecture right?
OO is too hard to get right because there are too many opinions out
there about what OOD "should be". Popular authors endorse wrapping the
hell out of RDBMS because it allegedly gives them the ability to
switch DB vendors etc. They swear by such crap and defend it to the
death.
>
> J.
-T-
JXStern
wrote:
>Not surprising. My philosophising about biz modeling has also lead me
>away from OO. The "smorgishboard/buffet of features" is a direct
>result of this insight.
Was also standard practice just before OO, circa 1980s.
>I have called this kind of polymorphism "utility" polymorphism.
>(Another example is "toString".) However, it is not the cornerstone of
>OO biz modeling, at least not the examples that I've seen. One is not
>going to build an *entire* app this way.
I don't know what that means. I don't build applications with
polymorphism, I build classes with polymorphism, or perhaps methods
with polymorphism, or namespaces with common entries.
>Again again again, I said it was "not common" or "not key". I did NOT
>say it was not possible. You are confusing existence with utility.
Well, but I think you are confusing what the tool is good for, with
the abuses people commit with it.
>> The problem is in OO you typically have no central meta-dictionary,
>> the way RDB's are supposed to have, but that meta-stuff is seldom used
>> in RDB, either. It remains to be developed on both sides.
>
>Developed?
Higher-level features and tools utilize meta-information, semantics
uses or comprises meta-information, it's a really interesting area -
and lots of attempts are made to use it, but most go nowhere. I think
eventually the right combination will be found and will become
mainstream. MDA and all that.
>> I repeat: use OO to write relational-looking code, and you're off to a
>> good start,
>
>If so, then why not skip the OO?
IOW, use the OO to talk to the RDB and do presentation and connection
management and such.
>> and you have much more control over caching and scrolling
>> and stuff related to realizations (presentation) and not semantics.
>
>Example? I generally do not want to micromanage caching anyhow. At
>best, offer "hints" about when to do garbage collection, etc, but not
>micromanage it.
Oh, you know, the 10,000 (or 10m) result set that you only want to
ship back 100 at a time, but encoding/decoding that everyone wants so
it's more efficient to do in code, effectively locking stuff in RAM,
anything where the connection has to be stateful.
>> On a total app, use the RDB to hold a data model, rather than
>> "persisted instances" in class-tables, and use the OO front and middle
>> tiers basically as event handlers and smart caches.
>
>Why not use procedures for event handlers? And what exactly is a
>"smart cache"?
Because the architecture typically has events at the presentation
level and it's a long way back to the RDB, and the RDB is generally
not also the web service or the object server - though perhaps there's
a trend towards putting all three together. Probably more of a
licensing and pricing issue than technical, at this point.
Again, a smart cache is about the app being able to set priorities on
what stays in RAM, or even result sets saved to disk but not needing
to be recomputed, in spite of not being MRU. All the way up to
automagically replicating partial or entire tables out to middle or
presentation tiers to process there instead of back on the central
server, yet keeping them subscribed to global changes.
>OO is too hard to get right because there are too many opinions out
>there about what OOD "should be". Popular authors endorse wrapping the
>hell out of RDBMS because it allegedly gives them the ability to
>switch DB vendors etc. They swear by such crap and defend it to the
>death.
Sturgeon's Law.
Anyway, I blame Microsoft majorly here, their OO people have tended to
be major abusers and totally ignorant of RDB, and some large
percentage of the rest of the world gets 101% of their knowledge of
things from Microsoft, and there ya go. On the plus side, there's
usually SOMEONE at Microsoft who knows what they're doing, and ADO+
has been designed to support smart caching architectures, and actually
I've rather lost track of what Microsoft is doing in most areas, but
they did have some other good initiatives, too, just to be fair.
J.
topmind
JXStern wrote:
> On 19 May 2007 10:14:21 -0700, topmind <top...@technologist.com>
> wrote:
>
> >Not surprising. My philosophising about biz modeling has also lead me
> >away from OO. The "smorgishboard/buffet of features" is a direct
> >result of this insight.
>
> Was also standard practice just before OO, circa 1980s.
But RDBMS were generally not sufficiently powerful enough back then so
that people had to reinvent a lot of DB-like features in their
procedural code.
>
>
> >I have called this kind of polymorphism "utility" polymorphism.
> >(Another example is "toString".) However, it is not the cornerstone of
> >OO biz modeling, at least not the examples that I've seen. One is not
> >going to build an *entire* app this way.
>
> I don't know what that means. I don't build applications with
> polymorphism, I build classes with polymorphism, or perhaps methods
> with polymorphism, or namespaces with common entries.
I guess I would have to see your code to comment.
>
>
> >Again again again, I said it was "not common" or "not key". I did NOT
> >say it was not possible. You are confusing existence with utility.
>
> Well, but I think you are confusing what the tool is good for, with
> the abuses people commit with it.
I don't know whether they are abuses of OO or flavors of OO. Since
most OO looks like like shanty-town hack-a-class code to me, I don't
see a difference.
> >> and you have much more control over caching and scrolling
> >> and stuff related to realizations (presentation) and not semantics.
> >
> >Example? I generally do not want to micromanage caching anyhow. At
> >best, offer "hints" about when to do garbage collection, etc, but not
> >micromanage it.
>
> Oh, you know, the 10,000 (or 10m) result set that you only want to
> ship back 100 at a time, but encoding/decoding that everyone wants so
> it's more efficient to do in code, effectively locking stuff in RAM,
> anything where the connection has to be stateful.
DB == disk is a fallacy. Anyhow, if stuff has to be buffered in app
RAM for whatever reason, why is OO alleged better at such? I agree
that existing languages don't support "local DBs" very well, but that
is a vendor flaw, not a paradigm flaw. Is OO the consolation prize for
languages that lack end-end-end table handling? Perhaps.
>
>
> >> On a total app, use the RDB to hold a data model, rather than
> >> "persisted instances" in class-tables, and use the OO front and middle
> >> tiers basically as event handlers and smart caches.
> >
> >Why not use procedures for event handlers? And what exactly is a
> >"smart cache"?
>
> Because the architecture typically has events at the presentation
> level and it's a long way back to the RDB, and the RDB is generally
> not also the web service or the object server - though perhaps there's
> a trend towards putting all three together. Probably more of a
> licensing and pricing issue than technical, at this point.
I meant application procedures, not necessarily stored procedures.
>
> Again, a smart cache is about the app being able to set priorities on
> what stays in RAM, or even result sets saved to disk but not needing
> to be recomputed, in spite of not being MRU. All the way up to
> automagically replicating partial or entire tables out to middle or
> presentation tiers to process there instead of back on the central
> server, yet keeping them subscribed to global changes.
In most parts of my apps, there is little reason to let stuff "linger
around". And the few times it is needed would be helped by languages
that provided in-app table handling (which could potentially be
buffered to disk if large). These were common in the late 80's before
OO hype ruined them.
>
>
> >OO is too hard to get right because there are too many opinions out
> >there about what OOD "should be". Popular authors endorse wrapping the
> >hell out of RDBMS because it allegedly gives them the ability to
> >switch DB vendors etc. They swear by such crap and defend it to the
> >death.
>
> Sturgeon's Law.
>
> Anyway, I blame Microsoft majorly here, their OO people have tended to
> be major abusers and totally ignorant of RDB, and some large
> percentage of the rest of the world gets 101% of their knowledge of
> things from Microsoft, and there ya go. On the plus side, there's
> usually SOMEONE at Microsoft who knows what they're doing, and ADO+
> has been designed to support smart caching architectures, and actually
> I've rather lost track of what Microsoft is doing in most areas, but
> they did have some other good initiatives, too, just to be fair.
Well, if you know how to do OO right and can document in detail what
MS-flavor does wrong, then please do show it in a blog or whatnot. I
have yet to see OO biz app code done well. They seem driven by dogma
instead of cost-benefit change analysis. The OO books seem to
overemphasize certain change patterns, and the masses swallow it
without scrutiny.
>
> J.
-T-
S Perryman
> On 17 May 2007 08:54:31 -0700, topmind <top...@technologist.com>
> wrote:
>>But it [math] still carries the philosophical baggage of "physical stuff"
>>modeling and hierarchical noun taxonomies (or mutually-exclusive
>>subtypes).
> But I *like* the baggage of "physical stuff"!
> However, I wish to point out that this baggage does not imply the need
> for noun-taxonomies or mutually-exclusive subtypes. One problem with
> OO is that it suggests you try to taxonimize something, which leads to
> multiple-inheritance systems, which leads to (directed-graph)
> spaghetti, and both semantic and implementation ambiguities. So, few
> people really try do to that with OO, although they make believe they
> do, ... and there are always newbies who don't know what they're
> getting into!
Just to be more precise here :
The OO type substitutability model based on Simula defines substitutability
= inheritance. There are other widely available models *** (structural
equivalence etc) in use in FP prog langs etc where substitutability is not
dictated by an inheritance relationship. These models are far more flexible
and ad-hoc than the Simula model.
[ *** I am talking about strong typing here, which enforces correctness.
In a weakly-typed prog lang (Smalltalk etc) everything is substitutable
for everything anyway so inheritance etc is moot. ]
Regards,
Steven Perryman
Dmitry A. Kazakov
> JXStern wrote:
>
>> On 17 May 2007 08:54:31 -0700, topmind <top...@technologist.com>
>> wrote:
>
>>>But it [math] still carries the philosophical baggage of "physical stuff"
>>>modeling and hierarchical noun taxonomies (or mutually-exclusive
>>>subtypes).
>
>> But I *like* the baggage of "physical stuff"!
>
>> However, I wish to point out that this baggage does not imply the need
>> for noun-taxonomies or mutually-exclusive subtypes. One problem with
>> OO is that it suggests you try to taxonimize something, which leads to
>> multiple-inheritance systems, which leads to (directed-graph)
>> spaghetti, and both semantic and implementation ambiguities. So, few
>> people really try do to that with OO, although they make believe they
>> do, ... and there are always newbies who don't know what they're
>> getting into!
>
> Just to be more precise here :
>
> The OO type substitutability model based on Simula defines substitutability
> = inheritance. There are other widely available models *** (structural
> equivalence etc) in use in FP prog langs etc where substitutability is not
> dictated by an inheritance relationship. These models are far more flexible
> and ad-hoc than the Simula model.
Also, spaghetti rather represent an undirected graph. (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
topmind
wrote:
> On Sun, 20 May 2007 14:43:34 +0100, S Perryman wrote:
> > JXStern wrote:
>
> >> wrote:
>
> >>>But it [math] still carries the philosophical baggage of "physical stuff"
> >>>modeling and hierarchical noun taxonomies (or mutually-exclusive
> >>>subtypes).
>
> >> But I *like* the baggage of "physical stuff"!
>
> >> However, I wish to point out that this baggage does not imply the need
> >> for noun-taxonomies or mutually-exclusive subtypes. One problem with
> >> OO is that it suggests you try to taxonimize something, which leads to
> >> multiple-inheritance systems, which leads to (directed-graph)
> >> spaghetti, and both semantic and implementation ambiguities. So, few
> >> people really try do to that with OO, although they make believe they
> >> do, ... and there are always newbies who don't know what they're
> >> getting into!
>
> > Just to be more precise here :
>
> > The OO type substitutability model based on Simula defines substitutability
> > = inheritance. There are other widely available models *** (structural
> > equivalence etc) in use in FP prog langs etc where substitutability is not
> > dictated by an inheritance relationship.
And it is difficult to tell/define whether such features are OO or FP
or a hybrid. One has to hold back on giving OO credit.
> > These models are far more flexible
> > and ad-hoc than the Simula model.
>
> Also, spaghetti rather represent an undirected graph. (:-))
It still comes down to managing "variations on a theme" with graphs
versus sets. That seems to be the big picture here. Sets and
polymorphism are at odds with each other for the most part.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
-T-
S Perryman
> On May 20, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
SP>The OO type substitutability model based on Simula defines substitutability
SP>= inheritance. There are other widely available models *** (structural
SP>equivalence etc) in use in FP prog langs etc where substitutability is not
SP>dictated by an inheritance relationship.
> And it is difficult to tell/define whether such features are OO or FP
> or a hybrid. One has to hold back on giving OO credit.
1. Poor netiquette IMHO to reply to one persons' words in a posting to
another person.
2. Type substitutability is about *types* .
Type theory in computer programs is a *maths/CS* concept.
Therefore credit cannot be given to any particular programming style for
the concept (although Simula did a bring a practical form into the
programming mainstream) .
That should clear up any ignorance you have on the origins of type
substitutability.
SP>These models are far more flexible and ad-hoc than the Simula model.
>>Also, spaghetti rather represent an undirected graph. (:-))
> It still comes down to managing "variations on a theme" with graphs
> versus sets. That seems to be the big picture here. Sets and
> polymorphism are at odds with each other for the most part.
Type substitutability is all about sets. Specifically : structural
equivalence = (property) subsets. In a strongly-typed world, this
is fundamental regardless of the specific substitutability model (Simula
etc) .
That should clear up any ignorance you have on the relationship between
set theory and type substitutability.
Regards,
Steven Perryman
topmind
S Perryman wrote:
> topmind wrote:
>
> > On May 20, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> SP>The OO type substitutability model based on Simula defines substitutability
> SP>= inheritance. There are other widely available models *** (structural
> SP>equivalence etc) in use in FP prog langs etc where substitutability is not
> SP>dictated by an inheritance relationship.
>
> > And it is difficult to tell/define whether such features are OO or FP
> > or a hybrid. One has to hold back on giving OO credit.
>
> 1. Poor netiquette IMHO to reply to one persons' words in a posting to
> another person.
>
> 2. Type substitutability is about *types* .
> Type theory in computer programs is a *maths/CS* concept.
>
> Therefore credit cannot be given to any particular programming style for
> the concept (although Simula did a bring a practical form into the
> programming mainstream) .
>
> That should clear up any ignorance you have on the origins of type
> substitutability.
There is no industry concensus that OO is about "types". You are
mistaking your personal ADT view of OO for everybody else's.
>
>
> SP>These models are far more flexible and ad-hoc than the Simula model.
>
> >>Also, spaghetti rather represent an undirected graph. (:-))
>
> > It still comes down to managing "variations on a theme" with graphs
> > versus sets. That seems to be the big picture here. Sets and
> > polymorphism are at odds with each other for the most part.
>
> Type substitutability is all about sets. Specifically : structural
> equivalence = (property) subsets. In a strongly-typed world, this
> is fundamental regardless of the specific substitutability model (Simula
> etc) .
It can be emulated with sets (T.E. again), but saying it is "about"
sets is going to far.
>
> That should clear up any ignorance you have on the relationship between
> set theory and type substitutability.
"Ignorance"? This from somebody lecturing me about "poor netiquette".
The "H" word comes to mind.
>
>
> Regards,
> Steven Perryman
-T-
S Perryman
> S Perryman wrote:
SP>The OO type substitutability model based on Simula defines substitutability
SP>= inheritance. There are other widely available models *** (structural
SP>equivalence etc) in use in FP prog langs etc where substitutability is not
SP>dictated by an inheritance relationship.
TM>And it is difficult to tell/define whether such features are OO or FP
TM>or a hybrid. One has to hold back on giving OO credit.
>>2. Type substitutability is about *types* .
>>Type theory in computer programs is a *maths/CS* concept.
>>Therefore credit cannot be given to any particular programming style for
>>the concept (although Simula did a bring a practical form into the
>>programming mainstream) .
>>That should clear up any ignorance you have on the origins of type
>>substitutability.
> There is no industry concensus that OO is about "types". You are
> mistaking your personal ADT view of OO for everybody else's.
1. There is plenty of consensus in the maths/CS community about types in
computer programs.
2. Thus I am not mistaking my "personal view of OO" (whatever you actually
believe it is) . Albeit that my views on type substitutability are heavily
influenced by the (consensus) body of work in the CS community on type
theory.
That should clear up any ignorance you have about the consensus on type
substitutability in the CS field, and my views of OO.
>>Type substitutability is all about sets. Specifically : structural
>>equivalence = (property) subsets. In a strongly-typed world, this
>>is fundamental regardless of the specific substitutability model (Simula
>>etc) .
> It can be emulated with sets (T.E. again), but saying it is "about"
> sets is going to far.
Type substitutability is frequently discussed/defined in *set-theoretic
terms* . Therefore it is "about" sets. Specifically : *property* sets.
Again, that should clear up any ignorance you have on the relationship
between set theory and type substitutability.
>>That should clear up any ignorance you have on the relationship between
>>set theory and type substitutability.
> "Ignorance"? This from somebody lecturing me about "poor netiquette".
> The "H" word comes to mind.
Go and get any dictionary and read what the word actually means (ignorance
about the word "ignorance" is pretty much hitting rock-bottom IMHO) .
Regards,
Steven Perryman
topmind
S Perryman wrote:
> topmind wrote:
> > There is no industry concensus that OO is about "types". You are
> > mistaking your personal ADT view of OO for everybody else's.
>
> 1. There is plenty of consensus in the maths/CS community about types in
> computer programs.
We are talking about OO, not types in general.
> Steven Perryman
-T-
S Perryman
> S Perryman wrote:
TM>There is no industry concensus that OO is about "types". You are
TM>mistaking your personal ADT view of OO for everybody else's.
>>1. There is plenty of consensus in the maths/CS community about types in
>>computer programs.
> We are talking about OO, not types in general.
1. Actually this particular thread was started by me to tell JXStern that
any notion of "noun-taxonomies or mutually-exclusive subtypes" will depend
on the type substitutability model. The predominant form used in OOP
(Simula) is indeed subject to such critique. Other models that are
widely-available in other prog langs that support OO (FP-based prog langs
such as OCaml etc) have no such problems.
2. There is plenty of consensus in the OO field about types (as there is
about types in general) . As if to easily prove the point, at the weekend I
picked up the recently published 3rd edition of a well-known book on OO,
that defines/discusses 'class' with reference to a seminal paper on type
theory that was first published over 20 years ago. I look in other books
by other authors and I see same/similar consensus, more often than not
using/citing the same predecessor publications (ie a body of knowledge) .
That should clear up any ignorance you have about the consensus in the CS
community on types in the context of OO.
Of course, lack of consensus can be easily proved by you. You only need to
provide a set of cited definitions of type/class in the OO field (the
more prominent in the field the source is, the better) that are so
obviously different from eachother as to render a consensus (actually or
practically) impossible.
But while comp.object awaits such a proof, to summarise :
Claims about what form a set of type definitions will take in an OO program
will depend on the type substitutability model(s) supported by the
prog lang being used.
Regards,
Steven Perryman
Mark Nicholls
> topmind wrote:
> > S Perryman wrote:
>
> TM>There is no industry concensus that OO is about "types". You are
> TM>mistaking your personal ADT view of OO for everybody else's.
>
> >>1. There is plenty of consensus in the maths/CS community about types in
> >>computer programs.
> > We are talking about OO, not types in general.
>
> 1. Actually this particular thread was started by me to tell JXStern that
> any notion of "noun-taxonomies or mutually-exclusive subtypes" will depend
> on the type substitutability model. The predominant form used in OOP
> (Simula) is indeed subject to such critique. Other models that are
> widely-available in other prog langs that support OO (FP-based prog langs
> such as OCaml etc) have no such problems.
Sounds interesting can you give me an example...or a reference to
somewhere I can read about it.
topmind
S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>There is no industry concensus that OO is about "types". You are
> TM>mistaking your personal ADT view of OO for everybody else's.
>
> >>1. There is plenty of consensus in the maths/CS community about types in
> >>computer programs.
>
> > We are talking about OO, not types in general.
>
> 1. Actually this particular thread was started by me to tell JXStern that
> any notion of "noun-taxonomies or mutually-exclusive subtypes" will depend
> on the type substitutability model. The predominant form used in OOP
> (Simula) is indeed subject to such critique. Other models that are
> widely-available in other prog langs that support OO (FP-based prog langs
> such as OCaml etc) have no such problems.
With "FP". Again, how do we know whether this is a feature of FP or
OO?
>
> 2. There is plenty of consensus in the OO field about types (as there is
> about types in general) . As if to easily prove the point, at the weekend I
> picked up the recently published 3rd edition of a well-known book on OO,
> that defines/discusses 'class' with reference to a seminal paper on type
> theory that was first published over 20 years ago. I look in other books
> by other authors and I see same/similar consensus, more often than not
> using/citing the same predecessor publications (ie a body of knowledge) .
You tend toward strong-typed OO languages, and thus your books
probably reflect that view. Smalltalk-influenced languages have much
less of a typish viewpoint, if any. In short, you and your library are
a biased source.
Some even say that Alan Kay "get's to" define OOP since he coined the
term. (I don't necessarily agree with this.)
>
> That should clear up any ignorance you have about the consensus in the CS
> community on types in the context of OO.
The "ignorance" is yours.
>
> Of course, lack of consensus can be easily proved by you. You only need to
> provide a set of cited definitions of type/class in the OO field (the
> more prominent in the field the source is, the better) that are so
> obviously different from eachother as to render a consensus (actually or
> practically) impossible.
>
>
> But while comp.object awaits such a proof, to summarise :
>
> Claims about what form a set of type definitions will take in an OO program
> will depend on the type substitutability model(s) supported by the
> prog lang being used.
>
>
> Regards,
> Steven Perryman
-T-
S Perryman
> On 21 May, 10:09, S Perryman <q...@q.net> wrote:
>1. Actually this particular thread was started by me to tell JXStern that
>>any notion of "noun-taxonomies or mutually-exclusive subtypes" will depend
>>on the type substitutability model. The predominant form used in OOP
>>(Simula) is indeed subject to such critique. Other models that are
>>widely-available in other prog langs that support OO (FP-based prog langs
>>such as OCaml etc) have no such problems.
> Sounds interesting can you give me an example...or a reference to
> somewhere I can read about it.
type Me
{
name : Name ;
age : Age ;
employeeId : id ;
}
type Person
{
name : Name ;
age : Age ;
}
type Employee
{
name : Name ;
number : Id ;
}
type NamedThing
{
name : Name ;
}
type AgedThing
{
age : Age ;
}
type JustAMereNumberInTheGrandPlan
{
number : Id ;
}
Me me ; // obviously :-)
Person p = nil ;
Employee e = nil ;
NamedThing n = nil ;
AgedThing a = nil ;
JustAMereNumberInTheGrandPlan x = nil ;
p = me ;
e = me ;
n = me ; n = p ; n = e ;
a = me ; a = p ;
x = me ; x = e ;
The properties in each type are not mutually exclusive.
Therefore the types are not mutually exclusive.
The fundamental basis of type substitutability (structural equivalence)
allows the above program to be legal.
Some schemes (FP prog langs etc) make no further demands of their
substitutability models. Other schemes (Simula/OO, Liskov/Wing subtypes
etc) have additional (sometimes different) demands.
Regards,
Steven Perryman
JXStern
wrote:
>> Was also standard practice just before OO, circa 1980s.
>
>But RDBMS were generally not sufficiently powerful enough back then so
>that people had to reinvent a lot of DB-like features in their
>procedural code.
You see, the OO guys still do this today, nothing ever changes! :)
>> I don't know what that means. I don't build applications with
>> polymorphism, I build classes with polymorphism, or perhaps methods
>> with polymorphism, or namespaces with common entries.
>
>I guess I would have to see your code to comment.
That's just a comment about where any and all polymorphism resides,
really, I'm not claiming any magical approach.
>DB == disk is a fallacy. Anyhow, if stuff has to be buffered in app
>RAM for whatever reason, why is OO alleged better at such? I agree
>that existing languages don't support "local DBs" very well, but that
>is a vendor flaw, not a paradigm flaw. Is OO the consolation prize for
>languages that lack end-end-end table handling? Perhaps.
Well, to some degree, yes! Procedural/OO is still mostly preferred
for general programming, as opposed to say Prolog, which is to a large
degree non-procedural and very much like SQL.
>In most parts of my apps, there is little reason to let stuff "linger
>around". And the few times it is needed would be helped by languages
>that provided in-app table handling (which could potentially be
>buffered to disk if large). These were common in the late 80's before
>OO hype ruined them.
Not so much OO there, as the switch to thin clients and stateless
web-service apps. OO was just along for the ride.
>> Sturgeon's Law.
>>
>> Anyway, I blame Microsoft majorly here, their OO people have tended to
>> be major abusers and totally ignorant of RDB, and some large
>> percentage of the rest of the world gets 101% of their knowledge of
>> things from Microsoft, and there ya go. On the plus side, there's
>> usually SOMEONE at Microsoft who knows what they're doing, and ADO+
>> has been designed to support smart caching architectures, and actually
>> I've rather lost track of what Microsoft is doing in most areas, but
>> they did have some other good initiatives, too, just to be fair.
>
>Well, if you know how to do OO right and can document in detail what
>MS-flavor does wrong, then please do show it in a blog or whatnot. I
>have yet to see OO biz app code done well. They seem driven by dogma
>instead of cost-benefit change analysis. The OO books seem to
>overemphasize certain change patterns, and the masses swallow it
>without scrutiny.
Sturgeon's Law.
Sturgeon's Law.
Sturgeon's Law.
Sturgeon's Law.
Sturgeon's Law.
J.
JXStern
>> But I *like* the baggage of "physical stuff"!
>
>> However, I wish to point out that this baggage does not imply the need
>> for noun-taxonomies or mutually-exclusive subtypes. One problem with
>> OO is that it suggests you try to taxonimize something, which leads to
>> multiple-inheritance systems, which leads to (directed-graph)
>> spaghetti, and both semantic and implementation ambiguities. So, few
>> people really try do to that with OO, although they make believe they
>> do, ... and there are always newbies who don't know what they're
>> getting into!
>
>Just to be more precise here :
>
>The OO type substitutability model based on Simula defines substitutability
>= inheritance. There are other widely available models *** (structural
>equivalence etc) in use in FP prog langs etc where substitutability is not
>dictated by an inheritance relationship. These models are far more flexible
>and ad-hoc than the Simula model.
>
>[ *** I am talking about strong typing here, which enforces correctness.
> In a weakly-typed prog lang (Smalltalk etc) everything is substitutable
> for everything anyway so inheritance etc is moot. ]
All OK by me.
I think a LOT of what bothers topmind are artifacts of Simula/C++
narrow substitutability. I know that's a lot of what bothers *me*!
That, and OO suggests that you can and should and must taxonomize the
world, and no matter the language, that turns out to be more work than
it looks like, and is a different task in many ways from writing a
program to do some particular X.
J.
S Perryman
> S Perryman wrote:
TM>We are talking about OO, not types in general.
>>1. Actually this particular thread was started by me to tell JXStern that
>>any notion of "noun-taxonomies or mutually-exclusive subtypes" will depend
>>on the type substitutability model. The predominant form used in OOP
>>(Simula) is indeed subject to such critique. Other models that are
>>widely-available in other prog langs that support OO (FP-based prog langs
>>such as OCaml etc) have no such problems.
> With "FP". Again, how do we know whether this is a feature of FP or OO?
Irrelevant. The originator of a model does not change the fact that that
model is *being used by existing* OO prog langs.
What does matter is that there are OO prog langs that are not constrained
by the type substitutability model of Simula. From this it is therefore
obvious (as has been stated several times) that your claims about OO can
at best only apply to *one specific* type substitutability model.
Therefore in future you will now have to qualify any claims you make that
involve type substitutability, with the *specific* substitutability models.
Unless of course you have scenarios that are problems for all widely-known/
used OO type substitutability models ...
>>2. There is plenty of consensus in the OO field about types (as there is
>>about types in general) . As if to easily prove the point, at the weekend I
>>picked up the recently published 3rd edition of a well-known book on OO,
>>that defines/discusses 'class' with reference to a seminal paper on type
>>theory that was first published over 20 years ago. I look in other books
>>by other authors and I see same/similar consensus, more often than not
>>using/citing the same predecessor publications (ie a body of knowledge) .
> You tend toward strong-typed OO languages, and thus your books
> probably reflect that view.
And what "view" would that be ??
> Smalltalk-influenced languages have much less of a typish viewpoint, if any.
Smalltalk has a very strong type viewpoint.
Specifically, there is one type form : the class.
Classes also can inherit from other classes (as conceived by Simula) .
Weakly-typed programming languages such as Smalltalk diff from strongly-
typed prog langs in that variables and operation input/output parameters
have no type associated with them. Therefore the explicit type of said
artifacts has not been declared or inferred.
For type substitutability, this means that the fundamental basis
(structural equivalence) is applied at the point of execution rather than
possibly being done long before that point. The end result (an unexecutable
program vs an executable one that may crash) may be different, but the same
fundamental application is done as is the case with strongly-typed prog
langs.
That should clear up any ignorance you have about the relationship and use
of types between/in strongly and weakly-typed OO prog langs.
> In short, you and your library are a biased source.
My library (which includes at least 150+ books on OO A/D/P - including
several on Smalltalk) is probably as wide-ranging and balanced in scope
and content as many.
That should clear up any ignorance you have about my companys' technical
library and its "bias" .
> Some even say that Alan Kay "get's to" define OOP since he coined the
> term. (I don't necessarily agree with this.)
Actually I do agree with this.
Alan Kay used the term "object-oriented" , for which his basic definitions
can be found. Those definitions I recall speak in terms of a world of
objects (instances of classes) interacting with each other via "sending
messages" .
>>That should clear up any ignorance you have about the consensus in the CS
>>community on types in the context of OO.
> The "ignorance" is yours.
For you, unfortunately not.
Which would explain why you have yet to cite prominent definitions in the
OO field regarding type/class that are so vastly different to each other.
Regards,
Steven Perryman
topmind
Yawn. Such are more or less *associative arrays* with operations that
can merge attributes, and perhaps rules to not allow certain
attributes (not clear on this from example). Whether programming with
such makes something "better", well, it is not my job to show such. I
would rather manage massive amounts of attributes using RDBMS, which
provide order, consistency, scalability, and out-of-the-box tools,
such as query languages and schema browsers. RDBMS are the best
scalling attribute managers known to date (for at least the biz
domain). I've seen such in action to manage complex customer product
categories so that one didn't have to hard-wire taxonomies/categories
into app code. (I disagreed with some of their schema design, but it
did its job.)
Whether such associative-arrays in type clothing gets to be called
"types" or not depends on which definition of "types" one is using.
With vague enuf definitions, everything is types and everything is OO,
allowing everything to take credit for everything. Just like 1st-
month Kindergarten: without rigor, everybody's special.
-T-
S Perryman
> On Sun, 20 May 2007 14:43:34 +0100, S Perryman <q...@q.net> wrote:
>>The OO type substitutability model based on Simula defines substitutability
>>= inheritance. There are other widely available models *** (structural
>>equivalence etc) in use in FP prog langs etc where substitutability is not
>>dictated by an inheritance relationship. These models are far more flexible
>>and ad-hoc than the Simula model.
>>[ *** I am talking about strong typing here, which enforces correctness.
>> In a weakly-typed prog lang (Smalltalk etc) everything is substitutable
>> for everything anyway so inheritance etc is moot. ]
> All OK by me.
> I think a LOT of what bothers topmind are artifacts of Simula/C++
> narrow substitutability. I know that's a lot of what bothers *me*!
This particular thread has proved IMHO that regardless of what bothers you,
topmind doesn't understand enough about type substitutability to be
bothered period.
> That, and OO suggests that you can and should and must taxonomize the
> world, and no matter the language, that turns out to be more work than
> it looks like, and is a different task in many ways from writing a
> program to do some particular X.
The pre-dominant type substitutability model in OOP is the one Simula
devised. All texts for a prog lang that have only that model can by
definition only really speak in terms of that model (except of course
perhaps as a cursory nod to the fact that other models exist) .
More general books on OO (type theory particularly) are able to discuss
the various models (separately, compare/contrast etc) more appropriately.
I have several books that do exactly this.
Regards,
Steven Perryman
S Perryman
> S Perryman wrote:
[ example for Mark Nicholls snipped ... ]
>>The properties in each type are not mutually exclusive.
>>Therefore the types are not mutually exclusive.
>>The fundamental basis of type substitutability (structural equivalence)
>>allows the above program to be legal.
>>Some schemes (FP prog langs etc) make no further demands of their
>>substitutability models. Other schemes (Simula/OO, Liskov/Wing subtypes
>>etc) have additional (sometimes different) demands.
> Yawn. Such are more or less *associative arrays* with operations that
> can merge attributes
No such thing. Certainly not in specification, probably not in
implementation (although you are welcome to show the latter for prog langs
such as OCaml etc as I am ignorant as to the underlying implementation of
type substitutability in FP - the function mappings/bindings etc) .
>and perhaps rules to not allow certain attributes (not clear on this from
>example).
If you do not understand the fundamental basis of type substitutability
(structural equivalence) , nor how type substitutability is written in OO
prog langs, yes the example will not be clear to you.
> Whether programming with
> such makes something "better", well, it is not my job to show such. I
> would rather manage massive amounts of attributes using RDBMS, which
> provide order, consistency, scalability, and out-of-the-box tools,
> such as query languages and schema browsers.
1. All irrelevant to this thread.
2. YAAAAAAAAAAAAAAAAAAAAWN.
Regards,
Steven Perryman
topmind
> JXStern wrote:
> > On Sun, 20 May 2007 14:43:34 +0100, S Perryman <q...@q.net> wrote:
> >>The OO type substitutability model based on Simula defines substitutability
> >>= inheritance. There are other widely available models *** (structural
> >>equivalence etc) in use in FP prog langs etc where substitutability is not
> >>dictated by an inheritance relationship. These models are far more flexible
> >>and ad-hoc than the Simula model.
> >>[ *** I am talking about strong typing here, which enforces correctness.
> >> In a weakly-typed prog lang (Smalltalk etc) everything is substitutable
> >> for everything anyway so inheritance etc is moot. ]
> > All OK by me.
> > I think a LOT of what bothers topmind are artifacts of Simula/C++
> > narrow substitutability. I know that's a lot of what bothers *me*!
>
> This particular thread has proved IMHO that regardless of what bothers you,
> topmind doesn't understand enough about type substitutability to be
> bothered period.
Enough with the rudeness, okay? I'm trying to be cival to you, but my
patience is running thin.
>
> > That, and OO suggests that you can and should and must taxonomize the
> > world, and no matter the language, that turns out to be more work than
> > it looks like, and is a different task in many ways from writing a
> > program to do some particular X.
>
> The pre-dominant type substitutability model in OOP is the one Simula
> devised.
This is not the consensus opinion, as already described. You are
ignoring the work of Alan Kay. The "Smalltalk" OO view has been
battling the Simula/C++/Eiffel view of what OO is for quite a while.
Neither side has "won".
> All texts for a prog lang that have only that model can by
> definition only really speak in terms of that model (except of course
> perhaps as a cursory nod to the fact that other models exist) .
>
> More general books on OO (type theory particularly) are able to discuss
> the various models (separately, compare/contrast etc) more appropriately.
> I have several books that do exactly this.
Are you saying you need a book to explain your opinion because you are
crappy at articulating? That's what it sounds like as I read it.
Nor did you offer proof that your books represent a good sample of the
general OO community, and not just the strong-type-loving community.
Stating your claims over and over does not make it so.
>
> Regards,
> Steven Perryman
-T-
topmind
S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> [ example for Mark Nicholls snipped ... ]
>
> >>The properties in each type are not mutually exclusive.
> >>Therefore the types are not mutually exclusive.
>
> >>The fundamental basis of type substitutability (structural equivalence)
> >>allows the above program to be legal.
>
> >>Some schemes (FP prog langs etc) make no further demands of their
> >>substitutability models. Other schemes (Simula/OO, Liskov/Wing subtypes
> >>etc) have additional (sometimes different) demands.
>
> > Yawn. Such are more or less *associative arrays* with operations that
> > can merge attributes
>
> No such thing.
Writing such routines for associative arrays is relatively trivial. If
your language reinvents associative arrays with attribute merging and
validation management built into the syntax, well la dee da.
Glorified associative arrays are the Grand Solution? I don't think so.
Give up this attribute-diddling-in-app-code and go Sets and RDBs. Life
will be easier. Types scale poorly.
> Certainly not in specification, probably not in
> implementation (although you are welcome to show the latter for prog langs
> such as OCaml etc as I am ignorant as to the underlying implementation of
> type substitutability in FP - the function mappings/bindings etc) .
>
>
> >and perhaps rules to not allow certain attributes (not clear on this from
> >example).
>
> If you do not understand the fundamental basis of type substitutability
> (structural equivalence) , nor how type substitutability is written in OO
> prog langs, yes the example will not be clear to you.
If you do not understand how to articulate your point of view and thus
have to hide behind a book, then you are the problem, not me.
>
>
> > Whether programming with
> > such makes something "better", well, it is not my job to show such. I
> > would rather manage massive amounts of attributes using RDBMS, which
> > provide order, consistency, scalability, and out-of-the-box tools,
> > such as query languages and schema browsers.
>
> 1. All irrelevant to this thread.
> 2. YAAAAAAAAAAAAAAAAAAAAWN.
Indeed.
>
>
> Regards,
> Steven Perryman
-T-
Dmitry A. Kazakov
Speaking at this level of generality (and maybe lack of substance), how a
reasonable set theory can be built without is-member-of? Or, in terms of
topmind's beloved tables, can a table be a cell of itself? Isn't "A is a
table, B is a cell, C is a row", anything but taxonomization, be it damned?
Isn't "this piece of world to be modeled by relational algebra" a
taxonomization? Only God can speak declarative language. For us, mortals,
there has to be a machine to infer from declarations. By which set of
rules? Is there one for everything? Warning, by answering "no" you start to
taxonomize...
Universe
>
> - Show quoted text -
Couldn't you have the best of both worlds? To me the best of both
would be the ability to substitute any type whether the type is one
member of a set of a flat horizontal bush, or on the other hand, if
the type is a member of one or more vertical trees. To make things
easy a substitutable type would be able to auto pick up minimal
functionality required (per method or via a set of methods) for the
place where it is being substituted if that type did not implement
required functionality itself.
Elliott
---
Effective modelling (abstraction) reduces complexity in all areas.
topmind
Your point?
> Or, in terms of
> topmind's beloved tables, can a table be a cell of itself?
Does it need to be?
> Isn't "A is a
> table, B is a cell, C is a row", anything but taxonomization, be it damned?
> Isn't "this piece of world to be modeled by relational algebra" a
> taxonomization? Only God can speak declarative language. For us, mortals,
> there has to be a machine to infer from declarations. By which set of
> rules? Is there one for everything? Warning, by answering "no" you start to
> taxonomize...
I am not sure what your point is. OO tends to use DAG's for
classification systems while relational uses (a form of) set theory.
It is not classification versus non-classification, but rather a
matter of which kind is "best": DAGs or sets. I find sets a better fit
because they avoid IS-A related problems. RDBMS are industrial-
strength has-a management systems. OO can do has-a, but is messy and
not very scalable at it. Plus, any classification/taxonomy that
depends on the app language cannot easily share that info with other
languages. Defining domain noun classifications in the DB allows
Smalltalk, Eiffle, Lisp, Report writers, etc. to all see the
classification info. We don't have to marry Java etc.
There is also the definition issue of whether or not OO is about
"types". I would prefer we study somewhat realistic examples rather
than get mired in "OO" and "type" definition battles, which cannot be
settled until there are official definitions. Perryman wants to elect
himself God of Definitions, but I won't let him.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
S Perryman
> S Perryman wrote:
SP>The fundamental basis of type substitutability (structural equivalence)
SP>>allows the above program to be legal.
SP>Some schemes (FP prog langs etc) make no further demands of their
SP>substitutability models. Other schemes (Simula/OO, Liskov/Wing subtypes
SP>etc) have additional (sometimes different) demands.
TM>Yawn. Such are more or less *associative arrays* with operations that
TM>can merge attributes
>>No such thing.
> Writing such routines for associative arrays is relatively trivial. If
> your language reinvents associative arrays with attribute merging and
> validation management built into the syntax, well la dee da.
> Glorified associative arrays are the Grand Solution? I don't think so.
> Give up this attribute-diddling-in-app-code and go Sets and RDBs. Life
> will be easier. Types scale poorly.
So you are claiming that the type substitutability models used in FP langs
"reinvents associative arrays" ??
>>If you do not understand the fundamental basis of type substitutability
>>(structural equivalence) , nor how type substitutability is written in OO
>>prog langs, yes the example will not be clear to you.
> If you do not understand how to articulate your point of view and thus
> have to hide behind a book, then you are the problem, not me.
1. I am responsible for the fact that you do not understand the fundamental
basis of type substitutability ??
2. What "book" am I allegedly hiding behind ??
TM>Whether programming with
TM>such makes something "better", well, it is not my job to show such. I
TM>would rather manage massive amounts of attributes using RDBMS, which
TM>provide order, consistency, scalability, and out-of-the-box tools,
TM>such as query languages and schema browsers.
>>1. All irrelevant to this thread.
>>2. YAAAAAAAAAAAAAAAAAAAAWN.
> Indeed.
1. Thank you for admitting it.
2. 1 might beg the question why you wrote it in the first place (actually
to me it doesn't) .
Regards,
Steven Perryman
S Perryman
> On May 21, 8:57 am, S Perryman <q...@q.net> wrote:
>>JXStern wrote:
>>>That, and OO suggests that you can and should and must taxonomize the
>>>world, and no matter the language, that turns out to be more work than
>>>it looks like, and is a different task in many ways from writing a
>>>program to do some particular X.
>>The pre-dominant type substitutability model in OOP is the one Simula
>>devised.
> This is not the consensus opinion, as already described.
1. You do not appear to understand the english word "predominant" . I
suggest that you read the definition in a dictionary and then respond
after understanding the definition.
2. What is the "consensus opinion, as already described" of type
substitutability in OO ??
Going back through the postings in this thread and I find no such
definition from you, nor any citing to a reference source from which you
may have taken a definition.
Have I missed something (I don't think I have) ??
> You are
> ignoring the work of Alan Kay. The "Smalltalk" OO view has been
> battling the Simula/C++/Eiffel view of what OO is for quite a while.
> Neither side has "won".
As written above, I am waiting for you to tell us what the Smalltalk
"OO view" of type substitutability actually is.
SP>All texts for a prog lang that have only that model can by
SP>definition only really speak in terms of that model (except of course
SP>perhaps as a cursory nod to the fact that other models exist) .
>>More general books on OO (type theory particularly) are able to discuss
>>the various models (separately, compare/contrast etc) more appropriately.
>>I have several books that do exactly this.
> Are you saying you need a book to explain your opinion because you are
> crappy at articulating? That's what it sounds like as I read it.
Well no doubt it does, because as already stated, you appear to have some
serious mis-understanding of the meaning of words in the English language.
But I will bear this in mind, and attempt to re-explain :
Books on a specific OO prog lang, that supports a *specific type
substitutability model* , are not really likely to discuss type
substitutability models that the prog lang does not support. Books on OO in
general are more likely to discuss "variations on the theme" because their
target audience is not by definition the users of a specific OO prog lang.
> Nor did you offer proof that your books represent a good sample of the
> general OO community, and not just the strong-type-loving community.
> Stating your claims over and over does not make it so.
What is the above text being written in relation to ??
Ah I see, it appears to be written in response to a completely different
posting by me in this thread (message id <f2sev8$jci$1...@aioe.org> ) . Not
very good netiquette from you is it.
Oh ... yes ... of course there would be no reply from you to that message
(obviously) .
Regards,
Steven Perryman
topmind
S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> SP>The fundamental basis of type substitutability (structural equivalence)
> SP>>allows the above program to be legal.
>
> SP>Some schemes (FP prog langs etc) make no further demands of their
> SP>substitutability models. Other schemes (Simula/OO, Liskov/Wing subtypes
> SP>etc) have additional (sometimes different) demands.
>
> TM>Yawn. Such are more or less *associative arrays* with operations that
> TM>can merge attributes
>
> >>No such thing.
>
> > Writing such routines for associative arrays is relatively trivial. If
> > your language reinvents associative arrays with attribute merging and
> > validation management built into the syntax, well la dee da.
>
> > Glorified associative arrays are the Grand Solution? I don't think so.
>
> > Give up this attribute-diddling-in-app-code and go Sets and RDBs. Life
> > will be easier. Types scale poorly.
>
> So you are claiming that the type substitutability models used in FP langs
> "reinvents associative arrays" ??
I don't wish to talk about FP here. If the traits you seek require FP
languages, then they may not be OO traits, but FP traits. Why mix FP
issues into this? Again, you seem to be trying to find a way to force
your personal view of what OO is into this.
>
> >>If you do not understand the fundamental basis of type substitutability
> >>(structural equivalence) , nor how type substitutability is written in OO
> >>prog langs, yes the example will not be clear to you.
>
> > If you do not understand how to articulate your point of view and thus
> > have to hide behind a book, then you are the problem, not me.
>
> 1. I am responsible for the fact that you do not understand the fundamental
> basis of type substitutability ??
Am I responsable for the fact that you keep trying to change the
subject from OO to FP?
>
> 2. What "book" am I allegedly hiding behind ??
You claimed your explanation was in a book(s). Did you forget that
too?
>
> Regards,
> Steven Perryman
-T-
topmind
S Perryman wrote:
> topmind wrote:
>
> > On May 21, 8:57 am, S Perryman <q...@q.net> wrote:
>
> >>JXStern wrote:
>
> >>>That, and OO suggests that you can and should and must taxonomize the
> >>>world, and no matter the language, that turns out to be more work than
> >>>it looks like, and is a different task in many ways from writing a
> >>>program to do some particular X.
>
> >>The pre-dominant type substitutability model in OOP is the one Simula
> >>devised.
>
> > This is not the consensus opinion, as already described.
>
> 1. You do not appear to understand the english word "predominant" . I
> suggest that you read the definition in a dictionary and then respond
> after understanding the definition.
You have not shown it predominant either. The definitions of OO are
all over the map.
http://www.c2.com/cgi/wiki?DefinitionsForOo
>
> 2. What is the "consensus opinion, as already described" of type
> substitutability in OO ??
>
> Going back through the postings in this thread and I find no such
> definition from you, nor any citing to a reference source from which you
> may have taken a definition.
My working definition of OO? It is not my burden, but here it is
anyhow: Maps whereby each element contain one of three kinds of items:
attributes, pointers to other maps, or a function.
>
> Have I missed something (I don't think I have) ??
>
>
> > You are
> > ignoring the work of Alan Kay. The "Smalltalk" OO view has been
> > battling the Simula/C++/Eiffel view of what OO is for quite a while.
> > Neither side has "won".
>
> As written above, I am waiting for you to tell us what the Smalltalk
> "OO view" of type substitutability actually is.
Duck typing. It matches "messages" by name.
>
>
> SP>All texts for a prog lang that have only that model can by
> SP>definition only really speak in terms of that model (except of course
> SP>perhaps as a cursory nod to the fact that other models exist) .
>
> >>More general books on OO (type theory particularly) are able to discuss
> >>the various models (separately, compare/contrast etc) more appropriately.
> >>I have several books that do exactly this.
>
> > Are you saying you need a book to explain your opinion because you are
> > crappy at articulating? That's what it sounds like as I read it.
>
> Well no doubt it does, because as already stated, you appear to have some
> serious mis-understanding of the meaning of words in the English language.
No, you do.
>
> But I will bear this in mind, and attempt to re-explain :
>
> Books on a specific OO prog lang, that supports a *specific type
> substitutability model* , are not really likely to discuss type
> substitutability models that the prog lang does not support. Books on OO in
> general are more likely to discuss "variations on the theme" because their
> target audience is not by definition the users of a specific OO prog lang.
>
What does this allegedly answer? Specific languages have their own
type system (or perhaps lack of). That is not news. Since OO is not
about "types", the second part of your statement is true. You appear
to have concurred with my statement that "OO is not about types"
because being OO does *not* dictate in any clear way which typing
system is used by a language. Otherwise, there would not be a
disconnect between the first half of your paragraph and the second.
>
> > Nor did you offer proof that your books represent a good sample of the
> > general OO community, and not just the strong-type-loving community.
> > Stating your claims over and over does not make it so.
>
> What is the above text being written in relation to ??
Your claim of "predoment".
>
>
> Regards,
> Steven Perryman
-T-
JXStern
<mai...@dmitry-kazakov.de> wrote:
>> That, and OO suggests that you can and should and must taxonomize the
>> world, and no matter the language, that turns out to be more work than
>> it looks like, and is a different task in many ways from writing a
>> program to do some particular X.
>
>Speaking at this level of generality (and maybe lack of substance),
yes, ...
> how a
>reasonable set theory can be built without is-member-of? Or, in terms of
>topmind's beloved tables, can a table be a cell of itself? Isn't "A is a
>table, B is a cell, C is a row", anything but taxonomization, be it damned?
I'd say programs are small and particular and can be internally
taxonomized.
>Isn't "this piece of world to be modeled by relational algebra" a
>taxonomization?
No, there may be any level of detail in some piece of the external
world.
>Only God can speak declarative language.
Er, yeah?
> For us, mortals,
>there has to be a machine to infer from declarations.
Oh, I see, ... I think. But I'm not sure infering from declarations
is quite the same as executing a procedural program.
> By which set of
>rules? Is there one for everything? Warning, by answering "no" you start to
>taxonomize...
LOL. OK, ok.
But (as topmind says in another message), taxonomizing everything into
IS-A doesn't get the job done, and depending where you go with it,
can't even all be done at the class level, ... you can try to
translate HAS-A, or DOES-X, and the properties and methods are much
more diverse and noncannonical than IS-A, which is just positional.
...
How did I get into this anyway, I really just meant to point out that
topmind was calling "polymorphism" what was really (Simula-style)
inheritance. That's about all I wanted to say.
On all the rest, just put me down for opinion X.Y.Z(3).
J.
Dmitry A. Kazakov
Set of methods + set of values (type) do not imply substitutability
(defined as functionality), which is THE problem.
Also, let's consider the idea of type more closely. It is all about
distinguishing values which appear substitutable for each other, but in
fact, functionally they are not. The value -1 can be inversed when Integer,
but not when Negative. It can be squared when Complex, but not when Real,
etc. So -1 is not -1 if types are different. This is the level one.
Now, look what happens at the next level, where types themselves become
values. Suddenly everybody start to propose treating types of different
meta types same, when they resemble each other. Why? What makes you folks
be so sure that something that didn't worked for values would magically do
for types?
It will not work either. At least if you wanted meta programming and types
of types. It might work if you dropped types of types, but then your
framework will be sufficiently weaker. Without meta programming it is where
it was in 70s, or, ..., in RDBMS today. (:-))
S Perryman
> S Perryman wrote:
>>topmind wrote:
SP>The pre-dominant type substitutability model in OOP is the one Simula
SP>devised.
TM>This is not the consensus opinion, as already described.
>>1. You do not appear to understand the english word "predominant" . I
>>suggest that you read the definition in a dictionary and then respond
>>after understanding the definition.
> You have not shown it predominant either. The definitions of OO are
> all over the map.
> http://www.c2.com/cgi/wiki?DefinitionsForOo
The topic of this thread is *TYPE SUBSTITUTABILITY* .
Here are some references to help you overcome your ignorance of the
basic concepts :
http://en.wikipedia.org/wiki/Substitutability
http://en.wikipedia.org/wiki/Category:Type_theory
http://en.wikipedia.org/wiki/Structural_type_system
http://www.c2.com/cgi/wiki?NominativeAndStructuralTyping
>>2. What is the "consensus opinion, as already described" of type
>>substitutability in OO ??
>>
>>Going back through the postings in this thread and I find no such
>>definition from you, nor any citing to a reference source from which you
>>may have taken a definition.
> My working definition of OO?
OO !!??
Do you actually understand english ??
Do you actually read what people write before you reply to them ??
I will re-write my original text, appropriately highlighted :
<quote>
What is the "consensus opinion, as already described" of *TYPE
SUBSTITUTABILITY* in OO ??
</quote>
>>As written above, I am waiting for you to tell us what the Smalltalk
>>"OO view" of type substitutability actually is.
> Duck typing. It matches "messages" by name.
As does *STRONG TYPING* .
Unless you are going to claim that a strongly-typed system does not match
"messages by name" when the correctness of a program is verified (this I
must see) .
>>Books on a specific OO prog lang, that supports a *specific type
>>substitutability model* , are not really likely to discuss type
>>substitutability models that the prog lang does not support. Books on OO in
>>general are more likely to discuss "variations on the theme" because their
>>target audience is not by definition the users of a specific OO prog lang.
> What does this allegedly answer? Specific languages have their own
> type system (or perhaps lack of)
No. That a C++ book is not likely to discuss the type substitutability
model used by OCaml etc when the model used by C++ is based on Simula (a
different model) .
> Since OO is not
> about "types", the second part of your statement is true. You appear
> to have concurred with my statement that "OO is not about types"
> because being OO does *not* dictate in any clear way which typing
> system is used by a language. Otherwise, there would not be a
> disconnect between the first half of your paragraph and the second.
You really do not understand the english language.
Everything you write just makes you look a bigger fool.
But it is this together with your disingenous attempts to evade your
own ignorance that makes you such a unique beast.
From the first posting I have made in this thread, the debate has been
about *TYPE SUBSTITUTABILITY MODELS* used by OO. Specifically your claims
about what/how OO forces developers to do in terms of writing code.
Your ignorance of type substitutability models was quickly shown by the
fact that there are other OO prog langs that do not (need to) use the
Simula model (the Simula model being *predominant* in that it is the one
used in the great majority of OO prog langs) .
When faced with the fact that your rantings are now rubbish, you try to
claim that because these other models are widely-used in OO prog langs
that have an FP heritage, that somehow this is an FP 'thing' and not an
OO 'thing' .
When faced with the fact that the heritage of different type
substitutability models is irrelevant, you then try to switch the
discussion to what OO is.
1. You are the Usenet equivalent of the person who likes the sound of their
own voice.
2. But the sounds coming out of the talking orifice betray your
ignorance on a variety of topics. And on that point, IMHO Robert Martin
described you best : you have too much to say about things that you know
too little about. As I have told you before, this is why most of
comp.object treat you as a joke.
If you could somehow control 1, you would not have to suffer the
embarrassment of 2.
Steven Perryman
S Perryman
> On 21 May 2007 11:22:01 -0700, Universe wrote:
>>Couldn't you have the best of both worlds? To me the best of both
>>would be the ability to substitute any type whether the type is one
>>member of a set of a flat horizontal bush, or on the other hand, if
>>the type is a member of one or more vertical trees. To make things
>>easy a substitutable type would be able to auto pick up minimal
>>functionality required (per method or via a set of methods) for the
>>place where it is being substituted if that type did not implement
>>required functionality itself.
> Set of methods + set of values (type) do not imply substitutability
> (defined as functionality), which is THE problem.
The problem is for those who believe :
substitutability *equals* structural equivalence
when the reality is :
substitutability *implies* structural equivalence
Regards,
Steven Perryman
Dmitry A. Kazakov
> On Mon, 21 May 2007 19:18:16 +0200, "Dmitry A. Kazakov"
> <mai...@dmitry-kazakov.de> wrote:
>
>> how a
>>reasonable set theory can be built without is-member-of? Or, in terms of
>>topmind's beloved tables, can a table be a cell of itself? Isn't "A is a
>>table, B is a cell, C is a row", anything but taxonomization, be it damned?
>
> I'd say programs are small and particular and can be internally
> taxonomized.
Fair enough. However, you could say that it is because they are small and
taxonomized there is a problem to deploy them in a world which is big and
non-taxonomizable.
>> For us, mortals,
>>there has to be a machine to infer from declarations.
>
> Oh, I see, ... I think. But I'm not sure infering from declarations
> is quite the same as executing a procedural program.
Absolutely. The difference is only in how obvious are the results to the
programmers. The classification (oops) is: when the results are obvious and
trivial we call it imperative, when the results are rather complicated and
embarrassing, it becomes declarative, politicians do it all the time.
Basically, when we don't know/care what we are doing we declare/proclaim,
the only question is, what? (:-))
>> By which set of
>>rules? Is there one for everything? Warning, by answering "no" you start to
>>taxonomize...
>
> LOL. OK, ok.
>
> But (as topmind says in another message), taxonomizing everything into
> IS-A doesn't get the job done, and depending where you go with it,
> can't even all be done at the class level, ... you can try to
> translate HAS-A, or DOES-X, and the properties and methods are much
> more diverse and noncannonical than IS-A, which is just positional.
It is in the levels. Is-a is the next level of abstraction. It is
equivalent to millions of small has-a, a machine gun vs. pistol. If you
have no drill, you could make a hole in the wand with a pistol. A machine
gun would also make at least one hole, among some others...
Hey, you wanted to go declarative. Is-a is just that sort of declarations -
"complicated, cryptic, powerful, unforgiving, dangerous."
> How did I get into this anyway, I really just meant to point out that
> topmind was calling "polymorphism" what was really (Simula-style)
> inheritance. That's about all I wanted to say.
>
> On all the rest, just put me down for opinion X.Y.Z(3).
(:-))
Dmitry A. Kazakov
> The problem is for those who believe :
>
> substitutability *equals* structural equivalence
>
> when the reality is :
>
> substitutability *implies* structural equivalence
(:-))
S Perryman
> On Tue, 22 May 2007 09:11:08 +0100, S Perryman wrote:
>>The problem is for those who believe :
>>substitutability *equals* structural equivalence
>>when the reality is :
>>substitutability *implies* structural equivalence
> (:-))
I am wondering now (especially with topminds' spectacular displays of
ignorance regarding type substitutability, the existence of different
substitutability models, the relationships/differences between the models,
the relationships/differences between strong/weak type systems etc) whether
an attempt should be made to write a beginners guide to type
substitutability in both informal/formal terms.
Such a guide would be a useful FAQ supplement for comp.object IMHO given
the topic is frequently/perennially discussed.
Regards,
Steven Perryman
Dmitry A. Kazakov
It is a great good idea and not just for comp.object, because IMO, there is
a great misunderstanding of programming paradigms altogether. Many battles
between OO vs FP vs RA are fought over fictions.
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> Or, in terms of
>> topmind's beloved tables, can a table be a cell of itself?
>
> Does it need to be?
If your answer is no, then observe how promptly you have created a
hierarchy table -> cell and classified everything into tables and cells.
>> Isn't "A is a
>> table, B is a cell, C is a row", anything but taxonomization, be it damned?
>> Isn't "this piece of world to be modeled by relational algebra" a
>> taxonomization? Only God can speak declarative language. For us, mortals,
>> there has to be a machine to infer from declarations. By which set of
>> rules? Is there one for everything? Warning, by answering "no" you start to
>> taxonomize...
>
> I am not sure what your point is. OO tends to use DAG's for
> classification systems while relational uses (a form of) set theory.
The set theory is built around asymmetric classification:
set -> members of
Don't argue to set theory, it speaks against you.
> Perryman wants to elect
> himself God of Definitions, but I won't let him.
He just uses a *normal* coherent scientific approach. If you don't give
definitions of what you are talking about, then he has every right to do it
himself.
There are only two ways you could defeat him:
1. Normal way: take his definitions and infer contradiction or
undecidability.
2. By flagrancy: reject any definitions and keep on mumbling.
S Perryman
> Dmitry A. Kazakov wrote:
>>Isn't "A is a
>>table, B is a cell, C is a row", anything but taxonomization, be it damned?
>>Isn't "this piece of world to be modeled by relational algebra" a
>>taxonomization? Only God can speak declarative language. For us, mortals,
>>there has to be a machine to infer from declarations. By which set of
>>rules? Is there one for everything? Warning, by answering "no" you start to
>>taxonomize...
> I am not sure what your point is. OO tends to use DAG's for
> classification systems while relational uses (a form of) set theory.
Graph theory *IS SET-THEORETIC* .
Specifically : a graph is two sets related to eachother by an invariant
predicate.
Your God of Definitions has spoken ...
topmind
S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> >>topmind wrote:
>
> SP>The pre-dominant type substitutability model in OOP is the one Simula
> SP>devised.
>
> TM>This is not the consensus opinion, as already described.
>
> >>1. You do not appear to understand the english word "predominant" . I
> >>suggest that you read the definition in a dictionary and then respond
> >>after understanding the definition.
>
> > You have not shown it predominant either. The definitions of OO are
> > all over the map.
>
> > http://www.c2.com/cgi/wiki?DefinitionsForOo
>
> The topic of this thread is *TYPE SUBSTITUTABILITY* .
NO, it is NOT! You tried to turn it into that.
>
> Here are some references to help you overcome your ignorance of the
> basic concepts :
Take your rudeness and shuv it where the sun ain't shine.
>
> http://en.wikipedia.org/wiki/Substitutability
> http://en.wikipedia.org/wiki/Category:Type_theory
> http://en.wikipedia.org/wiki/Structural_type_system
> http://www.c2.com/cgi/wiki?NominativeAndStructuralTyping
>
>
> >>2. What is the "consensus opinion, as already described" of type
> >>substitutability in OO ??
> >>
> >>Going back through the postings in this thread and I find no such
> >>definition from you, nor any citing to a reference source from which you
> >>may have taken a definition.
>
> > My working definition of OO?
>
> OO !!??
> Do you actually understand english ??
> Do you actually read what people write before you reply to them ??
You are a lame writer.
>
> I will re-write my original text, appropriately highlighted :
>
> <quote>
>
> What is the "consensus opinion, as already described" of *TYPE
> SUBSTITUTABILITY* in OO ??
>
> </quote>
>
No, that is not the issue.
>
> >>As written above, I am waiting for you to tell us what the Smalltalk
> >>"OO view" of type substitutability actually is.
>
> > Duck typing. It matches "messages" by name.
>
> As does *STRONG TYPING* .
> Unless you are going to claim that a strongly-typed system does not match
> "messages by name" when the correctness of a program is verified (this I
> must see) .
We need to start from the begginning here. Let's see you define
"types" in under 4 paragraphs. I should bet a paycheck that you can't
do it properly, but my wife won't let me gamble.
> > Since OO is not
> > about "types", the second part of your statement is true. You appear
> > to have concurred with my statement that "OO is not about types"
> > because being OO does *not* dictate in any clear way which typing
> > system is used by a language. Otherwise, there would not be a
> > disconnect between the first half of your paragraph and the second.
>
> You really do not understand the english language.
> Everything you write just makes you look a bigger fool.
Blah blah blah. You good me bad.
> But it is this together with your disingenous attempts to evade your
> own ignorance that makes you such a unique beast.
>
> From the first posting I have made in this thread, the debate has been
> about *TYPE SUBSTITUTABILITY MODELS* used by OO. Specifically your claims
> about what/how OO forces developers to do in terms of writing code.
No, YOU tried to turn it into that because you WANT to think about
types and not OO. Your "types == OO" view is your own personal fantasy
(or meaningless in a Turing Equivalency way).
>
> Your ignorance of type substitutability models was quickly shown by the
> fact that there are other OO prog langs that do not (need to) use the
> Simula model (the Simula model being *predominant* in that it is the one
> used in the great majority of OO prog langs) .
That is because types and OO are generally *orthogonal*. You keep
proving my point.
>
> When faced with the fact that your rantings are now rubbish, you try to
> claim that because these other models are widely-used in OO prog langs
> that have an FP heritage, that somehow this is an FP 'thing' and not an
> OO 'thing' .
You haven't shown that the ARE inherent to OO.
>
> When faced with the fact that the heritage of different type
> substitutability models is irrelevant, you then try to switch the
> discussion to what OO is.
Me switch????? ha ha ha, you a funny man.
>
>
> 1. You are the Usenet equivalent of the person who likes the sound of their
> own voice.
blah blah blah. Me bad you good blah blah blah. Unlike you, I am not
going to dwell on whether you are fundimentally flawed as a person or
not. I am not here to fix idiots. I don't care about that. The problem
is that you hijacked the topic here and now.
>
> 2. But the sounds coming out of the talking orifice betray your
> ignorance on a variety of topics. And on that point, IMHO Robert Martin
> described you best : you have too much to say about things that you know
> too little about. As I have told you before, this is why most of
> comp.object treat you as a joke.
He is just jealous because my runnable payroll example kicked his
payroll example's ass. At least it is not objectively worse. People
make up nonsense reasons to dismiss others when they are defeated. I
hold up my example as a testament to the sham of published OOP.
>
> If you could somehow control 1, you would not have to suffer the
> embarrassment of 2.
>
>
> Steven Perryman
-T-
topmind
S Perryman wrote:
> Dmitry A. Kazakov wrote:
>
> > On Tue, 22 May 2007 09:11:08 +0100, S Perryman wrote:
>
> >>The problem is for those who believe :
>
> >>substitutability *equals* structural equivalence
>
> >>when the reality is :
>
> >>substitutability *implies* structural equivalence
>
> > (:-))
>
> I am wondering now (especially with topminds' spectacular displays of
> ignorance regarding type substitutability,
If you cannot be cival, then SHUT the hell up!
The problem is you changing the subject to types instead of OO, not
me. I was talking about managing variations-on-a-theme and how it
relates to OO, not types in and of themselves.
-T-