* chuck everything vaguely related in a class
* share code by using inheritance
IMHO, the way Java and C++ have been taught (in practice, if not by teachers) has done a disservice to OOP. So much so that many programmers now don't consider languages to be OOP unless they have the class keyword and inheritance.
If a language doesn't support inheritance, in what sense is it an object-oriented programming language?
It's true that you can use OOP principles in languages that don't have language-level support for OOP. The canonical example of this is the GObject library for C. That doesn't tell us how we should use the term object-oriented programming language though. I don't see why we'd use a more expansive definition.
The big difference I see between Elixir and (example) Java or Ruby is that everything is an object in those languages but a big Elixir application has only a few GenServers, where keeping a state matters. Everything else is passed as argument, which by the way it's what a GenServer does internally with an endless tail recursion.
If you look at the entire breadth of OO languages and see what they have in common, there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.
(Certainly moreso than something like C++, which wouldn’t look out of place on a Melanesian island. Never could figure why C++ and all its typed kin would choose to dispatch [dynamically] on only one argument instead of on all. Playing to their weaknesses, no?)
I imagine some syntax sugar to help with the delegation to make it less cumbersome.
Just take what you believe is the better definition of OOP and rebrand it.
The very name of this site is a powerful argument to the contrary. Slashdotters initially dissed it, saying the word "hacker" (as in coder or builder as opposed to criminal) should be retired. Now the older sense of the word is widespread enough that people halfway around the world are aware of hackers in the sense that PG named this forum. Indie Hackers is only further cementing the reversal of the trend that once appeared inevitable.
What most people think of when they think OOP is C++, Java, and Python which got OOP completely wrong and ruined our perception of OOP. They also tried to use their misshapen OOP hammer on every problem they could find to the point that it’s an overused meme. These days you see languages actively trying to distance themselves from OOP as a form of enticement (Rust and Go being the two prime examples).
They definitely distance themselves from inheritance. However both Rust traits and Go interfaces look to me like they're there to appease people who like the .method() calling syntax. (I know there's more to the story than that, particularly for Rust and its type system...) I think either could've gone with multimethods or overloaded functions and have been better for it, but a lot of people seem to really like the object.method() look.
There’s a pretty simple reason for that: autocomplete.
In most halfway decent dev environments, typing “object.” will present you with a list of possible operations on that object. OTOH, if you want to do “method(object)” you need to know the method name (in all current scopes, including globals).
I’m not saying this is the only or even best way to write code, but it’s definitely a factor IMHO.
I don't think this is true. Objects can message themselves as part of base-class code; implementation inheritance means that this has to involve a level of indirection and dispatch, not just explicit delegation.
or maybe Erlang is its own thing and OOP -as what most people are thinking when talking about it- is the set of practices followed in languages descended from the cross between C and Smalltalk.
This explains how every introductory course in OOP using either Java, C#, Python, etc. will list some sort of OOP principles always including something along "objects talk to each other though message passing" which is hand-waved simply as something to do with taking other objects by ref
// taking a reference
bar.someMethod(foo)
import Foo;
class Bar {
someMethod() {
// init the import
foo = new Foo()
// ... do something with it
foo.someMethod()
}
}
It is a matter of actually learning about OOP concepts in general, and Kant features in particular.
Swift's protocol oriented programming actually goes back to Objective-C protocols, Java's inspiration for interface types or Smalltalk traits (post-Smalltalk-80).
1) An object is a poor man's closure; and a closure is a poor man's object.
2) Most object-oriented programming is done with mutable state, which muddles what OO is. You don't really need state to have objects.
In a closure, the lexical scope is preserved, and the functions defined in it can access it any time. This is very similar to what an object does: https://stackoverflow.com/a/2498010
When objects are immutable, one gets to truly appreciate the elegance of grouping both data and their functions together: https://dev.realworldocaml.org/objects.html#scrollNav-3
"Having state" often implies mutability, i.e. to be in a given state means the same thing can be in different states/configurations as well.
On the other hand people often also use the word "state" to refer simply to a "current state" of something at a given time, and then under this interpretation there is state in immutable objects.
As you already know, "representing (real world) state at some step/time" does not require mutability on the language level. These immutable objects are state snaphots of a hypothetical mutable object. Operations on them cannot mutate them, but instead derive a new snaphot that represents the new state at a given time after the operation. So working with those snapshot does represent state and state changes and models real world state, but the individual snaphots/immutable objects cannot be mutated.
Whether those immutable objects deserve the monicker "object", I don't really have a opinion on, but I wouldn't outright deny it.
Are they useful in similar ways that mutable objects are? I'd say so.
Immutable objects can still get you polymorphism/subtyping and encapsulation, features often ascribed to object oriented programming.
But the components were completely encapsulated. Black box, no source code, no inheritance. You could argue the same for services today. Services are software ICs, you can call them objects it whatever you like but they achieve Brad Cox's objective, which is all that matters. (It's just a pity that people think that a service/component has to run in a separate process always, unlike VB)
There were always APIs but they're still parts with an exposed interface - now just distributed over the Internet "as a service".
Almost everything except C has web loadable modules and online docs (analogous to IC data sheets in retrospect!) at this point, whether it's Perl's CPAN (going back to 1995) or Gems or MVN or whatever through obvious L-Pad disasters and now containers and various Hubs.
edit. What we didn't dream of when the Byte Smalltalk issue came out (should NOT have tossed mine :-) was the implications of networked module repos. Add one or two lines of code and the system goes out and gets a standard module and wires it in for you. This was not on the menu for people shopping for 74xx at Radio Shack and Digikey.
1) Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean
https://www.washingtonpost.com/news/speaking-of-science/wp/2...
OOP is a difficult to judge because it became such a big envelope. Alan Kay famously said in 1997 "I invented the term Object Oriented Programming, and this [C++ and Java] is not what I had in mind."
He would later even tell the Smalltalk community that even that wasn't spot on, only an early step, to what he was really after in his visionary's quest that would create a DynaBook that would increase world peace (visionaries always reach big).
In my own journeys, my own personal conviction came to be that the "paradigm shift" with the OO movement was to learn to bind behavior to data. This (IMO) fits Kay's ideas about cellular biology and the inspiration he embraced with his ideas. It's all about binding behavior to data.
Everyone should read that byte magazine (because apparently 500+ pages was a magazine), especially Peter Deutsch's section on block closures. Smalltalk did more with closures than any other language I've used since. Because closures are objects too.
One issue that Szyperski's book examined was the composition model (i.e. object model: COM, CORBA, JavaBeans, etc) used for defining interfaces between software components and how those interfaces can be composed. The idea of standardizing interfaces and composition mechanisms does not get so much attention today. It seems that things are currently balkanized into language communities, each doing their own thing.
The industrial manufacturing concept of "interchangeable components" comprises of two things: (1) standardized specifications, (2) multiple independent manufacturers who are able to independently implement specifications. We do have this kind of practice in, for example, the specification and implementation of the C++ standard library. But that's not how most software is developed, and it is commonly held that it is not how most software should be developed. On the other hand, we do have "component reuse" in the form of software libraries -- but the interfaces are unique and idiosyncratic to each library, not standardised, and there is usually a single "manufacturer".
I think it's mostly a market failure. The units of trade were complete software products and/or services/apps these days. Mostly because that's what the end users actually see on the desktop, the atomic unit of software is huge and perceptible.
Once upon a time, it looked like it could be different. Component-oriented systems arose. COM, CORBA, CommonPoint, Taligent, D'OLE etc. (Heck, one might even argue for Amiga filetypes and embedded X windows to belong in the same category)
But apart from UI Widgets (ie. windows controls for VS or Delphi), it never seemed like there was a marketplace for it. It also was quite hard to sell to managers, as it's something you can't put in a box or have a big trademark for it.
So we ended up with fast food joints and black-box-systems, no ICs, condiments, recipes etc.
Open Source could've been an answer/alternative, but the OSS world mostly copies stuff from the programmer's day jobs.
(Gnome actually started out with CORBA and KDE had some component structure, too, but that doesn't appear to be anyone's focus, compared to copying notifications and doing flat redesigns)