There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values.

This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object.

So for the anti-OOP folks out there using languages like Python as an example,

    Python 3.13.0 (tags/v3.13.0:60403a5, Oct  7 2024, 09:38:07) [MSC v.1941 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x = 23
    >>> type(x)
    <class 'int'>
    >>> dir(x)
    ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes']
    >>>

▲ treve 5 days ago | parent | next [-]

This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.

▲

pjmlp 5 days ago | parent [-]

Not really, because in machinery requires OOP to work.

That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM.

It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

▲

saghm 5 days ago | parent | next [-]

I think you have things backwards; you're the one complaining about the the underlying implementation, whereas the others are talking about the interface for it. They're talking about whether they prefer to drive cars or trains, and you're basically claiming that there's no difference between a car and a train if the train also runs on gas.

▲

pjmlp 5 days ago | parent [-]

I am complaining about the distortion field OOP haters happen to have regarding language semantics.

	▲	saghm 5 days ago \| parent [-]
		That's fair, but I'd still argue that there's a difference in whether code has to be written by defining objects directly or being able to work at a different abstraction level where objects are an underlying implementation detail that get leveraged by other language constructs that are familiar from non-OO paradigms. Whether or not that difference is important or good is a subjective opinion, but I don't see an argument about the underlying implementation as a particularly strong refutation of someone stating that they like having that level of abstraction available.

▲

SeanDav 5 days ago | parent | prev | next [-]

You stopped too soon - those apparently OOP semantics ultimately require decidedly non-OOP machine code at the real level it is executed. Everything else is just abstraction.

Trying to argue that you are, in fact driving a steam engine, requires one to assume a level of abstraction and definition, in order to set an arena in which a discussion can occur.

	▲	pjmlp 5 days ago \| parent [-]
		Except we are talking about the layer written on top of Python, not underneath.

▲

5 days ago | parent | prev [-]

[deleted]

▲ constantcrying 5 days ago | parent | prev [-]

The talk makes a very specific complaint. That complaint is not that you are associating data with the functions operating on that data.

What the talk is about compile time (and maybe execution time in the case of python) hierarchies being structured as a mapping of real objects. This is how I was taught OOP and this is what people are recognizing as "OOP".

>So for the anti-OOP folks out there using languages like Python as an example,

Just because a language associates data with functions, does not mean that every program hierarchy has to map onto a real world relationship.

Why are you even commenting on this with your nonsense? Do you really think that if someone is complaining about OOP they are complaining that data types store functions for operating on that data? Has literally anyone ever complained about that?

▲

igouy 5 days ago | parent | next [-]

> This is how I was taught OOP …

That's unfortunate.

"The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. …

While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. …"

"Designing Object Systems", Steve Cook & John Daniels, 1994, page 6

https://archive.org/details/designingobjects0000cook

▲

constantcrying 4 days ago | parent [-]

I encourage you to listen to the talk, because it gives a very specific reason why historically that thinking about OOP was so common. Notably it was Stroustrups motivation, to allow exactly that kind of thinking to be implemented in C, which became C++. Simula was developed to allow this structuring.

>While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software.

A great line. I just wished it wasn't out shone by all the lectures, tutorials, books which explain OOP by saying "a Labrador is a dog is an animal" and then tell you how this abstraction is exactly what you should be doing.

OOP revisionism is always very surprising, because the only people aware of it are OOP revisionists, the vast majority of developers are completely unaware of it.

	▲	igouy a day ago \| parent \| next [-]
		How can it be revisionism when it's taken from Bjarne Stroustrup's 1988 paper 'What is object-oriented programming?', page 13. 6:03 -- "And what he [Marc LeBlanc] said was for some reason OOP has gotten into this mindset of compile-time hierarchies that match the domain model. …" 6:29 -- "And what he [Marc LeBlanc] is saying is like why are we pushing this? Why is that the idea, right? …" And Stroustrup's starting-point is abstract-data-types not a compile-time-hierarchy — "Consider defining a type 'shape' for use in a graphics system. Assume for the moment that the system has to support circles, triangles, and squares. Assume also that you have some classes … You might define a shape like this … This is a mess." And Stroustrup then says what he's pushing and why and when — "The problem is that there is no distinction between the general properties of any shape … and the properties of a specific shape … The ability to express this distinction and take advantage of it defines object-oriented programming. … The programming paradigm is: Decide which classes you want; provide a full set of operations for each class; make commonlity explicit by using inheritance. … Where there is no such commonality, data abstraction suffices."
	▲	igouy 4 days ago \| parent \| prev [-]
		I listened to the presenter tell us Alan Kay "kind of soured on it [inheritance]" 13:45 The source doesn't say that. I listened to the presenter tell us "… look at what they were actually talking about when they were talking about Smalltalk in the times before they had chance to reflect and say that it [inheritance] didn't work". 14:10 The source doesn't say that. I listened to the presenter tell us "… literally representing in the hierarchy what our domain model is. … They have a Path class and from that Path class they have different shapes derived from it." 14:46 Chapter 20 "Smalltalk-80: The Language and its Implementation" describes how Graphics was implemented in the Smalltalk-80 system — "Class Path is the basic superclass of the graphic display objects that represent trajectories. Instances of Path refer to an OrderedCollection and to a Form. The elements of the collection are Points. … LinearFit and Spline are defined as subclasses of Path. … Class Curve is a subclass of Path. It represents a hyperbola that is tangent to lines … Straight lines can be defined in terms of Paths. A Line is a Path specified by two points." page 400 As they say in the Preface — "Subclasses support the ability to factor the system in order to avoid repetitions of the same concepts in many different places. … subclassing as a means to inherit and to refine existing capability." I listened to the rest of part one.

▲

pjmlp 5 days ago | parent | prev [-]

What matters are language implementations and CS definitions, not layman understanding on the street.

▲

constantcrying 5 days ago | parent [-]

What a silly objection. You just made up a random argument in your head what that talk was about or what arguments are being made.

It actually does matter a whole lot what developers think. It matters far more than any "CS definition", not that anything here is about computer science.

>What matters are language implementations

No, they do not matter at all. They are totally irrelevant to the topic. In python you can construct your hierarchies to match real world hierarchies. You also can not do that. It is totally irrelevant how the language is implemented.

	▲	pjmlp 5 days ago \| parent [-]
		Education is important, otherwise people are chasing ghosts based on their lack of understanding and biased opinions.