

Alan Kay on the Meaning of “Object-Oriented Programming” (2003) - siteshwar
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

======
robert_tweed
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.

In fact, the origins of OOP are basically what we would now call microservice
architecture (CSP-inspired languages like Go being a specialisation of this).
Each service can be as stateless or as stateful as it needs to be (without
shared state) and services should be loosely coupled.

That's quite different to most large-scale OOP architectures, but it is
possible to code in that style in any OOP language.

Heavy reliance on inheritance for code reuse is a whole problem class in
itself that again has little to do with OOP and lots to do with the influence
of C++.

~~~
alan82
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.

~~~
thewarrior
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.

~~~
derefr
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.

~~~
thewarrior
Got it. Thank you.

------
vishnugupta
"OOP to me means only messaging, local retention and protection and hiding of
state-process, and extreme late-binding of all things. It can be done in
Smalltalk and in LISP. There are possibly other systems in which this is
possible, but I'm not aware of them."

Such a pity that this filtered essence about OOP was lost on me during
formative years of learning OO-programming; for no fault of mine! It took me
half a decade into professional programming in Java to realize the importance
of these key concepts.

And the worse part is that most of the books/blogs start OO programming
tutorial with examples that try to literally model the problem state using
Objects (e.g., "Animals", "Shapes" etc.,).

I guess tutorials, classes just focus on these key goals and show how concepts
such as "polymorphism", "inheritance" etc., are work towards achieving (or
not) them. What generally happens is that one is taught about all these
peripheral concepts and students are left to wonder the problems they are
trying to solve.

~~~
swalsh
Those examples worked really badly for me too. It wasn't until about a year
after I got my first paycheck for writing code that I made this switch in my
mind. My thought process started out something along the lines of "ok, i just
need to get all these things in line... somehow... and then I can accomplish
the goal". However at some point I realized, I did some similar things quite
often, and I needed to make some piece of code kind of generic. My mindset
kind of changed dramatically. Instead of thinking about how I could make
something work, I started to think of how I'd like the API to look. How could
I make the code reusable. I thought about the perspective of another dev using
the code rather than the goal itself, since that eventually became the easy
part.

Once you start thinking in terms of the API, and how you can design it so
someone with minimal documentation could still use it (though you still
document it!) you start wanting to hide the implementation etc, and all the
other OOP ideas fall into place.

of course, I don't think it's something that can be taught. It's an evolution.
When you first start programming, everything is unknown, so you don't have the
brain power to focus on design. When you learn more, and you free up brain
power you can start concentrating on these other things.

------
jayvanguard
"OOP to me means only messaging, local retention and protection and hiding of
state-process, and extreme late-binding of all things."

Bam. That is it right there. Java really messed this up.

Strong static typing and OO is an abomination.

~~~
wellpast
So what specifically about __OO __gets so much better as soon as you take
types away? Can you give a specific improvement?

~~~
Jare
Ability to change or replace object instances (maybe with instances of
different types) on the fly could be an example. In general, you can design
incredibly dynamic and reconfigurable systems. Whether you want to or not, and
at what level should you stop doing it, is certainly a good debate to have.

~~~
backlava
If the system you are building makes sense, there is probably a reasonable
type system that shows it to be well typed.

~~~
Jare
Yeah, "makes sense" and "reasonable" would be criteria involved in the debated
I mentioned.

------
pfraze
Towards the end:

    
    
      But just to show
      how stubbornly an idea can hang on, all through the seventies and
      eighties, there were many people who tried to get by with "Remote
      Procedure Call" instead of thinking about objects and messages. Sic
      transit gloria mundi.
    

Can somebody explain to me what distinction he's drawing here? What's the
issue with RPC that's solved by Objects+Messages?

~~~
Joeri
A remote procedure call blocks on the response, ensuring the system is only as
strong as its weakest link. If every object communicates asynchronously with
every other object, using messages instead of shared memory (hence avoiding
locking issues), the design by necessity evolves in ways which becomes more
robust and easy to scale. Synchronous RPC calls encourage unscalable and
unreliable architectures.

~~~
jcrites
All remote calls must have a timeout. The lack of timeouts in certain RPC
implementations was an implementation weakness, not a conceptual one.

[Edit: I've removed most of my original comment since it pertained to
messaging between machines, rather than within an application.]

------
davidw
I wonder what he thinks of Erlang, as it's very much about message passing,
hiding of process state, and late binding. Of course, this is built at a
higher level and it's not turtles all the way down: you don't send messages to
numbers to do basic math.

~~~
edgurgel
He will be here: [http://www.erlang-factory.com/sfbay2015](http://www.erlang-
factory.com/sfbay2015) . Hopefully he will share his thoughts.

------
agumonkey
@previously (1272 days ago)
[https://news.ycombinator.com/item?id=2628897](https://news.ycombinator.com/item?id=2628897)

------
cesarbs
> I wanted to get rid of data.

What exactly does he mean by that? How does one get rid of data?

> The B5000 almost did this via its almost unbelievable HW architecture.

I've heard about the B5000 numerous times here on HN. What was so fantastic
about it?

~~~
tim333
[http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000](http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000)

------
jonahx
>My math background made me realize that each object could have several
algebras associated with it, and there could be families of these algebras

Could someone explain what he meant here?

~~~
tailrecursion
For example an automobile can be thought of as an emitter of pollution, if
your problem concerns pollution, or, it can be thought of as a particle, if
your problem concerns traffic congestion.

The auto "fits" into each of these different problem domains.

~~~
jonahx
Thanks for the reply, but I'm still not seeing the connection to algebra?

~~~
jfarmer
He means "algebra" in the "universal algebra" sense of the word:
[http://en.wikipedia.org/wiki/Universal_algebra](http://en.wikipedia.org/wiki/Universal_algebra)

That probay doesn't clarify the connection, but at least you'll be pointed in
the right direction! :)

------
read
Why Alan Kay came up with object-oriented:

 _I wanted to get rid of data._

 _I didn 't understand the monster LISP idea of tangible metalanguage then_

~~~
abecedarius
He said he did understand before he created Smalltalk.

~~~
read
Can you point to the sentence where he said that?

~~~
abecedarius
First sentence of the next paragraph.

~~~
read
Thanks. I still find it fascinating people do good work without fully
understanding an area. It's as if you're not supposed to. I wonder if this
could be used as a guiding principle in making things.

If what you are working on originally looks understandable, you should be
alarmed.

~~~
fsloth
I presume by 'understanding an area' you mean being familiar with established
abstract models of that area? I think that often in practical conditions the
abstract models are not the area under work. They are the _mapping_ of the
area to some formal system. And that the 'area' under question - whatever it
may be - can be mapped to an infinite amount of formal systems. For lots of
practical purposes, there is some 'obvious' algebra of a thing one wants to do
- in these instances all that is needed is an individual who can map the
problem to any logically coherent structure, even just a private one in their
head, and a willingness to solve the problem - and great stuff can ne done
without a literature review. Sometimes the establishes models are really,
really good since they either simplify a messy looking problem and/or point
out to some not so obvious aspects of a system at which point an expert in the
field can have an advantage over the clever layman. I think sometimes the
knowledge of existing formal models can make a person blind to certain facets
of the system they are working with.

Also, if one approaches a thing by a burning desire just to implement one
single thing on top of it they will probably have an internal model that is
very much focused on the problem they are solving.This practical need can
induce them to create a new formal model or just sidestep lots of non-issues
that would be a burden to deal with.

