Objects are just the poor man's actors. If you want to see what encompasses objects and more, look up the actor model.
That's what I thought this article is going to talk about but not even a honorary mention.
When objects are not enough (2021)
51–58 of 58 posts
Re: When objects are not enough (2021)
#52I enjoyed this post a lot. I happened to blog about the same thing from the FP side of things [1] (well, because Closures are just the poor man's Objects).
Generally, I don't know how to (philosophically) navigate the tensions between Functional / Object Oriented / Imperative / Declarative paradigms, except to remind myself about The Thing That Actually Matters (in my estimation)... to always remember that The State is the frenemy.
For the love of State is the root of all evil: which while some coveted after, they have erred from Lambda the Ultimate, and pierced themselves through with many sorrows. --- Yours Truly.
:)
[1] https://www.evalapply.org/posts/what-makes-functional-progra...
(edit: forgot to link to blog post)
Re: When objects are not enough (2021)
#53Earlier quoted context omitted.
> My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number). Are you storing the version as part of the object? If so, they’re no longer equal values regardless of identity. If not, what purpose is there in versioning the same value? Even if there is a purpose, are same-…
Identity doesn't imply 'value' equality, that's the whole point of mutability! Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.
> Identity doesn't imply 'value' equality, that's the whole point of mutability!
That’s exactly the point I started with!
> Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.
Agree completely. My point—my only point—was that identity implies mutability. Without mutability, identity distinct from value doesn’t mean anything.
Re: When objects are not enough (2021)
#54Earlier quoted context omitted.
But then you'd have other problems that come with using another paradigm, since there's no silver bullet, and no paradigm that handles all problems better than other paradigms. Probably popular languages tend to be multi-paradigm.
That's not really true. Structured programming completely supplanted the paradigm that predated it. I think it's pretty close to a consensus now that null values are a mistake. Same with manual memory management.
Programming paradigms meaning imperative, functional, logical, OOP, stack-based, array-based, that sort of thing.
Widely used languages like C++, Javascript, Python allow for a mix of those approaches. If one programming paradigm was best, we'd expect languages like Haskell, Prolog or APL to be popular instead.
Re: When objects are not enough (2021)
#55What works for me:
There are two types of objects: State objects and Tool objects.
The purpose of a State object is to maintain a state. Think strings, databases, files etc.
The purpose of a Tool object is to operate on State objects. Think loaders, printers, editors, transformers etc.
It’s a simple way to organise OO code. And it works. At very large scale (millions of lines of C++).
It is similar to the functional Data/Function thinking. However it actually works better because State objects can enforce constraints, and Tool objects can cleanly maintain an internal temporary state while operating on State objects.
Re: When objects are not enough (2021)
#56Earlier quoted context omitted.
It's not a requirement, but an immutable object has fewer uses than a mutable one. Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.
Object identity effectively implies mutability. Without that implication, two objects of the same structured value being non-equal doesn’t mean anything (and would probably be better classified as a mistake). Another way to look at it is that property setters (or whatever mechanism is used to directly mutate an object’s sub-data) is not meaningfully different from a method doing the same. You could even call it synta…
This point is actually emphasized strongly by the CS giant, Guy Steele himself.
Re: When objects are not enough (2021)
#57Earlier quoted context omitted.
That's not really true. Structured programming completely supplanted the paradigm that predated it. I think it's pretty close to a consensus now that null values are a mistake. Same with manual memory management.
Programming paradigms meaning imperative, functional, logical, OOP, stack-based, array-based, that sort of thing. Widely used languages like C++, Javascript, Python allow for a mix of those approaches. If one programming paradigm was best, we'd expect languages like Haskell, Prolog or APL to be popular instead.
The contemporary "multi-paradigm" style is influenced by the many paradigms which preceded it, but for all the elements it borrows, there are elements it leaves behind, too. Implementation inheritance is often left out of newer languages (see Rust, Go). I don't think it makes sense to view new langauges and styles as the sum of all preceding paradigms. It's an evolutionary process, rather than accretive. We keep the good bits and discard the rest.
Re: When objects are not enough (2021)
#58Earlier quoted context omitted.
Why would a type ever own another type? What would that even mean? Like an inner class? Or are you taking about ORMs?
Think about a collection of one related type on another, such as Customer -> Accounts + Account -> Customers. In banking, it is possible for one customer to have many accounts, and for each account to have many customers. OOP will let you express this kind of problem from a data modeling perspective (List on each type), but from a serialization and dependency perspective you have to pick a "winner". In banking, it is…
> OOP will let you express this kind of problem from a data modeling perspective (List on each type), but from a serialization and dependency perspective you have to pick a "winner". In banking, it is unclear which type should be king.
Serialisation is not necessarily a big deal, just pick one and refer back to it — check out PRINT-CIRCLE, Sharpsign Equal-Sign and Sharpsign Sharpsign in Common Lisp.
For dependencies, I think this only matters with strong type systems which don’t support forward declarations, or which lack null references/empty containers (if the language does support that, just create one object without any references, create the second, then add the second to the first).