Today we had a guest lecture at the university for the course Information Security, that was given by a philosopher. It was very interesting, talking about the influence of technology on our lives and the implications that would have. But that’s for another topic.
One of the things it touched upon, was that humans are the creatures that are able to separate their consciousness from their body. (There might be other animals that can do this, but we don’t know) This, the ability to consider things from different viewpoints, has allowed us to plan ahead, overcome many difficult situations, and solve problems in a more general way than possible when not considering multiple perspectives.
I then realized: Maybe the different programming paradigms can be subjected to the same kind of reasoning:
Looking at it from this angle/with this analogy, it seems to me that the Actor-Model is the paradigm that allows us to solve problems in the most generic, adaptable way; i.e. solve the most problems.
I have other way to see it, but it would be hard to answer here.
I don’t know if you follow the Morning Paper by Adrian Colyer (do it, it is not hard to google) but he recently talked about the Liskov paper on ADT. There is one important thing here, it is that ADT are about the operations done on the data.
Basically, OOP come from Simula. Nothing else. Now OOP is mainly applying a hierarchical classification on tops of programs. It is about separating programs while staying in the same context. By definition, OOP is a 19th century taxonomy applied to programming.
FP… is not really that well defined anyway. Mainly because OOP should have never been separated from imperative anyway. And because it mix two differentway to look at code (dynamic homoiconic LISP like vs ADT Lazy point free pure Haskell/ML like).
Actor fit more in the SmallTalk/Lisp side because it is basically Closure running in isolation with an additional mailbox.
I hate to be contrary, but the very phrase “object oriented” was first said by Alan Kay, who designed the Smalltalk language (with much Simula influence, certainly). So I don’t think it’s fair to consider only the Simula heritage to define “OOP”. It’s not a common terminology, but I refer to the taxonomical approach as Class Oriented. Moving on …
How does your definition (or Adrian Colyer’s) of OOP mix both homoiconic LISP with lazy point free Haskell? Homoiconic and lazy and point-free are three things I never see in “OOP” (or class oriented) programs.
I know totally the history of the word OOP. And what i mean here is that the part of Smalltalk that made it mainstream are the one coming from Simula. Should we name the Actor model OOP because Hewitt got the idea from Smalltalk too ? And let not talk about how Alan Key himself keep yelling that what we got is not what he meant… I still use OOP as it means nowadays, but if we want to go in philosophy
My definition does not mix with OOP. There i point to FP as a whole. And i point out that the whole idea of putting together homoiconic and lazy have some ground but should not be pushed too hard either. They have fundamental different ways to answer some things.
In the end, i was mainly pointing that the links made between actor, OOP and FP on top were really limiting. I advise to listen to Liskov talk at the Heidelberg forum this year. While i don’t agree with everything, she point an important thing : in her ways to look at ADT, subclasses and a hierarchy of subclasses are useless and even probably overly complex.
Because ADT can work in any of these paradigm. ADT work well being in LISP late binding via ad hoc polymorphism or via typeclasses. They are, in a lot of way, orthogonal to the interpretor paradigms but more linked to the linker paradigm and the interface we define between our things. In OOP you put the operation into the object in itself while in FP it is the functions that got the definition of what they accept and their own different implementation. But for the interpreter, once it is linked, there is no difference.
Homoiconicity, Lazyness, Pattern Matching and Partial function application are all features that occur frequently in Functional Programming languages, but I believe most (all?) of them can be introduced in imperative or (Adrian Colyer’s) OOP-style languages (which are usually very imperative as well), although it might be hard. (So I diagree with you on this, @gregvaughn; while it might have less benefits to port these functionalities to non-FP languages, I believe it to be possible.)
I think these features distract from the -in my opinion- core concept of Functional Programming: Immutability.
Abbreviated: In Imperative languages (and most (Colyer-style) OOP languages), executions happens by mutating the state of the things you have. A variable is a ‘box’ that you put something in, which is then changed at a later time. This means that you can never be sure what a variable actually contains. In these languages, Identity ≡ State.
In FP, variables are just ‘names’ we give to a data structure, and then it will never change. A new state is the result of a function called on the old state. This means that Identity ≠ State; instead, an Identity has a state. This means that you do not have to be afraid of the floor changing under your feet, as in the current scope (regardless of what is going on concurrently), the value that a variable refers to will never change.
I think that immutability is the important aspect that FP has, which allows you to easily build predictable(and therefore maintainable, concurrent, etc.) applications.
For me Actor-Model is type of Concurrency Mode from book Seven Concurrency Models in Seven Weeks. You can use Actor-Model using OO language as Functioanl langauge.
@mkunikow yes, you are totally right. I had’t considered languages like e. g. Pony, which attempt to combine OOP and the Actorr-Model.
I am very interested to hear about the other ways of doing concurrency. Besides the Actor-Model I knoe of State-Transactional Memory (keep a log of read/writes, when a conflict happens, revert and reread) and plain ol’ Mutex-land with all headaches that come with it. What are the other three?
Well the thing is, if you remember “Why FP Matters?” by John Hughes, the answer of the “special” thing of FP is higher kind functions.
And no, you can’t import that into OOP easily, because if you can do that, why even have object, if your functions can be independant ? You reach the good old problem that Java is dealing with these days (and Go too) with primitives and object reacting differently.
You can totally do an imperative language with immutable data. It is doable. In a lot of way, that is what things like Rust allow you to do … OK Rust is stealing a lot from FP. In a lot of way, ZFS in itself is doing that with CoW, or Postgres with their CoW too.
The thing i was pointing with Colyer is more that he mix polymorphism with objects
The important thing is the glue that functional give us. Now in Elixir/erlang, functional was chosen mainly because it was more declarative and because the only way to do proper message passing is through copying. So immutable data make sense. The higher kind of functions were essential to produce actors, because they are just a closure spawned independently.
But there is no currying nor lazy evaluation because Erlang was not meant to be a functional language. It just happened to be the way to implement the “share nothing, message passing” way.
