Python was designed (was Re: Multi-threading in Python vs Java)

[Steven D'Aprano]

On Fri, 18 Oct 2013 22:26:02 -0700, rusi wrote:

> On Saturday, October 19, 2013 2:02:24 AM UTC+5:30, Peter Cacioppi wrote:
>> 
>> I still say that object-based is a distinct and meaningful subset of
>> object-oriented programming.
> 
> Yes that is what is asserted by
> http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/
Wegner87.pdf
> -- a classic though old reference

The truth of a definition is not really something that is amenable to 
proof, only to agreement. In my experience, there is no widespread 
agreement on what the terms "object oriented" or "object based" 
programming mean. I expect that most people would consider them synonyms, 
or might consider the first to have some vigorous meaning while the 
second is just an informal term for a language that in some sense is 
based on objects in some way.

Even if we agreed that there was a distinction between the two -- and I 
don't think we do -- there is certainly no agreement as to what that 
distinction actually is. There are far too many mediocre programmers with 
limited experience outside of their narrow field who assume that whatever 
sliver of C++/Java/Python/whatever that they learned is the One True 
Definition of object-oriented programming. And too many academics looking 
for hard boundaries between concepts which, fundamentally, exist in a 
continuum.

It's all just part of the human tendency to pigeon-hole. According to 
some, Java, which has many low-level machine primitive types, is an 
object-oriented language, while Python, which has no machine primitives 
and where every value is an object, is not. Explain that one, if you can.



[...]
>> It's an important distinction, because a project that is constrained to
>> C should (IMHO) target an object-based design pattern but not an
>> object-oriented one. That said, I'm open to disputation-by-example on
>> this point, provided the example is reasonably small and pretty. (If
>> the only polymorphic C code is ugly and non-small, it sort of proves my
>> point).

Define ugly :-)

One of the reasons multiple languages exist is because people find that 
useful programming idioms and styles are *hard to use* or "ugly" in some 
languages, so they create new languages with different syntax to make 
those useful patterns easier to use. But syntax is not everything. 
Whether you write:

object.method(arg)    // Python, VB, Ruby, Java
object#method arg     // OCaml
object:method arg     // Lua
method object arg     // Haskell, Mercury
object method arg     // Io
object->method(arg)   // C++, PHP
method(object, arg)   // Ada, Dylan
send method(arg) to object  // XTalk family of languages


etc. does not really change the fact that you are calling a method on an 
object, despite the change in syntax. Even Forth has frameworks that let 
you write object-[oriented|based] code using a stack and reverse Polish 
notation syntax.


[...]
> Just as the study of algorithms arose out of a desire to study program
> efficiency but with the nitty-gritty details of machines abstracted
> away, in the same way programming language semantics arose in order to
> study broad classes of languages with details hidden away.

I don't think that programming language semantics arose so much in order 
to *study* languages, more to *program*. Programming languages pre-date 
the study of programming languages :-)


> Unfortunately, even after 50 years of trying, semantics has been a
> dismal failure in defining the what and where and whither of OOP. In a
> sane world this would have signified that perhaps OOP as a concept(s)
> needs to be questioned. Considering that the opposite has happened --
> programming language semantics as an area has become distinctly
> 'old-fashioned' and not-so-respectable-- I can only conclude that the
> world is not sane.

All the words are in English, yet somehow I can't quite make sense of 
this paragraph. You seem to be using "semantics" in a way that doesn't 
quite make sense to me. To me, "programming language semantics" is the 
*meaning* of code: "var = func(arg)" is the syntax, "call func with arg 
and assign the result to var" is the semantics. What do you mean by it?


> Well the tide is slowly turning -- here's a growing bunch of people
> questioning the validity of OOP:
> http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

*Criticism* is not the same as questioning the validity. Certainly I can 
criticise OOP:

- if you care about machine efficiency, shoving small ints into a bulky 
object wrapper is bad for machine efficiency;

- ravioli code is to OOP as spaghetti code was to BASIC;

- large, deep object hierarchies are complex and hard to understand and 
learn;

etc. But then I can also criticise functional programming, declarative 
programming, imperative programming, logic programming, etc. There is no 
One True Programming Paradigm suitable for every task, just as there is 
no One True Programming Language.

 
> Of these I find two noteworthy:
> 1. Stepanov who is next to Stroustrup in C++ circles, calls OOP a hoax.
> 2. Carnegie Mellon university has eliminated OOP as "unsuitable for a
> modern CS curriculum"

I can't imagine what Stepanov means by calling OOP a hoax. It certainly 
exists. The fact that he equates it with AI as a hoax speaks more about 
him than about OOP -- AI is quietly and without fanfare changing the 
world. It's not just showy, high-profile stuff like the fact that the 
best chess masters in the world are now machines, but little stuff, often 
astonishingly important, that people don't necessarily associate with AI:

- autonomous weapons
- natural language parsing
- speech recognition
- data mining

etc. I think what happens is that whenever AI leads to progress, some 
people redefine that area as "not AI". Or they presume that anything less 
than HAL or 3-CPO means AI is a failure.

As far as Carnegie Mellon University, in isolation that doesn't say much. 
It could mean that they've decided to shift to more academically 
fashionable languages, like Mercury and Haskell; or it could mean that 
they've decided that the business of "a modern CS curriculum" is to churn 
out as many half-trained PHP monkeys as possible. (Substitute Java for 
PHP, and that's the philosophy of a lot of CS departments.)

Sure enough, reading the quote in full, the answer is that they've 
shifted to teaching functional languages, which is great for academic 
rigor and not so great for either programmer productivity or machine 
efficiency.


-- 
Steven