Interesting take on the PLO - page 12
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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 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.
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.
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
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 ideaThis 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
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 ))