On 12/1/2024 10:34 PM, Tim Rentsch wrote:
wij <[email protected]> writes:
In response to the question of the subject line...
Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.
Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.
More than anything else object-oriented programming is a mindset
or a programming methodology. It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.
A quote:
My guess is that object-oriented programming will be in the
1980s what structured programming was in the 1970s.
Everyone will be in favor of it. Every manufacturer will
promote his products as supporting it. Every manager will
pay lip service to it. Every programmer will practice it
(differently). And no one will know just what it is.
That paragraph is taken from a paper written more than 40 years
ago. The prediction came true with a vengeance, even more than
the author expected. Most of what has been written about object
oriented programming was done by people who didn't understand it.
Two more quotes, these from Alan Kay:
I invented the term "Object Oriented Programming," and C++
is not what I had in mind.
Though Smalltalk's structure allows the technique now known
as data abstraction to be easily (and more generally)
employed, the entire thrust of its design has been to
supersede the concept of data and procedures entirely; to
replace these with the more generally useful notions of
activity, communication, and inheritance.
The most important aspect of OOP is the ability to decompose
a problem into independent component parts. This can eliminate
the side effects in the structured programming model that
result from global data.
On 12/6/24 9:40 PM, olcott wrote:
On 12/1/2024 10:34 PM, Tim Rentsch wrote:
wij <[email protected]> writes:
In response to the question of the subject line...
Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.
Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.
More than anything else object-oriented programming is a mindset
or a programming methodology. It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.
A quote:
My guess is that object-oriented programming will be in the
1980s what structured programming was in the 1970s.
Everyone will be in favor of it. Every manufacturer will
promote his products as supporting it. Every manager will
pay lip service to it. Every programmer will practice it
(differently). And no one will know just what it is.
That paragraph is taken from a paper written more than 40 years
ago. The prediction came true with a vengeance, even more than
the author expected. Most of what has been written about object
oriented programming was done by people who didn't understand it.
Two more quotes, these from Alan Kay:
I invented the term "Object Oriented Programming," and C++
is not what I had in mind.
Though Smalltalk's structure allows the technique now known
as data abstraction to be easily (and more generally)
employed, the entire thrust of its design has been to
supersede the concept of data and procedures entirely; to
replace these with the more generally useful notions of
activity, communication, and inheritance.
The most important aspect of OOP is the ability to decompose
a problem into independent component parts. This can eliminate
the side effects in the structured programming model that
result from global data.
Excpet that normally OOP is fully based on the operation resulting in
"side effects" as they mutate the state of the object the methods are
part of.
What this does is not ELIMINATE the side effects, but limits their
scope. A given object type will tend to keep its own state "private"
and interact only with other object via "public" interfaces, allowing
us to limit the scope we need to think of when looking at
interactions.
This makes it very different from the "functional" model, where we do
not allow for side-effects.
On 12/6/24 9:40 PM, olcott wrote:
On 12/1/2024 10:34 PM, Tim Rentsch wrote:
wij <[email protected]> writes:
In response to the question of the subject line...
Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.
Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.
More than anything else object-oriented programming is a mindset
or a programming methodology.� It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.
A quote:
���� My guess is that object-oriented programming will be in the
���� 1980s what structured programming was in the 1970s.
���� Everyone will be in favor of it.� Every manufacturer will
���� promote his products as supporting it.� Every manager will
���� pay lip service to it.� Every programmer will practice it
���� (differently).� And no one will know just what it is.
That paragraph is taken from a paper written more than 40 years
ago.� The prediction came true with a vengeance, even more than
the author expected.� Most of what has been written about object
oriented programming was done by people who didn't understand it.
Two more quotes, these from Alan Kay:
���� I invented the term "Object Oriented Programming," and C++
���� is not what I had in mind.
���� Though Smalltalk's structure allows the technique now known
���� as data abstraction to be easily (and more generally)
���� employed, the entire thrust of its design has been to
���� supersede the concept of data and procedures entirely;� to
���� replace these with the more generally useful notions of
���� activity, communication, and inheritance.
The most important aspect of OOP is the ability to decompose
a problem into independent component parts. This can eliminate
the side effects in the structured programming model that
result from global data.
Excpet that normally OOP is fully based on the operation resulting in
"side effects" as they mutate the state of the object the methods are
part of.
What this does is not ELIMINATE the side effects, but limits their
scope. A given object type will tend to keep its own state "private" and >interact only with other object via "public" interfaces, allowing us to
limit the scope we need to think of when looking at interactions.
This makes it very different from the "functional" model, where we do
not allow for side-effects.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:02:25 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,664 |