This lesson was translated automatically – it may contain errors.
The answer to the software crisis was OOP: first Simula 67, then Smalltalk. Why bringing data and behaviour together turned out to be such a good solution is covered in the later modules of this course – for now what matters is where the idea came from and how it became the standard.
Plenty of unfamiliar terms ahead – that is intentional. What matters now is seeing what these languages brought; each concept gets its own treatment in the modules that follow.
Simula 67: class, object, inheritance
1967 Ole-Johan Dahl and Kristen Nygaard, Norwegian Computing Center
Simula was not written for the sake of «beautiful code», it was written for simulation: queues in a port, flows of customers, processes on a factory floor. Such a task is naturally described in terms of entities – a ship, a berth, a customer – each with its own state and its own behaviour. That practical need is where the notions we still use today came from:
- class and object – the description of an entity and a concrete instance of it with its own state;
- inheritance – a new class as a refinement of an existing one, without copying its code;
- virtual methods – a subclass replaces the behaviour and the calling code never knows; polymorphism grows out of this later;
- coroutines and garbage collection – nothing to do with OOP as such, but they appeared here too.
The key point: data and the procedures that work with it live in one place for the first time. Exactly what procedural code was missing.
Smalltalk: everything is an object
1972 – 1980 Alan Kay, Dan Ingalls, Adele Goldberg, Xerox PARC
Simula added objects to a general-purpose language; Smalltalk went further and built everything out of them. Alan Kay also coined the term «object-oriented programming» itself – and by it he meant not classes but messages exchanged between independent objects.
- the object is the only unit: numbers, symbols, classes themselves – all objects;
- messages instead of calls: you send an object a message, and how to answer it is the object’s own decision; hence late binding and dynamic typing;
- encapsulation with no exceptions: an object’s state cannot be reached other than through its own methods;
- an environment, not a compiler: the system is alive as a whole, code is edited and restarted on the fly. MVC was born in Smalltalk-80 as well.
The languages we write in today took a bit from each: classes and inheritance from Simula, live objects and late binding from Smalltalk.
From a research idea to the industry
What made OOP the industry standard was the 1990s and the dot-com boom. Most businesses moved onto the internet, and the workhorses of that new economy were C++ and Java.
It was not a matter of fashion: objects gave procedural code what it had been missing – scale. A system could now be cut into parts, each understood and changed on its own, and those parts assembled into products no single person will ever read in full: operating systems, databases, browsers, banking software. That is exactly how the crisis of the 1960s was solved.
The community liked the paradigm so much that virtually every mainstream language of the 1990s and 2000s was built on it. Architectural styles and design patterns – the subject of the last module of this course – grew on the same ground.
Why this is worth remembering
OOP was not invented as «the right way to write code». It appeared as a tool against a specific problem: a program could no longer be held in one head, because the data and the procedures working on it lived in different places and changed independently.
Keep that reason in mind while working through encapsulation, inheritance and polymorphism: each of those mechanisms solves its own part of that same problem.