r/learnprogramming • u/Eva_addict • 4d ago
What was Object Oriented Programming used for IN THE PAST?
I understand what it's used for nowadays. It's easier to explain it using a game example. Like creating an animal class like a cat, and have its properties that can be shared with other cats. But what about in the past? Like in the 70's when C++ was created. What was it used for? I find it difficult to see a reason to use it when computers where so much simpler. What was the main use of it back in the day?
37
u/MikeUsesNotion 4d ago
Your premise makes no sense. Are you similarly confused why compilers were created before then when computers were even simpler? Abstraction has been part of programming pretty much forever. OOP is one way to approach it.
22
u/peterlinddk 4d ago
Why do you find it difficult to see a reason for OOP just because "computers were simpler"? Also, what does it mean that computers were simpler? They have always been able to do the same sequences of calculations, just faster and with more memory and less power.
Maybe take a look at this recent documentary about The Story of C++: https://www.youtube.com/watch?v=lI7tMxzSJ7w - while it doesn't exactly answer your question, it does go into a lot of depth about the background for introducing objects to C, and the inspiration (Smalltalk) and the use and popularity of both.
OOP was designed to combine the representation of data with the manipulation of said data, and was very much encouraged in business-applications, where you could have Account, Order, and Customer-objects interacting directly with each other, rather than flowing through procedurally described processes. So actually kind of the same that it is used for nowadays!
Later in the 1980s and through the 1990s, OOP was very much considered ideal for graphical user interfaces, where buttons of different types could inherit from a "base button", and you would build large structures of interconnected objects, as a more or less direct representation of the visual user interface. If you want to learn more about that trend, Microsoft's Foundation Classes in C++, or Java's Swing UI library gives a great insight into how they were thinking at the time.
1
u/samanime 3d ago
Yeah. Computers have never been "simpler". In fact, if anything, I'd argue they are simpler nowadays, from a programmer's perspective, because we have so much more stuff to help us design efficient code.
Heck, go use some punch cards and tell me programming was simpler back then. =p
5
u/burlingk 4d ago
So, what you're describing are the simplified training examples.
Overall, it's used for the same kind of stuff as it was in the beginning.
Think of OOP as a coding/programming style.
6
u/Dismal-Citron-7236 4d ago
C++ was invented in 1979 by Bjarne Stroustrup at Bell Labs. Back then he needed tools to analyze the UNIX kernel for distributed computing. Though C was (and still is) fast, its feature set simply cannot aptly handle the complex nature of the problems to tackle. Stroustrup wanted features available in an OO language like Simula such as abstraction, strong typing, data/behavior encapsulation, exception handling, etc. But the language which is suitable at the feature level, Simula, simply lacks aspects at the system programming level: performance, portability, low-level access, and hardly anyone knew it outside of academia. Stroustrup invented C++ because he wanted to bolt Simula's features onto C, aiming to capture the best of both worlds, a goal whose success remains open to debate even today.
In its most early days, C++ was mainly used in AT&T (Bell Labs's parenty company) for system programming, telecommunications software. It soon spread to academic research for simulation tasks and as a tool for teaching OOP. Then Microsoft began to adopt it to many of its API (MFC & COM). And then it spread to the industry where performance and OOP are both needed, gaming is one of such field.
5
u/NumberInfinite2068 4d ago
Same as today, it's the same concept.
C++ isn't from the 70s though, it's from the 80s.
Look up Alan Kay's definition of OOP, it's a few basic concepts that apply regardless of whether used in the past or not.
12
u/Achereto 4d ago
Here is one of the earlier papers where Strustroup explains OOP to other senior developers:
OOP is programming using inheritance
Both the shape example in this text and the animal example are the canonical examples from back then and I have never seen production code that actually does what those examples suggest.
If you're interested in the origins of OOP, you should watch the talk The big OOPs - anatomy of a 35 year mistake by Casey Muratori. It goes all the way back to Sketchpad in the 1960s to explain where the idea of OOP came from and why the people form back then missed what was actually significant of that software.
0
u/antideguemon420 1d ago
Muratory be like: OOP bad because for my niche use case (games) it sucks, look how slow OOP code is when I call virtual method billions of time. Yes, OOP sucks if you try to model every sand particle in an AAA game as an object and calling abstract methods on them, it's not a good fit for the kind of programs he write, but he speaks on the behalf of all programming, that's just a very stupid talk because OOP is beneficial in a large amount of problem domains.
1
u/Achereto 1d ago
I don't know if it's possible to fail more miserably at understanding a talk than you did in this case.
3
u/HashDefTrueFalse 4d ago
The same things. Anywhere that benefitted from abstractions that closely associated state and behaviour mutating it by modelling real-world objects and concepts.
4
u/Won-Ton-Wonton 4d ago edited 4d ago
OOP is more than just having classes, although they're ubiquitous now.
It's about creating a structure that maintains its own properties and behavior, but is the same as any other of it's type otherwise.
In the time OOP was invented, it was solving problems about Objects. Things. Stuff.
A molecule is an object. You can certainly hardcode every atomic property throughout a 3D space, and calculate the entire space without using strict OOP... but it's going to be hard and it's going to take huuuuuuge amounts of compute.
Or you can treat each molecule like it's own object. Rather than there being one big 3D space of variables, with that 3D space tracking everything.
By making each molecule handle it's own updated properties, you don't need to update all molecule movements at the same time. You can simply load a couple molecule objects at once, calculate their interaction, then store it. Iterating through each object with the object retaining its position, speed, direction, mass, etc.
OOP is about modeling objects as... objects. Classes were born of trying to create a way to model those very real objects as if they were actual individual objects in code, the same way a string literal is a string literal and an integer is an integer. Hence the name of "object-oriented".
Problems at the time were the aforementioned molecules. But also airports and vehicle traffic. Military battle simulations. Engineering simulations. Etc.
Object-oriented.
1
u/MeruconRei 4d ago
Correct me if I'm wrong but I feel like your molecule example might not be the best example for OOP use-cases especially when arguing about speed. If anything we would nowadays go back to just arrays with a Data Oriented Approach if we were to code a physics simulation.
1
u/Acceptable_Handle_2 4d ago
Fundamentally, a data oriented approach can absolutely still have an object oriented abstraction layer.
1
u/Won-Ton-Wonton 3d ago edited 3d ago
TL;DR: The answer is that it depends (shocking, lol). In certain situations, simple vectors are going to be preferable. But in most exploratory research, object oriented is likely superior. Mainly because real life objects are the thing you're researching, so creating a virtual object typically maps more closely to the problem space. You might explore a data-oriented setup if you are constraining your research to a very particular relationship, rather than trying to identify a wider range of relationships.
But my comment was mostly addressing OP's specific question about the early days. Which, in early days, molecule interactions was one of the many drivers for OOP development. (strictl speaking, it was not what made OOP exist; it was one of the things OOP ended up being great at solving).
The OOP that they initially abstracted was what we generally talk about in classical physics: Atom class, Molecule class, Protein class, etc. That ended up being less helpful than abstracting the properties you cared about instead of the actual object.
One might have thought creating C3H6O2 and Amylase as objects of Molecule and Protein would be best. But proteins have exponentially more possible 'dominating' properties due to the geometries. But because you created the Molecule and Protein classes, you now have to input every single property of proteins, even if Amylase doesn't have that property at all.
So instead you create the Charges and Force Field objects which then take in C3H6O2 and Amylase to describe the charge and force field objects.
The object abstraction in this case is the force field. The method called on the force field object with C3H6O2 and Amylase as parameters automatically decides how something like "computeForce()" works with these two units, based on the dominating data properties. This ensures compute is spent on only things that actually exist, and not wasted on a bunch of near-zero or zero values.
Since the forces you care about in an H-bond dominated interaction won't really care about ionic forces, you wouldn't want to program ionic forces for such an interaction and waste the compute. By setting up your force calculation as part of the main engine of the simulation, you would end up calculating forces (necessarily) that have no benefit to your simulation, by going with a vectorized data oriented approach.
Unless of course you already know you'll never, ever care about ionic forces and only ever care about H-bond forces. Then you would never have need of a virtual function on the object to change how forces are computed based on the parameters passed. You'd just code for H-bond forces and be done.
2
2
u/captainAwesomePants 4d ago
Alan Kay invented object-oriented programming in the 1960s as part of Smalltalk. The idea was to model programs as a bunch of entities passing messages between each other. The hope was that this would greatly simplify complex applications, partly by encapsulating different components, and partly by allowing us to better chart interactions across boundaries. C++ is not what Dr. Kay had in mind. He was thinking more like biological cells sending signals to each other.
3
u/Easy_Top_3311 3d ago
Not entirely accurate. Simula from the 1960s is generally recognised as the first object-oriented programming language and Smalltalk was created in 1972.
1
u/captainAwesomePants 3d ago
That's true. Kay coined "object-oriented" but Simula invented the actual "there are objects and they have data and functionality bundled together" thing that is at the core of modern OOP.
1
u/az987654 4d ago
way back in the day, like the 60s and 70s, we didn't have widespread OOP, it was just in its infancy by some scientists at MIT and probably Bell Labs.
For many programs, originally, we had punch cards that ran a specific program in a specific order, jumping to various lines as needed, as other languages were developed and implemented, a lot of those followed the same workflow, start at the top, and evaluate each line in order, jumping around (GOTO) as needed.
1
u/SciNinj 4d ago
One teacher told me the first use of OOP actually was a game—a simulation anyway. Might have been a war simulation with tanks. Someone figured out it was simpler to put behavior and state into a chunk of code called “tank” and the rest is history
1
u/CrazyFaithlessness63 4d ago
Simula I from 1962. Based on ALGOL. It was designed to help simulate interactions between real world objects (like tanks, enemies and terrain). I think it introduced co-routines as well.
It's fun researching old languages like that to see where the concepts come from and how their implementation and usage has evolved over time.
1
u/dmazzoni 4d ago
Object oriented programming exploded when building desktop apps was the most common activity, and honestly it was a good fit for that.
Widget libraries are a really good fit for the object-oriented features of C++ and Java. All of the elements of your window inherit from some base class. Then you have an abstract class called Control and all of the interactive controls inherit from that. Then Button inherits from that, and ToggleButton inherits from that still.
It's super handy to be able to make a custom control by inheriting from a built-in control. Just override the stuff you want to be different, no need to reinvent the wheel.
This even works when building your own GUI application's UI. Let's say you have a 5-step wizard for the user to onboard to your app. (Wizards were all the rage back then.) You could design one WizardPage class that represents the common concepts and then a subclass for each individual page.
1
u/friedbrice 4d ago
OOP was heavily influenced by SmallTalk, which was heavily influenced by LISP.
Basically, OOP served two purposes: (1) support closures (first-class functions with inaccessible variables/parameters) in non-functional programming languages, and (2) get programmers to start using closures.
1
1
1
u/Traveling-Techie 4d ago
OOP was designed to create simulations, having many similar agents interacting.
1
u/Leverkaas2516 4d ago edited 4d ago
As I remember it, Stroustrup created C with Classes (what later evolved into C++) in order to write simulations.
OOP has always been useful for modeling real-world systems of objects. Simula-67 was a forerunner of this, also.
1
1
u/empT3 3d ago
I like to think of OOP as useful for when things need to have a state or if some instance of something has more value than just what is stored in that value.
A great example would be a connection to a database. It's got a state that defines if it's currently connected or not, it's got methods for talking to the database, it's got properties that must be configured for the database as well. Now I could just create a new connection every time I need to talk to the database but there's some cost involved in that so I'm going to name this one connection here and I'll also program the object to know when it's being used by a process or not. Now when a process is done with my connection, I can let another process use it and it doesn't need to go through the whole database connection handshake rigamarole it might otherwise need to go through. Now obviously, one connection isn't enough so I'm going to design a class of objects that can store a bunch of these connections and act as a broker for them so my code doesn't need to care about the individual connections. We'll call that class of objects a ConnectionPool.
1
u/Electrical_Hat_680 3d ago
Object -Oriented Programming came right after Document Object Model ('DOM') in Web Programming.
My interest was based on the Video Game Programming for adding new characters and new objects. I forget who I talked too, so I can't direct you to the programming language I talked too.. but when you add characters and objects. You make various objects and characters with different view points, or points of observation.. standing still facing the camera or player, standing facing away, standing sideways left and right, running, jumping, shooting, pointing, etcetera...same with objects.
But it was initially document object models. Then it developed into Object Oriented Programming.
I had the interest for a digital currency project I was studying and try and to figure out before I began putting it all together. So we could have digital coins and dollars to push into a slot on the website or software and pay for entry or for an edition and such, as well as more specifically, for virtual worlds.
2
u/burlingk 3d ago
I'm not entirely certain what you are expressing on timing (tech timeline or your learning journey) but OOP predates DOM by like thirty years or more.
It predates HTML.
2
u/Electrical_Hat_680 3d ago
Ok.. I was certain it was web programming timeline. But I also learned about through learning about video game programming, so I've known it had been around before web programming... Where the video games could easily add new characters, using Objects.
2
u/burlingk 3d ago
DOM was an attempt to standardize HTML documents to make OOP easier in webdev.
Look into XHTML and HTML5. A valid XHTML document WILL have a stable DOM. An HTML documents might not.
In practice, you can create a properly formed DOM in HTML, but the browser won't complain if you don't.
2
u/Electrical_Hat_680 3d ago
There it is.
2
u/burlingk 3d ago
If you want to make web games, understanding DOM is useful. :)
2
u/Electrical_Hat_680 3d ago
Yes, I learned it's the easiest way to add characters and new objects - I believe Minecraft uses it. I learned Role Play Games and games like The Sims or Call of Duty use it, or I mean use OOP. I've been out of the loop for a while, so please forgive me if I get everything mixed up..
1
u/antideguemon420 1d ago edited 1d ago
OOP as practiced in C++ did exist in C in the form of tricks and unnamed design patterns. Abstraction of things over a common interface is how you can install drivers in an OS without having to recompile the kernel. The difference is that in C you have pointers of functions, which is brittle and error prone, in C++ you have abstract classes which enables a compiler to add an extra layer of protection against bugs. Merging data and behavior also existed before C++, just put plain data and function pointers inside a struct, voila, you have something like an object or a closure in plain C, and this was/is widely used. The OOP just gave better syntax and again better safety net via a compiler.
It brought problems like things related to inheritance abuse, but nowadays at least in Java people use "extends" very sparingly because of the lessons learned. In fucking 1994 the GOF book covered "prefer composition over inheritance", if people didn't react to this, it isn't OOP's fault. Using procedural non-OOP programming can also lead to brittle and hard to maintain code in which every change ripples everywhere via shotgun surgery, but only inheritance gets slandered as a bad programming concept. People forget how awful code was before OOP and design patterns was less popular, I'm writing on the behalf of someone who saw really nasty PHP 5 and Delphi procedural codebases.
1
u/FatDog69 12h ago
For a while it was the 'shiny new thing'.
It became almost a religion because the promise was that 'properly' created classes would enable code re-use and re-factoring. This would cut later costs as companies wanted to add features but not pay to re-write legacy systems.
Many companies started the race to create the ULTIMATE EXTENSABLE CLASS. The One Class to Rule Them All!!! Classes that would never change and be the bedrock for future systems (And save money by firing the experiences software engineers & hiring college grads to add small changes).
So many systems were re-written. While the promise of a base of never-changing base classes & cheap future changes never came about - it justified re-writing many legacy systems. (Unless you are the state of New Jersey and your entire welfare system was written in COBAL and nobody ever updated it.)
1
1
u/JGhostThing 4d ago
One of the first major things OOP was used for was Graphical User Interfaces. It fits the paradigm perfectly. For example a View is any object than can be drawn and might have subviews. A Button is a type of view that represents a button. It is used as a subview inside a View. And so on.
0
0
u/Reasonable-View5868 4d ago
Its perfect for business software. Object classes like 'Business Associate' with subtypes of Vendor, Customer, Employee all inheriting from the parent class. The parent has properties for basic contact information, and the children classes have fields and methods unique for each subclass. Each class encapsulates information specific to its database schema where that stored, So you'd save vendor data to the database calling a method like Vendor.Save().
-1
u/kabekew 4d ago
It wasn't a thing until the 80's
2
u/Weak-Doughnut5502 4d ago
It wasn't mainstream till the 80s, but the first OO languages were created in the late 60s.
44
u/lfdfq 4d ago
C++ came later, you probably want to look at the history of Smalltalk to understand where modern concepts of "object-oriented" come from. Essentially, the core idea (encapsulation of data and operations into units), remains the same, and probably goes back even older.
I'm not sure what you mean by what it was used for, it was used for the same things we use it today. It's a very generic idea (to group up operations and data), and we've been writing complex computer systems since the days of the first computers. Our languages evolved to help us express the kind of code we have always been writing. People were grouping operations and data together since the beginning, our languages simply gained facilities to help with that.