Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43865 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Robert Harper <rwh@cs.cmu.edu> - 2013-04-18 17:14 -0400
    Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 12:00 +0000
      Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-19 09:07 -0400
        Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-19 23:33 +1000
          Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-19 11:31 -0400
            Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-20 01:40 +1000
              Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-19 12:02 -0400
                Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 16:16 +0000
                  Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Ned Batchelder <ned@nedbatchelder.com> - 2013-04-19 12:41 -0400
                    Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-20 00:50 -0700
                  Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-19 16:38 +0000
                Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-19 19:03 -0400
                  Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-19 19:40 -0400
        Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 16:37 +0000
          Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-19 19:37 -0400
            Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 23:47 +0000

#43865 — Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

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 <andreas.abel@ifi.lmu.de>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
>> 
>> andreas.abel@ifi.lmu.de
>> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>> 

[toc] | [next] | [standalone]

#43895

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

[toc] | [prev] | [next] | [standalone]

#43896

In article <517131cd$0$29977$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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.

[toc] | [prev] | [next] | [standalone]

#43898

On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <roy@panix.com> 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

[toc] | [prev] | [next] | [standalone]

#43905

In article <mailman.821.1366378384.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <roy@panix.com> 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.

[toc] | [prev] | [next] | [standalone]

#43906

On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <roy@panix.com> 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.)

[toc] | [prev] | [next] | [standalone]

#43908

In article <mailman.824.1366386029.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <roy@panix.com> 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.

[toc] | [prev] | [next] | [standalone]

#43910

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

[toc] | [prev] | [next] | [standalone]

#43914

On 4/19/2013 12:16 PM, Steven D'Aprano 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!
>
>
The only difference between a class and a struct is that classes default 
to "private" access for their members, and structs default to "public".

--Ned.

[toc] | [prev] | [next] | [standalone]

#43951

Ned Batchelder於 2013年4月20日星期六UTC+8上午12時41分03秒寫道：
> On 4/19/2013 12:16 PM, Steven D'Aprano 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!
> 
> >
> 
> >
> 
> The only difference between a class and a struct is that classes default 
> 
> to "private" access for their members, and structs default to "public".
> 
> 
> 
> --Ned.
In python even a class can be decorated. Also features of instances
can be added at run time from programs by different programmers
or even programs from machines by the code generation scheme
used in many CAD tools.

Nowadays the concept of a structure is not clear without
specifying the language used in programming.

A list is a structure of non-homogeneous types of items  in LISP,
PERL and PYTHON.

But the cases are different in C++, PASCAL, ADDA, JAVA ....

[toc] | [prev] | [next] | [standalone]

#43915

On Fri, Apr 19, 2013 at 4:16 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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.

[toc] | [prev] | [next] | [standalone]

#43938

On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith <roy@panix.com> declaimed
the following in gmane.comp.python.general:

> 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.

	It's been 15+ years but...

	"class" defaults to private; " struct" defaults to public... (very
simplified <G>)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#43941

In article <mailman.843.1366412626.3114.python-list@python.org>,
 Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith <roy@panix.com> declaimed
> the following in gmane.comp.python.general:
> 
> > 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.
> 
> 	It's been 15+ years but...
> 
> 	"class" defaults to private; " struct" defaults to public... (very
> simplified <G>)

You were doing well until you added the "very simplified" part :-)  That 
is indeed the only difference.

Many people are surprised that you can write member functions for 
structs.  Or that you can subclass (substruct?) them.

[toc] | [prev] | [next] | [standalone]

#43913

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

[toc] | [prev] | [next] | [standalone]

#43940

I wrote:
> > 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.
> 

In article <517172e7$0$29977$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 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.

Now that I think about it, I suspect relatively few people learned 
Python as their first programming language.

Java, for example, is very popular as a teaching language in colleges 
and universities.  There are lots of people who go through a 4-year 
program, do all of their coursework in Java, and come out as one-trick 
ponies.

There aren't many schools who teach Python as a first (and only 
language), but I suppose it's starting to catch on.  5 years from now, 
we may see waves of kids graduating from college knowing nothing but 
Python, with a similarly narrow view of the universe.

[toc] | [prev] | [next] | [standalone]

#43942

On Fri, 19 Apr 2013 19:37:38 -0400, Roy Smith wrote:

> There aren't many schools who teach Python as a first (and only
> language), but I suppose it's starting to catch on.  5 years from now,
> we may see waves of kids graduating from college knowing nothing but
> Python, with a similarly narrow view of the universe.

Send the young whipper-snappers here, we'll soon learn 'em better!



-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web