>A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns.

sorry, but this is no true Scotsman fallacy. All these "bad implementations" is OOP, real OOP, not some idealized ephemeral non-existent Avalon. If an idea easily and more frequently than not lands itself to the bad implementations then there is something wrong with the idea. (I happen to come from a country which was pursuing what was looking like a pretty good idea - communism - which has got a lot of bashing during recent decades, due to "bad implementations" i guess, and as result it was critically rethought and now we know what it is not a good idea really)

In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.

I was taught OOP using Modula-2 in 1989, by defining structures and functions that took a pointer to the struct as first parameter. No inheritance goodies! I used that style in C until 1996 when I definitely moved to C++. Probably why I am not terribly dismissive of OOP but very much of things like inheritance trees, the Java OOP style, and the overuse of GoF in architecture, literature and especially programming discussions.

How would you design something like :

Person --> Full Time Employee --> Manager

Person --> Contract Employee

Without inheritance assuming that salary calculation is the only thing which differentiates them.

Something like...

   Person HAS A IEmploymentRelationship
   ContractEmployment IMPLEMENTS IEmploymentRelationship
   FullTimeEmployment IMPLEMENTS IEmploymentRelationship
   FullTimeEmployment HAS A IDirectReport
   Manager HAS A Person
   Manager IMPLEMENTS IDirectReport

And then salary() is a polymorphic function declared by the IEmploymentRelationship interface, where FullTimeEmployment instances use the manager somehow, and ContractEmployment doesn't.

You can even put some sugar on that by having a salary() function on Person that calls the salary() function on its IEmploymentRelationship—but I wouldn't, for the same reason I wouldn't denormalize a relational database.

Got it. Thank you.

In Ada, I remember reading that you can limit the inheritance depth.

If we redefine the word "OOP:object" to mean process-with-mailbox, and redefine the word "OOP:message" to mean asynchronous message passing, then objects and messages make sense and are useful.

Those are not Smalltalk's definitions -- even though I think you're right on about Alan Kay's original inspiration -- and confusion can arise if we redefine terms.

It seems to me that you can't really do message passing in most languages with high efficiency? (Objective-C and Swift being the exceptions.)

Rather the opposite. Almost all HPC (high-performance computing) systems use message passing and not shared memory. The fastest and imho best unix-like kernel L4 is entirely MP based.

So if you want to embrace high performance (and concurrent), go message passing. Alan Kay's favor of late binding does not help performance, as method lookup at run-time dominates the cost then, but the fast systems are early bound, i.e. typed.

Well, you are discounting CUDA, which has been seen as suited for many tasks when compared to MPI. Of course, you can use MPI and CUDA together (people are working on that), which you then have messaging between nodes and shared memory (via GPU-style SIMD) within.

Of course, you are probably referring to NUMA, but people still actually use that.

Pure OO isn't very much desired in the HPC world, but then neither is pure FP.

I think it's a bit charitable to call what Objective C does to be "message passing". The messages are not asynchronous and have only a single recipient, so in practice I would say they're method calls with late binding.

However, they can easily be made asynchronous and address multiple recipients. See Higher Order Messaging[1][2], first implemented in Objective-C[3]. So for example:

    [[myView onMainThread] setNeedsDisplay:YES];

    result = [[someObject future] someMessage:arg];

    combined = [[prefixes collect] stringByAppendingString:[suffixes each]];

The reason this is easy in Objective-C is because its brand of message passing is just (barely) powerful enough to qualify as message passing. In fact, if you squint just a little, you can see it as fully reified message passing with the common-case (a synchronous method is invoked) optimized.

[1] http://en.wikipedia.org/wiki/Higher_order_message

[2] http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS...

[3] https://github.com/mpw/MPWFoundation

At least you can redirect messages to another recipient, and write a handler for "unhandled messages." Impossible with c++, at least with standard method calls.

You can do one-to-many messages via notifications, though it's less elegant.

Alan Kay may have coined the term, but OOP (as any other word or term) is what people believe it to be. Which is pretty far from CSP.