I found it difficult to come up with any. I was wondering if this is
because the world is inherently OO by nature,

and the whole original
methodologies of designing software by linearly ("what do you do
next") or procedurally was really off the ball and a complete mis-
conception of the nature of things.

However, recently, it occurred to me, that maybe the difference is
centered around the how we look at things: what can we do with them to
achieve a particular goal (procedural) or what are these things
capable of doing (OO).

E.g., a new manager is hired into an existing department. If he
focuses on who his workers are: their strengths and weaknesses, then
that's OO. But if just careers ahead defining goals with thinking
about the capabilities of his workers, then that's procedural.

Another example: If I wanted to make a model to represent all the
factories in a town. What would a OO model look like and what would a
procedural  model look like?

On May 14, 4:05 am, "amake... at (no spam) gmail.com" <amake... at (no spam) gmail.com> wrote:

I found it difficult to come up with any. I was wondering if this is
because the world is inherently OO by nature,

No, the world is neither OO nor procedural in nature. Objects and
classes are a mechanism used in software development. It is a part of
the world (like computers are parts of the world), but it has nothing
to do with philosofi.

and the whole original
methodologies of designing software by linearly ("what do you do
next") or procedurally was really off the ball and a complete mis-
conception of the nature of things.

OO is also an imperative (linear) technique.
There are non-imperative languages like Haskell, Erlang, etc. But they are not OO.

The main problem is when you start to look at the world in black-and-
white. Objects and classes are useful tools in some scenarios.
Functions are useful too. The real problem starts when you have
languages like Java, that only have classes and doesn't have
functions.

The OO model is almost identical to the network model.

frebe wrote:
On May 14, 4:05 am, "amake... at (no spam) gmail.com" <amake... at (no spam) gmail.com> wrote:
I found it difficult to come up with any. I was wondering if this is
because the world is inherently OO by nature,
No, the world is neither OO nor procedural in nature. Objects and
classes are a mechanism used in software development. It is a part of
the world (like computers are parts of the world), but it has nothing
to do with philosofi.

Objects are a conceptual metaphor that one guy in Norway in the 1960s
wanted to use to use to model/simulate real world stuff with on computers..

That guy decided on that metaphor after realising that a procedural view
of said real world couldn't naturally/easily represent what he wanted to
do.

That guy got together with another guy to devise a prog lang that would
realise this concept. That language was called Simula.

and the whole original
methodologies of designing software by linearly ("what do you do
next") or procedurally was really off the ball and a complete mis-
conception of the nature of things.
OO is also an imperative (linear) technique.
There are non-imperative languages like Haskell, Erlang, etc. But they are not OO.

Which are also "linear".
W
M

The main problem is when you start to look at the world in black-and-
white. Objects and classes are useful tools in some scenarios.
Functions are useful too. The real problem starts when you have
languages like Java, that only have classes and doesn't have
functions.

Yes, the dogmatic imposition of one paradigm to the exclusion of others
is indeed a big problem in prog langs. That is why those that support
many (FP, C++ etc) are more powerful or useful than those that don't.

The OO model is almost identical to the network model.

And almost identical to the relational model.

Objects have relationships with other objects.

You have made the oh so common mistake of confusing *concept* with
*implementation of concept* (re the above, your comments on
"imperative" etc) .

Avi,

With kids (really little ones), you have to do everything for them.  
Brush their teeth, feed them, bath them, dress them.

put toothpaste on brush.
insert toothbrush into child's mouth.
do {
    move brush up;
    move brush down;
    move brush randomly;

} until (satisfied)

Object Oriented Programming is like having older kids.  Instead of
grabbing a brush and cleaning their teeth or  I can say

    child.brushTeeth()

or

    child.bathe()

Or with a really talented dog object I could

    dog.brushTeeth()

A good way, I think, of measuring whether programmers think procedurally
or OOly is to gauge how often they use simple properties, or expose all
an object's variables publicly.  

Show me how you apply 2NF to objects.

Objects have relationships with other objects.

The relational model doesn't have relationships.

On 14 Maj, 15:25, frebe <freb... at (no spam) gmail.com> wrote:



Show me how you apply 2NF to objects.

2NF is not well-defined, I'm afraid. Without a string of caveats it's
mathematical mumbo-jumbo.

Objects have relationships with other objects.

The relational model doesn't have relationships.

Which is a great weakness of the relational model - fully acknowledged
by the relational community - since its inception.

Even today, it is
proposed that most users should interact with a relational model of
data consisting of a collection
of relationships rather than relations.

Relations have always played second-fiddle to relationships because
relations are logically inferior.

frebe wrote:
On May 14, 10:50 am, S Perryman <a... at (no spam) a.net> wrote:

F>OO is also an imperative (linear) technique.
F>There are non-imperative languages like Haskell, Erlang, etc. But they
are not OO.

Which are also "linear".
W
M
I think you should readhttp://en.wikipedia.org/wiki/Imperative_programming.

Dont' need to. But you obviously do.
Be careful to put the blinkers on when you come to the bit that tells you
that imperative programs are also declarative.

And you better sit down before I tell you that Functional Programming is
also imperative.

That aside, you introduce a bogus term "linear" that nobody has defined or
used. Given your confusion about imperative/declarative programming,
perhaps you meant *sequential* .

F>The OO model is almost identical to the network model.

And almost identical to the relational model.
Show me how you apply 2NF to objects.

Dpes the 2NF of the *"Relational" data* model apply to OO ??

Here is an OO *relational* model (in UML) of the example :

       1..*               *
Skill --------- Employee -------- Current Work Location
               *              0..1

Objects have relationships with other objects.
The relational model doesn't have relationships. (Maybe you think of
referential constraints?).

The relational model does have relationships (the clue is in the name) .

You have made the oh so common mistake of confusing *concept* with
*implementation of concept* (re the above, your comments on
"imperative" etc) .
Do you claim that the network and relational models are
implementations of the same concept?

1. What is a "network" model ?? A graph ??
If so, graphs are relationships.

2. Are you asking whether graphs can be used to implement a relational
    model ??

On May 14, 10:50 am, S Perryman <a... at (no spam) a.net> wrote:

Which are also "linear".
W
M

I think you should read http://en.wikipedia.org/wiki/Imperative_programming.

And almost identical to the relational model.

Show me how you apply 2NF to objects.

Objects have relationships with other objects.

The relational model doesn't have relationships. (Maybe you think of
referential constraints?).

You have made the oh so common mistake of confusing *concept* with
*implementation of concept* (re the above, your comments on
"imperative" etc) .

Do you claim that the network and relational models are
implementations of the same concept?

Part of the major flaw in this is
actually related to the fact that they didn't properly integrate with
WCF (Windows Communication Foundation) and WPF (Windows Presentation
Foundation).

On 14 Maj, 15:25, frebe <freb... at (no spam) gmail.com> wrote:



Show me how you apply 2NF to objects.

2NF is not well-defined, I'm afraid. Without a string of caveats it's
mathematical mumbo-jumbo.

Objects have relationships with other objects.

The relational model doesn't have relationships.

Which is a great weakness of the relational model - fully acknowledged
by the relational community - since its inception.

Even today, it is
proposed that most users should interact with a relational model of
data consisting of a collection
of relationships rather than relations.

Relations have always played second-fiddle to relationships because
relations are logically inferior.

On 19 Maj, 08:16, saraberg... at (no spam) hotmail.co.uk wrote:

On 14 Maj, 15:25, frebe <freb... at (no spam) gmail.com> wrote:

Show me how you apply 2NF to objects.

2NF is not well-defined, I'm afraid. Without a string of caveats it's
mathematical mumbo-jumbo.

References please.

Objects have relationships with other objects.

The relational model doesn't have relationships.

Which is a great weakness of the relational model - fully acknowledged
by the relational community - since its inception.

References please

Even today, it is
proposed that most users should interact with a relational model of
data consisting of a collection
of relationships rather than relations.

Who proposes that?

Relations have always played second-fiddle to relationships because
relations are logically inferior.

Your opinion, or do you have some support for that statement?

On May 20, 4:56 pm, saraberg... at (no spam) hotmail.co.uk wrote:
On 19 Maj, 14:37, frebe <freb... at (no spam) gmail.com> wrote:

On 19 Maj, 08:16, saraberg... at (no spam) hotmail.co.uk wrote:

On 14 Maj, 15:25, frebe <freb... at (no spam) gmail.com> wrote:

Show me how you apply 2NF to objects.

2NF is not well-defined, I'm afraid. Without a string of caveats it's
mathematical mumbo-jumbo.

References please.

1NF is not well defined, see:http://en.wikipedia.org/wiki/1NF

Particularly, " ... there is no universal agreement as to which
features would disqualify a table from being in 1NF."

2NF is based on 1NF. As 1NF is not well-defined, then neither is 2NF.
Nor is any normal form. They are all ambiguous.

I agree that 1NF has been redefined (by Chris Date and others) to
include virtually anything. The definition of 2NF is:

a 1NF table is in 2NF if and only if none of its non-prime attributes
are functionally dependent on a part (proper subset) of a candidate
key.

Since 1NF can mean almost anything, the requirment "1NF table" doesn't
exclude much, but in what way does it make 2NF (and all other normal
forms) "mumbo-jumbo"?

//frebe

"Daniel T." <danie... at (no spam) earthlink.net> wrote in message
On May 20, 12:40 pm, "cr88192" <cr88... at (no spam) hotmail.com> wrote:

typically, I don't use contexts for functions which are essentially
stateless (and will always be stateless).
IMO, it just seems a little silly to put these as static methods in some
particular class. similarly for types/objects which are conceptually
atomic
and pass-by-value. ...

yes, such things exist...

You mean a procedure that doesn’t return information nor change any
values in memory?

well, it can return stuff...

but, yes, all input is provided in arguments, and any return value depends
purely on the input...

this is typical of many mathematical functions, ...
traditionally, these would be things like sin, cos, tan, ...

but could include things like sinc, integrators, interpolators, ...
also typical is to implement custom math support, for example, vector and
quaternion support, ...

however, the typical "OO" mindset tends to ignore the existence of things
like this... (like, math is some kind of novelty no "real" programmers
use...).

but, yes, in these cases we don't need a context...

"Daniel T." <danie... at (no spam) earthlink.net> wrote in message
On May 20, 12:40 pm, "cr88192" <cr88... at (no spam) hotmail.com> wrote:

typically, I don't use contexts for functions which are essentially
stateless (and will always be stateless).
IMO, it just seems a little silly to put these as static methods in
some
particular class. similarly for types/objects which are conceptually
atomic
and pass-by-value. ...

yes, such things exist...

You mean a procedure that doesn’t return information nor change any
values in memory?

well, it can return stuff...

but, yes, all input is provided in arguments, and any return value depends
purely on the input...

this is typical of many mathematical functions, ...
traditionally, these would be things like sin, cos, tan, ...

but could include things like sinc, integrators, interpolators, ...
also typical is to implement custom math support, for example, vector and
quaternion support, ...

however, the typical "OO" mindset tends to ignore the existence of things
like this... (like, math is some kind of novelty no "real" programmers
use...).

but, yes, in these cases we don't need a context...