> That's what it sounds like, the Pov-Ray world anyway. You've greatly 
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my 
> house not for
> convenience or comfort but to teach me the current accepted practice in 
> carpentry.

Even if POV4 does change to an OOP model that you don't like, a) that is not 
going to be released for decades, and b) you are free to still use the 
latest stable 3.x release.  I wouldn't worry about it.

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Chambers wrote:

> > For one, OOP more closely models how many people think of problems, 
> > while functional programming more closely models how mathematicians 
> > think of problems.  

> ??!! Though the second clause of this sentence seems true  to me, nothing
>   that I have read or heard in a long time seems so obviously false!

  And exactly what is it that makes it false?

  Object-oriented programming closely matches the thought process of people.
OOP can be deconstructed into to most basic elements: Concepts and algorithms.

  People think about things conceptually. For example, you can have one pen,
one car, one dog, and so on.

  Moreover, people use hierarchies of concepts. Some concepts are more
abstract while other concepts are more concrete. For example, the concept
of "animal" is more abstract than the concept of "dog" or "cat", which are
more concrete. Moreover, there's a hierarchical relationship between these
concepts: A dog is an animal, and a cat is an animal (but a dog is not a cat).

  Concepts can have properties to them. For example a dog has color, weight,
gender, race, etc. These properties can be different for different dogs.
Likewise the concept of "book" can have many properties, including its title,
author, date of publication, cover picture, table of contents, and so on
(all of which in themselves are also concepts).

  The other basic element of OOP is algorithms. These can be thought in the
same way as food recipes. Food recipes use some concepts (ingredients, cooking
utensils, etc) and a list of instructions on how to prepare the meal.

  This is the way people think naturally, and object-oriented programming
simulates this kind of design: It defines concepts (which may be hierarchical)
and algorithms on what to do with those concepts.

  Now please explain to me exactly what here is "so obviously false"?

-- 
                                                          - Warp

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> It is not yet clear which one is better for managing 
> large, complex programs in general

  I have hard time believing that large programs written in a functional
language like Haskell don't use one of the basic features of OOP: Modularity.

  Modularity (and the abstraction related to it) is one of the most essential
properties of a large project, if you want it to be manageable.

  Functional programming sounds to me more like just a way of expressing
what you want to do (ie. algorithms), not how you should distribute your
code among modules. Modularity transcends things like imperative or
functional programming paradigms. You could say it's a metaparadigm used
in many if not most large projects, regardless of the language used.

-- 
                                                          - Warp

Post a reply to this message

On 07/23/09 08:07, David H. Burns wrote:
> ??!! Though the second clause of this sentence seems true to me, nothing
> that I have read or heard in a long time seems so obviously false! It makes

	Perhaps it's because you tried learning OOP from C++/Java?

	I'm sure you think in OOP all the time with POV-Ray. You create a 
sphere. It's an object with certain properties (texture, location, etc). 
Now let's say you want to rotate the sphere, does it hurt so much to do 
something like:

mysphere.rotate(45)

	Let's say you want to have lots of balls in your scene. You want some 
to be red, some blue, and some green. And some of _those_ you want to be 
translucent.

	So you create your "basic" ball as a sphere with little texture. You 
subclass it to create two kinds of balls: "solid" and "translucent". In 
terms of actual code, you just create a new object that is the subclass 
of your "basic", and you merely add to it the texture that makes it 
translucent.

	Then you can subclass each to get the red, blue and green balls.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

On 07/23/09 07:55, David H. Burns wrote:
> That's what it sounds like, the Pov-Ray world anyway. You've greatly
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my
> house not for
> convenience or comfort but to teach me the current accepted practice in
> carpentry.

	Try lying in front of the house when the bulldozers come. And if you 
see someone coming along hugging a towel, become friends with him. 
Otherwise your life will be in danger.

	And not because of the bulldozers.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

Warp wrote:

>   This is the way people think naturally, and object-oriented programming
> simulates this kind of design: It defines concepts (which may be hierarchical)
> and algorithms on what to do with those concepts.
> 
>   Now please explain to me exactly what here is "so obviously false"?
> 

*I* don't think, naturally or otherwise, like any OOP programming I have 
seen!! You may be trying to
read your on programming philosophy onto the world, or we may be of 
different genera. :)

David

Post a reply to this message

Neeum Zawan wrote:

>     I'm sure you think in OOP all the time with POV-Ray. You create a 
> sphere. It's an object with certain properties (texture, location, etc). 
> Now let's say you want to rotate the sphere, does it hurt so much to do 
> something like:
> 
> mysphere.rotate(45)
> 

No! I think in terms of objects, not of OOP. The concept of an "object" 
as used
in Pov-Ray in a valuable tool for thinking and programming -and used 
well there.
What I have seen of OOP programming is something else. :)

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> *I* don't think, naturally or otherwise, like any OOP programming I have 
> seen!! You may be trying to
> read your on programming philosophy onto the world, or we may be of 
> different genera. :)

  You clearly don't understand what "object-oriented programming" means.
Then you come here to tell us that you don't want it, whatever it might be.

-- 
                                                          - Warp

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> What I have seen of OOP

  Clearly you haven't. You don't even understand what "object-oriented
programming" means.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Object-oriented programming closely matches the thought process of people.

I think it's more like how people categorize real-world stuff. Since a lot 
of programming is essentially simulating the real world, OO makes sense.

There's a bunch of things that go on in the real world that don't make sense 
to do with OO: expert systems, board game AIs, financial analysis, 
accounting, etc.

There's a bunch of things that make sense with OO: Windowing system, 
interactions between businesses and customers, etc.

To say "people think in OO" is to miss that in many situations people don't 
think in OO.

>   This is the way people think naturally,

I would say this is *A* way people think naturally.  Something as simple as 
a decision table or decision tree is another way people think naturally.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message