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

Discussion in 'Python' started by Robert Harper, Apr 18, 2013.

  1. 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 <>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://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
    >>
    Robert Harper, Apr 18, 2013
    #1
    1. Advertising

  2. Re: [TYPES] The type/object distinction and possible synthesis ofOOPand imperative programming languages

    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
    Steven D'Aprano, Apr 19, 2013
    #2
    1. Advertising

  3. Robert Harper

    Roy Smith Guest

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

    In article <517131cd$0$29977$c3e8da3$>,
    Steven D'Aprano <> 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.
    Roy Smith, Apr 19, 2013
    #3
  4. On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <> 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
    Chris Angelico, Apr 19, 2013
    #4
  5. Robert Harper

    Roy Smith Guest

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

    In article <>,
    Chris Angelico <> wrote:

    > On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith <> 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.
    Roy Smith, Apr 19, 2013
    #5
  6. On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <> 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.)
    Chris Angelico, Apr 19, 2013
    #6
  7. Robert Harper

    Roy Smith Guest

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

    In article <>,
    Chris Angelico <> wrote:

    > On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith <> 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.
    Roy Smith, Apr 19, 2013
    #7
  8. Re: [TYPES] The type/object distinction and possible synthesis ofOOP and imperative programming languages

    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
    Steven D'Aprano, Apr 19, 2013
    #8
  9. Re: [TYPES] The type/object distinction and possible synthesis ofOOP and imperative programming languages

    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
    Steven D'Aprano, Apr 19, 2013
    #9
  10. Robert Harper

    Ian Kelly Guest

    On Fri, Apr 19, 2013 at 4: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!


    C++ class members are private by default; struct members are public by
    default. That's the only difference as I recall.
    Ian Kelly, Apr 19, 2013
    #10
  11. Re: [TYPES] The type/object distinction and possible synthesis ofOOP and imperative programming languages

    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.
    Ned Batchelder, Apr 19, 2013
    #11
  12. On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith <> 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
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Apr 20, 2013
    #12
  13. Robert Harper

    Roy Smith Guest

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

    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$>,
    Steven D'Aprano <> 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.
    Roy Smith, Apr 20, 2013
    #13
  14. Robert Harper

    Roy Smith Guest

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

    In article <>,
    Dennis Lee Bieber <> wrote:

    > On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith <> 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.
    Roy Smith, Apr 20, 2013
    #14
  15. Re: [TYPES] The type/object distinction and possible synthesis ofOOP and imperative programming languages

    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
    Steven D'Aprano, Apr 20, 2013
    #15
  16. 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 ....
    88888 Dihedral, Apr 20, 2013
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page