Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages

Reply
Thread Tools

Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages

 
 
Robert Harper
Guest
Posts: n/a
 
      04-18-2013
In short, there is no such thing as a "paradigm". I agree fully. This term is a holdover from the days when people spent time and space trying to build taxonomies based on ill-defined superficialities. See Steve Gould's essay "What, If Anything, Is A Zebra?". You'll enjoy learning that there is, in fact, no such thing as a zebra---there are, rather, three different striped horse-like mammals, two of which are genetically related, and one of which is not. The propensity to be striped, like the propensity to have five things (fingers, segments, whatever) is a deeply embedded genetic artifact that expresses itself in various ways.

Bob Harper

On Apr 18, 2013, at 2:48 PM, Jason Wilkins wrote:

> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
>
> Warning, this is a bit of a rant.
>
> That paragraph from Wikipedia seems to be confused. It gives the fourth
> paradigm as "declarative" but then says "first order logic for logic
> programming". It seems somebody did an incomplete replacement of
> "declarative" for "logic". Wikipedia is often schizophrenic like that.
>
> Personally, I think that object oriented and logical programming only
> became official paradigms because there was a certain level of hype for
> them in the 1980s and nobody has thought to strike them off the list after
> the hype died down.
>
> Object-oriented, as constituted today, is just a layer of abstraction over
> imperative programming (or imperative style programming in functional
> languages, because objects require side-effects). What "object-oriented"
> language actually in use now isn't just an imperative language with fancy
> abstraction mechanisms?
>
> The problem with having declarative languages as a paradigm (which logical
> languages would be a part) is that it feels like it should be a
> "miscellaneous" category. Being declarative doesn't tell you much except
> that some machine is going to turn your descriptions of something into some
> kind of action. In logical programming it is a set of predicates, but it
> could just as easily be almost anything else. In a way all languages are
> "declarative", it is just that we have some standard interpretations of
> what is declared that are very common (imperative and functional).
>
> My wish is that the idea of there being four paradigms would be abandoned
> the same we the idea of four food groups has been abandoned (which may
> surprise some of you). We have more than four different modes of thinking
> when programming and some are much more important than others and some are
> subsets of others. We should teach students a more sophisticated view.
>
> Ironically Wikipedia also shows us this complexity. The
> programming language paradigm side bar actually reveals the wealth
> of different styles that are available. There is simply no clean and
> useful way to overlay the four paradigms over what we see there, so it
> should be abandoned because it gives students a false idea.
>
>
> On Wed, Apr 17, 2013 at 9:42 AM, Andreas Abel <(E-Mail Removed)>wrote:
>
>> [ The Types Forum, http://lists.seas.upenn.edu/**
>> mailman/listinfo/types-list<http://lists.seas.upenn.edu/mailman/listinfo/types-list>]
>>
>> On 17.04.2013 11:30, Uday S Reddy wrote:
>>
>>> Mark Janssen writes:
>>>
>>> From: en.wikipedia.org: Programming_paradigm:
>>>>
>>>> "A programming paradigm is a fundamental style of computer
>>>> programming. There are four main paradigms: object-oriented,
>>>> imperative, functional and declarative. Their foundations are distinct
>>>> models of computation: Turing machine for object-oriented and
>>>> imperative programming, lambda calculus for functional programming,
>>>> and first order logic for logic programming."
>>>>
>>>

>> I removed the second sentence relating paradigms to computation models
>> and put it on the talk page instead. It does not make sense to connect
>> imperative programming to Turing machines like functional programming to
>> lambda calculus. A better match would be random access machines, but the
>> whole idea of a connection between a programming paradigm and a computation
>> model is misleading.
>>
>>
>> While I understand the interest in purely theoretical models, I wonder
>>>> two things: 1) Are these distinct models of computation valid? And,
>>>> 2) If so, shouldn't a theory of types announce what model of
>>>> computation they are working from?
>>>>
>>>
>>> These distinctions are not fully valid.
>>>
>>> - Functional programming, logic programming and imperative programming are
>>> three different *computational mechanisms*.
>>>
>>> - Object-orientation and abstract data types are two different ways of
>>> building higher-level *abstractions*.
>>>
>>> The authors of this paragraph did not understand that computational
>>> mechanisms and higher-level abstractions are separate, orthogonal
>>> dimensions
>>> in programming language design. All six combinations, obtained by
>>> picking a
>>> computational mechanism from the first bullet and an abstraction mechanism
>>> from the second bullet, are possible. It is a mistake to put
>>> object-orientation in the first bullet. Their idea of "paradigm" is vague
>>> and ill-defined.
>>>
>>> Cheers,
>>> Uday Reddy
>>>
>>>

>>
>> --
>> Andreas Abel <>< Du bist der geliebte Mensch.
>>
>> Theoretical Computer Science, University of Munich
>> Oettingenstr. 67, D-80538 Munich, GERMANY
>>
>> http://www.velocityreviews.com/forums/(E-Mail Removed)
>> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>>


 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-19-2013
On Thu, 18 Apr 2013 17:14:13 -0400, Robert Harper wrote:

> In short, there is no such thing as a "paradigm".


Of course there is. A paradigm is a distinct way of thinking, a
philosophy if you will. To say that there is no such thing as a paradigm
is to say that all ways of thinking about a topic are the same, and
that's clearly nonsense.

OOP is a distinct paradigm from procedural programming, even though the
distinctions are minor when compared to those between imperative and
functional programming. Java's "everything in a class" style of
programming is very distinct from Pascal's "functions and records" style
of programming, even though both are examples of imperative programming.
They lead to different styles of coding, they have different strengths
and weaknesses, and even taking into account differences of syntax, they
differ in what you can do simply and naturally without the language
getting in the way.


> I agree fully. This
> term is a holdover from the days when people spent time and space trying
> to build taxonomies based on ill-defined superficialities. See Steve
> Gould's essay "What, If Anything, Is A Zebra?". You'll enjoy learning
> that there is, in fact, no such thing as a zebra---there are, rather,
> three different striped horse-like mammals, two of which are genetically
> related, and one of which is not.


All life on earth is genetically related. Even if the so-called "tree of
life" doesn't have a single common ancestor, it has a single set of
common ancestors.

In the case of the three species of zebra, they are all members of the
genus Equus, so they are actually *extremely* closely related. The
argument that "zebra is not a genealogical group" (which is very
different from the false statement that there is no such thing as a
zebra!) is that one of the three species of zebra is in fact more closely
related to non-zebras than the other two species of zebra.

Something like this tree:

Common ancestor of all Equus
|
+-- Common ancestor of Burchell's Zebras and Grevy's Zebras
| +-- Burchell's Zebra
| +-- Grevy's Zebra
|
+-- Common ancestor of horses and Mountain Zebras
+-- Horse
+-- Mountain Zebra

(I've left out asses and donkeys because I'm not sure where they fit in
relation to the others.)

There's no natural genealogical group that includes all three species of
zebra that doesn't also include horses. But that doesn't mean that
there's no reasonable non-genealogical groups! For example, all three
species of zebra have fewer than 50 chromosome pairs, while all other
Equus species have more than 50 pairs. Based on physical characteristics
rather than ancestry, zebras make up a perfectly good group, distinct
from other members of Equus.

To put it another way, the three species of zebra may not make up a
natural group when considered by lines of descent, but they do make up a
natural group when considered by other factors.


> The propensity to be striped, like
> the propensity to have five things (fingers, segments, whatever) is a
> deeply embedded genetic artifact that expresses itself in various ways.


"Zebra" is not a classification of "thing that is striped", but a
specific subset of such things, and stripes are only one of many
distinguishing features. Cladistics is an important classification
scheme, but it is not the only valid such scheme.


--
Steven
 
Reply With Quote
 
 
 
 
Roy Smith
Guest
Posts: n/a
 
      04-19-2013
In article <517131cd$0$29977$c3e8da3$(E-Mail Removed) om>,
Steven D'Aprano <(E-Mail Removed)> wrote:

> On Thu, 18 Apr 2013 17:14:13 -0400, Robert Harper wrote:
>
> > In short, there is no such thing as a "paradigm".

>
> Of course there is. A paradigm is a distinct way of thinking, a
> philosophy if you will. To say that there is no such thing as a paradigm
> is to say that all ways of thinking about a topic are the same, and
> that's clearly nonsense.


This thread has gone off in a strange direction. When I said:

> One of the nice things about OOP is it means so many different things to
> different people. All of whom believe with religious fervor that they
> know the true answer.


I was indeed talking about the ways people think about programming. For
example, OOP in C++ is very much about encapsulation. People declare
all data private, and writing setter/getter functions which carefully
control what access outside entities have to your data.

Often, when you talk to C++ people, they will tell you that
encapsulation is what OOP is all about. What they are doing is saying,
C++ isa OOPL, and C++ has encapsulation, therefore OOPL implies
encapsulation. When they look at something like Python, they say,
"That's not object oriented because you don't have private data".

I suppose people who grew up learning Python as their first language
look at something like C++ and say, "That's not OOP because classes
aren't objects", or something equally silly.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      04-19-2013
On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <(E-Mail Removed)> wrote:
> I was indeed talking about the ways people think about programming. For
> example, OOP in C++ is very much about encapsulation. People declare
> all data private, and writing setter/getter functions which carefully
> control what access outside entities have to your data.


The funny thing about that notion is that, even in C++, it's
completely optional. I've subclassed someone else's class using a
struct and just left everything public. In fact, I've gotten so used
to the Python way of doing things that now I'm quite happy to run
everything public anyway.

Is OOP truly about X if X is optional?

ChrisA
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
Chris Angelico <(E-Mail Removed)> wrote:

> On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <(E-Mail Removed)> wrote:
> > I was indeed talking about the ways people think about programming. For
> > example, OOP in C++ is very much about encapsulation. People declare
> > all data private, and writing setter/getter functions which carefully
> > control what access outside entities have to your data.

>
> The funny thing about that notion is that, even in C++, it's
> completely optional.


Well, yeah:

#define private public
#define protected public
#include <whatever.h>

Not to mention all sorts of horrible things you can do with pointers and
const_cast, etc. But that doesn't stop people from thinking that
somehow they've built some uber-protected cocoon around their data, and
that this is part and parcel of what OOPL is all about.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      04-19-2013
On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <(E-Mail Removed)> wrote:
> #define private public
> #define protected public
> #include <whatever.h>


And:
#define class struct

But what I mean is that, _in my design_, I make everything public. No
getters/setters, just direct member access. The theory behind getters
and setters is that you can change the implementation without changing
the interface... but I cannot remember a *single time* when I have
made use of that flexibility. Not one. Nor a time when I've wished for
that flexibility, after coding without it. No no, not one!

ChrisA
(He's telling the truth, he is not Mabel.)
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
Chris Angelico <(E-Mail Removed)> wrote:

> On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <(E-Mail Removed)> wrote:
> > #define private public
> > #define protected public
> > #include <whatever.h>

>
> And:
> #define class struct


I suppose, while we're at it:

# define const ""

(I think that works, not sure).

PS: a great C++ interview question is, "What's the difference between a
class and a struct?" Amazing how few self-professed C++ experts have no
clue.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-19-2013
On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote:

> PS: a great C++ interview question is, "What's the difference between a
> class and a struct?" Amazing how few self-professed C++ experts have no
> clue.


I'm not a C++ expert, but I am an inquiring mind, and I want to know the
answer!


--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-19-2013
On Fri, 19 Apr 2013 09:07:15 -0400, Roy Smith wrote:

> Often, when you talk to C++ people, they will tell you that
> encapsulation is what OOP is all about. What they are doing is saying,
> C++ isa OOPL, and C++ has encapsulation, therefore OOPL implies
> encapsulation. When they look at something like Python, they say,
> "That's not object oriented because you don't have private data".
>
> I suppose people who grew up learning Python as their first language
> look at something like C++ and say, "That's not OOP because classes
> aren't objects", or something equally silly.


You might say that, but I find in my experience that Python users don't
tend to fall for the "No True Scotsman" fallacy anywhere near as often as
(say) Java or C++ users. I'm not sure what the reason for this is.
Perhaps it is that the Python community as a whole is more open to other
languages and paradigms, and less stuffed to the gills with code monkeys
who only know how to copy and paste code from StackOverflow. The Python
community frequently tosses around references to other languages,
compares how Python would do something to other languages, or relates how
certain features were borrowed from language X (e.g. list comprehensions
are taken from Haskell; map, filter and reduce are taken from Lisp). But
when I read forums and blogs about (say) Java, it's nearly always about
Java in isolation, and one would be forgiven for thinking it was the only
programming language in existence.

I don't think that there is One True Way to design an OOP language, but I
do think there are *degrees* of OOP. Java, for instance, I would say is
only moderately OOP, since classes aren't objects, and it supports
unboxed native types. I think the first part of that is a weakness, and
the second is a pragmatic decision that on balance probably is a
strength. Yes, Python's "everything is an object" is a cleaner design,
but Java's unboxed types leads to faster code.

It also depends on what you mean by OOP. If we judge Python by the fact
that everything is an object, then it is strongly OOP. But if we judge
Python by its syntax and idioms, it is only weakly OOP, even less than
Java.


--
Steven
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      04-19-2013
On Fri, Apr 19, 2013 at 4:16 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote:
>
>> PS: a great C++ interview question is, "What's the difference between a
>> class and a struct?" Amazing how few self-professed C++ experts have no
>> clue.

>
> I'm not a C++ expert, but I am an inquiring mind, and I want to know the
> answer!


C++ class members are private by default; struct members are public by
default. That's the only difference as I recall.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Ian Kelly Python 0 04-16-2013 11:52 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Mark Janssen Python 0 04-16-2013 11:40 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Mark Janssen Python 0 04-16-2013 11:16 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Matthias Felleisen Python 0 04-15-2013 01:50 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Uday S Reddy Python 0 04-15-2013 09:06 AM



Advertisments