Hacker News Reader

Comment by asragab | Hacker News Reader

Orthogonal to the article, but: "He is widely considered one of the fathers of object-oriented programming, or OOP, which at its simplest is a “if-then” programming paradigm that links data to pinpointed procedures."

I'd like to think I have read a few definitions of OOP, I have to say I don't recognize the above - what does "pinpointed procedures" mean? Also, "if-then" programming doesn't seem like a paradigm or a necessary/representative flow control structure of OOP.

To be fair, I am not familiar with Smalltalk and perhaps this definition makes more sense in that context.

View on HN

I think that the "if-then" part is a simplification of imperative paradigms.

I've never heard it described that way, but I assume the part about "pin pointed procedures" tied to data is a weird way of describing the way that methods relate to the data encapsulated by their owning object.

Ultimately, I think this is a case where someone familiar with the concept has explained it to someone who is not, who has then tried to paraphrase and, lacking any domain knowledge, summarised it in an unusual and vague way.

Actually that reads as a pretty good non-developer summary of how current object-oriented programming languages work. Give that to a business person and it would probably make sense to them.

Jonathan Rees has a "really interesting response" where he lists several of definitions of OO [0]:

"Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list.

1. Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.

2. Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.

3. Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.

4. Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.

5. Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).

6. All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.

7. Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)

8. Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)

9. Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.

So OO is not a well defined concept. Some people (eg. Abelson and Sussman?) say Lisp is OO, by which they mean {3,4,5,7} (with the proviso that all types are in the programmers' heads). Java is supposed to be OO because of {1,2,3,7,8,9}. E is supposed to be more OO than Java because it has {1,2,3,4,5,7,9} and almost has 6; 8 (subclassing) is seen as antagonistic to E's goals and not necessary for OO.

The conventional Simula 67-like pattern of class and instance will get you {1,3,7,9}, and I think many people take this as a definition of OO.

Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser."

[0] http://www.paulgraham.com/reesoo.html

This also left me scratching my head. I always think of "structured programming" when if statements are brought up, and that's purely procedural and significantly predates object orientation. I think it's a poor definition.

> a “if-then” programming paradigm that links data to pinpointed procedures.

this is an overly simplified and reduced way of describing the idea of encapsulation.

I think "if-then" is the layman's term for "imperative" in that context.

sure, it could be. OOP is basically an imperative style of programming. it defines procedures as methods of objects, rather than as stand-alone functions. in any case its the awkward use of language by a journalist without deep subject matter expertise.

OOP is basically an imperative style of programming.

lol you would have been flamed to a crisp for saying that in the 90s.

maybe I would have been, but now its 20 years later and people actually have done some OOP and they know what it is really like in practice, and are no longer just reciting the bullet points from a slide show they saw at a conference.

what are the other paradigms we usually contrast with imperative though?

Declarative style can be done with OOP but it is still implemented in an almost strictly imperative way internally within the classes implementing the interfaces. Even the gluing together of interfaces is usually done in a more imperative than declarative style with OOP. The ideal for OOP is to have declarative interfaces from top to bottom but we almost never achieve this goal in practice.

Functional style is basically not done with OOP. It's possible, and my first exposure to "objects" was in working with closures in Scheme. However, in mainstream OOP functional style is only used as part of a mixed paradigm approach. We see a lot of this in languages like Python, Ruby, and Javascript.

Aspect-oriented programming? orthogonal to the question of imperative vs. not. This style is supported naturally in almost any language that offers first class introspection of its runtime but is only popular in niche use cases.

The actor model (i.e. what Erlang does)? A subset of functional style that is designed for highly concurrent systems. Orthogonal to imperative vs. non-imperative. Each actor within a system is probably an imperatively coded procedure. The system as a whole is not.

Why am I bothering to point this stuff out? Because I want to get past the kind of shallow and limiting view that the label "imperative style" matters.

  >Functional style is basically not done with OOP.

Check out Smalltalk, it's actually more derived from Lisp than from Simula.

  >The actor model (i.e. what Erlang does)?

Smalltalk matches the actor model. A lot of people compare Erlang and Smalltalk, actually.

Reply on news.ycombinator.com