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.

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]