Programming paradigsm

There are several programming paradigsm. Probably the 2 most populars are: OOP and functional. Today we want to add a different programming paradism called Automata programming.

This paradigsm is based on FSM (Finute State Machines) to describe Flow of states and actions to do between transitions.

It doesnt exist the best paradigsm. They need to be evaluated within the problem they try to solve. Then, It is important to choose the right paradisgm to resolve the specific problem.

Programming is a technique for which we are trying to model a problem in the real life. A specific paradigsm will be more suited for a problem if the charasteristics of the real problem are similar to the paradigsm. Another way to say this, is that The translation between Real live and Programming code is what makes it difficul. If this translation is minimal because the paradigsm fits the real problem, then it will be easy and readable to program.

• OOP: Suited for describing a considarable number of different type of Actors (Objects, Entities). For example we want to model a town with a PoliceMan, a Doctor, A Teacher...

Suited: We have names for Classes that represent business domain entities: Person, Account, Withdrawal... Code Smell: Most of the Object names dont identify Business actors: stateManager, serviceManager, pushSender... they are abstract tools to execute functions.

Suited for: Games, Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports. Data-driven business applications.

• Functional: Suited when the main problem to model is to do an action or to build something as a sequence of actions. For example process language, or data transformation.

Suited: When what we try to model are action or the build through steps rather than describing objects and their interactions.

Suited for: Critical systems with concurrency as mutation is reduced. Microservices (to do actions)

• Automata: Suited when the problem to model is a flow. Web flow, Operational process. Programming starts with the definition of the state diagram: State and events as functions connecting states. State diagram is a first class citizen.

functional

Jump, turn right, left, go ahead.

We can apply this to a car, a person, a cat.

Process:

1. map
2. splitInTwo.
3. processFirstSplit
4. processSecondSplit
5. Converge

The scope of the functional is to defined the Process rather than the actual feeding of data... execution of the process.

Feed process with data

@startuml functional
node verb
node data

verb <- data
@enduml

OOP

Here you have a car (noun).... you can operate it with these controls: start, brake, accelarate (functions = verbs)... you dont need to care about internal details (state = adjective)... engine... we try to hide these details and manage internally. For example, when going to high speed, we can change state so ABS brake is triggered more easylity when stepping into the break. In exceptional circunstances we can display a pilot led to indicate internal errors or exeptions to do certain operations. The control of the object (so indirectly the state where it is...) is left to the outside consumer, so somehow it needs to know the order of operations. For example, speed up will not work if we have not started the car. This is a difference with state diagrams where consumer does not need to know the order to apply controls. for example: A mechanical gear will be a OOP. The consumer could make a mistake to gear up from 1st gear to 4th gear. A semi-automatic gear will be a State Diagram implementation. The consumer interacts by gearing up() or down() but it cannot make a mistake of changing from 1st to 4th.

@startuml functional
node noun
node verb
node adjective


noun -> verb
verb -> adjective
@enduml

State diagram

The state diagram is the representation of an entity (draggable objet, traffic light, car gear (functions: up, down. state: first gear, 2nd gear,...)) as a collection of states and how they transition through events. We add another piece of information and it is the Context. The context describes important information we want to track about the entity (For example: General stats about traffic light like the number of colour changes in the last hour). The current event (not the context), and the transition to process (determined by the state diagram with event as an input) is enough information to modify the entity new value (the state) and to create a new version of the Context.

The transition to the state diagram is the main construct of the program. While in OOP the consumer handle/trigger the controls and indirectly the state... here we invert and it is the state diagram the one that controls the state and the consumer observe the change of state as reaction to events. Input events do not control the state directly and used instead to feed information that help the automata to decide the next state. The consumer sends dummy events (some of them will be considered and some ignored) and the automata dictates the flow back to the consumer. OOP is imperative to handdle the control, Automata is declarative. The state diagram represents the Ojbect representation.

Example 1: Traffic light

digraph G {
  graph [fontsize=18]; node [colorscheme=pastel19, fontsize=18];

  green [style=filled, color="3"]
  amber [style=filled, color="5"]
  red [style=filled, color="1"]

  init -> green [label="init"]
  green -> amber [label="timeOut"]
  amber -> red [label="timeOut"]
  red -> green[ label="timeOut"]
}

Example 2: Draggable object in a screen. The state diagram returns information to the consumer through the current state: dropped, dragging or through the context x, y position of the draggable object. The diagram is a construct that helps to filter out events that are no important as they dont change the current state (Context or state node). And reacts only to the important events that change Context or state node. This constructs avoid writing complicated "if" logic. The consumer sends events without specifying imperatively the effect in the state. The consumer is not in controls of the state. Consumer and State diagram are loosely couple. The diagram takes the event and adjusts itself.

digraph G {
  graph [fontsize=18]; node [colorscheme=pastel19, fontsize=18];

subgraph cluster0 {
  label="Context";
  "Object\nposition\nx:30\ny:30"
  }

  init [style=filled, color="3"]
  dropped [style=filled, color="2"]
  dragging[style=filled, color="4"]

  init -> dropped [label="init"]
  dropped -> dragging [label="clicObjectkDown"]
  dragging -> dragging [label="mouseMove"]
  dragging -> dropped [label="clickUp"]
}