4 ms·
I think Alan Kay himself has suggested that what he really wanted when thinking of OOP was something more akin to the Actor model as espoused by Hewitt and real
by faichai 6y ago
I think Alan Kay himself has suggested that what he really wanted when thinking of OOP was something more akin to the Actor model as espoused by Hewitt and realised by Erlang and to a lesser extent Scala on the JVM.
This model gives full benefit of FP at the actor level whilst being realistic about distributed messaging semantics.
I’ve always felt that it would be interesting to research processor cores that could better exploit the assumptions in this model, and this would be the future of both multi-core and distributed computing. Actor message queues would be in hardware, there would be opportunities to reduce context switching overhead between actor activations, memory models would be more fine grained, capability based security would be ingrained.
- Rochus 6y agoHave a look at the paper. It's actually one of its conclusions that Simula had active objects even in 1961 and also in the OO version 1967, but for some reason this aspect didn't make it into the concept generally envisioned by OO today.
- to11mtm 6y ago> I think Alan Kay himself has suggested that what he really wanted when thinking of OOP was something more akin to the Actor model as espoused by Hewitt and realised by Erlang and to a lesser extent Scala on the JVM. > This model gives full benefit of FP at the actor level whilst being realistic about distributed messaging semantics. It's interesting you bring that up; I normally am very much on the 'Use interfaces and Dependency injection instead of inheritance' camp. And yet, When I work with Actor Model frameworks (Mostly Akka/Akka.Net) I find places where using some simple inheritance is insanely powerful yet intuitive. You wind up getting something in-between OOP and AOP with the results.
- moocowtruck 6y agohave some examples?
- valenterry 6y agoI think so too. FP does not work over a distributed system, because it requires to view "the world" in one chunk. But that does not scale. Using actors is a great way to chunk the worlds into smaller parts, each of which can then be handled in fully FP manner.
- alquemist 6y agoIt depends on what the meaning of the word 'scale' is. Analytics is definitely using a ton of FP-flavored computation at gigantic scales. The #1 principle of FP is the insistence on computation with no side effects. Relational algebra (SQL, MapReduce, Linq, etc.) is adhering to this principle, making it arguably the most successful application of FP, running some of the largest computations on the planet.
- discreteevent 6y agoThe parent wasn't talking just about scale, but distributed systems at scale. You could argue that making a call to a db is a distributed system but that is usually not what is meant. FP without side effects is excellent for transforming immutable data. History is by definition immutable so it suits that. It doesn't fit quite as well with a distributed system that has changing state, where the current state of the system is the primary concern for users.
- alquemist 6y agoObviously. Yet the 'FP doesn't scale for distributed systems' is too broad. MapReduce / Flume / Spark / BigQuery are distributed systems. What he probably meant is one can't use pure FP for OLTP at scale. This is again a bit too broad, as most systems benefit from having a FP 'business logic' core with some mechanisms to integrate with the rest of the world. Often times distributed systems are build of purely functional layers talking RPC with the lower layers. Even Erlang, the canonical example of 'we really meant actors when talking about objects' is heavily functional in its design. For reference, I use FP as in 'eschew mutable state', and not 'let's use category theory to solve FizzBuzz using compile-time type metaprogramming'.
- pjmlp 6y agoIt is also to note that features like closures and LINQ-like operations were already available in Smalltalk-80, which tend to be the most FP features used by average enterprise joe/jane developer.