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 -- https://mail.python.org/mailman/listinfo/python-list