object-oriented vs. functional
Chris Burkert
I used to work with the object-oriented Language Smalltalk and I am very
happy with this. But last time I heard about the functional Concepts.
For example I heard that it is possible to proof a program written in a
functional Language.
So here are my Question
1) What pro's have the object-oriented Languages?
2) What con's have the object-oriented Languages?
3) What pro's have the functional Languages?
4) What con's have the functional Languages?
5) What Concept do think will make it in the future?
[fup2comp.object]
Regards
Chris Burkert
--
------------------------------------------------------------------------
Student of applied Computer Science at Chemnitz University of Technology
http://www.chrisburkert.de/ ch...@hrz.tu-chemnitz.de
------------------------------------------------------------------------
Friedrich Dominicus
> Hi all
>
> I used to work with the object-oriented Language Smalltalk and I am
> very happy with this. But last time I heard about the functional
> Concepts. For example I heard that it is possible to proof a program
> written in a functional Language.
Theoretically it's easier, anyway I do not know of any larger program
relly proofed.
>
>
> So here are my Question
>
> 1) What pro's have the object-oriented Languages?
I find the thinking about objects easy. And it's very nice to
lay out datastructures.
> 2) What con's have the object-oriented Languages?
What do you think? Well I would think they have a slight smell of
over-engineering. You probably write things more general than needed
because it "fits", and you have to. E.g try to abstract out a simply
algorithms. Renaming files in a directory. You can extract all things
into separat classes and it will work but it's really much code for a
task which is a three-liner or so in a functional language.
> 3) What pro's have the functional Languages?
All things for abstracting algorithms.
> 4) What con's have the functional Languages?
Well I found it annoying in purely functional languages that you can
not just put int some output routines in the middle of a function. The
other thing is that some things can be really nice mapped onto objects
but are harder in functional languages. Just try to build a hierachy
of objects. Of course you'll find a way but it could happen that you
have to touch functions over and over again if it should support a new
Datastructure.
> 5) What Concept do think will make it in the future?
They will both persist for quite a while and I'm sure the will adopt
things from the other side. Some examples are still there: OCaml,
Mozart/Oz, Sather, Ruby and bunch more...
Regards
Friedrich
H. S. Lahman
> 1) What pro's have the object-oriented Languages?
They are well suited to volatile environments (i.e., where the
requirements change). They are well suited to environments with complex
and fuzzily defined entities where abstraction can be helpful in
managing complexity (e.g., conceptual models for things like ecological
systems).
> 2) What con's have the object-oriented Languages?
They are less intuitive to use properly, especially when coming from a
procedural or functional environment.
> 3) What pro's have the functional Languages?
They are well suited to stable environments (i.e., where requirements
don't change much). They are more intuitive in environments that are
well defined (e.g., mathematical algorithms, network protocols, etc.).
> 4) What con's have the functional Languages?
Once solutions are developed they tend to be more difficult to modify.
> 5) What Concept do think will make it in the future?
Both. There is no one-size-fits-all in languages. One selects the
tools best suited to the task in hand.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Topmind
>
> I used to work with the object-oriented Language Smalltalk and I am very
> happy with this. But last time I heard about the functional Concepts.
> For example I heard that it is possible to proof a program written in a
> functional Language.
>
> So here are my Question
>
> 1) What pro's have the object-oriented Languages?
You will get a different answer depending on
who you ask. There is no industry consensus.
> 2) What con's have the object-oriented Languages?
See: http://geocities.com/tablizer/oopbad.htm
> 3) What pro's have the functional Languages?
> 4) What con's have the functional Languages?
> 5) What Concept do think will make it in the future?
I tend to believe that the productivity of a paradigm
is subjective, and some surveys from Ed Yourdon tend
to also suggest this. Some have OO minds, some have functional
minds, some have relational minds, etc. Hopefully the
future will realize the subjectivity of it all, and
realize for once that software engineering is more
like the discipline of *psychology* rather than math.
It would be *nice* if it was like math, because then
things could be mathematically proven, ending fierce
arguments and fads. However, we are not that lucky.
>
> [fup2comp.object]
>
> Regards
> Chris Burkert
> --
> ------------------------------------------------------------------------
> Student of applied Computer Science at Chemnitz University of Technology
> http://www.chrisburkert.de/ ch...@hrz.tu-chemnitz.de
> ------------------------------------------------------------------------
>
-T-
Topmind
> Responding to Burkert...
>
> > 1) What pro's have the object-oriented Languages?
>
> They are well suited to volatile environments (i.e., where the
> requirements change).
Bull. IMO OOP is optimized for changing implementation, and
not changing interfaces. I have never heard anybody brag
that OOP greatly improves changing interfaces, yet braggings
about wrapping changing implementations are all over the
place. OOP has a bad habit of *duplicating* interfaces
and interface patterns. Sometimes this is euphemisticly
called "polymorphism". However, factoring interfaces to
one or fewer spots is just as important as factoring
implemenation IMO.
Also, it depends on the kinds of changes. For example,
polymorphism quickly melts under a loss of mutual exclusion
of "choices". Sets better handle such, and OOP has nothing
built-in that improves upon or helps with sets above
other paradigms.
> They are well suited to environments with complex
> and fuzzily defined entities where abstraction can be helpful in
> managing complexity (e.g., conceptual models for things like ecological
> systems).
Ecological systems? Do you mean like physical modeling,
Simula-67 style?
IMO, OOP fails to grasp the need for "relative abstraction",
instead putting all eggs in the one basket of "encapsulation",
which is a limiting one-interface-fits-all philosophy.
-T-
Neelakantan Krishnaswami
Chris Burkert <ch...@hrz.tu-chemnitz.de> wrote:
>
> I used to work with the object-oriented Language Smalltalk and I am
> very happy with this. But last time I heard about the functional
> Concepts. For example I heard that it is possible to proof a program
> written in a functional Language.
It's possible to prove a program written in any language, but it does
tend to be a lot easier to prove the correctness of a program written
in a functional style. The reason for this is that when you don't have
to think about state and sequencing, you can decompose the proof more
easily -- the dataflow consists simply of the arguments to a function
and the return values, so you can prove the correctness of each
function and then treat it as a black box henceforth. (This also means
that it's easier to *test* a functional program, since your test
harness doesn't have to do nearly as much work setting up the correct
environment as it would with a program written in a more imperative
style.)
> 1) What pro's have the object-oriented Languages?
> 2) What con's have the object-oriented Languages?
> 3) What pro's have the functional Languages?
> 4) What con's have the functional Languages?
The distinctive features of the functional style are: a) the use of
functions as first-class values, and b) an avoidance of mutation and
assignment in favor of building new values. The distinctive features
of the OO style are a) a type system with subtyping, and b) method
overloading controlled by dynamic dispatch on the runtime type of the
values. In use, the big advantage that FP languages have is that they
allow you to build very sophisticated abstractions very quickly --
higher order functions let you easily parameterize behavior in complex
ways. They also let you add new behaviors on a type without any
problems. The advantage OO languages offer is that you can refine
existing datatypes very easily through subclassing -- you can add new
branches to a datatype by defining a new subclass.
The bumper-sticker slogan is that functional languages make it easy to
add behavior, and OO languages make it easy to add data.
> 5) What Concept do think will make it in the future?
Both. I think that the hybrid object-functional is best, because
programmers need every bit of flexibility they can grab onto. Most new
scripting languages -- like Python, Ruby, and so on -- have both OO
and functional features.
--
Neel Krishnaswami
ne...@alum.mit.edu
Kurt M. Alonso
Hi Bruce,
I see you are still posting here :-)
Topmind wrote:
> IMO, OOP fails to grasp the need for "relative abstraction",
> instead putting all eggs in the one basket of "encapsulation",
> which is a limiting one-interface-fits-all philosophy.
>
Could you define in detail the following expressions:
- "relative abstraction"
- "putting all eggs in the one basket of encapsulation"
I am probably too busy working in real software projects
to engage in any serious discussions with you, but anyway ...
> -T-
Kurt
Topmind
> > IMO, OOP fails to grasp the need for "relative abstraction",
> > instead putting all eggs in the one basket of "encapsulation",
> > which is a limiting one-interface-fits-all philosophy.
> >
>
> Could you define in detail the following expressions:
> - "relative abstraction"
May I suggest: http://geocities.com/tablizer/abstract.htm
>
> I am probably too busy working in real software projects
> to engage in any serious discussions with you, but anyway ...
You would be finished by now if you used p/r :-)
>
>
> > -T-
>
>
> Kurt
>
>
Kurt M. Alonso
Topmind wrote:
>>>IMO, OOP fails to grasp the need for "relative abstraction",
>>>instead putting all eggs in the one basket of "encapsulation",
>>>which is a limiting one-interface-fits-all philosophy.
>>>
>>
>>Could you define in detail the following expressions:
>>- "relative abstraction"
>>- "putting all eggs in the one basket of [OO] encapsulation"
>
Still don't see how a relational model should be any better
at providing 2 incompatible views of the same data.
How would you solve your car problem?
A number of more general objections to your text:
- Within a system you usually need only view data in one way.
I mean, in an accountancy system you will hardly ever need a
mechanic view of cars. But even if you did, you haven't proved
that OOP can't do it, or that it does it worse than a relational
model
- It appears to be the case (still!) that you think that the
trivial zoology or car examples in basic, introductory texts
is all there is to OOP.
Kurt
Universe
> Sorry for misspelling your name in my earlier posting.
> Topmind wrote:
>>>>IMO, OOP fails to grasp the need for "relative abstraction",
>>>>instead putting all eggs in the one basket of "encapsulation",
>>>>which is a limiting one-interface-fits-all philosophy.
This is a joke right?
Giving a single role task multiple interfaces is a bedrock of OO
mechanics. It's called p*o*l*y*m*o*r*p*h*i*s*m.
E unum pluribus - "Out of one, many"
What do you call it when OO engineers and analyst have given a single role
task (class) multiple interfaces for the context of the role task
abstraction via overloading (C++, Ada), and even a many interfaces for
an actual single class as with 'implements "I"nterface' (Objective C,
Java, Smalltalk, Beta, Ada).
And don't put don't overloading in terms of multiple interfaces for an
abstraction. Each class may have only a single interface, but each class
that is in the overloading "chain" is still the _same_ essential _role
task abstraction_ with regard to the *relative context*, the vital issue
or job to be done, at the time of typically a sequence of method dispatch
invocations on that abstraction.
OO gives a single abstraction muliple interfaces by means of various
design time "glove fitting" means:
~ dynamic dispatch (like Smalltalk, but even C++ coders uses it liberally)
~ multiple interfaces for the same essential role task via "overloading"
and overriding (both of which come in static and dynamic flavors)
~ implementing interfaces of which a single class role asbtraction may
have any number
~ slots
~ now even metamorphism
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2002 my comments ~ newsgroups+bitnet OK
Universe
[Here, I just cleaned up typos...]
> Kurt M. Alonso wrote:
>> Sorry for misspelling your name in my earlier posting.
>> Topmind wrote:
>>>>>IMO, OOP fails to grasp the need for "relative abstraction",
>>>>>instead putting all eggs in the one basket of "encapsulation",
>>>>>which is a limiting one-interface-fits-all philosophy.
> This is a joke right?
> Giving a single role task multiple interfaces is a bedrock of OO
> mechanics. It's called p*o*l*y*m*o*r*p*h*i*s*m.
> E unum pluribus - "Out of one, many"
> What do you call it when OO engineers and analyst have given a single role
> task (class) multiple interfaces for the context of the role task
> abstraction via overloading (C++, Ada), and even
*[]* many interfaces for
> an actual single class as with 'implements "I"nterface' (Objective C,
> Java, Smalltalk, Beta, Ada).
> And don't put
*[down]*
> overloading in terms of multiple interfaces for an
> abstraction. Each class may have only a single interface, but each class
> that is in the overloading "chain" is still the _same_ essential _role
> task abstraction_ with regard to the *relative context*, the vital issue
> or job to be done, at the time of typically a sequence of method dispatch
> invocations on that abstraction.
> OO gives a single abstraction muliple interfaces by
*[way]*
Topmind
>
> Topmind wrote:
> >>>IMO, OOP fails to grasp the need for "relative abstraction",
> >>>instead putting all eggs in the one basket of "encapsulation",
> >>>which is a limiting one-interface-fits-all philosophy.
> >>>
> >>
> >>Could you define in detail the following expressions:
> >>- "relative abstraction"
> >>- "putting all eggs in the one basket of [OO] encapsulation"
> >
>
>
> Still don't see how a relational model should be any better
> at providing 2 incompatible views of the same data.
> How would you solve your car problem?
There is no *one* "car problem". You issue the query to
deliver whatever view you need for a given task.
I will agree that a given query may not provide *all*
the processing you need to do a task, but that is
why we also have code.
>
> A number of more general objections to your text:
> - Within a system you usually need only view data in one way.
I don't find this to be the case in non-trivial apps/systems.
> I mean, in an accountancy system you will hardly ever need a
> mechanic view of cars.
Didn't say they would. My point is that an accountant
and a mechanic will want different views of the same
part. The same part record(s) can serve both needs. Thus,
no *duplicate* data is needed. You can do that in
OOP, but you end up managing indexes yourself.
> But even if you did, you haven't proved
> that OOP can't do it, or that it does it worse than a relational
> model
Well, you have not proven it worse. Hard-wiring a view
into code is NOT a good thing in my book.
REQUIREMENTS CHANGE
> - It appears to be the case (still!) that you think that the
> trivial zoology or car examples in basic, introductory texts
> is all there is to OOP.
It generally is one of two things:
Either you follow the simplistic zoo/shape-like approaches
to modeling, or you end up re-inventing the database.
IOW:
if simplistic trees then
too inflexible, no multi-views
else
you are re-inventing the database the hard way
end if
I have not seen much that does not follow
these patterns. Most of GOF is hand-indexing
classes together like a granny weaving patches
of material together. I would rather issue
formulaic commands to order the machine to
sew those patches together according to the
"pattern" formulas than to do it by hand.
And it is virtual, not perm, so I can change
it without affecting other simultaneous
uses of the patches.
>
>
> Kurt
>
>
-T-
Topmind
>
> > Sorry for misspelling your name in my earlier posting.
>
> > Topmind wrote:
> >>>>IMO, OOP fails to grasp the need for "relative abstraction",
> >>>>instead putting all eggs in the one basket of "encapsulation",
> >>>>which is a limiting one-interface-fits-all philosophy.
>
> This is a joke right?
>
> Giving a single role task multiple interfaces is a bedrock of OO
> mechanics. It's called p*o*l*y*m*o*r*p*h*i*s*m.
>
> E unum pluribus - "Out of one, many"
>
> What do you call it when OO engineers and analyst have given a single role
> task (class) multiple interfaces for the context of the role task
> abstraction via overloading (C++, Ada), and even a many interfaces for
> an actual single class as with 'implements "I"nterface' (Objective C,
> Java, Smalltalk, Beta, Ada).
Show me a psuedo-code example.
>
> And don't put don't overloading in terms of multiple interfaces for an
> abstraction. Each class may have only a single interface, but each class
> that is in the overloading "chain" is still the _same_ essential _role
> task abstraction_ with regard to the *relative context*, the vital issue
> or job to be done, at the time of typically a sequence of method dispatch
> invocations on that abstraction.
>
> OO gives a single abstraction muliple interfaces by means of various
> design time "glove fitting" means:
> ~ dynamic dispatch (like Smalltalk, but even C++ coders uses it liberally)
> ~ multiple interfaces for the same essential role task via "overloading"
> and overriding (both of which come in static and dynamic flavors)
> ~ implementing interfaces of which a single class role asbtraction may
> have any number
> ~ slots
> ~ now even metamorphism
Brochure Blowchure, show it in black-and-white.
>
> Elliott
> --
> http://www.radix.net/~universe ~*~ Enjoy! ~*~
> Hail OO Modelling! * Hail the Wireless Web!
> @Elliott 2002 my comments ~ newsgroups+bitnet OK
>
-T-
Kurt M. Alonso
Topmind wrote:
>>Still don't see how a relational model should be any better
>>at providing 2 incompatible views of the same data.
>>How would you solve your car problem?
>
>
>
> There is no *one* "car problem". You issue the query to
> deliver whatever view you need for a given task.
>
> I will agree that a given query may not provide *all*
> the processing you need to do a task, but that is
> why we also have code.
>
Are you evading the question? Assume that you are designing
a single system requiring both views of car parts, a mechanic and
a economic/inventory oriented one. On one side you have mechanical
characteristics, and on the other side you have prices, taxes,
inventory forecasts, etc.
How would you solve this problem?
>
>>A number of more general objections to your text:
>>- Within a system you usually need only view data in one way.
>
>
>
> I don't find this to be the case in non-trivial apps/systems.
>
Just give me concrete examples and we will discuss them.
>
>
>>I mean, in an accountancy system you will hardly ever need a
>>mechanic view of cars.
>
>
>
> Didn't say they would. My point is that an accountant
> and a mechanic will want different views of the same
> part. The same part record(s) can serve both needs. Thus,
> no *duplicate* data is needed. You can do that in
> OOP, but you end up managing indexes yourself.
>
In such simple setups, where one modelled item has a
set of simple physical attributes and a set of simple
accountancy attributes one might consider using a single
class to represent car parts, as well. What's your point?
>
>
>>But even if you did, you haven't proved
>>that OOP can't do it, or that it does it worse than a relational
>>model
>
>
>
> Well, you have not proven it worse. Hard-wiring a view
> into code is NOT a good thing in my book.
>
> REQUIREMENTS CHANGE
>
Just give me an example where you think a OO programmer
would "hardwire a view into code" and where a "p/r" programmer
wouldn't.
>
>
>>- It appears to be the case (still!) that you think that the
>>trivial zoology or car examples in basic, introductory texts
>>is all there is to OOP.
>
>
>
> It generally is one of two things:
>
> Either you follow the simplistic zoo/shape-like approaches
> to modeling, or you end up re-inventing the database.
>
> IOW:
>
> if simplistic trees then
> too inflexible, no multi-views
> else
> you are re-inventing the database the hard way
> end if
>
Let's discuss examples, please.
> I have not seen much that does not follow
> these patterns. Most of GOF is hand-indexing
> classes together like a granny weaving patches
> of material together. I would rather issue
> formulaic commands to order the machine to
> sew those patches together according to the
> "pattern" formulas than to do it by hand.
> And it is virtual, not perm, so I can change
> it without affecting other simultaneous
> uses of the patches.
>
"hand-indexing class together"? Could you explain
that?
Kurt
Topmind
>
> Topmind wrote:
>
> >>Still don't see how a relational model should be any better
> >>at providing 2 incompatible views of the same data.
> >>How would you solve your car problem?
> >
> >
> >
> > There is no *one* "car problem". You issue the query to
> > deliver whatever view you need for a given task.
> >
> > I will agree that a given query may not provide *all*
> > the processing you need to do a task, but that is
> > why we also have code.
> >
> Are you evading the question? Assume that you are designing
> a single system requiring both views of car parts, a mechanic and
> a economic/inventory oriented one. On one side you have mechanical
> characteristics, and on the other side you have prices, taxes,
> inventory forecasts, etc.
> How would you solve this problem?
I don't see any "problem", as in "stumper" here. Perhaps
you can present a specific situation.
I'll provide one to start things.
Let's say we have the following table structure:
Table: Parts
------------
PartID
Weight
Cost
ParentID // What it is connected to [1]
InStock // Number in stock
PerCar // How many per car
...
Suppose the accountant wants to know which inexpensive
items are low in inventory, thinking that the cheaper
ones are easier to replace or bulk-up on
without breaking the bank.
Select top 100 * from Parts order by
(inStock / PerCar) * price
This will provide a list of 100 parts that
generally match the description above. (The "top"
command is not standardized and varies per
DB engine. Some use "limit" or a result
row count instead.)
[1] Sets or groups may be more effective here
since a tree implies an importance or size ranking
of parts, which may not be the case. Two gizmos
may be roughly equals, but fit into each other.
I would also note that this example is probably
simpler than a real world one would turn out, but
that is usually the way illustrative examples are.
For example, we are not checking for division by
zero here.
>
> >
> >>A number of more general objections to your text:
> >>- Within a system you usually need only view data in one way.
> >
> >
> >
> > I don't find this to be the case in non-trivial apps/systems.
> >
> Just give me concrete examples and we will discuss them.
>
> >
> >
> >>I mean, in an accountancy system you will hardly ever need a
> >>mechanic view of cars.
> >
> >
> >
> > Didn't say they would. My point is that an accountant
> > and a mechanic will want different views of the same
> > part. The same part record(s) can serve both needs. Thus,
> > no *duplicate* data is needed. You can do that in
> > OOP, but you end up managing indexes yourself.
> >
> In such simple setups, where one modelled item has a
> set of simple physical attributes and a set of simple
> accountancy attributes one might consider using a single
> class to represent car parts, as well. What's your point?
Are you saying the class is *mirroring* the database or
replacing it?
If the first, then why have duplication? If the second,
then classes cannot compete with the full spectrum
of DB operations without programming them yourself.
>
>
> >
> >
> >>But even if you did, you haven't proved
> >>that OOP can't do it, or that it does it worse than a relational
> >>model
> >
> >
> >
> > Well, you have not proven it worse. Hard-wiring a view
> > into code is NOT a good thing in my book.
> >
> > REQUIREMENTS CHANGE
> >
> Just give me an example where you think a OO programmer
> would "hardwire a view into code" and where a "p/r" programmer
> wouldn't.
GOF. GUI's. We have been over this before.
Look at a GOF-based "role" pattern. That is hand
linking stuff. IOW, you are building an index
using code. I say why bother when a DB can
do that for you without clutter up the code
with grunt-work linking crap. IOW, the DB
manages the noun relations, not your code.
("Role" is not in the original GOF book,
I would note, but is generally accepted
into the circle.)
It gets even messier to reinvent the DB when you
consider ad-hoc queries, ACID transactions, backups,
inter-language info sharing, etc. OO Classes just
cannot compete.
>
> Kurt
>
>
-T-
Universe
> Kurt M. Alonso wrote:
>> Sorry for misspelling your name in my earlier posting.
>> Topmind wrote:
>>>>>IMO, OOP fails to grasp the need for "relative abstraction",
>>>>>instead putting all eggs in the one basket of "encapsulation",
>>>>>which is a limiting one-interface-fits-all philosophy.
> This is a joke right?
> Giving a single role task multiple interfaces is a bedrock of OO
> mechanics. It's called p*o*l*y*m*o*r*p*h*i*s*m.
I'm sorry, not really. Poly is more many behaviors for a single
interface.
But my point below stil holds, that in OO we achieve many interfaces for a
single role/task/responsibility with:
~ overloading
~ implements interface
Elliott
panu
> ... The distinctive features of the functional style are: a) the use of
> functions as first-class values, and b) an avoidance of mutation and
> assignment in favor of building new values.
The avoidance of state/mutation also means that it is somewhat
difficult to model real world behavior in a purely functional style.
The real world is changing constantly. So is the state of
an OO program or OO database. But a functional program doesn't
change over time, does it? (see the last paragraph below)
One characterization of functional programs is that they are
'filters', taking an input and transforming it to something
else, then forgetting about it.
To overcome the problem of representing state, you might
naturally write a functional program that writes a new
functional program that replaces the old program after
each execution. But this seems a little awkward, especially
in a multi-user situation.
-Panu Viljamaa
Neelakantan Krishnaswami
> Neelakantan Krishnaswami wrote:
>
> > ... The distinctive features of the functional style are: a) the use of
> > functions as first-class values, and b) an avoidance of mutation and
> > assignment in favor of building new values.
>
> The avoidance of state/mutation also means that it is somewhat
> difficult to model real world behavior in a purely functional style.
> The real world is changing constantly. So is the state of an OO
> program or OO database. But a functional program doesn't change over
> time, does it? (see the last paragraph below)
>
> One characterization of functional programs is that they are
> 'filters', taking an input and transforming it to something else,
> then forgetting about it.
Surprisingly, I find this to actually be one of the big wins of the
functional style. One way that you can model a state-changing
operation mathematically is with a function that takes a state and
returns a new state, in addition to its regular inputs and output. Eg:
op
(inputs, state) =====> (output, new-state)
The reason that this is a win, is that you can factor the program
state so that each operation can take just the state it needs, and
ignore all the rest. This makes figuring out what a program does
vastly easier.
At this point, you might be thinking, "Hey, that sounds just like how
a good object model decomposes state!" This is exactly right, and
explains why functional thinking is really helpful when designing the
right protocol for a class. If a class has lots of extraneous state,
with each bit of state used only in a few methods, that's a good sign
IMO that it should be decomposed.
--
Neel Krishnaswami
ne...@alum.mit.edu
E. Robert Tisdale
> The avoidance of state/mutation also means that
> it is somewhat difficult to model real world behavior
> in a purely functional style.
Please give us an example of "real world behavior"
that can't be modeled in a "purely functional style".
> The real world is changing constantly.
> So is the state of an OO program or OO database.
> But a functional program doesn't change over time, does it?
> (see the last paragraph below)
>
> One characterization of functional programs is that
> they are 'filters', taking an input,
> transforming it to something else
> then forgetting about it.
>
> To overcome the problem of representing state,
> you might naturally write a functional program
> that writes a new functional program
> that replaces the old program after each execution.
> But this seems a little awkward,
> especially in a multi-user situation.
You are confused.
Replacing the old function with a new function
is a state change so you wouldn't have
a purely functional program anymore.
You are a procedural programmer.
Your programs modify the program state
which is represented by variable objects
using a sequence of imperatives.
Universe
> ... procedural programm[ing] ...
> programs modify the program state
> which is represented by variable objects
> using a sequence of imperatives.
Great, with you here, please explain how functional programming differs
from procedural as you see it.
I've repeatedly corrected what I think is the mistaken notion by some on
comp.object who repeatedly equate procedural with structured+relational
system development. They say OO is distinct from this "functional". I
maintain that most OO programming is procdural as well.
In OO most coding involves what I understand to distinguish procedural
programming and that is where developers detail how to reach the goal
rather than simply stating the goal. The latter is more what I grasp to
be characteristic of functional programming.
> programs modify the program state
> which is represented by variable objects
> using a sequence of imperatives.
So it seems functional is more about "declaring" a state rather than
modifying variables to reach a state.
In OO, class abstraction task responsibility behavior is modified within a
set of parameters (a parametric), or within proscribed constraints by
setting/tweaking class attributes/properties.
A bird may have the property of possesing wings but it that is not quite
the same kind of property, for all birds that have wings, that many bird
abstractions expressed in classes would have. Properties for many
bird classes might have attributes that allow one to set wingspan width
within limits, no so much whether or not birds have wings period.
Although of course there are indeed bird class abstrations that have an
attribute like 'isWinged'.
Most class abstractions embody, or implicitly posses, properties to the
abstraction within a domain context and have no data members/attributes
expressing the property directly. As for instance wings in the kind of
bird class abstractions I refer to in the previous paragraph.
I'm comfortable with the statement that in OO modelling for the most part
role task responsibility behavior is key to most class abstractions and
data members for the most part vary the state of that behavior within
limits. Or data members adapt the abstractions so that they may
perform their responsibility in varying contexts. Typically there is a
limit to how much the behavior may be modified, or in the degree of
contextual change within which the abstraction can operate.
Topmind
>
> > ... The distinctive features of the functional style are: a) the use of
> > functions as first-class values, and b) an avoidance of mutation and
> > assignment in favor of building new values.
>
> The avoidance of state/mutation also means that it is somewhat
> difficult to model real world behavior in a purely functional style.
One functional fan told me that they often mix functional
with procedural. There may be long stretches without
side-effects, but the final result of this long
stretch may be a state change,
such as a database update, for example.
The skill is knowing where to use functional
and where to allow side-effects.
I don't know what a "functional purist" would say
though.
>
> The real world is changing constantly. So is the state of
> an OO program or OO database. But a functional program doesn't
> change over time, does it? (see the last paragraph below)
>
> One characterization of functional programs is that they are
> 'filters', taking an input and transforming it to something
> else, then forgetting about it.
>
> To overcome the problem of representing state, you might
> naturally write a functional program that writes a new
> functional program that replaces the old program after
> each execution. But this seems a little awkward, especially
> in a multi-user situation.
>
> -Panu Viljamaa
>
>
-T-
E. Robert Tisdale
> Great, with you here, please explain
> how functional programming differs from procedural as you see it.
>
> I've repeatedly corrected
> what I think is the mistaken notion by some on comp.object
> who repeatedly equate procedural
> with structured+relational system development.
They probably mean Procedure Oriented Programming (POP)
when they say "procedural programming" in contrast to
Object Oriented Programming (OOP).
> They say OO is distinct from this "functional".
> I maintain that most OO programming is procedural as well.
Correct.
> In OO, most coding involves
> what I understand to distinguish procedural programming
> and that is where developers detail how to reach the goal
> rather than simply stating the goal.
> The latter is more what I grasp to be
> characteristic of functional programming.
>
> So it seems functional is more about "declaring" a state
> rather than modifying variables to reach a state.
>
> In OO, class abstraction task responsibility behavior
> is modified within a set of parameters (a parametric)
> or within proscribed constraints
> by setting/tweaking class attributes/properties.
>
> A bird may have the property of possessing wings
> but that is not quite the same kind of property
> for all birds that have wings,
> that many bird abstractions expressed in classes would have.
> Properties for many bird classes might have attributes
> that allow one to set wingspan width within limits,
> not so much whether or not birds have wings period.
> Although, of course, there are indeed bird class abstractions
> that have an attribute like 'isWinged'.
>
> Most class abstractions embody, or implicitly posses,
> properties to the abstraction within a domain context
> and have no data members/attributes expressing the property directly.
> As for instance wings in the kind of bird class abstractions
> that I refer to in the previous paragraph.
>
> I'm comfortable with the statement that,
> in OO modeling for the most part,
> role task responsibility behavior is key to most class abstractions
> and data members for the most part
> vary the state of that behavior within limits.
> Or data members adapt the abstractions
> so that they may perform their responsibility in varying contexts.
> Typically there is a limit to how much the behavior may be modified,
> or in the degree of contextual change
> within which the abstraction can operate.
What I mean by functional programming
is what Ellis Horowitz calls "applicative" programming in
"Fundamentals of Programming Languages",
Chapter 1 The Evolution of Programming Languages,
Section 4 The Stormy '60s, page 19.
"An applicative language is one which achieves its primary effect
by applying functions either recursively or through composition."
For example:
variable Integer n = 13;
variable Integer factorial = 1;
while (1 < n) {
factorial <-- factorial*n;
n <-- n - 1;
};
is a procedure which computes 13! but
constant Integer factorial(constant Integer n) {
return (1 < n)? n*factorial(n - 1): 1;
}
factorial(13);
is a functional program which computes 13!.
The difference is that the functional program
has no [explicit] program state variables.
All of the objects in a functional program are constants --
once instantiated, they remain immutable
until they are destroyed.
Object Oriented Programming languages like C++
allow the programmer to define constructors for classes
which can instantiate constant objects
const myClass object(/* initializer list */);
at the point where the object is defined.
It is always possible but not always practical
to instantiate some objects (such as containers --
arrays, lists, etc.) as constants in C++ except in trivial cases.
But C++ programmers needn't be anal
about functional programming.
They just need to define functions
which return objects by value and avoid defining functions
which modify their arguments or any global variables
then avoid assignments to variables in their programs
whenever possible [practical].
The idea is to limit the number of state variables
that they need to keep track of when analyzing their programs.
This makes programs much easier to read, understand and maintain.
Daniel Parker
"H. S. Lahman" <vze2...@verizon.net> wrote in message
news:3DB451C0...@verizon.net...
> Responding to Burkert...
>
> > 3) What pro's have the functional Languages?
>
>
Uh huh. Can you show me a _practical_ algorithm in a functional language
for, say, a numerical integration problem or a QR factorization of a matrix?
Practical solutions to numerical problems generally require in place
updating of variables. Sure, the algorithm for QSort can be expressed
elegently in say, Haskell, but even there, is that how you would code it in
practice?
Regards,
Daniel Parker
E. Robert Tisdale
> Can you show me a _practical_ algorithm in a functional language
> for, say, a numerical integration problem or a QR factorization of a matrix?
// QR decomposition using Householder transformations and partial pivoting.
const
offsetVector
doubleSubMatrix::qrd(void) {
doubleSubMatrix& A = *this;
doubleSubMatrix T = A.t();
const
Extent m = A.extent2();
const
Extent n = A.extent1();
offsetVector p(m, 0, 1); // permutation vector
for (Offset j = 0; j < m && j < n; ++j) { // Householders method.
doubleSubVector x = T[j].sub(j, m-j, 1);
if (j < m-1) { // Find the pivot element.
Offset k = j + abs(x).max();
if (j < k) { // There is a non-zero pivot element.
p.swap(j, k);
A.swap(j, k);
}
}
double mu = sqrt(x.dot());
if (0 < mu) {
double beta = x[0] + ((x[0] < 0)? -mu: +mu);
doubleVector v = (1/beta)*x;
v[0] = 1; // Householder vector v
T.sub(j, n-j, 1, j, m-j, 1).hht(v);
if (j+1 < m) {
// Pack the essential part of each Householder vector
// into the subdiagonal elements of matrix A.
x.sub(1, m-j-1, 1) = v.sub(1, m-j-1, 1);
}
}
else
break;
}
return p;
}
From
The C++ Scalar, Vector, Matrix and Tensor class library
http://www.netwood.net/~edwin/svmtl/
You don't need to be anal about functional programming.
But it helps to practice it where ever you can
even in "in-place" procedures.
Also, please not that so-called in-place QR Decomposition
usually leaves you with an object that cannot be considered
to be a matrix anymore. It would be better to construct
doubleQRD::doubleQRD(const doubleSubMatrix& A);
a separate QR Decomposition object from a [sub]matrix object.
Mark Alexander Wolton
>
> One functional fan told me that they often mix functional
> with procedural. There may be long stretches without
> side-effects, but the final result of this long
> stretch may be a state change,
> such as a database update, for example.
>
> The skill is knowing where to use functional
> and where to allow side-effects.
>
> I don't know what a "functional purist" would say
> though.
I think this is a very common pattern, actually. In haskell, which is
purely functional, you model this with a monad at the top level which
does I/O, updates, etc, and *uses* pure functions which make up the
engine of the program.
(the nice thing about this is that the complex sections tend to be
functional, making them easier to reason about, and the "impure"
sections tend to be simple.)
mrak
--
call no man happy till he dies
-- Solon the Lawgiver, via Tom Waits
Chris Burkert
> Hi all
>
> I used to work with the object-oriented Language Smalltalk and I am very
> happy with this. But last time I heard about the functional Concepts.
> For example I heard that it is possible to proof a program written in a
> functional Language.
>
> So here are my Question
>
> 1) What pro's have the object-oriented Languages?
> 2) What con's have the object-oriented Languages?
> 3) What pro's have the functional Languages?
> 4) What con's have the functional Languages?
> 5) What Concept do think will make it in the future?
Thanks a lot for all of your answers.
I will stay in the object-oriented World and sometimes will take a look
at the functional World. From my point of view it's better to model most
of the real world problems object-oriented, because the real world is
kind of object-oriented.
Regards
Chris Burkert
--
------------------------------------------------------------------------
Student of applied Computer Science at Chemnitz University of Technology
http://www.chrisburkert.de/ ch...@hrz.tu-chemnitz.de
------------------------------------------------------------------------
"I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind." - Alan Kay --> http://www.squeak.org/
gr...@cs.uwa.edu.au
: Neelakantan Krishnaswami wrote:
:> ... The distinctive features of the functional style are: a) the use of
:> functions as first-class values, and b) an avoidance of mutation and
:> assignment in favor of building new values.
: The avoidance of state/mutation also means that it is somewhat
: difficult to model real world behavior in a purely functional style.
Huh?
: The real world is changing constantly. So is the state of
: an OO program or OO database. But a functional program doesn't
: change over time, does it? (see the last paragraph below)
The program doesn't change, but neither do imperative programs, typically.
As new data becomes available, though, it will begin to operate on the new
data, hence adapting to external circumstances. The new data is not treated
as a replacement for the old data, though, merely as new data that always
had the same value, but that value had not been computed/accquired earlier
because it was not needed. Does that make sense?
: One characterization of functional programs is that they are
: 'filters', taking an input and transforming it to something
: else, then forgetting about it.
I wouldn't say "forgetting about it". Older data will usually be used to
calculate exactly what kind of filter to apply to new data.
: To overcome the problem of representing state, you might
: naturally write a functional program that writes a new
: functional program that replaces the old program after
: each execution.
Not exactly: An imperative program would probably have to rewrite itself to
create a the filter based on old data, but functional languages have
higher-order functions, so they don't need to rewrite themselves - they
just compose their modular components in an appropriate way.
: But this seems a little awkward, especially in a multi-user situation.
What you have described would be awkward indeed. No wonder we don't do it. ;)
-Greg
Kurt M. Alonso
Topmind wrote:
OK. Your RDBMS has a query language that allows you to
execute arbitrary ad-hoc queries.
ODBMSs also support general purpose query languages
nowadays.
What's your point?
>
>>>>A number of more general objections to your text:
>>>>- Within a system you usually need only view data in one way.
>>>
>>>
>>>
>>>I don't find this to be the case in non-trivial apps/systems.
>>>
>>
>>Just give me concrete examples and we will discuss them.
>>
>>
>>>
>>>>I mean, in an accountancy system you will hardly ever need a
>>>>mechanic view of cars.
>>>
>>>
>>>
>>>Didn't say they would. My point is that an accountant
>>>and a mechanic will want different views of the same
>>>part. The same part record(s) can serve both needs. Thus,
>>>no *duplicate* data is needed. You can do that in
>>>OOP, but you end up managing indexes yourself.
>>>
>>
>>In such simple setups, where one modelled item has a
>>set of simple physical attributes and a set of simple
>>accountancy attributes one might consider using a single
>>class to represent car parts, as well. What's your point?
>
>
>
> Are you saying the class is *mirroring* the database or
> replacing it?
>
> If the first, then why have duplication? If the second,
> then classes cannot compete with the full spectrum
> of DB operations without programming them yourself.
>
Consider the following example:
You are writing a strictly procedural Pro*C program.
You need to select all the columns from one table.
In your infinite wisdom you decide to define a C struct
to effect this easily, that is, you define a record
type containing a field for every selected column.
This allows you to do your select easily.
Are you "mirroring" the database?
Please answer Yes or No.
If you answer No, could you please tell me where
the limit is? That is, when can a software construction
be said to "mirror" a database?
>
>
>>
>>>
>>>>But even if you did, you haven't proved
>>>>that OOP can't do it, or that it does it worse than a relational
>>>>model
>>>
>>>
>>>
>>>Well, you have not proven it worse. Hard-wiring a view
>>>into code is NOT a good thing in my book.
>>>
>>>REQUIREMENTS CHANGE
>>>
>>
>>Just give me an example where you think a OO programmer
>>would "hardwire a view into code" and where a "p/r" programmer
>>wouldn't.
>
>
> GOF. GUI's. We have been over this before.
>
As far as I remember you didn't manage to prove anything then,
only that some programmers hardcode constants and others don't.
You tried to imply that there was a way to put GUI structures
in tables but you weren't able to show that there was any
advatange at all in doing so.
>>"hand-indexing class together"? Could you explain
>>that?
>
>
> Look at a GOF-based "role" pattern. That is hand
> linking stuff. IOW, you are building an index
> using code. I say why bother when a DB can
> do that for you without clutter up the code
> with grunt-work linking crap. IOW, the DB
> manages the noun relations, not your code.
> ("Role" is not in the original GOF book,
> I would note, but is generally accepted
> into the circle.)
>
I am sorry, but what is "GOF-based role pattern"?
> It gets even messier to reinvent the DB when you
> consider ad-hoc queries, ACID transactions, backups,
> inter-language info sharing, etc. OO Classes just
> cannot compete.
>
Let me analyze these statements.
You assume that OOP reinvents databases. Please show
me how this may be so, in your opinion.
You proceed then to imply that this re-invention has some
negative relationship with query languages, ACID transactions,
backups, inter-language info sharing.
Please define this relationship.
Kurt
Topmind
>
> > Hi all
> >
> > I used to work with the object-oriented Language Smalltalk and I am very
> > happy with this. But last time I heard about the functional Concepts.
> > For example I heard that it is possible to proof a program written in a
> > functional Language.
> >
> > So here are my Question
> >
> > 1) What pro's have the object-oriented Languages?
> > 2) What con's have the object-oriented Languages?
> > 3) What pro's have the functional Languages?
> > 4) What con's have the functional Languages?
> > 5) What Concept do think will make it in the future?
>
>
> Thanks a lot for all of your answers.
>
> I will stay in the object-oriented World and sometimes will take a look
> at the functional World. From my point of view it's better to model most
> of the real world problems object-oriented, because the real world is
> kind of object-oriented.
This claim has come up before. It is not universally agreed on
by many OO fans, and certainly not by me.
For example, in the biz world, many nouns (entities) often
come together to solve a particular problem. The "central"
thing is the problem being dealt with, and NOT the
participating entities. The participating entities may
come and go (non-invariants). Sure, you can model such in
OO by making a "task class", but it looks fishily
like a procedural "task" in OO clothing to me.
-T-
>
> Regards
> Chris Burkert
Topmind
Is this now RDBMS vs. OODBMS?
The state of OODBMS is currently a dismal mess. (RDB's need
some work too, but far better off than OODB's these days.)
Exactly what an OODBMS is is a contentious issue
in the OO community. Many OO fans seem to really want
RAM that never looses power rather than a "database".
Further, OO query languages have often been criticized
as hard to learn and hard to use.
And, OODB's still require "entity structure
duplication" (see below).
I would try to use a dynamically generated
struture to hold the "result set" rather
than pre-wire it into code. I don't know how
well C can do such. I don't like C, I would
note.
In practice the DB API's usually take care
of such things so that the app programmer
does not have to worry about them. Statically-typed
languages seem to have a harder time with such
issues.
>
> If you answer No, could you please tell me where
> the limit is?
C
:-)
> That is, when can a software construction
> be said to "mirror" a database?
>
> >
> >
> >>
> >>>
> >>>>But even if you did, you haven't proved
> >>>>that OOP can't do it, or that it does it worse than a relational
> >>>>model
> >>>
> >>>
> >>>
> >>>Well, you have not proven it worse. Hard-wiring a view
> >>>into code is NOT a good thing in my book.
> >>>
> >>>REQUIREMENTS CHANGE
> >>>
> >>
> >>Just give me an example where you think a OO programmer
> >>would "hardwire a view into code" and where a "p/r" programmer
> >>wouldn't.
> >
> >
> > GOF. GUI's. We have been over this before.
> >
>
> As far as I remember you didn't manage to prove anything then,
> only that some programmers hardcode constants and others don't.
IIRC, this broke down into what the definition of "OO" was
because I suggested that such designs were not OO or
leaning toward p/r designs in OO clothing.
> You tried to imply that there was a way to put GUI structures
> in tables but you weren't able to show that there was any
> advatange at all in doing so.
Yes I did: Divorce of GUI from specific languages.
Most languages can relatively easily talk to
relational databases. The infrastructure for
that is already in place. Thus, if the GUI
was mostly modeled in relational tables, than
multiple languages could use the same GUI
engine and GUI data.
>
>
> >>"hand-indexing class together"? Could you explain
> >>that?
> >
> >
> > Look at a GOF-based "role" pattern. That is hand
> > linking stuff. IOW, you are building an index
> > using code. I say why bother when a DB can
> > do that for you without clutter up the code
> > with grunt-work linking crap. IOW, the DB
> > manages the noun relations, not your code.
> > ("Role" is not in the original GOF book,
> > I would note, but is generally accepted
> > into the circle.)
> >
>
> I am sorry, but what is "GOF-based role pattern"?
I will see if I can find the original links.
>
> > It gets even messier to reinvent the DB when you
> > consider ad-hoc queries, ACID transactions, backups,
> > inter-language info sharing, etc. OO Classes just
> > cannot compete.
> >
>
> Let me analyze these statements.
> You assume that OOP reinvents databases. Please show
> me how this may be so, in your opinion.
I gave an example where an "invoice" class maintains
its own list of "line items". IOW, the OO programmer
makes an array of pointers/references
to the line-item objects. This is
a DB-like "index" operation, and resembles the
discredited "network databases" of the 1960's.
Many OO fans seem to use such techniques.
When we are done with this example, I have
another little example to discuss.
>
> You proceed then to imply that this re-invention has some
> negative relationship with query languages, ACID transactions,
> backups, inter-language info sharing.
> Please define this relationship.
The noun modeling and noun management is:
1. in the DB
2. in the code
3. or in both
I find things better if #1. If #2, then one has to
re-invent many things that you get for free or
little effort in a DB. #3 creates fighting over
territory, "update 2 spots" factoring problems, and
some of the problems of #2 also.
>
> Kurt
>
>
-T-
Joachim Durchholz
> From my point of view it's better to model most
> of the real world problems object-oriented, because
> the real world is kind of object-oriented.
The real world is indeed object-oriented.
The problem is: this isn't too releant. First, 90% of all software
written is for business; money, bank transfers, invoices, rules and
regulations etc. aren't very "real-world". Second, even if these things
were real, this would still be of secondary importance - the computer
program is never more than an abstraction of real things, and
abstractions are, well, abstract, never object-oriented in any sense.
This doesn't mean that OO isn't a good way to model real-world
interaction. It just means that OO isn't always the natural choice.
Besides, the principles of OO and functional programming can be combined
without damaging either. Actually OO could benefit from functional
ideas: immutable objects are helpful when it comes to avoiding
downcasts, and they are also the first (and most important) step towards
functional programming.
(The other way round isn't too exciting: functional languages can
emulate all the semantics of OO without too much hassle. Most functional
programmers couldn't care less about OO - they don't think it solves any
of their problems. I don't know whether they are right.)
Regards,
Joachim
--
This is not an official statement from my employer.
Daniel Parker
news:3DBA0E1B...@jpl.nasa.gov...
mutating variables, e.g. ++j, or x.sub(1, m-j-1, 1) = v.sub(1, m-j-1, 1),
and you can't do that in a pure functional language. I would challenge you
to express it in a pure functional language, say Haskell, and come up with
an implementation that looked anything like the algorithmic steps in the
book.
Regards,
Daniel Parker
Alfredo Novoa
wrote:
>The state of OODBMS is currently a dismal mess. (RDB's need
>some work too
Actual implementations need a lot of work. Actual implementations can
not be called true relational.
>, but far better off than OODB's these days.)
OODBM's are near to be dead. Their market share is decreasing day by
day.
>Exactly what an OODBMS is is a contentious issue
>in the OO community. Many OO fans seem to really want
>RAM that never looses power rather than a "database".
Although you have terabytes of RAM that never looses power you still
need DMBS's
>Further, OO query languages have often been criticized
>as hard to learn and hard to use.
They don't have a solid theorical foundation like the relational
algebra/calculus
>> If you answer No, could you please tell me where
>> the limit is?
The limit is in replicating the database using a DBMS.
>> Let me analyze these statements.
>> You assume that OOP reinvents databases. Please show
>> me how this may be so, in your opinion.
>
>I gave an example where an "invoice" class maintains
>its own list of "line items". IOW, the OO programmer
>makes an array of pointers/references
>to the line-item objects. This is
>a DB-like "index" operation, and resembles the
>discredited "network databases" of the 1960's.
It is even worse. It resembles when data was managed by applications
not by DBMS's in the 50's.
Alfredo
Topmind
> On Sat, 26 Oct 2002 18:11:59 GMT, top...@technologist.com (Topmind)
> wrote:
>
> >The state of OODBMS is currently a dismal mess. (RDB's need
> >some work too
>
> Actual implementations need a lot of work. Actual implementations can
> not be called true relational.
Oh golly gee, please not this again.
How about "relational based", or "street relational"?
Unless somebody can show a practical, real-world
flaw in the current crop of products, the current
approach is not going away. (I should keep a list,
for SQL has some annoying flaws IMO. Nulls also
bother me.)
>
> >, but far better off than OODB's these days.)
>
> OODBM's are near to be dead. Their market share is decreasing day by
> day.
>
> >Exactly what an OODBMS is is a contentious issue
> >in the OO community. Many OO fans seem to really want
> >RAM that never looses power rather than a "database".
>
> Although you have terabytes of RAM that never looses power you still
> need DMBS's
Some OO fans think otherwise. But I will let them speak
for themselves. Again, their approach seems similar
to the "network databases" of the 1960's. What did they
call that standard? ODYSSAL or something?
>
> >Further, OO query languages have often been criticized
> >as hard to learn and hard to use.
>
> They don't have a solid theorical foundation like the relational
> algebra/calculus
Well, I am not convinced that a "solid theorical foundation"
is necessary. Our brains are not modeled on high math, after all.
The bottom line is that OOQL was just fricken
hard to learn and use for the humans who tried.
>
> >> If you answer No, could you please tell me where
> >> the limit is?
>
> The limit is in replicating the database using a DBMS.
Do you mean copying data? Or replicating functionality?
>
> >> Let me analyze these statements.
> >> You assume that OOP reinvents databases. Please show
> >> me how this may be so, in your opinion.
> >
> >I gave an example where an "invoice" class maintains
> >its own list of "line items". IOW, the OO programmer
> >makes an array of pointers/references
> >to the line-item objects. This is
> >a DB-like "index" operation, and resembles the
> >discredited "network databases" of the 1960's.
>
> It is even worse. It resembles when data was managed by applications
> not by DBMS's in the 50's.
Ouch! Yes.
Actually the "database" back then was a room full of
punched cards and card sorting machines.
>
>
> Alfredo
>
-T-
Alfredo Novoa
wrote:
>How about "relational based", or "street relational"?
How about SQL based, or SQL DBMS's?
>Unless somebody can show a practical, real-world
>flaw in the current crop of products, the current
>approach is not going away.
The list of real world flaws is big. And the confussion is very big.
People usually identifies SQL flaws with relational model flaws.
This is one of the reasons because we should not identify SQL with the
relational model.
>> Although you have terabytes of RAM that never looses power you still
>> need DMBS's
>
>Some OO fans think otherwise.
I know, and it is a very fundamental blunder.
If they think otherwise they don't know what a DBMS is, and what were
the motivations behind DBMS's emergence.
> But I will let them speak
>for themselves. Again, their approach seems similar
>to the "network databases" of the 1960's. What did they
>call that standard? ODYSSAL or something?
CODASYL. And yes it is very similar. The OODBMS approach to data
management is sometimes called "reheated CODASYL"
>> They don't have a solid theorical foundation like the relational
>> algebra/calculus
>
>Well, I am not convinced that a "solid theorical foundation"
>is necessary.
It is very necessary for systematization.
> Our brains are not modeled on high math, after all.
Our brains fails very often. And the brains which do not understand
maths and logic fails very more often.
>The bottom line is that OOQL was just fricken
>hard to learn and use for the humans who tried.
And is not more powerful than the easy and systematic relational
algebra.
>> The limit is in replicating the database using a DBMS.
>
>Do you mean copying data? Or replicating functionality?
I mean replicating database.
Database = data + business rules.
Alfredo
H. S. Lahman
> The real world is indeed object-oriented.
> The problem is: this isn't too releant. First, 90% of all software
> written is for business; money, bank transfers, invoices, rules and
> regulations etc. aren't very "real-world". Second, even if these things
> were real, this would still be of secondary importance - the computer
> program is never more than an abstraction of real things, and
> abstractions are, well, abstract, never object-oriented in any sense.
The use of "real world" in the OO context is a relative term. Basically
it refers to the underlying domain where the problem to be solved
exists. Since OT is about abstraction the "real world" is simply the
problem space from which the OO solution is abstracted. So in the world
of business things like bank transfers are quite "real world".
There are also situations where the "real world" is the computing space
itself. For example, when an application is persisting data in an RDB
the "real world" is that of the relational data model, server bandwidth,
deadlocks, etc.
>
> This doesn't mean that OO isn't a good way to model real-world
> interaction. It just means that OO isn't always the natural choice.
>
> Besides, the principles of OO and functional programming can be combined
> without damaging either. Actually OO could benefit from functional
> ideas: immutable objects are helpful when it comes to avoiding
> downcasts, and they are also the first (and most important) step towards
> functional programming.
I am a bit dubious of this. They are quite different paradigms for
development. As a result 3GL features that support the paradigms are
quite different. What counts is the synergy between all the pieces
playing together properly. Mixing and matching features can break that
synergy.
For example, there is a lot of bad OO software around because developers
converting from procedural to OO development mapped familiar procedural
paradigms like hierarchical control structures onto OOPLs.
BTW, downcasts are easily avoided (except for a few language-dependent
situations) if one identifies and implements relationships properly in
OO development. But the handling of state is very, very different. The
notion of an immutable object may play well in an FP context, but not
necessarily so in an OO context.
> (The other way round isn't too exciting: functional languages can
> emulate all the semantics of OO without too much hassle. Most functional
> programmers couldn't care less about OO - they don't think it solves any
> of their problems. I don't know whether they are right.)
That's interesting. I had a debate here (comp.object) quite awhile ago
with an FP advocate who argued that it would very difficult to translate
a translation quality OOA model into a language like Haskell or Miranda.
His argument was based on the fact that they are quite different
paradigms (e.g., state variables) so the structure would be difficult to
emulate efficiently.
As a translationist I didn't see a major problem. We routinely target C
in translation without difficulty. C has state variables but none of
the other OOPL facilities. (OTOH, I didn't know enough about FP to
argue the point convincingly.) But I agreed with him that because of
the different paradigms it might not be desirable to target an FP
language in the translation. [Since the code is not maintained, it
doesn't much matter what language one targets. So one trades off code
size and performance vs. making the translation engine easier to build.]
I can certainly see the FP programmers' view, though. The relative
strengths and weaknesses tend to result in OT and FP being applied in
different problem domains. One probably doesn't see a lot of linear
programming packages implemented with OT. B-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Topmind
> On Sun, 27 Oct 2002 01:21:35 GMT, top...@technologist.com (Topmind)
> wrote:
>
> >How about "relational based", or "street relational"?
>
> How about SQL based, or SQL DBMS's?
Okay. I'll buy that.
>
> >Unless somebody can show a practical, real-world
> >flaw in the current crop of products, the current
> >approach is not going away.
>
> The list of real world flaws is big. And the confussion is very big.
Perhaps they are not articulating them properly. They tend to
get too philosophical it seems. Instead provide some
specific failure scenarios that resonate with current
SQL users. IOW, describe problems that they can relate
to rather than be preachy. IOW, "Here is a situation
that will require you to change 4 spots instead of
just one" rather than "it lacks symetric transversal
sine provability".
>
> People usually identifies SQL flaws with relational model flaws.
Indeed! It is sort of like, "procedural is bad because I used
C and it sucked", or "cars are bad because I had an Escort and
it sucked."
>
> This is one of the reasons because we should not identify SQL with the
> relational model.
>
> >> Although you have terabytes of RAM that never looses power you still
> >> need DMBS's
> >
> >Some OO fans think otherwise.
>
> I know, and it is a very fundamental blunder.
>
> If they think otherwise they don't know what a DBMS is, and what were
> the motivations behind DBMS's emergence.
>
> > But I will let them speak
> >for themselves. Again, their approach seems similar
> >to the "network databases" of the 1960's. What did they
> >call that standard? ODYSSAL or something?
>
> CODASYL. And yes it is very similar. The OODBMS approach to data
> management is sometimes called "reheated CODASYL"
"Those who don't know history are doomed to repeat it" :-)
The same complexity that plagued the network
databases are plaguing OODBMS in similar ways it seems.
Two strikes is hopefully enough to bury it once and for all.
Otherwise, we will see it tried again if I live to be 80
perhaps.
>
> >> They don't have a solid theorical foundation like the relational
> >> algebra/calculus
> >
> >Well, I am not convinced that a "solid theorical foundation"
> >is necessary.
>
> It is very necessary for systematization.
>
> > Our brains are not modeled on high math, after all.
>
> Our brains fails very often. And the brains which do not understand
> maths and logic fails very more often.
Logic, yes. But I am not sure that modeling everything on
math is the way to go. It might provide some
theorietic consistency, but that does not necessarily
make it easy to relate or nor necessarily model well
to the domain world.
For example, relativity might be more accurate
than Newtonian phyz, but it requires far more
educution to use effectly, but providing insignificant
improvement for that effort.
Software engineering is as much about psychology
as it is math. After all, software engineering is
about communicating clearly with humans, not
just computers.
I would note that relational got more attention when
researchers found that it could greatly simplify a test
set of queries, not because of its alleged mathematical
purity. Codd was originally ignored more or less
until he learned how to show practical benefits in
his speeches.
If you cannot translate conceptual ideas into
practical benefits, then either the idea is flawed
or you are selling it wrong.
>
> >The bottom line is that OOQL was just fricken
> >hard to learn and use for the humans who tried.
>
> And is not more powerful than the easy and systematic relational
> algebra.
>
> >> The limit is in replicating the database using a DBMS.
> >
> >Do you mean copying data? Or replicating functionality?
>
> I mean replicating database.
>
> Database = data + business rules.
>
How much of the "business rules" should be in the
DB is a highly contentious issue. Some will say
that it is hard to know what are truely invariant
and/or "global" biz rules up front.
>
> Alfredo
>
-T-
Kurt M. Alonso
Topmind wrote:
>>OK. Your RDBMS has a query language that allows you to
>>execute arbitrary ad-hoc queries.
>>ODBMSs also support general purpose query languages
>>nowadays.
>>What's your point?
>
>
>
> Is this now RDBMS vs. OODBMS?
>
> The state of OODBMS is currently a dismal mess. (RDB's need
> some work too, but far better off than OODB's these days.)
>
> Exactly what an OODBMS is is a contentious issue
> in the OO community. Many OO fans seem to really want
> RAM that never looses power rather than a "database".
>
> Further, OO query languages have often been criticized
> as hard to learn and hard to use.
>
> And, OODB's still require "entity structure
> duplication" (see below).
>
The proper context for my comment above has been lost.
You had implied that your approach was superior because
an accountant was able to query the database for the 100
topmost car part that satisfied some property.
But that is obviously irrelevant to the issue at hand:
some DBMSs implement query languages and some don't,
regardless of paradigm.
>
>>Consider the following example:
>>You are writing a strictly procedural Pro*C program.
>>You need to select all the columns from one table.
>>In your infinite wisdom you decide to define a C struct
>>to effect this easily, that is, you define a record
>>type containing a field for every selected column.
>>This allows you to do your select easily.
>>Are you "mirroring" the database?
>>Please answer Yes or No.
>
>
>
> I would try to use a dynamically generated
> struture to hold the "result set" rather
> than pre-wire it into code. I don't know how
> well C can do such. I don't like C, I would
> note.
>
> In practice the DB API's usually take care
> of such things so that the app programmer
> does not have to worry about them. Statically-typed
> languages seem to have a harder time with such
> issues.
>
In real world projects, managers tend to choose
compiled languages, with static typing, and solutions
such as the one I mention above are the norm. Technically
speaking, it is possible to implement a dynamic solution
in C, but the language being statically typed, you would
probably just end up moving elsewhere (but not removing)
your assumptions about the results of a given query.
>
>
>>If you answer No, could you please tell me where
>>the limit is?
>
>
> C
>
> :-)
>
As an aside, what existing procedural language would
you recommend for a semi-large project?
>
>>As far as I remember you didn't manage to prove anything then,
>>only that some programmers hardcode constants and others don't.
>
>
>
> IIRC, this broke down into what the definition of "OO" was
> because I suggested that such designs were not OO or
> leaning toward p/r designs in OO clothing.
>
>
>
>>You tried to imply that there was a way to put GUI structures
>>in tables but you weren't able to show that there was any
>>advatange at all in doing so.
>
>
> Yes I did: Divorce of GUI from specific languages.
>
> Most languages can relatively easily talk to
> relational databases. The infrastructure for
> that is already in place. Thus, if the GUI
> was mostly modeled in relational tables, than
> multiple languages could use the same GUI
> engine and GUI data.
>
The important question here is exactly what you
put in tables. I suspect that what you are envisioning
is one or more tables containing GUI item attributes,
such as position, font, foreground color, etc, and
a code library that can construct a GUI by retrieving
data from these tables.
Question:
Couldn't you put this data in a configuration file instead,
and have the GUI library read this file instead? What
are the advantages of using database tables?
I don't get the point. I have seen this very setup zillions
of times in procedurally designed systems. Master-detail
relationships are usually solved with the help of
arrays or sibling-type pointer structures.
>
>
>>You proceed then to imply that this re-invention has some
>>negative relationship with query languages, ACID transactions,
>>backups, inter-language info sharing.
>>Please define this relationship.
>
>
> The noun modeling and noun management is:
>
> 1. in the DB
> 2. in the code
> 3. or in both
>
> I find things better if #1. If #2, then one has to
> re-invent many things that you get for free or
> little effort in a DB. #3 creates fighting over
> territory, "update 2 spots" factoring problems, and
> some of the problems of #2 also.
I suspect that the problem here is that you lack
experience with larger systems. Relational database
theory tells you, in essence, that you must factorize
your data and store every factor separately. This
entails, for instance, that you must atomize cars
into parts, and parts into subparts, before you
can consider storing them in a database. Which means
that such a database would not directly contain the notion
of car. Which in turn means that the notion of car
must be constructed by you in your program.
That is, the noun "car" is managed by your client
code.
In other words, solution #1 is most often not
available, except for very simple systems.
Kurt
Topmind
If somebody could identifiable agreeable guidelines for when to
use what paradigm (including p/r) and why, it would prevent
a lot of debates and flamewars.
BTW, I do not see how OO allegedly better maps to the real
world. (I snipped that portion.)
If you would like to offer a formal proof or
a careful line of reasoning, you are welcome. IMO OO may
indeed map to some individuals' *perception* of the real
world. But every head is different. If you wish to claim
that OO maps well to how you as an individual view the
world, then I have no problem with that as long as you
don't extrapolate that to other heads without better
evidence.
-T-
Topmind
>
> Topmind wrote:
>
> >>OK. Your RDBMS has a query language that allows you to
> >>execute arbitrary ad-hoc queries.
> >>ODBMSs also support general purpose query languages
> >>nowadays.
> >>What's your point?
> >
> >
> >
> > Is this now RDBMS vs. OODBMS?
> >
> > The state of OODBMS is currently a dismal mess. (RDB's need
> > some work too, but far better off than OODB's these days.)
> >
> > Exactly what an OODBMS is is a contentious issue
> > in the OO community. Many OO fans seem to really want
> > RAM that never looses power rather than a "database".
> >
> > Further, OO query languages have often been criticized
> > as hard to learn and hard to use.
> >
> > And, OODB's still require "entity structure
> > duplication" (see below).
> >
>
> The proper context for my comment above has been lost.
> You had implied that your approach was superior because
> an accountant was able to query the database for the 100
> topmost car part that satisfied some property.
NO! I said nothing about simplifying labor for the
accountant IIRC. That was not my intentioned meaning.
> But that is obviously irrelevant to the issue at hand:
> some DBMSs implement query languages and some don't,
> regardless of paradigm.
So you are assuming that a database (of some sort) is
being used in both cases?
If that is the case, then still, why have the noun
model and noun management be in application code
and not the DB?
>
> >
>
> >>Consider the following example:
> >>You are writing a strictly procedural Pro*C program.
> >>You need to select all the columns from one table.
> >>In your infinite wisdom you decide to define a C struct
> >>to effect this easily, that is, you define a record
> >>type containing a field for every selected column.
> >>This allows you to do your select easily.
> >>Are you "mirroring" the database?
> >>Please answer Yes or No.
> >
> >
> >
> > I would try to use a dynamically generated
> > struture to hold the "result set" rather
> > than pre-wire it into code. I don't know how
> > well C can do such. I don't like C, I would
> > note.
> >
> > In practice the DB API's usually take care
> > of such things so that the app programmer
> > does not have to worry about them. Statically-typed
> > languages seem to have a harder time with such
> > issues.
> >
>
> In real world projects, managers tend to choose
> compiled languages, with static typing, and solutions
> such as the one I mention above are the norm.
Are you suggesting that OOP works better if one
is forced to use a static language? IOW, it works
better if you are not allowed to use the right
tool for the job?
I will agree that dynamic languages seem to work
better with databases IMO. That is perhaps one reason
why I prefer dynamic languages. Static languages
are kind of insular--they assume you can compile
everything needed up front, which is often unrealistic
in an interconnected world. You just can't compile
the whole world.
> Technically
> speaking, it is possible to implement a dynamic solution
> in C, but the language being statically typed, you would
> probably just end up moving elsewhere (but not removing)
> your assumptions about the results of a given query.
True. There would perhaps be dynamic code generation (yik)
or a lot of funky pointer stuff.
There is a bit of philisophical disconnect between
databases and compiled languages because you cannot
effectively "compile" a database and do compile-time
checks on it without some kind of tie-in tool.
>
> >
> >
> >>If you answer No, could you please tell me where
> >>the limit is?
> >
> >
> > C
> >
> > :-)
> >
>
> As an aside, what existing procedural language would
> you recommend for a semi-large project?
I don't know. OOP is killing off the progress and variety
of alternatives to OOP. Procedural language progress
stopped pretty much dead in its tracks around 1990.
I have a list of features I like in procedural languages
here:
http://geocities.com/tablizer/prtips.htm
Also, "large project" is hard to define because the
boundaries and divisions are not always descrete.
In my approach the database is the "glue" of the system,
and not code. Each "task" is coded relatively independently.
The main exception is to coordinate the UI. However,
tablized GUI's are possible. It is code-centric
GUI's that lead to "one big EXE" more than anything
IMO.
If GUI's were (properly) tablized, then we could
return to the idea of each procedural task being
relatively independent, REGARDLESS of the size
of the application or system (if "application"
still had meaning.)
>
> >
>
> >>As far as I remember you didn't manage to prove anything then,
> >>only that some programmers hardcode constants and others don't.
> >
> >
> >
> > IIRC, this broke down into what the definition of "OO" was
> > because I suggested that such designs were not OO or
> > leaning toward p/r designs in OO clothing.
> >
> >
> >
> >>You tried to imply that there was a way to put GUI structures
> >>in tables but you weren't able to show that there was any
> >>advatange at all in doing so.
> >
> >
> > Yes I did: Divorce of GUI from specific languages.
> >
> > Most languages can relatively easily talk to
> > relational databases. The infrastructure for
> > that is already in place. Thus, if the GUI
> > was mostly modeled in relational tables, than
> > multiple languages could use the same GUI
> > engine and GUI data.
> >
>
> The important question here is exactly what you
> put in tables. I suspect that what you are envisioning
> is one or more tables containing GUI item attributes,
> such as position, font, foreground color, etc, and
> a code library that can construct a GUI by retrieving
> data from these tables.
Pretty close. The other big peice is event handling
dispatching. I talk about it some at:
http://geocities.com/tablizer/guitable.htm
>
> Question:
> Couldn't you put this data in a configuration file instead,
> and have the GUI library read this file instead? What
> are the advantages of using database tables?
Primarily random access. If you have 500 items in a GUI
setup, then a sequential search for every GUI transaction
becomes slow. Secondary benefits are the
ability to search, sort, filter, cross-reference,
etc. for debugging and maintenance. You are not
stuck with a single division criteria (such as
one form per file). Your view of it is up to
you. You can view the GUI attributes by form,
by widget "type", but screen position, by
label title, etc.
I should note that often GUI attributes are changed
during the running of an application (or at least
a copy is changed). Thus, there is more than just
"reading" a config file. We want to be able to
change stuff, such as filling in the name of an
employee after an employee number is typed in, or
perhaps hide certain fields if the user does not
have proper access levels.
To be dynamic, either we are going to have to
use some array-like thingy, or a database. Arrays
suck IMO, and if you fix them so that they don't
suck anymore, they will take on characteristics
of a database. Hint hint.
> >
> >>
> >>>>"hand-indexing class together"? Could you explain
> >>>>that?
> >>>
> >>>
> >>>It gets even messier to reinvent the DB when you
> >>>consider ad-hoc queries, ACID transactions, backups,
> >>>inter-language info sharing, etc. OO Classes just
> >>>cannot compete.
> >>>
> >>
> >>Let me analyze these statements.
> >>You assume that OOP reinvents databases. Please show
> >>me how this may be so, in your opinion.
> >
> >
> >
> > I gave an example where an "invoice" class maintains
> > its own list of "line items". IOW, the OO programmer
> > makes an array of pointers/references
> > to the line-item objects. This is
> > a DB-like "index" operation, and resembles the
> > discredited "network databases" of the 1960's.
> >
> > Many OO fans seem to use such techniques.
> >
> > When we are done with this example, I have
> > another little example to discuss.
> >
>
> I don't get the point. I have seen this very setup zillions
> of times in procedurally designed systems. Master-detail
> relationships are usually solved with the help of
> arrays or sibling-type pointer structures.
Yes. I agree that such *could* be done in arrays,
but IMO it is usually a sign of poor design or poor
DB tools. Many DB tools only target big formal
stuff instead of "work areas", and this is a mistake
IMO. Arrays are evil things to be avoided like the
plague if possible in my book. Microsoft is putting
more "local DB" gizmos in its tools to address these
kinds of things. Thus, I am not the only one to
recognize this problem. (Remember, I used to use
a lot of XBase, which made tables a snap....even
though the language sucked in other ways.)
> >
> >>You proceed then to imply that this re-invention has some
> >>negative relationship with query languages, ACID transactions,
> >>backups, inter-language info sharing.
> >>Please define this relationship.
> >
> >
> > The noun modeling and noun management is:
> >
> > 1. in the DB
> > 2. in the code
> > 3. or in both
> >
> > I find things better if #1. If #2, then one has to
> > re-invent many things that you get for free or
> > little effort in a DB. #3 creates fighting over
> > territory, "update 2 spots" factoring problems, and
> > some of the problems of #2 also.
>
> I suspect that the problem here is that you lack
> experience with larger systems.
An easy out for you if true.
> Relational database
> theory tells you, in essence, that you must factorize
> your data and store every factor separately. This
> entails, for instance, that you must atomize cars
> into parts, and parts into subparts, before you
> can consider storing them in a database. Which means
> that such a database would not directly contain the notion
> of car. Which in turn means that the notion of car
> must be constructed by you in your program.
> That is, the noun "car" is managed by your client
> code.
You could have a "Car" table if needed. I don't
understand this complaint. Could you elaborate on it more?
It is true that in p/r a custom "view" is indeed often constructed
for each task. But this is a benefit, not a liability.
This means that your models do not have to be "correct"
up front, at least not behavioral interfaces.
If the same view is needed by *multiple* tasks, then
you simply make a shared view-maker routine, a DB "view", or
a stored procedure. Thus, you can factor out duplication
if needed.
This is in contrast to OO philos which tends to
say, "Here is entity Car and it has an
interface that is to serve as the sole gate
to ALL interactions and operations on a car."
The flaw of that is that first it requires a
kind of "one interface fits all" pressure,
and second you have to reinvent a lot of
DB-like operations into that interface such
as Add (add car), delete, find, sort, search,
cross-reference (join), etc. DB experts have
noticed that these needs tend to frequenty come
up for entities, so thus factored such operations
into the DB instead of DUPLICATING them for each
entity in code. It thus simplifies interfaces.