Alan kay on object oriented programming
Alan Kay coined “object oriented program”, though many of the ideas came before.
Some choice quotes:
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).
This is a great quote, as it is quite different from what popular OOP languages do. But there is another facet:
I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, and that “<-“ would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures.
So, what about OOP today? Its about data encapsulation, that second idea. Message passing, representation of relationships, etc, are all parts that have been modified by the three principle OOP styles:
- Actor based
- Class based
- Prototype based
The most common implementation of this is Class based programming. Class based programming predates Object Oriented programming, as it was introduced in 1969 in Simula.
Classes are a way to define a type, to classify, and to build a taxonomy – that one class has relationships to other classes. It is called different things in different languages. The underlying idea can be desecribed as a type that describes a set of data relations. That banana you are getting belongs to that gorilla, who lives in that particular forest.
However, this isn’t the only way to encapsulate data. Maybe, the data you are working with and its relationships are maliable. You can also do prototypical programming. The same concept of the banana held by a gorilla in the forest applies, but you can swap out the gorilla for an orangatang, and the forest for a jungle, and if you want – the banana for a plantain.
Class based programming is more rigid, making it slower to program in. But it is highly maintainable. You know that it will always be a gorilla holding that banana.
prototypical programming is more flexible, fast to prototype in. But it is more difficult to know what you can be certain of.
Notes mentioning this note
There are no notes linking to this note.