OfficeFloor is now available to develop within IntelliJ.
While the plugin was originally developed for Eclipse, we have now isolated the functionality into IDE agnostic bundle. This means with a bridging implementation, it is possible to port the OfficeFloor plugin to other IDEs.
However, for now we are content with Eclipse and IntelliJ for OfficeFloor development.
Though if you would like to see OfficeFloor development supported by other IDEs, please get involved!
IntelliJ OfficeFloor Plugin is available at https://plugins.jetbrains.com/plugin/13151-officefloor (and in the IntelliJ Marketplace - when using latest IntelliJ version).
Inversion of Coupling Control
Wednesday, 16 October 2019
Tuesday, 10 September 2019
Inverting Functions: Effect Thread binding for Stateless Actors
Functional programming can be perceived as "hard". Yes, spend time with it and it gets simpler and the benefits make your code definitely better. However, when type errors can start spanning multiple lines, it does suggest the abstract concepts may be "hard" to see clearly.
We really need to make it easier for junior developers to assist in functional programming of larger systems.
Now as functional programming pulls heavily on mathematics, I look to a prominent mathematician's early 1800's statement regarding getting better clarity on hard problems:
What I understand Carl Jacobi was saying is that invert the problem for a different perspective to try and get an answer. Therefore, maybe in inverting functional programming we can get clarity on making it perceived as "easier".
So what can we invert about the function?
We invert the coupling.
I've written about Inversion of Coupling Control in object oriented paradigms. This is even to the point of identifying the OO Matrix. In summary, there are 5 couplings of the method that restrict us:
The function suffers similar coupling. Ok, the exceptions are not thrown but returned as values. However, changing the function's return type, name, parameters, executing thread requires changing all other functions calling that function.
Now beyond concurrency, Actors provide means to isolate the coupling impact of these changes. As long as the messaging semantics between Actors does not change, the Actor is free to change all its internal functions as it sees fit. This isolates the impact of changing a function to just the Actor.
So I have to ask. Functional programming is appearing in many mainstream languages. Furthermore, we've now been moving to multi-threaded programming for some time now. So why aren't Actors also becoming more prevalent?
For me, the reason is the Thread binding in the Actor is to State rather than Effect. This to me makes use of Actors difficult.
My reasoning comes from these observations:
Therefore, what I see in Actor modelling is the following relationship:
Furthermore, developer resources are scarce and we need a way for junior developers to assist in building systems. Yes, there is a beauty and satisfaction in building a finely tuned system that fits together like clockwork. However, businesses don't really want to keep building expensive finely tuned watches just so customers can tell the time. We need to make things easier not harder.
Hence, that's why I believe we need to invert the function to create a stateless Actor with focus on mapping Threading to Effects. Details of how this can be achieved is available in the following articles:
What this achieves is the following:
Simplifying this down:
Hey! Effect was just removed!
Yes, because we don't really make the mapping decision of Thread to Effect. We make it based on the nature of the Effect - blocking / long running. The Effect encapsulates this so we don't really know whether we are just quickly updating internal memory or making a blocking I/O interaction.
We make the Thread mapping decision based on the resources used by the Effect. If the Effect requires a database connection, it is likely to be making blocking SQL calls. If the Effect requires a HTTP Client, it is likely to be making blocking HTTP calls. If, however, the Effect only uses non-blocking resources, it is very unlikely to be blocking.
Now if we extract out the Thread from the above Actor, we get:
The junior developer is now free of threading to write the ActorEffect.
Later a senior developer is able to make the correct mappings of Thread to ActorEffect. This is because the determination can be made by the resources (whether blocking or not) used by the ActorEffect.
Furthermore, the ActorEffect can be written just as a function with State passed in. This makes the ActorEffect stateless so the junior developer is not involved heavily in thread-safety.
The ActorEffect is now able to be written by the skill level of the junior developer.
There are further improvements on the weaving together of the ActorEffects. The following article provides working code of how junior level functions can be weaved together with threading configured separately afterwards:
Weaving together functions (and other paradigms)
We really need to make it easier for junior developers to assist in functional programming of larger systems.
Now as functional programming pulls heavily on mathematics, I look to a prominent mathematician's early 1800's statement regarding getting better clarity on hard problems:
"Invert, always Invert", Mathematician Carl Jacobi(though he was German, so it was actually "man muss immer umkehren")
What I understand Carl Jacobi was saying is that invert the problem for a different perspective to try and get an answer. Therefore, maybe in inverting functional programming we can get clarity on making it perceived as "easier".
So what can we invert about the function?
We invert the coupling.
I've written about Inversion of Coupling Control in object oriented paradigms. This is even to the point of identifying the OO Matrix. In summary, there are 5 couplings of the method that restrict us:
- Method Name
- Varying number of parameters
- Varying number of exceptions
- Return type
- Executing thread
The function suffers similar coupling. Ok, the exceptions are not thrown but returned as values. However, changing the function's return type, name, parameters, executing thread requires changing all other functions calling that function.
Now beyond concurrency, Actors provide means to isolate the coupling impact of these changes. As long as the messaging semantics between Actors does not change, the Actor is free to change all its internal functions as it sees fit. This isolates the impact of changing a function to just the Actor.
So I have to ask. Functional programming is appearing in many mainstream languages. Furthermore, we've now been moving to multi-threaded programming for some time now. So why aren't Actors also becoming more prevalent?
For me, the reason is the Thread binding in the Actor is to State rather than Effect. This to me makes use of Actors difficult.
My reasoning comes from these observations:
- Actors encapsulate changes to State to make this thread-safe
- Effects can wrap changes to State (whether internally in the system or externally)
- Multi-threading provides more efficient execution of blocking Effects (such as I/O) *
- Threading is configured to the Actor
Therefore, what I see in Actor modelling is the following relationship:
Thread (pool) -> Actor -> StateWhen it should actually be:
Thread (pool) -> (Blocking / Long running) EffectIn attempting to get the right break down of the system into Actors, we have to simultaneously:
- Consider an Actor an Effect to assign it the appropriate Thread (pool)
- Decompose State of the system into these arbitrary Actors
Furthermore, developer resources are scarce and we need a way for junior developers to assist in building systems. Yes, there is a beauty and satisfaction in building a finely tuned system that fits together like clockwork. However, businesses don't really want to keep building expensive finely tuned watches just so customers can tell the time. We need to make things easier not harder.
Hence, that's why I believe we need to invert the function to create a stateless Actor with focus on mapping Threading to Effects. Details of how this can be achieved is available in the following articles:
What this achieves is the following:
def Actor(m: Message, s: State, t: Thread): Array[Effect]
def Effect(r: Resource): AlteredState
Simplifying this down:
def Actor(m: Message, s: State, t: Thread, r: Array[Resource]): AlteredState
Hey! Effect was just removed!
Yes, because we don't really make the mapping decision of Thread to Effect. We make it based on the nature of the Effect - blocking / long running. The Effect encapsulates this so we don't really know whether we are just quickly updating internal memory or making a blocking I/O interaction.
We make the Thread mapping decision based on the resources used by the Effect. If the Effect requires a database connection, it is likely to be making blocking SQL calls. If the Effect requires a HTTP Client, it is likely to be making blocking HTTP calls. If, however, the Effect only uses non-blocking resources, it is very unlikely to be blocking.
Now if we extract out the Thread from the above Actor, we get:
def ActorEffect(m: Message, s: State, r: Array[Resources]): AlteredState
def Actor(e: ActorEffect, t: Thread): AlteredState
The junior developer is now free of threading to write the ActorEffect.
Later a senior developer is able to make the correct mappings of Thread to ActorEffect. This is because the determination can be made by the resources (whether blocking or not) used by the ActorEffect.
Furthermore, the ActorEffect can be written just as a function with State passed in. This makes the ActorEffect stateless so the junior developer is not involved heavily in thread-safety.
The ActorEffect is now able to be written by the skill level of the junior developer.
There are further improvements on the weaving together of the ActorEffects. The following article provides working code of how junior level functions can be weaved together with threading configured separately afterwards:
Weaving together functions (and other paradigms)
Therefore, it is now easy for junior developers to assist in building large functional applications. With the use of Prototype Threading by IoC, this is potentially to millions (even billions) of stateless Actors scattered across thousands of underlying physical machines. But the ease of writing small functions remains for the junior developers making it easier for them to be involved on large scale projects.
And thus I ask, whether in attempting to improve functional programming by finding even more niche and complex mathematics is the right way forward? Or do we follow Carl Jacobi's advice and invert, always invert!
Friday, 9 August 2019
What is The OO Matrix?
Morpheus: I've seen an agent punch holes in designs with only a single dependency. Developers have fought against them with APIs that resulted in nothing but limitations. Yet their strength and their speed are still based in a world that is built on coupling. Because of that, they will never be able to write as simple or as fast code as you can.
Neo: What are you trying to tell me, that I can design objects for easy refactoring within applications?
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't have to.
Take the red pill. Read on and I show you how deep The OO Matrix goes...
In my opinion, The OO Matrix is what happened to Object Orientation when the interfacing of objects devolved to the method.
As per my other article Inversion of (Coupling) Control, there are 5 caller coupling aspects to the method.
However, objects interacting via methods have very different shapes. The variability of the method coupling has objects look a lot more like jigsaw pieces. The connectors are not simple lines, but complex methods that shape the object differently:
Piecing these method interfacing objects together forms a rigid jigsaw. This rigid jigsaw is difficult to refactor due to all the coupling. The result is The OO Matrix:
With the birth of Java in the 90's and the ratification of the C++ standard in the same decade, "it is not without a sense of irony" that the Matrix film came out about the same time we locked ourselves into programming within The OO Matrix. Some of us may sense it's existence with refactoring frustrations, while others grew up in it knowing no difference.
The OO Matrix exists all around our programming coupling us to the machine. If we consider:
And really, where in the real world do we find a thread stack? Object Orientation was derived from chemical reactions. Businesses operate in message passing (e.g. emails and documents). Even my understanding of our brains is built on message passing. In other words, thread stacks are a machine based construct. Using the thread stack derived method for object interaction binds us into the machine - The OO Matrix.
See my other articles on First-Class Procedures and Local Microservices about how we can break free from The OO Matrix. These articles demonstrate using messages to interface between objects (i.e. single parameter unnamed methods). This breaks us free from the method, the thread stack, and subsequently freeing our code from machines - The OO Matrix.
Well, this is how I like to describe it - as it's a pretty dry topic otherwise!
But I certainly cry about all those hours (if not days/weeks) of refactoring code in my life due to the method coupling problem. Especially, as if we followed Alan Kay's vision of focusing on message passing, this should never have been a problem. And to me, this may actually be a more expensive mistake than null.
Neo: What are you trying to tell me, that I can design objects for easy refactoring within applications?
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't have to.
Take the red pill. Read on and I show you how deep The OO Matrix goes...
In my opinion, The OO Matrix is what happened to Object Orientation when the interfacing of objects devolved to the method.
As per my other article Inversion of (Coupling) Control, there are 5 caller coupling aspects to the method.
- Return type
- Method name
- Variable number of parameters
- Variable number of exceptions
- Executing thread
However, objects interacting via methods have very different shapes. The variability of the method coupling has objects look a lot more like jigsaw pieces. The connectors are not simple lines, but complex methods that shape the object differently:
Piecing these method interfacing objects together forms a rigid jigsaw. This rigid jigsaw is difficult to refactor due to all the coupling. The result is The OO Matrix:
With the birth of Java in the 90's and the ratification of the C++ standard in the same decade, "it is not without a sense of irony" that the Matrix film came out about the same time we locked ourselves into programming within The OO Matrix. Some of us may sense it's existence with refactoring frustrations, while others grew up in it knowing no difference.
The OO Matrix exists all around our programming coupling us to the machine. If we consider:
- the method represents pushing/popping state on/off the thread stack
- the thread stack represents execution by machines
- then designing interfaces based in methods is binding us to the machines
- and as such we perpetuate The OO Matrix
And really, where in the real world do we find a thread stack? Object Orientation was derived from chemical reactions. Businesses operate in message passing (e.g. emails and documents). Even my understanding of our brains is built on message passing. In other words, thread stacks are a machine based construct. Using the thread stack derived method for object interaction binds us into the machine - The OO Matrix.
See my other articles on First-Class Procedures and Local Microservices about how we can break free from The OO Matrix. These articles demonstrate using messages to interface between objects (i.e. single parameter unnamed methods). This breaks us free from the method, the thread stack, and subsequently freeing our code from machines - The OO Matrix.
Well, this is how I like to describe it - as it's a pretty dry topic otherwise!
But I certainly cry about all those hours (if not days/weeks) of refactoring code in my life due to the method coupling problem. Especially, as if we followed Alan Kay's vision of focusing on message passing, this should never have been a problem. And to me, this may actually be a more expensive mistake than null.
Subscribe to:
Posts (Atom)