Ovidiu Deac

A few weeks ago, I received from Ovidiu Matan the invitation to participate, from TSM, in I.T.A.K.E. I had been waiting for this event since autumn, ever since I had a conversation during IT Days with Alex Bolboaca about the "unconference" concept, which I found very interesting. I admit having been a little reserved, given the fact that a "Software craftsmanship" conference had been announced, a movement I do not really resonate with. However, in the program, there were also a few presentations regarding functional programming, and I was hoping to meet more people interested in this subject. Therefore, I didn't hesitate and I accepted immediately.

Functional Programming (FP) (https://en.wikipedia.org/wiki/Functional_programming) is an old concept developed in the 1950s when Lisp language was created. It has its roots in” lambda calculus”, a formal system in mathematical logic, first formulated by Alonzo Church in the 1930s (https://secure.wikimedia.org/wikipedia/en/wiki/ Lambda_calculus). The functions are the main element in FP. Programmers generally work with immutable data structures and pure functions. Functional languages usually provide a set of tools that make it easier to work with functions.

Known under the acronym OOP, the Object Oriented Programming was introduced in the ‘60s with the language Simula67. It's the paradigm used by most of the software shops. It is supported by the mainstream programming languages like Java, C#, C++, Python, Ruby. OOP is an imperative paradigm which means that the program describes the way the system state is changed during the execution. The system is modeled through classes of objects. Each class describes the state variables of its instances, their properties and the actions that we can run on them. Through encapsulation we hide the implementation details and this way the user of the class is only interested in the interface exposed by that class. This way we can model the world around us. It seems like a very natural approach but still there are a few major problems. The problems start from the fact that, except for the constant methods, all the member functions produce side effects because they change the state of the object on which they are called or the states of other objects they have access to. Most of the object-oriented code is written this way.