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.
>
> In other words, solution #1 is most often not
> available, except for very simple systems.
Simple? In my observation DB's are more likely to
be in larger setups than simple ones. This is partly
why Larry Ellison is usually in the top 10 richest man
in the world lists.
>
>
> Kurt
>
>
-T-
panu
> ...
> 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.
I see the point that functional programming makes programs
easier to understand (since you need not reason about the
state of the program execution).
I believe fp actually had its roots in efforts to "model
programs with functions", so that they would be easier to
understand and prove theorems about. And since a program
with variable assignments could not be modeled as functions,
they perhaps figured: Why don't we create a programming
language where only thing you have is functions, so we can
easily reason about it.
So yes, functions make great models for computer programs.
The only objection to this is that sometimes we are more
interested in "modeling the world" than "modeling a computer
program". And if so, OO languages with variables that hold on
to changing state might be a better fit for the task.
-Panu Viljamaa
Joachim Durchholz
>
> So yes, functions make great models for computer programs.
>
> The only objection to this is that sometimes we are more
> interested in "modeling the world" than "modeling a computer
> program". And if so, OO languages with variables that hold on
> to changing state might be a better fit for the task.
No, no, no.
OO is not about modelling the world. Real-world objects and computer
objects are quite different animals! Unless you're doing physical
simulations, a computer program is about things that are quite abstract
in themselves: invoices, files, hash tables. By that argument, one could
say that functions are a better fit, since functions are closer to
mathematical models... but that's not true either. All functional
languages offer ways to work with state; it's just that functional
programs need little or no explicit internal state, the state stuff is
just needed for working with the external world.
Joachim Durchholz
> Responding to Durchholz...
>
>> 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".
If your definition of "real world" is just the problem space, then
objects are just an abstraction about the problem space, and don't come
as naturals.
>> 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.
Right.
OO and FPL are synergistic, in a sense: OO would benefit from functional
ideas, but it's not clear whether FPLs would benefit from OO ideas.
> 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.
I've seen such code, thanks *shudder*.
It's also easy to overdo OO in a hybrid OO/functional language, or so I
have been told.
The reverse experiment, adding functional facilities to an OO language,
has been successful though (see www.eiffel.com). They added "agents" (a
fancy term for "closure", essentially a function call with some or all
parameters already filled in, to be passed around and executed later),
and what I have read was stuff like "we wouldn't want to miss them".
> BTW, downcasts are easily avoided (except for a few
> language-dependent ituations) if one identifies and implements
> relationships properly in OO development.
Um... well... after a few iterations, the relationships tend to become
"improper".
However, you get into trouble if you override a result type and that
result type is mutable. That may not be "lots of downcasts", but it's
still a type hole that doesn't exist if you don't have mutable objects.
> 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.
It's compatible. You can do OO with mutable and immutable objects alike.
Likewise, you can add OO to functional languages; it's being done all
the time.
> 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.
For Haskell and Miranda, it would certainly be difficult. For starters,
these languages use lazy evaluation. This has some advantages for
program design (which aren't relevant when automatically translating to
the language), but makes complexity less predictable (which is a
definite disadvantage).
Mercury makes data ownership a type annotation. Only the owner of a
piece of data may modify it (and in a C context, the owner would also be
responsible for deallocating it). I don't know what a "translation
quality" OOA model is, so I can't tell whether that's a restriction or not.
ML does allow functions with side effects, so there should be no problems.
> 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.)
I don't see any problem either. Ultimately, all languages are translated
to machine code, a stateful paradigm with a stack and a lot of named
memory cells, where stack and cells except "registers" are aliased. It's
grossly incompatible with the majority of programming languages, yet we
routinely translate all software to that model, and it even works.
> 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.]
Exactly.
I don't see any advantages in using an FPL as a target for automated
translation.
UNLESS the OOA model is functional in nature; in that case, the FPL will
be advantageous because FPL run-time systems are geared towards that
style of computation.
> 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 aren't many in FPLs, either.
I have seen a FFT generator in an FPL though. You input the parameters
(like: number of rows/columns must be a power of two, squareness of
matrix, and some other factors), and the FP program will adapt the
algorithm and output a C program that's optimized for that particular
set of constraints.
It's been a while, but I have seen a handful of reports that it's been
helpful :-)
Last year's International Conference on Functional Programming contest
required programming a raytracer. Since the contest is open to all
programming languages, there were a lot of entries. Having bugs
disqualified, after that, entries were ranked according to speed. The
two top-scorers were functional :-)
From what I read, the task was 50:50 translating the scene description
language into a model and then doing the actual raytracing. (The
language wasn't simple: it allowed specifying procedureal - er,
functional surface patterns. So 50% of that contest were still symbolic
computation, one of the relative strengths of FPLs. But I think the
specialization of FPLs on symbolic computations is more due to tradition
than due to technical reasons.)
George Russell
[snip]
> There aren't many in FPLs, either.
> I have seen a FFT generator in an FPL though. You input the parameters
> (like: number of rows/columns must be a power of two, squareness of
> matrix, and some other factors), and the FP program will adapt the
> algorithm and output a C program that's optimized for that particular
> set of constraints.
> It's been a while, but I have seen a handful of reports that it's been
> helpful :-)
I think you are maybe thinking of FFTW.
http://www.fftw.org
FFT as taught in undergraduate courses usually assumes the
problem size to be a power of 2. To deal with other problem sizes, it's
necessary to come up with special code to deal with the various prime
factors of the problem size. (Thus people have written FFT programs
which will solve all problems which have size 2^i3^j5^k for some i,j,k.)
FFTW generalises this approach by using Objective CAML to search for
efficient methods for particular primes, outputting what it finds as
C.
As far as I know FFTW is the fastest general-purpose FFT program around,
at least in the public domain, though there may exist programs which
solve particular problem sizes on particular machines faster.
Joachim Durchholz
That's correct. Thanks for adding the reference.
Andreas Rossberg
>
> BTW, I do not see how OO allegedly better maps to the real
> world.
Me neither. I believe that the regular reappearance of that impression
is rather a result of 2 decades of object-oriented predominance in the
mainstream and the ensuing effect of public brain-washing.
- Andreas
--
Andreas Rossberg, ross...@ps.uni-sb.de
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.
Joachim Durchholz
>
> Me neither. I believe that the regular reappearance of that impression
> is rather a result of 2 decades of object-oriented predominance in the
> mainstream and the ensuing effect of public brain-washing.
The term "brainwashing" implies a person who's doing that on purpose. I
don't think that this has happened - it's just the model that has been
working best for encapsulating state (which is, ironically, as far from
the real world as one can get).
What has been so seductive is simply the combination of "it's useful, so
the term is in use", "the term is a deceptively common word", and
"real-world objects give a damn good analogy for the semantics of a
computer object".
The point being: computer objects share some similarities with
real-world objects, but similarities don't mean they are the best model.
Maybe it's best explained by an analogy:
The best model of the solar system is not an orange for the sun and
various fruits at appropriate distances. Even if the orange is a good
approximation to the sun in form and color.
But the best model is a set of differential equations. Last time I
looked they were neither round nor orange, but they are definitely a
better model ;-)
Similarly, a set of functions most likely will work very differently
than a real-world object, but it may still be the better model.
BTW even in programming, at most 10% of all objects have some analogy in
the real world. There must be other advantages to OO, else people would
be programming the other 90% in the traditional style.
Matthias Blume
> Neelakantan Krishnaswami wrote:
>
> > ...
> > 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.
>
> I see the point that functional programming makes programs
> easier to understand (since you need not reason about the
> state of the program execution).
Wrong. You always have to reason about state. In a functional
program, state is explicit, which makes reasoning is a bit easier.
> I believe fp actually had its roots in efforts to "model
> programs with functions", so that they would be easier to
> understand and prove theorems about. And since a program
> with variable assignments could not be modeled as functions,
> they perhaps figured: Why don't we create a programming
> language where only thing you have is functions, so we can
> easily reason about it.
Programs with variable assignments _can_ be modeled as functions. See
your favorite textbook on programming language semantics.
--
-Matthias
Daniel C. Wang
panu <pa...@fcc.net> writes:
{stuff deleted}
> programs with functions", so that they would be easier to
> understand and prove theorems about. And since a program
> with variable assignments could not be modeled as functions,
> they perhaps figured: Why don't we create a programming
> language where only thing you have is functions, so we can
> easily reason about it.
>
> So yes, functions make great models for computer programs.
>
> The only objection to this is that sometimes we are more
> interested in "modeling the world" than "modeling a computer
> program". And if so, OO languages with variables that hold on
> to changing state might be a better fit for the task.
The pure lambda calculus was invented before the computer, and used as a
system of logic. Only, later was it adopted as a computational programming
language.
Philip Wadler, Proofs are Programs: 19th Century Logic and 21st Century
Computing. This is a variant of another article, New Languages, Old Logic,
that appeared in Dr Dobbs Journal, special supplement on Software in the
21st century,
http://www.research.avayalabs.com/user/wadler/topics/history.html#drdobbs
It is simply not true that you cannot model languages with variables with a
FPL. In fact many optimizing compilers internally build a functional
representation of the program to make reasoning and optimizing the
imperative program easier.
SSA is Functional Programming. Andrew W. Appel, ACM SIGPLAN Notices v. 33,
no. 4, pp. 17-20, April 1998.
http://www.cs.princeton.edu/~appel/papers/ssafun.ps
It's a shame that most of this stuff is not common knowledge, and people
have incorrect perceptions about what's really going on.
panu
> ... 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.)
Can you explain a bit, how can Haskell be "purely functional"
if it has both 'pure functions' and "impure sections" ? Wouldn't
this suggest it is "almost purely functional" ?
Thanks
-Panu Viljamaa
Universe
Joachim Durchholz
>
> Can you explain a bit, how can Haskell be "purely functional"
> if it has both 'pure functions' and "impure sections" ?
It doesn't.
The main function of a Haskell program takes a list of inputs (such as:
the characters of an input file, or the sequence of events for a GUI
program), and returns a list of action descriptions. The run-time system
then executes these actions.
The above description is a bit misleading. The run-time system
alternates between reading the next action description and executing it;
the inputs are only read at the moment at which they are needed to
construct data in a given action description. However, the Haskell
programmer doesn't have to adapt his program to do that, accessing a
data field automatically triggers the computation that fills it. (In
fact this demand-driven computation is the default expression evaluation
strategy in Haskell; it's called "lazy evaluation" since the run-time
system defers any activities until the last possible moment.)
Peter G. Hancock
>>>>> panu wrote (on Mon, 28 Oct 2002 at 06:33):
> Can you explain a bit, how can Haskell be "purely functional"
> if it has both 'pure functions' and "impure sections" ? Wouldn't
> this suggest it is "almost purely functional" ?
I'll have a go.
A Haskell program (an object of type IO something) is essentially a
great big infinite data-structure, a bit like a tree. The input the
program gets as it runs steers a path into this tree, and causes
output.
Impure sections are really perfectly ordinary functional
code. However, the functions given for construction of IO programs have
an imperative flavour.
* basic operations in the run-time system (which are like
assignment statements to the system state),
* dispatch on input, and
* sequencing.
In some sense, in functional programming, you use a functional
language to write an imperative program.
Peter Hancock
Adrian Hey
> It is simply not true that you cannot model languages with variables with
> a FPL. In fact many optimizing compilers internally build a functional
> representation of the program to make reasoning and optimizing the
> imperative program easier.
>
> SSA is Functional Programming. Andrew W. Appel, ACM SIGPLAN Notices v.
> 33, no. 4, pp. 17-20, April 1998.
>
> http://www.cs.princeton.edu/~appel/papers/ssafun.ps
>
>
> It's a shame that most of this stuff is not common knowledge, and people
> have incorrect perceptions about what's really going on.
Yes, it seems that many folk don't really understand just how expressive
FPL's are. Using a "functional programming style" in a conventional
imperative language (OO or not OO) is a poor second best (and IMHO more
likely to put people of FP altogether rather than persuade them it's a
good thing).
I think it would be an instructive exercise for such doubters to write
purely functional equivalents of imperative "while do" and "repeat untils"
as higher order functions. Anything I can do with a loop and mutable
variables can just as easily be done using tail recursive functions, but
the converse is not true (well not without using the evil goto :-).
As for the OOP vs. FP debate on this thread, MHO's are..
1- Referential transparency seems to pretty much essential
for desirable features like type security, static analysis,
theorem proving and sophisticated compiler optimisations.
Any programming language which doesn't offer guarantees in this
respect is a poor design. Therefore just about all widely used OO
languages and some "functional" (but not purely functional) languages
are poor designs (or perhaps I should say "less than ideal" :-).
2- As an electronics engineer (I'm not a computer scientist) I get the
clear impression that FP is a science, but with OOP all this talk of
"models" and "real worlds" seems more like voodoo to me. I'm probably
doing the OO community an injustice by saying that. The trouble with
OO is that there are so many businesses trying to peddle tools to
support "object technology" it becomes very difficult to distinguish
fact from fiction in the torrents meaningless BS from marketdroids.
3- I don't see the choice of OOP vs. FP as a strictly either/or decision.
I can't see any reason why you couldn't have an purely functional
object oriented language. Reading about the CLOVER language of Chris
Clack and Lee Braine was quite instructive to me, particularly in
helping me sort out in my own mind what "object oriented" actually
means in the context of a pure FPL. Maybe folk from both communities
could learn something by taking a look at it.
Regards
--
Adrian Hey
Albert Lai
> 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
Object orientation is a way to organize the structure of a program.
Functional programming is a way to implement an algorithm. I find
them orthogonal; they are relevant in different levels of software
construction. When I am structuring my program, I choose between
objects, aspects, and modules. When I get to implement a core method,
I choose between functional programming and imperative programming.
In Smalltalk programming, sometimes you decide that certain objects
should be immutable, and operations over them should create new
immutable objects rather than modify existing ones. That is already a
form of functional programming. Another favourite thing that
functional programmers like to do is to define and use higher order
functions or higher order procedures; these are simply blocks in
Smalltalk.
Object orientation means you want to organize your program and data
around classes and objects. Functional programming means you stick
with immutable objects and side-effect-free methods.
I would compare object orientation with higher-order modules.
A comparison I like is done by Xavier Leroy:
http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz
H. S. Lahman
> I believe fp actually had its roots in efforts to "model
> programs with functions", so that they would be easier to
> understand and prove theorems about.
FWIW, I don't think it is that simple. I think FP and OT both evolved
from procedural development in an attempt to eliminate some common
pitfalls. That is, developing a good procedural program in the '70s was
difficult and both approaches sought to provide a systematic discipline
to make developing good programs easier.
However, they took quite different paths. FP essentially eliminated
state variables, adopted lambda calculus as an underlying discipline,
and sought reuse through hierarchical abstraction. OT preserved state
variables, adopted set and graph theory as underlying disciplines, and
sought reuse through encapsulation, interfaces, and peer-to-peer
communications.
To an extent the two approaches reflected different views of software
itself. FP is a more computational perspective that is quite consistent
with the Turing view of the computing space and exposes the underlying
mathematics much more explicitly. As a result FP is more intuitive for
implementing mathematical algorithms on a computer.
OTOH, OT was triggered by the need to simulate complex systems where the
"correct" behavior was unknown. It also grew out of a frustration with
software that didn't do what the customer wanted and with development in
situations where the requirements were ill-defined or constantly
changing. So the focus of OT was not on computation but on modeling,
understanding requirements, and adopting to change. As a result OT is
more intuitive for modeling conceptual systems.
The bottom line is that both approaches evolved from, but provide more
systematic development than, the procedural development of the '70s.
Thus both seek to express software solutions. But because of their
differences they may not solve the same problem equally well. More
important, they may not work equally well in the same business
environment. Each does some things quite well that the other does badly.
There is also a rather broad spectrum of problem spaces and development
environments that lies between the extremes that are up for grabs for
either approach. Personally I believe one should chose FP or OO
techniques on a subsystem-by-subsystem basis but most shops commit to
only one.
Universe
> Neelakantan Krishnaswami wrote:
OO seems to hinge upon noun role units/abstractions. OTOH, fp is oriented
around as you all say 'functions'. They are 2 different modelling
paradigms and I can sense that fp would also apply to areas other than
structured programming which centers around functions: COBOL-procedures;
Fortran-routines; BASIC-subprocedures; C-functions, etc.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2002 my comments ~ newsgroups+bitnet OK
Kurt M. Alonso
Topmind wrote:
>>
>>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.
>
In that case, what was your intended 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?
>
I am sorry, but I think it was you who in your description
implicitly assumed a database.
> If that is the case, then still, why have the noun
> model and noun management be in application code
> and not the DB?
>
Read further down.
No, I am not suggesting anything at all, only making
statements about programming language choices on part
of project managers.
> 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.
>
I am sorry, but you will have to be more concrete.
Exactly what mainstream languages are you talking about
here? And exactly how can you avoid "replicating the
database structure in code" in such languages?
>
>
>>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.
>
With RDBMSs it is the case that they are by design a
separate thing from the clients using it. That is why
there will always be certain impedance between RDBMSs
and database programs, regardless of whether they are
procedurally or OO written.
>
>>>
>>>>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
>
Most of what you propose does not excede the category
of syntatic sugar, candy for the eye that may save one
line or two of code here and there, but does not support
lead to any new/re-made programming paradigm.
By the way, Perl happens to implement most of your
desirable features.
I am sorry, but I still think that what you propose
is creating a mess, removing the inherent structure in
a GUI in piling up GUI items in an unstructured list.
GUI applications I have seen contain often thousands
of GUI items. How are you going to handle the structure
with a database browsing tool??????
Also, you suggest storing code in the database as well.
Firstly, you know what most managers, OO practitioners
or not, would tell you about using dynamic code.
Secondly, to effect something useful, your stored
code would have to make reference to internals in your
program, variables, or something. Otherwise, show
me how you would make use of a changed value in a
text field, with a code snippet stored in your
GUI item table.
Your original claim was that using pointers in this case
was like replicating table indices. You implied that this
was undesirable. Now, please answer this question, what
do you propose as an alternative, and how does it differ
from using pointers/references?
>
>>>>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.
>
It's a suspicion I have.
>
>>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?
>
The "nouns" handled by your relational database are
in principle low level notions. Higher level notions
must therefore be handled by our client program.
> 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.
>
Sorry, it may be too late in the night but I must
admit that I don't understand what you are talking about.
> 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."
>
It is obvious that if a system required multiple
views of the same underlying entities, any sensible
project manager would deliver them. What is your
point?
> 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.
>
Give an example.
Universe
>> >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".
Efficiency, and economically wise for most projects, they don't know what
they are talking about, pure and simple. Otherwise we would have to
write a database management system for each and every project, and
frequently we would have to write many different db mgmt types for a
single project: xml, optimized for images, optimized for transactions,
hierarchical, network, object, etc.
>> Although you have terabytes of RAM that never looses power you still
>> need DMBS's
Precisely.
> 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?
"CODASYL"
"Conference on Data Systems Languages (CODASYL) was a volunteer
organization to promote more effective data systems analysis, design, and
implementation. Its membership consisted of individuals from industry and
government involved in data processing activity. The organization was
formed in 1959 to guide the development of a standard programming language
that could be used on many computers. This effort led to the development
of COBOL."
from
"24.5 cubic feet in 26 boxes"
By: Bruemmer, Hanson, and Corbitt, January 1997
Conference on Data Systems Languages Records, 1959-1990, (CBI 11), Charles
Babbage Institute, University of Minnesota, Minneapolis.
Network vs. hierarchy vs relational has nothing to do with it.
A Network dbms is a formalized written data storage management system,
it's not raw RAM. Only hopeless hackers would think it's generally best
for most projects to eschew a already written commercial dbmses in favor
of writing a new one for each project.
Daniel C. Wang
"H. S. Lahman" <vze2...@verizon.net> writes:
> Responding to Viljamaa...
>
> > I believe fp actually had its roots in efforts to "model
> > programs with functions", so that they would be easier to
> > understand and prove theorems about.
>
> FWIW, I don't think it is that simple. I think FP and OT both evolved
> from procedural development in an attempt to eliminate some common
> pitfalls. That is, developing a good procedural program in the '70s
> was difficult and both approaches sought to provide a systematic
> discipline to make developing good programs easier.
FYI Algol was first introduced around 1958. Lisp came about in 1959. Simula
showed up in 1967. All these ideas are older than most of the
programmers who are using them.
Joachim Durchholz
>
> OO seems to hinge upon noun role units/abstractions.
> OTOH, fp is oriented around as you all say 'functions'.
This is superficially correct, but far from the real picture (both for
OO and for FP).
> They are 2 different modelling
> paradigms and I can sense that fp would also apply to areas other than
> structured programming which centers around functions: COBOL-procedures;
> Fortran-routines; BASIC-subprocedures; C-functions, etc.
All of which don't have higher-order functions, let alone closures.
These languages are far from functional.
In a functional languages, the vast majority of loops is pre-canned; you
almost never fiddle with termination conditions. You just take a worker
function, a collection, and call a function that iterates the worker
function over the collection. Without worrying that the worker function
could smash the iterator function by inserting or deleting items, or (if
the collection is a hash table) moving entries around by changing keys.
THAT is functional programming. Not the presence or absence of functions
per se.
-Joachim
Neelakantan Krishnaswami
Okay, the basic idea behind a function being "pure" is that if you
give it the same values as arguments, then it will always return the
same value as results. Regular languages break this assumption, eg in
files:
let s1 = read_line(socket);
let s2 = read_line(socket);
let s3 = read_line(socket);
The same socket is passed to read_line(), but we would get a different
strings out of at each call. This is why doing a common subexpression
elimination on function calls is illegal in OO and procedural
languages. To purify read_line(), we need to figure out some way of
eliminating the mutable state from the interface.
This sounds like a tall order, but there's a clever little hack we can
pull: we can say that every time we modify a socket, we need to return
a *new* socket value representing the modified socket. Eg:
let s1, socket1 = read_line(socket0);
let s2, socket2 = read_line(socket1);
let s2, socket3 = read_line(socket2);
So now our read_line() function takes a socket object, and then
returns a string and a new value representing the modified socket.
Cool beans, we have purity. The only question is, what happens to all
of those old, used-up socket objects? In particular, what happens if
we *reuse* an old socket?
let s1, socket1 = read_line(socket0);
let s2, socket2 = read_line(socket1);
let s2, socket3 = read_line(socket2);
let sn, socketn = read_line(socket0); // we reuse socket0!
For this to be pure, sn and socketn have to equal s2 and socket2. It
seems like we'd need to save the entire input history of the socket to
make this work, which really sucks. In plain old C or Java, you don't
have this problem, because once you've modified an object there's no
way to save its old state to be reused later. So if only we could
somehow guarantee that we only use a particular state once, then we
wouldn't need to save all of the old versions and could implement
things under the covers just like in C.
The pure language Clean lets you do this with something called
"uniqueness types". The compiler checks at compile time that a value
is referred to only once. Then, it can catch accidental reuse of
stateful objects and flag it as an error. Now the runtime can use
state to represent sockets and files, but the programmer doesn't have
to think about side effects. (Haskell does the same thing with a
different type-theory thing called monads.)
--
Neel Krishnaswami
ne...@alum.mit.edu
Topmind
> >
> > Me neither. I believe that the regular reappearance of that impression
> > is rather a result of 2 decades of object-oriented predominance in the
> > mainstream and the ensuing effect of public brain-washing.
>
> The term "brainwashing" implies a person who's doing that on purpose. I
> don't think that this has happened - it's just the model that has been
> working best for encapsulating state (which is, ironically, as far from
> the real world as one can get).
By whose standards/metrics to do you claim this?
It appears to be just a fad. Either that, people who think
better under OOP have been given too much attention.
>
> What has been so seductive is simply the combination of "it's useful, so
> the term is in use", "the term is a deceptively common word", and
> "real-world objects give a damn good analogy for the semantics of a
> computer object".
>
> The point being: computer objects share some similarities with
> real-world objects, but similarities don't mean they are the best model.
>
> Maybe it's best explained by an analogy:
> The best model of the solar system is not an orange for the sun and
> various fruits at appropriate distances. Even if the orange is a good
> approximation to the sun in form and color.
> But the best model is a set of differential equations.
Using that example, the motion the planets does NOT involve
'self handling nouns' of typical OO philosophy. Rather it is
multiple bodies interacting (mostly gravitationally) and
influencing each other.
My observation of the biz world shows similar issues. Forcing
each noun to handle itself is unnatural in both my head and
in many things in the real world.
Just wanted to point that out.
> Last time I
> looked they were neither round nor orange, but they are definitely a
> better model ;-)
> Similarly, a set of functions most likely will work very differently
> than a real-world object, but it may still be the better model.
>
> BTW even in programming, at most 10% of all objects have some analogy in
> the real world. There must be other advantages to OO, else people would
> be programming the other 90% in the traditional style.
>
> Regards,
> Joachim
> --
> This is not an official statement from my employer.
>
>
-T-
Topmind
> Topmind wrote:
>
> >> >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".
>
> Efficiency, and economically wise for most projects, they don't know what
> they are talking about, pure and simple.
This sentence seems to be missing a subject or two.
> Otherwise we would have to
> write a database management system for each and every project, and
> frequently we would have to write many different db mgmt types for a
> single project: xml, optimized for images, optimized for transactions,
> hierarchical, network, object, etc.
No, you simply use polymorphism: same interface, different
implementation. ODBC, for example, can query a toaster if
you write a driver for toasters that delivers content
in ODBC protocol. Why should a collections management
protocol for XML be significantly different than one
for a big formal DB?
>
> >> Although you have terabytes of RAM that never looses power you still
> >> need DMBS's
>
> Precisely.
>
> > 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?
>
> "CODASYL"
> "Conference on Data Systems Languages (CODASYL) was a volunteer
> organization to promote more effective data systems analysis, design, and
> implementation. Its membership consisted of individuals from industry and
> government involved in data processing activity. The organization was
> formed in 1959 to guide the development of a standard programming language
> that could be used on many computers. This effort led to the development
> of COBOL."
They also worked on network DB standards if I am not
mistaken.
>
> from
> "24.5 cubic feet in 26 boxes"
> By: Bruemmer, Hanson, and Corbitt, January 1997
> Conference on Data Systems Languages Records, 1959-1990, (CBI 11), Charles
> Babbage Institute, University of Minnesota, Minneapolis.
>
> Network vs. hierarchy vs relational has nothing to do with it.
> A Network dbms is a formalized written data storage management system,
> it's not raw RAM.
I did not mean to imply that network DB's are purly RAM-based.
However, the "links" tended to be rather physical, similar to
RAM addresses, in contrast to the logical links of relational.
> Only hopeless hackers would think it's generally best
> for most projects to eschew a already written commercial dbmses in favor
> of writing a new one for each project.
Well, it seems to be a common practice among OO
fans.
>
> Elliott
> --
> http://www.radix.net/~universe ~*~ Enjoy! ~*~
> Hail OO Modelling! * Hail the Wireless Web!
> @Elliott 2002 my comments ~ newsgroups+bitnet OK
>
-T-
panu
> ... A Haskell program (an object of type IO something) is essentially a
> great big infinite data-structure, a bit like a tree. The input the
> program gets as it runs steers a path into this tree, and causes
> output.
Thanks for the explanation, which I think is a great explanation.
So could we say in other words that there is a function that calculates
a new program from the old program + the history of inputs ? The new
program is then applied to the next input?
How well does this work in practice ?
-Panu Viljamaa
panu
> .... The pure language Clean lets you do this with something called
> "uniqueness types". .... (Haskell does the same thing with a
> different type-theory thing called monads.)
The fact that there are multiple ways of doing this, none of which
seem very simple seems to imply that representing state-changes
caused by the program's interaction with the 'real world' (via inputs)
is somewhat problematic in FP, right ?
Thanks for the pointer to Clean, should check it out.
-Panu Viljamaa
Peter G. Hancock
>>>>> panu wrote (on Tue, 29 Oct 2002 at 00:27):
> "Peter G. Hancock" wrote:
>> ... A Haskell program (an object of type IO something) is essentially a
>> great big infinite data-structure, a bit like a tree. The input the
>> program gets as it runs steers a path into this tree, and causes
>> output.
> Thanks for the explanation, which I think is a great explanation.
Well, thank you.
> So could we say in other words that there is a function that calculates
> a new program from the old program + the history of inputs ? The new
> program is then applied to the next input?
Yes.
> How well does this work in practice ?
Although it may not be the way people ordinarily describe it, I think
it is just the IO system of Haskell. This has several defects and
tricky points, but it works pretty well in many practical situations where
you can think of each IO primitive as an instantaneous transaction.
Both IO primitives, and programs built out of them usually have a type
of the form:
Inputs -> IO Outputs
in which one might compare "IO" with an OUTPUT specifier.
I think the idea of executing a program as tracing a path out in a
tree is a kind of "single-threading". One can also imagine exploring
different paths in the tree by back-tracking.
Peter Hancock
Peter G. Hancock
>>>>> panu wrote (on Tue, 29 Oct 2002 at 00:30):
> The fact that there are multiple ways of doing this, none of which
> seem very simple seems to imply that representing state-changes
> caused by the program's interaction with the 'real world' (via inputs)
> is somewhat problematic in FP, right ?
I disagree: the monadic approach is very simple. One problem with
Clean's type system is that it doesn't seem to rest on anything as
solid, thoroughly studied and simple as the idea of a monad. (But I
don't know much about Clean).
There's nothing particularly problematic about representing
state changes in FP; what is problematic is to get a clear
idea of what it means to run or execute a functional program.
Peter Hancock
Topmind
> >
> > NO! I said nothing about simplifying labor for the
> > accountant IIRC. That was not my intentioned meaning.
> >
>
> In that case, what was your intended meaning?
It simplifies the code and programming effort.
>
> >
> >
> >>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?
> >
> I am sorry, but I think it was you who in your description
> implicitly assumed a database.
Well, please pick your favorite approach, DB or no DB,
and lets stick with it for our discussion.
Again, lets assume that we can pick our prefered
approach for the sake of discussion.
>
> > 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.
> >
>
> I am sorry, but you will have to be more concrete.
> Exactly what mainstream languages are you talking about
> here? And exactly how can you avoid "replicating the
> database structure in code" in such languages?
For example, some scriptish
languages use dictionary arrays to
store a database row. This dictionary is generated
dymanically, at run-time. There is no C-like STRUC
or Class that has the field names in the code grouped
by entity in most cases.
...
row = query(DBhandle, "select * from foobar where......")
if row['~recordCount'] > 0
print 'Name: ' & row['name']
print 'SSN: ' & row['SSN']
print 'Credit:' & row['credit']
end if
...
Sure, a statically typed language could probably
do this also, but would need more castings probably
in order to use the fields.
This could be problematic if the field type is
changed, if for example due to a merger an ID
field is changed from numeric to text. A dynamic
language is more likely to handle this change
without code changes. (Of course, it depends on what
kind of comparing API's or techniques are used).
> >>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.
> >
>
> With RDBMSs it is the case that they are by design a
> separate thing from the clients using it. That is why
> there will always be certain impedance between RDBMSs
> and database programs, regardless of whether they are
> procedurally or OO written.
The integration possibilities are continuous in
my observation. But, it is more about general
design philosophy than language capabilities.
> >>>
> >>>>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
> >
>
> Most of what you propose does not excede the category
> of syntatic sugar,
I beg to differ. Besides, sometimes syntactic sugar
can singificantly reduce code-size, making programs
easier to read and grok IMO.
> candy for the eye that may save one
> line or two of code here and there, but does not support
> lead to any new/re-made programming paradigm.
It makes existing paradigms easier, not creates new ones.
That list is mostly based on debates where OO fans
say something like, "but procedural language X could
not do B, but my OO language could, therefore OO is better".
>
> By the way, Perl happens to implement most of your
> desirable features.
Yes, but it implements too many other things in addition,
encouraging programmers to be inconsistent and cryptic, like my
spelling :-)
Perl does not have nested routines IIRC, and I don't
like its parameter handling.
(snip)
Huh? What "inherent structure" are you talking about???
A table is an "unstructured list"????
The advantage of relational-based tables is that
you can give it whatever "structure" you want, just
about. The structure is virtual, dynamic, ad-hoc,
etc.
There is NO one-size-fits-all "structure". The
structure needed for one task or spot may be
different from the structure needed for another.
As Einstein would say, "it is all relative".
RDB's allow one to order the soldiers to organize
themselves into whatever structure you need for
a particular battle.
That is NOT "lack of structure" but FLEXIBILITY!
This seems like a key point between our perception
of DB technology.
> GUI applications I have seen contain often thousands
> of GUI items. How are you going to handle the structure
> with a database browsing tool??????
Beats code in my book. You want it grouped or filtered
by form?, got it! by widget "type"? got it! By button
text, got it!, by some user access-level code?, got it!
Your view of all that stuff is as dynamic as it
gets.
Besides, most GUI design is done via IDE's (or graphical GUI
builers) these days, not raw GUI info. In that case the
underlying data structure is not of much concern to
programmers. So, we might as well use a language-neutral
GUI configuration arrangment either way.
>
> Also, you suggest storing code in the database as well.
Not necessarily. It depends. Note that if I had my
way, file systems would be databases anyhow, so
code would be in "tables" by default. I don't
like tree-based file systems for non-trivial stuff.
They suffer the "one-view-fits-all" syndrom,
and thus grow messier and messier over time.
> Firstly, you know what most managers, OO practitioners
> or not, would tell you about using dynamic code.
> Secondly, to effect something useful, your stored
> code would have to make reference to internals in your
> program, variables, or something. Otherwise, show
> me how you would make use of a changed value in a
> text field, with a code snippet stored in your
> GUI item table.
You could issue a query, or perhaps use
an API:
x = GuiAttrib(formID, widgetID, "content")
The "local DB" is via a protocol pretty much identical
to the server DB. Thus, you don't have Meyerian Discontinuities
if you need to scale up or down from one to another.
IOW, you talk to the local DB just like you do the
big formal ones.
>
> >
> >>>>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.
> >
>
> It's a suspicion I have.
I would mention my suspicions of some of
your possible experience short-comings,
but that would not be productive to the
discussion in my estimation.
> >>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?
> >
>
> The "nouns" handled by your relational database are
> in principle low level notions. Higher level notions
> must therefore be handled by our client program.
I think it is example-time. This "low" and "high"
level thing is sounding a bit political.
>
> > 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.
> >
>
> Sorry, it may be too late in the night but I must
> admit that I don't understand what you are talking about.
I will await your above example.
>
> > 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."
> >
>
> It is obvious that if a system required multiple
> views of the same underlying entities, any sensible
> project manager would deliver them. What is your
> point?
I am saying that using a DB makes that task easier
than trying to do it from scratch in code.
>
> > 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.
> >
>
> Give an example.
A GUI drop-down list (HTML Select). Many API's have
add item, change item, delete item, and some with sort, find, etc
in them. If you can simply pass a query expression
then you don't need to have the add, change, delete,
sort, find, etc. IN THE API for it.
>
> >
> >>In other words, solution #1 is most often not
> >>available, except for very simple systems.
> >
> >
> > Simple? In my observation DB's are more likely to
> > be in larger setups than simple ones. This is partly
> > why Larry Ellison is usually in the top 10 richest man
> > in the world lists.
> >
>
> Kurt
>
>
-T-
Topmind
> >
> > So yes, functions make great models for computer programs.
> >
> > The only objection to this is that sometimes we are more
> > interested in "modeling the world" than "modeling a computer
> > program". And if so, OO languages with variables that hold on
> > to changing state might be a better fit for the task.
>
> OO is not about modelling the world. Real-world objects and computer
> objects are quite different animals! Unless you're doing physical
> simulations,
I would note that some "back to its roots" OO fans *do* see
physical modeling as an important part of OO. The OO methodologies
out there range the whole gammit. Now I *don't* think a majority of
OO fans share this view, but it does exist and still seems
to influence some of the OO training materials out there.
Universe tends to lean that way, in my observation.
> a computer program is about things that are quite abstract
> in themselves: invoices, files, hash tables. By that argument, one could
> say that functions are a better fit, since functions are closer to
> mathematical models... but that's not true either. All functional
> languages offer ways to work with state; it's just that functional
> programs need little or no explicit internal state, the state stuff is
> just needed for working with the external world.
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
>
> Object orientation is a way to organize the structure of a program.
> Functional programming is a way to implement an algorithm.
How is that *not* "structure of a program"?
IMO, OO tends to group algorithms by nouns, while
other paradigms tend to group them by task. One is not necessarily
"more" structure than the other, just a different approach to
the same thing. (I prefer the task approach because I prefer to
use a database to model noun structures instead of programming
code. DB's are better at giving one relative, dynamic views IMO.)
> I find
> them orthogonal; they are relevant in different levels of software
> construction. When I am structuring my program, I choose between
> objects, aspects, and modules. When I get to implement a core method,
> I choose between functional programming and imperative programming.
>
> In Smalltalk programming, sometimes you decide that certain objects
> should be immutable, and operations over them should create new
> immutable objects rather than modify existing ones. That is already a
> form of functional programming. Another favourite thing that
> functional programmers like to do is to define and use higher order
> functions or higher order procedures; these are simply blocks in
> Smalltalk.
>
> Object orientation means you want to organize your program and data
> around classes and objects. Functional programming means you stick
> with immutable objects and side-effect-free methods.
>
> I would compare object orientation with higher-order modules.
> A comparison I like is done by Xavier Leroy:
> http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz
>
My postscript reader chokes on this. Is there an HTML or
PDF version available somewhere?
Thanks, -T-
Marcel Weiher
>Topmind wrote:
>>
>> BTW, I do not see how OO allegedly better maps to the real
>> world.
>Me neither. I believe that the regular reappearance of that impression
>is rather a result of 2 decades of object-oriented predominance in the
>mainstream and the ensuing effect of public brain-washing.
You are confusing cause and effect.
Marcel
Marcel Weiher
>What has been so seductive is simply the combination of "it's useful, so
>the term is in use", "the term is a deceptively common word", and
>"real-world objects give a damn good analogy for the semantics of a
>computer object".
You call it "seductive"/"deceptive". I call it "useful". Computer
languages are for people, not for computers. (Computers are
perfectly happy with bit sequences...).
>The point being: computer objects share some similarities with
>real-world objects, but similarities don't mean they are the best model.
They aren't a "model" at all. They are a tool for allowing humans to
build models. The fact that they are similar to "real-world" objects
takes advantage of the fact that our human cognitive system has evolved
over millions of years to deal with real-world objects.
This is a Good Thing (tm).
Marcel
Marcel Weiher
>Programs with variable assignments _can_ be modeled as functions.
All the languages being examined are, AFAICT, Turing complete. So
let's not go down that particular road, OK?
Marcel
Marcel Weiher
>Yes, it seems that many folk don't really understand just how expressive
>FPL's are.
"They don't agree with us, they must be ignorant". Have you considered
that they might not be ignorant and STILL not agree with you? Or is
that just not possible?
>Using a "functional programming style" in a conventional
>imperative language (OO or not OO) is a poor second best
Not in my experience.
>(and IMHO more
>likely to put people of FP altogether rather than persuade them it's a
>good thing).
No. They just notice that they don't actually need "pure" FP to have
a benefit for themselves. From your point of view, that may look
like "putting them off FP altogether", I guess...
>I think it would be an instructive exercise for such doubters to write
>purely functional equivalents of imperative "while do" and "repeat untils"
>as higher order functions.
And what does that have to do with anything? Many imperative languages
have advanced iteration mechanisms. Smalltalk has do:, collect:, select:
etc. And in Smalltalk, these mechanisms are not, in fact, part of the
language, but part of the class library, so you can build your own.
Also, I personally am so fond of higher order functions, that I built
higher order messaging in Objective-C.
>1- Referential transparency seems to pretty much essential
> for desirable features like type security, static analysis,
> theorem proving and sophisticated compiler optimisations.
...for "seemingly" desirable features.
> Any programming language which doesn't offer guarantees in this
> respect is a poor design.
Generalizations are stupid. ;-)
> Therefore just about all widely used OO
> languages and some "functional" (but not purely functional) languages
> are poor designs (or perhaps I should say "less than ideal" :-).
Exactly. They are not meant to be "idealistic", but "realistic". That
is, they are intended to solve real-world engineering problems, not
satisfy theoretical demands.
>2- As an electronics engineer (I'm not a computer scientist) I get the
> clear impression that FP is a science,
Nope. FP is like "math", not science. Science deals with the real
world.
> but with OOP all this talk of
> "models" and "real worlds" seems more like voodoo to me.
Dealing with the real world is what science is about.
> I'm probably
> doing the OO community an injustice by saying that. The trouble with
> OO is that there are so many businesses trying to peddle tools to
> support "object technology" it becomes very difficult to distinguish
> fact from fiction in the torrents meaningless BS from marketdroids.
Fortunately, the FP community is spared any such effects... ;-)
>3- I don't see the choice of OOP vs. FP as a strictly either/or decision.
Neither do I, though "pure" FP probably doesn't fit well. In fact,
I personally am very interested in applying some FP ideas to the
objects/prototypes themselves (not the methods).
Marcel
Marcel Weiher
>In a functional languages, the vast majority of loops is pre-canned; you
>almost never fiddle with termination conditions. You just take a worker
>function, a collection, and call a function that iterates the worker
>function over the collection.
Hmm, works the same in Smalltalk, and in Objective-C if one uses HOM.
>Without worrying that the worker function
>could smash the iterator function by inserting or deleting items, or (if
>the collection is a hash table) moving entries around by changing keys.
>THAT is functional programming.
Funky, I've been doing functional programming all along and didn't know
it! Well, no, actually I do know about the connection, because I first
saw FP (the original FP notation) in university and certainly didn't
want to write loops any more. However, it seems that you can get that
particular advantage without buying into the whole FP religion.
Marcel
Ulf Wiger
>> Andreas Rossberg wrote:
>>
>> Maybe it's best explained by an analogy: The best model of the
>> solar system is not an orange for the sun and various fruits at
>> appropriate distances. Even if the orange is a good approximation
>> to the sun in form and color. But the best model is a set of
>> differential equations.
-> Using that example, the motion the planets does NOT involve 'self
-> handling nouns' of typical OO philosophy. Rather it is multiple
-> bodies interacting (mostly gravitationally) and influencing each
-> other.
Erlang solves this problem neatly, by using a lightweight concurrency
model. Each planet would of course be modeled as a separate process,
where interaction between planets occurs through (impure) message
passing. This model has been demonstrated as quite powerful e.g.
for army troop simulation. Within each process, the differential
equations would be implemented in a functional manner, as Erlang
is functional in nature except for the concurrency support.
It could be said for the concurrency model (basically, CSP -
Communicating Sequential Processes) that it quite nicely models
the real world. After all most real-world problems are solved
manually through Communicating People, and concurrency algorithms
are easily exemplified using real-world problems (sharing of
knives while preparing food was one example I remember from the
Programming Parallel Systems class in school.)
I never could get the same warm and fuzzy feeling for OO. In fact,
I felt quite stupid trying to get my brain around it, until I
discovered Erlang and found that things didn't have to be that
difficult. After 6 years of using Erlang, I can look back at what
I've been able to accomplish, and freely admit that I was to
dense to get any really interesting stuff done with OO (privately
thinking that perhaps my lack of intelligence wasn't the real
problem after all...)
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson Telecom AB, ATM Multiservice Networks
Adrian Hey
> Adrian Hey <ah...@NoSpicedHam.iee.org> writes:
>
>>Yes, it seems that many folk don't really understand just how expressive
>>FPL's are.
>
> "They don't agree with us, they must be ignorant". Have you considered
> that they might not be ignorant and STILL not agree with you? Or is
> that just not possible?
Judging by some of the all too common FUD that's been repeated on this
thread it's clear that many are ignorant of what FP is all about and what
a FPL is. I've even seen C described as a "functional" programming
language from time to time :-)
In answer to your question, I'm still open minded to the possibility
that someone who knows what they're talking about can come up with
a convincing argument against pure FPL's. I haven't seen one yet,
but maybe, one day..
That said, it so happens I have a convincing argument against pure
FPL's (well it convinces me anyway:-), but that is another story
(nothing to do with the FP vs. OOP debate).
>>Using a "functional programming style" in a conventional
>>imperative language (OO or not OO) is a poor second best
>
> Not in my experience.
You can't be serious (tm). Are you really saying that Clean,
Haskell,SML.. offer no significant advantages over C,C++,Java..
for functionally inclined programmers?
Do you have any particular experiences and/or languages in mind
that you could share with us?
>>I think it would be an instructive exercise for such doubters to write
>>purely functional equivalents of imperative "while do" and "repeat untils"
>>as higher order functions.
>
> And what does that have to do with anything?
It has to do with the fact that there exists a direct translation from
any imperative computation using loops and mutable variables to an
equivalent purely functional form. Not a particularly remarkable obvervation
I admit, but I was under the impression that there was some doubt about
this from earlier posts.
>> I'm probably
>> doing the OO community an injustice by saying that. The trouble with
>> OO is that there are so many businesses trying to peddle tools to
>> support "object technology" it becomes very difficult to distinguish
>> fact from fiction in the torrents meaningless BS from marketdroids.
>
> Fortunately, the FP community is spared any such effects... ;-)
Yes, that is indeed fortunate.
Another good reason to use FPL's IMHO :-)
Regards
--
Adrian Hey
Adrian Hey
> Well, no, actually I do know about the connection, because I first
> saw FP (the original FP notation) in university and certainly didn't
> want to write loops any more. However, it seems that you can get that
> particular advantage without buying into the whole FP religion.
FP isn't a religion (or a science). It's like math, remember :-)
Regards
--
Adrian Hey
Neelakantan Krishnaswami
> Neelakantan Krishnaswami wrote:
> >
> > .... The pure language Clean lets you do this with something called
> > "uniqueness types". .... (Haskell does the same thing with a
> > different type-theory thing called monads.)
>
> The fact that there are multiple ways of doing this, none of which
> seem very simple seems to imply that representing state-changes
> caused by the program's interaction with the 'real world' (via
> inputs) is somewhat problematic in FP, right ?
If you had asked this question in 1990, rather than 2002, the answer
would have been "yes, this is a problematic case." But that's not true
anymore -- it's just an engineering difference between Clean and
Haskell.
Both languages give you the ability to check the consistency of the
side-effects in your program at compile time. Since complete compile
time checking is impossible (for halting problem reasons), language
designers have to make some engineering tradeoffs to decide how much
static checking they want to do versus how much complexity they are
willing to accept. Clean and Haskell's designers chose different sets
of tradeoffs.
--
Neel Krishnaswami
ne...@alum.mit.edu
Julian Fondren
> The main function of a Haskell program takes a list of inputs (such as:
> the characters of an input file, or the sequence of events for a GUI
> program), and returns a list of action descriptions. The run-time system
> then executes these actions.
> The above description is a bit misleading. The run-time system
> alternates between reading the next action description and executing it;
> the inputs are only read at the moment at which they are needed to
> construct data in a given action description. However, the Haskell
> programmer doesn't have to adapt his program to do that, accessing a
> data field automatically triggers the computation that fills it.
Monadic I/O seems to have largely superceded this (stream-based) form of I/O.
In monadic I/O, main takes the state of the world, which is single-threaded
through the program (and all World-modifying functions), and returns it.
Since the state-of-the-world is single-threaded, it can be modified in-place
-- which is helpful; copying the World entails all kinds of problems.
Matthias Blume
That was not the point. (I am sorry that you didn't get it.)
--
-Matthias
H. S. Lahman
> FYI Algol was first introduced around 1958. Lisp came about in 1959. Simula
> showed up in 1967. All these ideas are older than most of the
> programmers who are using them.
I'm well aware of that since I wrote my first program in '57. B-) In
fact, I had Simula in mind when I said that OT had its roots in simulation.
But those languages were all precursors and each only reflected a few
nascent aspects of OT. Modern OT did not become a complete and
internally consistent methodology until the '70s (i.e., coincident with
the advent of Smalltalk) and it remained an Academic Curiosity until ~1980.
*************
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
H. S. Lahman
>> 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".
>
>
> If your definition of "real world" is just the problem space, then
> objects are just an abstraction about the problem space, and don't come
> as naturals.
Could you put some words around 'as naturals'?
>
>>> 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.
>
>
> Right.
> OO and FPL are synergistic, in a sense: OO would benefit from functional
> ideas, but it's not clear whether FPLs would benefit from OO ideas.
I don't see that synergy. In the cases where it has been tried there
have been disastrous side effects. For example, the OOPLs chose to
eliminate the OO distinction between message and method by mapping a
message directly to a procedure call. That seemed like a good idea at
the 3GL level because at that level procedure calls were the dominant
mode of communication between program units.
The problem is that we name our procedures by what they do. So the
message becomes an imperative that implies that the method generating
the message (a) knows the behavior exists, (b) knows who has that
behavior, and (c) knows that the behavior is the next thing to do in the
overall problem solution. It is then tempting to design the sender
behavior around that knowledge, which creates a dependence of that
implementation on the context of the responder's behavior and breaks OO
encapsulation.
When an army of procedural developers converted to OT in the late '80s
and early '90s they were naturally looking for a way to map familiar
paradigms onto OT (i.e., viewing the solution in terms of sequences of
operations). The mapping of message to procedure in the OOPLs seemed
like an obvious overlay. The result has been a lot of OO applications
that are really just FORTRAN programs with strong typing.
>
>> 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.
>
> I've seen such code, thanks *shudder*.
> It's also easy to overdo OO in a hybrid OO/functional language, or so I
> have been told.
> The reverse experiment, adding functional facilities to an OO language,
> has been successful though (see www.eiffel.com). They added "agents" (a
> fancy term for "closure", essentially a function call with some or all
> parameters already filled in, to be passed around and executed later),
> and what I have read was stuff like "we wouldn't want to miss them".
>
>> BTW, downcasts are easily avoided (except for a few
>
> > language-dependent ituations) if one identifies and implements
> > relationships properly in OO development.
>
> Um... well... after a few iterations, the relationships tend to become
> "improper".
>
> However, you get into trouble if you override a result type and that
> result type is mutable. That may not be "lots of downcasts", but it's
> still a type hole that doesn't exist if you don't have mutable objects.
Type systems are an OOP issue rather than an OOA/D issue. The downcast
is simply a 3GL implementation of relationship navigation from
superclass to subclass. The problem is more fundamental.
The navigation itself is wrong because it defeats generalization in the
is-a relationship. (It also implies that the superclass can be
independently instantiated from the subclass, which isn't true in an
is-a relationship.)
If there is a problem space rule that stipulates that the client can
only collaborate with instances of a particular subclass, then the OOA/D
should enforce that rule. One does so with an explicit relationship
between the client class and the target subclass and that relationship
is navigated in the collaboration context (i.e., relationship role)
rather than a path through the superclass.
[Unfortunately not all OOPLs have gotten things quite right in all
situations. In some (C++, as usual, is a good example of not getting
things quite right) there is no way to process an input stream of
arbitrary objects without using a downcast from a mother-of-objects type.]
Universe
>> panu wrote:
>> >
>> > So yes, functions make great models for computer programs.
>> >
>> > The only objection to this is that sometimes we are more
>> > interested in "modeling the world" than "modeling a computer
>> > program". And if so, OO languages with variables that hold on
>> > to changing state might be a better fit for the task.
>>
>> No, no, no.
>> OO is not about modelling the world. Real-world objects and computer
>> objects are quite different animals! Unless you're doing physical
>> simulations,
> I would note that some "back to its roots" OO fans *do* see
> physical modeling as an important part of OO. The OO methodologies
> out there range the whole gammit. Now I *don't* think a majority of
> OO fans share this view, but it does exist and still seems
> to influence some of the OO training materials out there.
And ohhhh... _Dahl_ & _Nygaard_ the cofounders of OO.
"Object-oriented [OO] programming. A program execution is regarded as
a physical model, simulating the behavior of either a real or
imaginary part of the world...The notion of a physical model should be
taken literally." ~ Computerized physical models
Madsen, Moeller-Pederson, Nygaard (co-founder of OO)
> Universe tends to lean that way, in my observation.
Apparently in good company, don'tcha think? <g>
A) Simulating the domain primarily via task responsible objects and object
collaboration networks
AND
B) Implementing use cases as an ordered sequence of behaviors by those
objects and collaborations
are the heart and soul, cell and lifeblood of the OO pardigm. That is
despite what may or may not be majority opinion. The majority thought the
earth was flat.
I elaborate on A) and B) as the core of the OO paradigm and methodology in
"Keystones of OO", which may be read by querying the www.google newsgroup
section for comp.oject in the last 30 days.
Nygaard and Dahl agreed with "Kestones" and in the course of discussing it
with me, informed me that reducing complexity was their main motivation
and that is why I reference it in the paper's summary point.
Elliott
--
OO: "Please do not fold, spindle, or mutilate".
Topmind
> I never could get the same warm and fuzzy feeling for OO. In fact,
> I felt quite stupid trying to get my brain around it, until I
> discovered Erlang and found that things didn't have to be that
> difficult. After 6 years of using Erlang, I can look back at what
> I've been able to accomplish, and freely admit that I was to
> dense to get any really interesting stuff done with OO (privately
> thinking that perhaps my lack of intelligence wasn't the real
> problem after all...)
I know the feeling. It is like telling a lefty, "If you are
not a right-hander, then something is wrong with you",
despite the fact that you can kick their ass with your
left hand.
-T-
Alfredo Novoa
wrote:
>> Only hopeless hackers would think it's generally best
>> for most projects to eschew a already written commercial dbmses in favor
>> of writing a new one for each project.
>
>Well, it seems to be a common practice among OO
>fans.
Very common.
OO middlewares, EJB's, object persistence frameworks, etc are common
flavors of that practice.
Some of the problems of that practice are described in a thread on
this group called: "Database Middle Layer".
Due that problems and others, DBMS construction kits were discarded a
lot of decades ago.
If you see people designing classes with names like: Customer,
Employee, Part, Invoice, etc. It is very probable that they are using
that approach.
Alfredo
Alfredo Novoa
<kurt.magn...@mailbox.swipnet.se> wrote:
>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.
It is not necessary, but it may be a good idea, especially with big
systems.
>Question:
>Couldn't you put this data in a configuration file instead,
Yes, but then you will loose a lot of advantages.
>and have the GUI library read this file instead? What
>are the advantages of using database tables?
Doing that you can use the power of DB query languages in order to
adapt the user interface to the different user roles.
You can manipulate the user interface definition easily with a high
level declarative query language.
>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.
A big mistake. It is a totally obsolete approach.
>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.
That is a big mistake.
The relational theory does not say that.
You can have a car domain if you want.
You don't know very well the relational model theory.
The following statements does not have any sense:
>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.
Alfredo
Marcel Weiher
>mar...@cs.tu-berlin.de (Marcel Weiher) writes:
I am sorry you didn't get that that *is* the point.
Marcel
Topmind
But modeling the real world does NOT necessarily reduce complexity.
You see, the real world is limited by certain things. For example,
you can physically arrange folders or books ONLY by a linear or
nested taxonomy at any given time.
However, the genious of multi-attribute indexing and virtual
joins ALLOWS COMPUTERS TO DO SHIT THAT THE REAL WORLD CANNOT
(very easily).
Thus, computers RESCUE us from some of the limitations of
the real world, giving as virtual and ad-hoc ways to
view and manage stuff that the real world cannot.
I will readily agree that modeling the real world may
make it easier to relate to a computer's model in some
cases for some people, but sometimes we also want *power*
to move beyond the limits of physical stuff.
It is sometimes said that if technology tried to
always mirror the real world, then planes would have
wings that flap. Da Vinchi tried that already, it
didn't work.
>
> Elliott
>
> --
> OO: "Please do not fold, spindle, or mutilate".
>
-T-
Topmind
> wrote:
>
> >> Only hopeless hackers would think it's generally best
> >> for most projects to eschew a already written commercial dbmses in favor
> >> of writing a new one for each project.
> >
> >Well, it seems to be a common practice among OO
> >fans.
>
> Very common.
>
> OO middlewares, EJB's, object persistence frameworks, etc are common
> flavors of that practice.
EJB's are a joke. No serious experienced
developer defends them anymore.
>
> Some of the problems of that practice are described in a thread on
> this group called: "Database Middle Layer".
>
> Due that problems and others, DBMS construction kits were discarded a
> lot of decades ago.
>
> If you see people designing classes with names like: Customer,
> Employee, Part, Invoice, etc. It is very probable that they are using
> that approach.
(Warning: big rant ahead)
When they finally agree on a set of practices for mapping
OO to RDBMS, then we can compare it to non-OO approaches.
Right now I just see a lot of fumbling in the dark
and empty promises and otherwise simple things turned into
Rube Goldberg messes.
OO seems to be the greatest complexity increaser of
all of IT history, except perhaps the vacuum tube.
Contractors love it, it makes them rich because they
are paid to come back to add yet more mess to
their existing mess in an attempt to fix it.
And the PHB's think it is as simple as the
shape and animal examples made it look.
>
>
> Alfredo
>
-T-
Joachim Durchholz
> Responding to Durchholz...
>
>>> 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".
>>
>> If your definition of "real world" is just the problem space, then
>> objects are just an abstraction about the problem space, and don't
>> come as naturals.
>
> Could you put some words around 'as naturals'?
I don't know what you're missing here.
I'm entirely confused what the heck you're talking about here.
First, even Smalltalk doesn't distinguish between method and message
(other than in the sense that a method is what gets called when you send
a message - but that's hard to confuse).
I certainly never heard about disastrous effects stemming from that
side. Though I agree there's a lot of beautiful C code written in C++.
>> However, you get into trouble if you override a result type and that
>> result type is mutable. That may not be "lots of downcasts", but it's
>> still a type hole that doesn't exist if you don't have mutable objects.
>
> Type systems are an OOP issue rather than an OOA/D issue. The downcast
> is simply a 3GL implementation of relationship navigation from
> superclass to subclass. The problem is more fundamental.
>
> The navigation itself is wrong because it defeats generalization in the
> is-a relationship. (It also implies that the superclass can be
> independently instantiated from the subclass, which isn't true in an
> is-a relationship.)
Right.
But if you lead that line of thought to its end, you end up with pretty
few opportunities for subclassing. If you take the LSP seriously, you
can't even make Square a subtype of Rectangle, since the
set_width_height routine of Rectangle might destroy the squareness
property of a Square.
Forbid mutation, and you get lots and lots of subtyping opportunities back.
> [Unfortunately not all OOPLs have gotten things quite right in all
> situations. In some (C++, as usual, is a good example of not getting
> things quite right) there is no way to process an input stream of
> arbitrary objects without using a downcast from a mother-of-objects
> type.]
This is not a problem of C++, but of all strongly-typed languages that
read data from untyped external sources. You need a downcast at some
point of the conversion process; you may be able to hide it in a library
routine, but that tends to hide potential error situations as well.
There's a good deal of things that I don't like about C++, but this is
not one of them.
Joachim Durchholz
> Joachim Durchholz <joac...@gmx.de> writes:
>
>>In a functional languages, the vast majority of loops is pre-canned;
>>you almost never fiddle with termination conditions. You just take a
>>worker function, a collection, and call a function that iterates the
>>worker function over the collection.
>
> Hmm, works the same in Smalltalk, and in Objective-C if one uses HOM.
Right - this workstyle isn't exclusive to functional programming.
>>Without worrying that the worker function
>>could smash the iterator function by inserting or deleting items, or
>>(if the collection is a hash table) moving entries around by changing
>>keys.
>>THAT is functional programming.
>
> Funky, I've been doing functional programming all along and didn't
> know it! Well, no, actually I do know about the connection, because
> I first saw FP (the original FP notation) in university and certainly
> didn't want to write loops any more. However, it seems that you can
> get that particular advantage without buying into the whole FP
> religion.
The "religious" part is that about nonmutable objects. The advantage is
that you can write the iterator functions without worrying about
modifications from the worker function. You don't have to copy data
structures if you want to be sure that nobody is changing them behind
your back. This becomes a real factor at the moment that a single person
doesn't understand everything that a software does.
Smalltalk doesn't give you any guarantees. If you're iterating through a
hash table, and the worker function happens to add entries to the table
you're iterating, you don't know whether the iterator will see the new
entries or not. If you're iterating through a linked list, and the
worker function removes entries from it, the iterator may not even get
to the end of the list.
If you want to avoid these anomalies without restricting the worker
function, the iterator must copy the container, whether that's needed or
not. (You *can* restrict the worker function, but as soon as other
people start working with your code, someone will, sooner or later,
overlook this requirement... and bugs of that type are about as nasty as
dangling pointers.)
At some point, paranoia will rise to far that people tend to copy
containers "just in case". At that point, functional languages will be
more efficient than imperative ones, because they copy only where necessary.
Joachim Durchholz
Well, right, Matthias' observation is a special case of Turing completeness.
Fact is that you don't really _need_ variable assignments in a good,
modern FPL. And that's a statement about the expressiveness of FPLs, not
about their power.
In practice, the difference between imperative and functional
programming is in techniques and in confidence:
* you don't write loops, you call an interator (very convenient);
* you assign to each local variable just once (not a problem);
* you don't modify objects in-place, you construct the new value (slight
efficiency disadvantage);
* and you're confident that nobody is changing your data behind your
back (slight efficiency advantage since you don't need to take a
snapshot of a data structure before submitting it to a black box that
may modify it; and a huge confidence advantage because one often
overlooks potential modifiers).
The first point works not just for functional languages, but also for
Smalltalk and Lisp; the others are unique to "pure" functional languages
(and in Lisp if in-place modification is not the default strategy).
Joachim Durchholz
>>real-world objects, but similarities don't mean they are the best
>>model.
>
> takes advantage of the fact that our human cognitive system has
> evolved over millions of years to deal with real-world objects.
>
> This is a Good Thing (tm).
Right. And the human mind is better suited for dealing with apples and
oranges than with differential equations. Still, equations are the
better model.
I agree that objects suit our cognitive system better than functions, as
long as we're thinking about the workings of an individual object. For
object collectives like "swarm of birds" or a "river", the analogy
starts to break down. For business rules, the model is almost useless.
Besides, you can easily define stateless objects, which is in flat
contradiction with the intuitive understanding of an object.
And, finally, in any computer program, 90% of the objects in existence
tend to have no analogy in the real world, at which point the usefulness
of an intuitive understanding becomes a quite dubious advantage. You
need training to avoid drawing false conclusions from superficial
analogies like these (and I guess this is one reason why there's so much
badly structured OO code around: the intuitive model is simply inadequate).
JXStern
wrote:
>It is sometimes said that if technology tried to
>always mirror the real world, then planes would have
>wings that flap. Da Vinchi tried that already, it
>didn't work.
Yeah, but it's coming back, some of these new bug-sized 'bots are
gonna flap little wings, hugely efficient on small scales.
Still, I agree with you that programming is NOT modeling.
Dang it, I'd love to flame on about this, but I want to try to publish
some of it elsewhere, not just dump it out in a newsgroup.
J.
panu
> ... In monadic I/O, main takes the state of the world, which is single-threaded
> through the program (and all World-modifying functions), and returns it.
Since every function is supposed to always return the same answer for the
same input, does the above imply that the "state of the world" is an implicit
argument of every function whose value could depend on the state of the world?
Or is it more like a 'global variable' that needs to be passed as an explicit argument?
> Since the state-of-the-world is single-threaded, it can be modified in-place
> -- which is helpful; copying the World entails all kinds of problems.
By what or whom is 'state of the world modified' ? I assume there are
no functions I can call that would have a side-effect?
But this seems curious. If my program is able to do output as well
- by calling a function - then surely it can cause side-effects in
the 'state of the world' . And since my program can read the 'state
of the world' as well, it seems my functions can cause side-effects,
and later change its behavior based on those previous side-effects.
Further, since the 'state-of-the-world' seems to be global, causing
a change in it will affect many different parts of my program.
How is this conceptually different -or better- than using
a global variable in a non-functional program? I can write
to the 'state of the world', and this change can affect many
different parts of my program later.
My guess is part of the answer may be: a program would be
ill-advised to depend on any output from having a predictable
effect in the 'state of the world'. Is this the case? If it
did, would it mean it is no longer a 'functional program'?
Thanks
-Panu Viljamaa
Topmind
> wrote:
> >It is sometimes said that if technology tried to
> >always mirror the real world, then planes would have
> >wings that flap. Da Vinchi tried that already, it
> >didn't work.
>
> Yeah, but it's coming back, some of these new bug-sized 'bots are
> gonna flap little wings, hugely efficient on small scales.
Are you saying that propellers don't work well on insect-size
models? I thot they used flapping so make it inconspicuous
for spy purposes, not because flapping is better than
propellers.
panu
> ... "real-world objects give a damn good analogy for the semantics of a
> computer object".
>
> The point being: computer objects share some similarities with
> real-world objects, but similarities don't mean they are the best model.
There's two opposite meanings of the word 'model', both frequently
used in the context of software. 'Model' can be the thing we are
trying to simulate, which is then "a model FOR" the simulation
being built. Or it can as often refer to a simulation *already
built*, which is now "a model OF" the real world.
Your post seems to suggest you are thinking about what is the best
"model FOR" software. From the OO perspective the question however
is: "Which machine executable constructs, programming languages,
are best for building models OF business problems, and the world
in general?"
OO is not trying to find a model after which to build or choose
a programming language. Rather we are trying to find or build
a programming language that allows us to accurately reflect the
model we already have: the 'real-world'.
This may be a basic difference in the direction of thought,
between OO and FP.
Thanks
-Panu Viljamaa
JXStern
wrote:
>> On Tue, 29 Oct 2002 22:08:45 GMT, top...@technologist.com (Topmind)
>> wrote:
>> >It is sometimes said that if technology tried to
>> >always mirror the real world, then planes would have
>> >wings that flap. Da Vinchi tried that already, it
>> >didn't work.
>>
>> Yeah, but it's coming back, some of these new bug-sized 'bots are
>> gonna flap little wings, hugely efficient on small scales.
>
>Are you saying that propellers don't work well on insect-size
>models? I thot they used flapping so make it inconspicuous
>for spy purposes, not because flapping is better than
>propellers.
AFAIK, at bug scales, air acts more like a viscous fluid, all the
aerodynamic models have to be rewritten, you can do tricks with the
vortices that the previous flap leaves in place, and for that matter
even static wings work differently, much less that you need to respond
more quickly to tiny gusts than a wing/propellor system would allow.
Yada yada time constant Reynolds number something something.
So, yeah, as far as I recall and understand, the wings are supposed to
be far better on the small scale. Let's spend ten seconds w google
...
http://www.cis.plym.ac.uk/cis/InsectRobotics/Wings.htm
http://popularmechanics.com/popmech/sci/0102STROAM.html
... nothing directly definitive, sorry, doesn't mention efficiency.
kinda OT at this point anywho.
http://web.math.fsu.edu/~smith/HTML_twim_past/1998.12_14-18.html
The myth "bumble-bees cannot fly according to convential aerodynamics"
simply relects our poor understanding of unsteady viscous fluid
dynamics. In particular, we lack a theory of vortex shedding at the
intermediate Reynolds numbers relevant to insect flight. Laboratory
measurements of time-dependent forces and vorticity in unsteady flows
are still dificult. Understanding aerodynamics of insect flight is not
only of theoretical interest, but is directly related to the current
challenge of building micro-aviation vehicles.
The Reynolds numbers of insect flight lie in the range of 100 to
10,000, which implies that both inertial and viscous effects are
important. Moreover, wings flap rapidly, with frequencies in the range
of 20 to 200 Hz, and produce highly unsteady flows. As a consequence,
simple extensions of conventional aerodynamics using quasi-steady and
inviscid approaches, have not been generally successful. Fortunately,
with the recent advances in CFD, it is now feasible to compute the
full flow around a moving wing at relevant Reynolds numbers. Such
simulations can complement the existing laboratory experiments by
quantifying both the vorticity and the forces, and can facilitate our
search of optimal solutions. These computations can further suggest
simple models for generating the observed aerodynamic forces.
http://flux.aps.org/meetings/YR97/BAPSDFD97/abs/S8900005.html
Flapping insect flight generates high mean lift by the interaction of
the flying surfaces with the shed vorticity. Typical Reynolds numbers
of insects are around 5000. The high lift of a hovering insect is not
usually explained by conventional quasi-steady aerodynamics. In this
study, we compute numerically, for the full Navier-Stokes equations,
the unsteady viscous flow that involve vorticity shed from a
two-dimensional wing. We model an insect wing by a thin ellipse, which
undergoes various translational and rotational motions. We present
results describing the vorticity field and the time history of lift
and drag forces for various Reynolds numbers and different wing
motions. We also discuss computational aspects of the force
measurements and the role of the far-field boundary conditions.
J.