The above is not a combinator. addSomething relies on the line x = 1 and is forever tied to it. You cannot reuse addSoemthing without moving x = 1 with it. Therefore addSomething is not modular. This is the root of organizational technical debt. When logic depends on external factors it cannot be reorganized or moved.
This is also a big argument against OOP because OOP is basically the same exact thing with a bit of scope around it:
class B()
x = 1
addSomething(y) = y + x
divideSomething ...
b = 3
Now addSomething can never be used without taking x=1 and everything inside B with it. It is less modular as a result.
A combinator is like this:
addSomething(x,y) = x + y
fully modular and not tied to state.
The point free style is a bit long to explain. Another poster brought up readability and now I think I went too far with it as a recommendation, it's like going vegan basically if you employ that style. Just stick to combinators and you get 99% of the same benefits.
Suffice to say the point free style eliminates the usage of all variables in your code. You are building just pipelines of pure logic without any state.
When you get rid of state as much as possible, your logic will not have any dependencies on state, and thus will generally be free of technical debt caused by logic being tied to dependencies.
This is also a big argument against OOP because OOP is basically the same exact thing with a bit of scope around it:
Now addSomething can never be used without taking x=1 and everything inside B with it. It is less modular as a result.A combinator is like this:
fully modular and not tied to state.The point free style is a bit long to explain. Another poster brought up readability and now I think I went too far with it as a recommendation, it's like going vegan basically if you employ that style. Just stick to combinators and you get 99% of the same benefits.
Suffice to say the point free style eliminates the usage of all variables in your code. You are building just pipelines of pure logic without any state.
When you get rid of state as much as possible, your logic will not have any dependencies on state, and thus will generally be free of technical debt caused by logic being tied to dependencies.