Interesting take on the PLO - page 12

 
fxsaber:

I understand that it's a matter of habit and knowledge of syntax, but I find it very hard to get into the code, even though I am the author of the original.

Unfortunately, I can't use MQL in FP style. In brief, the following approach is exploited: there are offer conditions (PammSet) and there are functions that convert conditions into financial results (AccountRecord). Both types are invariant and set at creation. The task is to generate set of offers and compare each element of this set with financial result through mapping function (Set1, Set2, Set3). The key element is the SELECT function applying an arbitrary function like Func<in, out> to each element of the sequence.

 

Jacques Fresco on FP and PLO


 
And how is this FP fundamentally different from using function pointers?
 
Dmitry Fedoseev:
And how is it fundamentally different from using pointers to functions?

it is, it's just that FP has a more convenient syntax.

so much more convenient that the entire code architecture is based on it

for example, you could create a block that will receive a task that will execute when the mouse is clicked .... for example for the GUI.

and there you can batch the calls into a list and add the job to be executed quite simply

example

Button1.MouseClickAdd(() => (here is a link to our function in the style of Funk();))

in this case, such setting, namely the task, can be added by the user, who uses the code of our toolbar to configure his actions on the button....

in this case, the function's binding will be taken from the scope. i.e. a class can be added to anything. So, we are not adding the final result of the function, but the function that should be executed (called) when this condition occurs.

 
Dmitry Fedoseev:
And how is this FP fundamentally different from using function pointers?

FP is an implementation of lambda-calculus, and imperative programming (which includes OOP) is an implementation of the Turing machine.

 
Aleksey Nikolayev:

FP is an implementation of lambda-calculus, and imperative programming (which includes OOP) is an implementation of the Turing machine.

Makes sense)

 

I think we are discussing "flies and cutlets".

If FP is an awesome substitute for OOP, show me an example of GUI implemented in FP, not the above example

Кнопка1.MouseClickAdd(()=>(тут ссылка на нашу функцию в стиле Funk();))

but an example of the buttons, checkboxes, scrollbars, etc. - all made in FP.


imho, if FP helps simplify formalization and problem solving, so as not to create dependence ofC++ on linear code execution (from top to bottom) - fine! but discussing that FP is an alternative to OOP (which grew out of the procedural style), imho another comparison of hot and cold

 
Igor Makanu:

I think we are discussing "flies and cutlets".

If FP is an awesome substitute for OOP, show me an example of GUI implemented in FP, not the above example

but an example of the buttons, checkboxes, scrollbars, etc. - all made in FP.


imho, if FP helps simplify formalization and problem solving, so as not to create dependence ofC++ on linear code execution (from top to bottom) - fine! but to discuss that FP is an alternative to OOP (which grew out of a procedural style), imho another comparison between warm and soft.

Here exactly one does not prevent the other, but complements it.

And if you want, you can also create everything in FP like in OOP with Tyke's structure - although it's a very dubious idea
 
Alexandr Andreev:

This is where one does not interfere with the other, but complements it.

that's what I'm writing about

and the article from the first post of the thread, tries to compare two completely different, in terms of purpose, programming paradigms

 
Aleksey Nikolayev:

FP is an implementation of lambda-calculus, and imperative programming (which includes OOP) is an implementation of the Turing machine.

Exhaustive! I would not add more ))